Author: Gerald Weinberg (1933-2018) | Published: 2008 | Pages: 182| Amazon Link
For over half a century Gerald Weinberg worked on transforming software organisations, particularly emphasising the interaction of technical and human issues. After spending the 1950 and 60s working within various roles as a software developer at companies such as IBM and Nasa, his focus switched to consulting.
In this book. Gerald Weinberg sets out to dispel fairly common misconceptions about testing and testers. This book was written well over 10 years ago and at times it does feel like it was written during a time when testers had to fight a lot harder for their place at the table. Having said that, his vast experience does shine through on every page and its a relatively short book that everyone working within the field of software should read.
The author, with his vast experience in life, has a wonderful way of discussing testing in a much broader sense than just software testing. Testing is something that is in our very nature as intelligent beings. Many of the decisions we make, large or small in our daily life are a result of testing out the waters. In a similar vein to what we do as software testers, if the ramifications of a decision are greater we tend to focus more on those areas. This relates extremely well to the risk-based decisions we take when testing software.
An unusually large portion of the book was dedicated to exploring the reasons why testing is necessary within modern software development, as a tester myself I felt most of what was discussed was straightforward and obvious but I can definitely see how it can be of benefit to those who do not appreciate the importance of software testing. whilst excellent real-world examples where given, they often felt like there where from a by-gone era.
Understanding the tasks that go into testing
The work that often goes into debugging, finding pattern and reproducing issuesis very often overlooked
This is something that most testers will know about first hand but could be an eye-opener for project managers and even some developers.
The work that often goes into debugging, finding pattern and reproducing issues is very often overlooked. This can often be compounded due to how difficult it can be to timebox these events. It has to be a matter of risk vs reward and the decision you take can bite eater way, I have found its just something I have gotten better at with experience, by making the wrong decisions as well the right decisions.
Testers, will very often lose large chunks of time task-switching. Re-testing a critical bug that has just been fixed but was reported weeks ago can often take longer to fully test than anyone would expect. Issues can arise when team members are not taking this time cost into consideration. It also raises questions of the tester whereby they must prioritise tasks as well as communicating this to the wider team.
Testing is sampling
When choosing what to tests, we must be aware of biases including our own
This covers the often misunderstood idea that you can’t test everything but it does this quite eloquently by giving excellent examples that gave me food for thought even though I have been testing for the best part of 10 years. As testers we obviously understand the limitations this can present but I feel it helps those who may be expecting something different from testing.
When choosing what to test, we must be aware of biases including our own, we may be more comfortable with a particular area of the product and end up focusing more in an area with inherently less risk, this can also be true of an area that another team member may be strangely attached to, or a developer may be fond of.
As testers, I think it is vitally important that we understand our time is limited with regards to testing the whole system so it becomes paramount we make informed decisions with which to focus our testing on whilst also accepting bugs will be found.
Testing does not fix things.. or does it?
One area that the author was often keen to point out was that testing does not improve a product. Although I do agree with this in the literal sense; a tester does not write the code that will make any changes to the application, the act of testing a product can often be much more than just identifying bugs. The experience I have gained over the years, I feel has put me in an excellent position to suggest improvements that may not even be part of the requirements. Although some may feel that this falls outside of the role of a tester, the collaborative role of modern agile teams requires everyone to test, so why then can testers not offer suggestions or ideas about the product design.
I agree that during a time when collaboration was not high on the agenda then it would have been highly unlikely that any amount of testing would have improved a product, and highlighting that point would have been extremely important for a tester.
The role of Testing In an Organisation
There is a heavy focus throughout the book on clearly outlining the benefits of testing within an organisation, those reading the book who are not testing and carry that mindset will no doubt benefit from the examples given, that clearly illustrates the importance of testing.
Times were slightly different leading up to 2008 when the book was published, and as a result, there is a focus throughout the book on the worst possible scenario. I am not one to say that these scenarios do not exist but there are more and more opportunities out there over a decade later where these issues are less prevalent, and my advice would be to avoid jobs where these situations are present, as opposed to upskilling in an area that is mostly only relevant in those difficult situations. the fight for relevance is definitely less of an issue in the companies most people would prefer to work with these days.
A Tester’s role within a team
our job is to make meaning of information and determine its significance
Gerald was working in the field of software before even my parents were born and his experience was vast, extremely vast. A fairly large chunk of this book is dedicated to the soft skills that can help a tester get their message across.
Although barriers amongst testers and developers are less of an issue in an agile world, I still feel there is enormous value to be had by being prepared for all outcomes including the worst with regards to delivering information as a tester, by its nature, you will more often than not be delivering bad news, bad news on someone’s code or even bad news further up the chain. Information in itself is neutral, its people’s reaction to that information that has to be managed, and as testers, we must understand that.
Humans naturally develop immunity to what they perceive as threatening information. This can present itself as denial or repression. These reactions can often be unconscious. I think it the job of the tester to be aware that this reaction is natural and you would quite possibly react in a similar way. Building a good relationship with other team members can often be more critical for testers as you will often need them to act on the information that you will be providing. Its also within our power to make things considerably worse by pointing fingers and criticising the work of team members.
Any piece of software that we test, will be providing us with constant feedback while we test it, what it does well, what it does not so well etc. It then becomes our job to make meaning of that information and determine its significance. Spending the time to debug an issue will very often make a massive difference when presenting it to a developer.
On reflection, I feel there were times whilst reading this book that maybe I had been too critical of the ideas presented. I had to take a step back and realise it was published over a decade ago and was not just for testers, but numerous individuals within a software project team.
The examples presented were extremely relatable and fit the ethos of the author, which was to bridge the gap between the technical and the human. Each chapter concluded with a section on common mistakes followed by a very good summary.
Overall I feel it’s a short enough read to get through in a week or so and for the time you put in there are huge benefits to be had. Gerald Weinberg uses his vast experience in the field of software to distinctly clarify a number of key questions that have been around since the dawn of software, just don’t expect anything too groundbreaking.
Thanks, Gelard for all your efforts (1933-2018)