Book review

This book addresses those parts that other testing books do not reach: the people and political realities of the life of the software tester in the current highly pressured corporate world. It is easy to read, small enough to carry with you (202 A5 pages), but is packed with practical down-to-earth advice.

There are two different types of skills needed by testers. The "Tester 1" skills are technical, knowing what and how to test, planning and performing tests. This book is about the "Tester 2" skills: negotiation, communication, psychology, marketing and being a politician inside the workplace.

The book begins with a self-assessment test and concludes with a Plan of Action chapter, containing sensible advice about what can be changed and how to do it.

Each of the ten challenges has its own chapter (10 to 18 pages) in a standard format: overview, state of the practice (usually a real life story), impact on testing, solutions to the challenge, solution impediments, guidelines for success, and plan of action. There are a number of amusing and appropriate quotes scattered throughout the book.

There isn't a lot to criticise with this book. Because the book is small, it does not go into a lot of detail and sometimes tends to gloss over the problems or propose slightly simplistic solutions.

It makes the assumption that the current state of testing practice is rather poor and immature. Unfortunately, although I wish it wasn’t true, it probably applies to the majority of organisations. The use of tables is perhaps slightly over-done, but not too excessive. The tools advice is particularly weak.

Here are the challenges, presented as in the book in reverse order.

10: Getting trained in Testing.

This chapter addresses the "anyone can be a tester" mindset, and discusses essential and optional skills for different types of testers and how they can be acquired. Solutions include raising management awareness, making time for training, developing your own skills, and becoming certified (a US scheme is mentioned; the BCS ISEB scheme did not exist then).

9: Building relationships with developers.

A story illustrates how an adversarial attitude can be harmful to progress as well as to morale. A number of constructive suggestions show how to get to a "win-win" situation through co-operation and constructive criticism.

8: Testing without tools.

This chapter is rather naïve, especially with regard to capture/replay tools. It even reproduces benefit charts from a tool vendor. The list of tool types includes the usual testing tools, but also checklists and flowcharts. However, tool support is needed in testing, and there is some sensible advice given. (See information about the new test automation book in this newsletter).

7: Explaining Testing to managers.

Managers often do not understand what testing can and cannot do. Poorly managed testing is ineffective and inefficient, normally stopping when the deadline arrives, rather than based on facts and well-defined results and processes. Political advice includes identifying high level management stakeholders.

6: Communicating with customers and users.

If the goals and objectives for the system are not agreed and understood by customers, users, developers and testers, the system may be unusable or give no or negative business benefits. Solutions include understanding each role and when and how to communicate (Examples include "Keep talking even it means disagreeing", "Don’t confuse meetings, memos and e-mail with communication").

5: Making time for Testing.

Sometimes testers are expected to test everything, either by their managers or even of themselves. Tests should be based on measurable requirements, risk analysis should prioritise tests, and tests should be re-used for efficiency.

4: Testing what's thrown over the wall.

This syndrome is a symptom of poor communication and can be very wasteful. A defined test process and standards are needed, and knowing who is responsible for what testing. Training and measurement of results are also important.

3: Hitting a moving target.

Most people now live in a world where technology not only enables but also encourages rapid change, which is often not well controlled. Yet testing is expected to fit into restrictive time-boxes without compromising the quality of the testing. Solutions include designing testware to cope with changes, automating regression tests, and change and release management. There is a useful table to identify the "people impact" of changes.

2: Fighting a lose-lose situation.

This chapter describes a project where the test manager continually reported serious defects for months. The final recommendation when the release date arrived was not to ship until the most serious defects were fixed. However, the marketing director over-rode this advice with the justification that users would tolerate bugs and if they didn't release now a competitor would steal market share.

The release was a disaster; support staff were swamped, shares fell and users threatened to sue. The test manager was then called into the marketing director’s office. Instead of being told "Sorry, you were right," the question asked was: "How could you let this product ship with so many defects?" (The test manager replied, "I didn’t, you did, I quit"). Solutions include communication, definition of roles and setting expectations.

1: Having to say no.

It is difficult to be the bearer of bad news. Testers tend to deal with the discomfort by informal or irregular reporting, being subjective rather than communicating objective facts, or down-playing the negative.

Sometimes testers go to the opposite extreme and become overly negative. The solutions include defining regular and factual test reports as part of the defined test process, managing expectations, and using charts and graphs. It is important to tell the truth.

This book fills a gap in current testing literature by addressing the types of problems that are experienced in real life by software testers. Any tester or test manager will identify with at least some of the challenges and will be likely to find helpful advice.

Review by Dorothy Graham, Grove Consultants