Modernizing The Five Phases of a Software Tester’s Mental Life

Boris Beizer (1934–2018) was a computer scientist mostly known for introducing the five phases of a software tester’s mental life. In his book “Software testing techniques” (1983, 2nd ed. 1990), Beizer introduced the five phases, which may be summarized as follows.

Phase 0 represents the mindset of many new learners of programming and also a large faction of seasoned programmers who have never participated in larger development projects. Print-line debugging is a common technique used by programmers in this phase. Setting breakpoints and inspecting variables is a slightly more advanced method often used by developers with a phase 0 mindset.

Testers in phase 1 write tests to show that the software works as intended. These tests typically focus on “proving” that the requirements are fulfilled by the code base, i.e., that it works as it was intended. In this phase, testers are wearing “blinds” and usually don’t see the corner cases causing the software to fail. For example, testing a web shopping cart with a negative number of items — who would be stupid enough to enter that, right?!?

In phase 2, the tester has realized that most bugs loom in the corners of the code, i.e., the branching paths less traveled. Here, unexpected effects arise which are caused by feeding abnormal data to the program. This is a swing to the other extreme of the mindset of phase 1. The danger here is that the intended functionality may be poorly covered by tests. Another danger of phase 2 thinking is that it may result in a tug-of-war between testers and developers. In such a scenario, testers want to prove their worth by developing increasingly complex tests to find more and more obscure bugs. In contrast, the developers focus on creating a shippable product, which may be hindered by eager testers who just want to add another test before we are done. A poisonous work climate may arise where the testers will never be able to approve the quality of the product as they have the responsibility for any errors in the shipped code. To some extent, this also shows that Beizer’s original thinking dates back to the eighties. Back then, software was shipped in a box and not fixed afterwards, which is no longer true in most cases except for some forms of embedded code.