10 years of testing - from covering your ass to accelerating feedbackloops

10 years ago, I started as a tester. During my higher vocational education, I heard an advertisement on the radio about a company called Getronics that was looking for recent graduates to train them in the field of testing. I was hired and, together with nine other young, newly graduated computer science students, I attended the testing masterclass where we were drilled in the theory of TMap, critical thinking, and what it means to work as a tester. My first assignments were silo-oriented. Large test teams of more than 10 people. The developers were housed on a different floor, and communication was mainly done through a defect tracking system. I remember we registered the 10,000th defect for an application. Sausage rolls for the testers, plus champagne, as it turned out the defect tracking system couldn’t handle more than 9999 defects. As a tester, you took pride in finding errors or providing a quality recommendation by counting test cases, whatever such a quality or release recommendation might be. Writing test plans, which were mostly to cover yourself, setting boundary conditions, and especially formulating clear entry and exit criteria so everyone knew where they stood. Because of the V-model.

RUP (Rational Unified Process) made its appearance. Massively adjusting templates, massively creating artifacts. I think I still have a RUP certificate somewhere. You also saw testers developing certain expertise: Web tester, SAP tester, SOA tester, and later Cloud tester, which made you quite special. Test tooling and test automation became increasingly important, or at least, more experimented with. We did test automation, but was it successful? There was little to no alignment with developers, record & playback tools that supposedly could do everything and made everything easier. The manufacturers promised the moon, and the tools themselves cost a fortune. Cool, an automated test set that ran for 25 hours, if it even worked with flaky or brittle tests because there was a great dependency on the test infrastructure and test data.

Agile came, no, really Agile didn’t come, Scrum came, and with it, we thought we were being Agile. All over the country, silos were transformed into scrum teams. A good development because suddenly you were really sitting next to the analyst or developer. You picked up things about other disciplines, and as a tester, you had a more direct influence on designs, for example. Today, every tester is an agile tester, agile test coordinator, or even agile test manager. I don’t understand the last two, and I still struggle with the first one. What exactly is an agile tester? A tester who is in a scrum team? What makes a tester truly agile? I deliberately poke fun at it because I still see so many (agile) testers around me who pick up their TMap book and distill test cases from the test basis – formed by a ready team before the sprint starts – and thereby do bi-weekly waterfalls. We really struggle to deliver a potentially shippable increment because many organizations and scrum teams are not yet ready for it. Why is that? Because I think we still do not collaborate enough and are not multidisciplinary enough. Additionally, having an ISTQB and/or TMap certificate is a requirement for almost all testing vacancies, both permanent and contract. This while there is far too little attention to Exploratory Testing in these two methodologies.

Test automation has become so important that we have a shortage of test automators. Everything revolves around Selenium, and companies are emerging that focus on technical testing and only provide test automators. In marketing, we call it ‘automated testing.’ By the way, I’m looking for someone who can explain to me what automated testing is. Haven’t we all created a skewed testing world? Testers who can’t automate and automators who can’t test? Why do we make such a big distinction between the tester and the test automator?

Now, 10 years later, two owner-occupied houses later, two employers later, now married, and regularly finding a gray hair in my sideburns (by the way, no relation between the last two), I wonder if the changes we see now in the testing field are an evolution or a revolution. As I outlined above, the evolution has always been there in terms of technology and development methodologies. Testing, itself not a trendsetter, has always neatly followed the trends in the market.

Now I really see the testing world changing. For eight years, I could easily keep up with the knowledge I gained during my testing masterclass. The nature of testing tasks slowly changed with the market. But now, now there’s something peculiar happening in the market. Developers are becoming increasingly aware of quality, testing their delivered software better and better, and the speed at which Continuous Delivery and DevOps deliver software is phenomenal. It is the path to truly being Agile, and as a tester, you can no longer get by with your test cases, defect registration, and a heap of automated end-to-end tests via Selenium. At the end of the sprint, that potential shippable increment is really a requirement. Scripted testing is being replaced by examples we create through ATDD/BDD/SbE. Exploratory Testing is also a must, but unfortunately, there are not many testers who are really good at it. I can therefore recommend the Rapid Software Testing training to everyone. Great training! Everyone starts testing, even the developer who has followed this RST training and sets up an ET charter. Test automation? We no longer do that separately. ATDD/TDD are so embedded in the way of working that we get a proper implementation of the test automation pyramid. And we now call it check automation. And who realizes those automated checks with outside-in-development? The developers and no longer the test automators. How cool is that?! We get well-maintainable test automation code that is considered just as important as the production code. The end of the test automator?

Quality has never been so important because errors can cause great damage to the reputation of companies. This is more relevant now than ever, competition is greater than ever, and the time to market needs to be shorter than ever. The necessity of testing has also never been so great. The tester as we know it now will disappear, at least in environments moving towards Continuous Delivery and DevOps. A new role will emerge, call it the feedback engineer. This engineer will continuously collect feedback on whether the right product has been built, whether this product can add value at all. Whether the product is built in the right way, at the right time, and will also establish through monitoring whether it actually adds value in production. I really see this as a very different interpretation of the testing field than the previous changes. As far as I’m concerned, it’s a revolution, and not everyone agrees with that, let alone is happy with it.

The strange thing is that it seems as if this revolution is not or hardly supported by the real testing companies or test business units at companies, both of which provide large numbers of testers through secondment. The revolution is mainly driven by software development parties. Are the testing companies sleeping too much or holding on too much to the old ways? Or am I diluting my own field by – at least it seems – looking at it differently? Will there still be work in a few years for the average tester and/or test automator? These are just a few questions that occupy me, and I am happy and enthusiastic to talk with you about them.

What I can tell you is that my learning curve over the past ten years has never been as steep as it is now, and that my passion and enjoyment in the field have never been as great. I enjoy the comments from developers who are happy with the CI build that provides feedback within 10 minutes on whether their refactor hasn’t accidentally broken something. I enjoy facilitating, making sure developers can develop faster. I enjoy really learning to program with mock objects instead of scripting. I enjoy working out examples with an analyst and developer during a three amigos session, and I enjoy setting up the CD pipeline. I enjoy the coaching I give to, yes, make myself redundant.

But above all, I enjoy the fact that the quality of the software we deliver is getting better and better. Without a pre-written test plan of 30+ pages or a poorly set-up defect registration system. Collaboration, pair-programming, mind maps & diagrams on the wall, and a lot of feedback back and forth, on all fronts, and enormous coverage with fast automated checks. I recommend you embark on the adventure, it’s so much more fun!