Introduction

As a member of Generation X, I find myself reminiscing about the days when "The One" was Neo, dodging bullets in "The Matrix," and when I started my journey in software QA.

My first introduction to testing was through User Acceptance Testing (UAT) on a large accounting and reconciliation software project and user requirements. It did not take long for me to realise I had a knack for testing and working in that environment. I moved into testing full-time, spending over ten years with nFocus, working on projects that spanned from large-scale government IT projects and e-commerce to finance and construction/infrastructure. In these sectors, I sometimes worked as a lone Tester, while other times I was part of cross-skilled teams that delivered award-winning products.

Looking back, my early view of software development was straightforward and from what seemed to be a simpler time. Most of my projects fell into one of two types: Waterfall and V-Model — both structured and rigid, often filled with surprises (not always the pleasant kind).

Reminiscing

The Waterfall model started with requirements, usually long written statements that only made sense to the writer. After extensive reviews and signoffs, it would proceed through design, implementation, testing, and finally, delivery. The process required each phase to be completed before moving on to the next.

The main pitfall was if a major gap was identified, you would have to go all the way back to the beginning to update the requirements, then repeat the cycle of design and development before re-testing. This could be slow and painful, and once the development stopped; I had limited involvement until the product was ready to be tested again.

The V-Model was like the Waterfall model, with one side dedicated to development phases (requirements, design, design specifications, and application development), and the other side dedicated to corresponding testing types. My involvement in these projects typically began with static testing requirements, design, and development documentation before I would get "hands-on" with integration tests, system design & tests, and sometimes operational acceptance testing.

Life in the Waterfall Era

During my time working on projects using these methodologies, I would often juggle multiple projects at various stages of development. On one project, I might be leading the test team, planning the testing phase, and resolving issues. On another, I would be writing test cases, only to discover that the requirements had changed without anyone informing me. It could be incredibly frustrating.

Projects would move from design to implementation, then eventually to testing and deployment. The transition could be described as "controlled chaos," with gaps in design and last-minute changes causing delays. Questions such as, "Why is testing taking so long?" or "Are you finding more issues?" were common occurrences. Despite the challenges, these inquiries spurred proactive problem-solving, with Testers.

As a Tester, being involved early was a mixed blessing. It provided insights into the project, although it required flexibility in adapting to design revisions and evolving requirements, it presented an opportunity for us to demonstrate our adaptability, even in the face of challenges associated with testing perceptions.

In both methodologies, it was common for key issues to be identified in development or even during testing. After a "review," the outcome was often to reduce the time allocated for testing to meet deadlines.

As a Tester, I often faced challenges in finding optimism in decisions that increased risk and limited my ability to test thoroughly. I had little influence, as testing was seen as a bottleneck, with Project Managers reducing testing time or prioritising only critical tests while leaving regression testing for another time.

Enter Agile: A Breath of Fresh Air

Fast forward to a world where for me, it was all about Agile software development. Everything was quicker, smoother, and many of the issues I used to face were fading memories. Agile was promised as the solution to the problems that plagued the Waterfall and V-Model projects on which I had worked.

I attended testing conferences and meetups where I heard stories about how Agile was transforming the testing landscape. Testers spoke about collaboration, early involvement, and frequent feedback loops - it sounded like a dream come true.

When the company I worked for decided to embrace Agile, it was not an immediate game-changer, but with training and success stories, projects began to transition from the old ways to something new.

As a Tester, I started being included in sprint estimation discussions and working side-by-side with Developers. Project teamwork and collaboration reached new levels, allowing me to test and catch issues early. I could talk to Developers and let them know I was monitoring their unit test coverage or discuss ambiguous requirements with business analysts. This approach reduced the number of surprises during testing.

In those early projects, some people misinterpreted Agile to mean "no documentation," or no "agile manifesto" but for me, it meant that documentation should be appropriate without getting in the way of encouraging communication. Agile should allow projects to be flexible and adaptable to changes in priorities, risks, and issues as the team moves forward. With improved communication and collaboration, I could provide better feedback on test progress and product quality. The retrospectives helped identify what worked, what did not, and what could be improved.

The soft skills required in Agile were different; building relationships and seeing the world from other perspectives became key. Through my experiences, I've come to realise that the majority of individuals aren't intentionally undermining a project. It's beneficial to grasp their motivations, the obstacles they face, and their preferred working methods. Understanding these factors fosters collaboration and enhances project outcomes. If you can adapt in those situations, you will build successful relationships that lead to successful project outcomes.

In The New World

In today's world, where Agile practices are widely adopted, I still value the foundational principles I originally learned. I incorporate these 'good parts' into Agile projects where they prove effective. I believe my ability to adapt within these environments allows me to contribute to the success of projects and achieve superior outcomes compared to the rigid methodologies of Waterfall and V-Model

I now work with organisations that have wholly or partially used Agile practices to deliver successful projects and agile project management. While not all of them have fully embraced Agile and use a mix of ‘mini-Waterfall’ and Agile to achieve their end goal when delivering projects, they do understand the need for continuous integration and automation in their development processes.

As these organisations mature in their processes and the Agile methods becomes more embedded in their software development process and teams, they are focusing on improvement within the tests being executed. They would be looking to increase efficiency and improve the speed of execution and repeatability of tests once carried out by Manual Testers.

With those improvements in mind, there is a move to increase automation and with that desire more skilled resources are needed like those offered by the nFocus' SDET Academy (Software Development Engineers in Test). With a SDET in your team, you get a Tester that is able to provide technical skills with a testing mindset. They will be proficient in various programming languages, frames, and tools. They will enable a project team to build automation frameworks and work on other test-related development processes, such as continuous delivery pipelines. Whilst being able to collaborate daily with Developers and Manual Testers, identifying and resolving software defects, SDETs add excellent value to Agile teams by reducing risk and ensuring better test coverage.

Conclusion

The shift to Agile processes emphasises creating cross-functional teams, where Testers are involved in discussions about requirements, design, and implementation. This collaboration breaks down the invisible wall between development and testing, ensuring everyone has an equal voice. I no longer receive "finished" work packages at the end of the development process. I am collaborating with Developers and discussing ambiguous requirements with business analysts. The Agile approach has reduced the feeling of isolation I once had, as it is now better understood that testing is an essential part of a project's success.

The benefits of Agile methodologies include projects that deliver better outcomes, higher customer satisfaction, and reduced project costs. The collaborative nature of Agile also enables teams and team members to deliver projects more quickly compared to the Waterfall and V-Model approaches.

As a Manual Tester, there is still a place for me and my testing methods within a test team. Agile allows me to engage earlier, collaborate more, and ultimately be part of projects that deliver better results. So, my takeaway is that Agile as a methodology and way of working is a significant improvement from where I started, but I am also reminded through my journey and memories that while I may not be able to dodge bullets, Agile is ‘The One’ for me.