Testing as Cultural Activity
Jeffrey Zaayman
on 27 September 2022
So, you have decided to embrace shift-left or even start with more exciting technologies like TDD (Test Driven Development). Perhaps now you think you no longer need testers? Before you throw your testers away, we suggest you stop and rethink their value first. The knowledge and experience embedded in each tester’s head still makes them invaluable to your new way of working. Let me explain why you should see Testing as Cultural Activity.
Co-writer: Dave van Stein.
For a long time, testing was done by either developers or beta users of a system. This changed at the end of the previous century, due in part to huge programs like the y2k problem and the introduction of the Euro. Suddenly, testing became a separate phase in software development with its own frameworks like TMap and ISTQB. The main job of testers was to identify that the developed software behaved as described in the requirements. However, testers became active quite late in the development lifecycle, as they needed running software, which resulted in problems only becoming visible at the end of the delivery cycle. Since most of the time testers were also not involved in the earlier stages (e.g. requirements analysis), this resulted in a highly inefficient situation where testing consumed a lot of time without providing the desired level of quality. It also gave testers a bad reputation, as they typically caused a lot of late rework (introducing new problems), which in turn caused delays and resulted in projects running out of time. In the beginning of this century, a lot of effort went into test automation, in order to make testing more scalable and faster. However, most of the early automation tools were nothing more than “record and replay”, making them flaky, brittle, and requiring a lot of maintenance. Being a tester back then was more about creating bug tickets than about being a heroic guardian of quality. Testing as Cultural Activity, hmm, not sure yet.
Improving software development is not something that came out of the blue. Ever since the early 80s, we already started thinking about how to apply lean philosophy to software development, resulting in things like rapid application development and, later, Agile. The idea was that early testing would increase the quality of your product, and testing went from a role to an independent activity that everybody in the team needed to contribute to. The role of a tester therefore changed completely. No longer were they dedicated specialists responsible for a single phase of a project, but rather experts in an aspect of software development. Nowadays, we tend to refer to that as the shift left movement.
Like many things in Agile, this change in the approach towards testing resulted in many misconceptions or downright falsehoods. If testing was no longer a separate phase, did that mean it was a specialty? If everybody is testing, is testing even an expertise? If testing is completely automated, do you still need testers?
This caused a huge rift in testing and quality assurance. On the one hand, people (like Kent Beck) were changing the philosophy towards software development by stating you should start by writing requirements into tests and adjust your code until it passed the tests. Next to that there was a huge boost in the test automation community with the rapid maturation of continuous integration tooling. On the other hand, a large part of the testing and quality community advocated that testing requires a certain mindset and is not an acquired skill, and therefore you cannot completely get rid of testers.
Good testers are not mindless drones blindly clicking through the UI. They must understand the interactions between multiple systems (think integration) and the business logic and behavior of the product. While development teams may each focus on their specific components, testers must have a holistic view of the product. Because of this knowledge, testers also think of clever ways to push the software to its limits, often weeding out unusual edge cases that developers (even those employing TDD) did not think of. Testing is not a role; it is a mindset and a valuable skill.
Another value of testers is their communication skills. Testers must extract the behavior of the system from developers who, let us face it, are not renowned for their communication skills. At the same time, most testers can extract important requirements from conversations with end users, who are often not able to specify them in technical detail. A tester’s innate mindset of questioning everything all the time is a great asset when it comes to identifying and weeding out biases and assumptions.
So, when you add these all together, what do you get? A valuable resource for your TDD / shift-left methodology. Testers are often seen as second-class citizens and antagonists to the developers. This is simply not true; they are underutilized and the unsung heroes of software development.
Instead of letting testers go, shift them left. How can this be done? What exactly does that look like?
Testers can contribute to a project before a single line of code has been written. They already know how to think in an integrated way, so why not have them design the integration tests? They can think of all the ways a user may interact with the software that a developer cannot even begin to imagine, so let them help write the TDD tests. Plus, having testers involved at such an early stage ensures no one can gloss over or simply forget about tests. Also keep in mind that some things are just hard to test with automation (think exploratory testing or business logic testing).
You could even involve testers in the development of the software by having them pair with developers. A tester would be able to define much better tests and ensure that TDD is done correctly. Does the sentence “Testing as Cultural Activity” makes sense already?
At a higher level, they already know how to hold the entire system in their heads. This gives them a good insight into the inter-system interactions. You could even let them be part of the design and definition of the system. Remember that testers think across software components, their way has always been to bridge silos. Their approach towards specifying requirements and reducing complexity make them valuable for backlog refinements and refactoring sessions.
Testers bring more to the table than just clicking through the UI at the end of the development process. Their unique skills and insights can supercharge your shift-left journey and ensure you have solid, reliable SDLC. Don’t throw them out with the bathwater. This is why you should see Testing as Cultural Activity.