A glance into my imaginary crystal ball tells me that even in 2022, countless software development projects will follow the waterfall model or the so-called Water-Scrum-Fall.
To all those who have not yet had the, in my opinion, dubious pleasure of Water-Scrum-Fall, I say "you don't want to experience that". Water-Scrum-Fall is, in my experience, nothing more than a waterfall project squeezed into an agile approach, usually Scrum. Sounds absurd? It is! It is also extremely stressful and frustrating for those involved.
I would like to state at this point that I am not talking about projects in a regulated and/or safety-critical environment, in which a procedure according to the V-model is justified. My focus is on projects in industries that have sufficient room for manoeuvre, can leave the waterfall behind and enjoy the prospect of a promising rainbow. The explanations in this article are based on my personal experience in various software projects, different industries and companies.
I entered software testing when "Agile" was still on the horizon (at least in Switzerland). At that time, my job was clear. It was my turn as soon as everyone else had finished. Testing was at the end of the process. Good old Waterfall. As many testers can certainly confirm, this meant that there was hardly ever enough time for full or at least satisfactory testing. The project had been running for a considerable time and all buffers had been used up. Testing had to be done, but please without cutting corners and in half the time. This in turn resulted in stressed, overworked testers, a frustrated project team across all disciplines and, in the end, faulty software and dissatisfied users.
I have often experienced this and asked myself more and more, "Will I always be the bottleneck? Why is the responsibility for quality on my shoulders when so many people have worked on the product? Why am I not involved earlier? ". These and more questions have never left my mind. Good software quality was and is a matter close to my heart. So I rolled up my sleeves and decided to go new ways. A holistic approach was needed in which quality was understood and lived as a principle and not as an annoying evil at the end of the process. Quality cannot be tested in at the end. Quality is the responsibility of the entire team, regardless of role or discipline. Only together can we be successful, efficient and deliver the right product at the right time. Easily said, but not easily done.
At the beginning of 2019, after some setbacks and detours, I was lucky enough to start in a big project. I finally got the chance to be very close to the development. My specific assignment was even to analyse and successively improve the quality and quality assurance directly on the development side. This was THE opportunity to put my ideas into practice. I had support from the highest level. What I had underestimated, however, was the fact that we humans are creatures of habit. Anything that is new or different, we are initially sceptical about. It took a lot of time, commitment, willingness to discuss, empathy and understanding from all sides to get the following things rolling, but it was definitely worth it.
At the beginning, the project team consisted of around 60 people from various disciplines and has since grown to more than 80 people. The majority were developers. The development was divided into several Scrum teams. The teams consisted of 6-10 people. There was also a separate test team. A separate test team? Yes, exactly. The test team did not sit in the same open-plan office as "the team", but in a separate room across the hall. That seemed strange to me. Especially because the project was organised in an agile way. I quickly found out that within the Scrum teams agile work was done, but the official testing still followed the good old waterfall. The feedback on the quality of the software flowed back into development much too late and with great difficulty. My solution: testers in the Scrum teams, immediately! This met with little joy, much scepticism and sometimes even destructive behaviour on the part of those involved. To make matters worse, there had already been attempts to have testers in the teams in the past, but they turned out to be nagging, criticising and blocking contemporaries and were thus summarily dismissed from the teams. But I didn't let that put me off. Every person is different and that is exactly the point. The best approaches, frameworks and process models do not work without the right people. Everything stands and falls with the attitude, the much-vaunted "mindset", towards a project. So I decided to join a Scrum team myself and prove that my approach can work.
Shortly after I found myself as an embedded tester in the only team without GUI (graphical user interface) components. That may not be worth mentioning for many. For me it is, as I have no deep technical education, my programming skills are at an absolute basic level and my entire testing career up to that point had been on the graphical user interface, the GUI. I had great respect for the new task. In retrospect, however, it couldn't have come at a better time.
The fact that I couldn't test independently, especially in the early stages, forced the whole team to work more closely together and try out new approaches. I have always had a quick grasp and a good technical understanding. These qualities allowed me to quickly immerse myself in the issues and responsibilities of my team. I quickly understood that I could support my team less with the execution of tests and more with my expertise in smart test design, reviews and with critical questions. And suddenly there it was, the rainbow beyond the waterfall.
Together we analysed our test coverage starting at the lowest level, the unit tests. We were always open to ideas and ventured into Behaviour Driven Development (BDD a.k.a. Specification by example). BDD brought us a common language, regardless of our disciplines. The whole team understood the requirements more clearly than ever before. In addition, we had defined concrete test scenarios in the same work step before even one line of code was written. This saved us an immense amount of time. The test scenarios could also be used at every test level. The close and immediate cooperation in the team and the knowledge about the concrete test coverage at all test levels enabled me to reduce manual test cases to a minimum. Finally, I was able to contribute my skills from the beginning, drive Built-in Quality and engage in exciting exploratory testing. The high self-discipline of every single team member as well as the consistent use of automatic CI/CD (continuous integration/continuous deployment) pipelines and corresponding quality gates made us successful. In addition, we constantly reflected on ourselves, adapted things, improved them or threw them out.
After only a few months, my team was a role model for cross-role cooperation and quality assurance within the project. It didn't take long and we were the poster child beyond the project boundaries. Many asked about our secret.
It sounds so simple, yet it is difficult to implement: it takes the right mix of people, with the right skills, the willingness of everyone to pull together, especially when things are not going so well.
Those who take this to heart and, with a bit of luck, are in the right place at the right time, have a good chance of seeing the glitter of gold in the pot at the end of the rainbow.
I wish us all more togetherness, openness, acceptance, exciting projects and lots of rainbows for the future, because quality assurance and testing are much more fun that way.