Modern Testing - The Evolution of The QA Role
Software development has evolved from the days of waterfall, Agile and now DevOps. Naturally, testing as a discipline has also seen a few major shifts to accommodate the new ways of working and delivering software.
However, there is still a huge misunderstanding and an incorrect perception of the role of testers and quality assurance as a whole.
In this post, we take a look at how testing has evolved, particularly in the last decade, and what QA professionals need to do to stay ahead of the game.
Testing can only get more interesting!
While software testing activities has changed to adapt to the new ways of working, I still see a lot of old-fashioned views on testing and the role of a QA.
It is disheartening to see that there are still a lot of people in the IT industry that see QAs or Testers as the bottom line. Testers are often seen as just functional testers that only test once developers have finished working on a feature. “Quality Assurance” is perceived as testing, finding and reporting bugs and giving the Green light for release.
What’s even more worrying is that this perception of the QA role is paramount amongst testers and QA professionals themselves.
Traditional Software Testing
Historically, taking a lead in the final phases of a waterfall project, testing would sit firmly on the right of the project lifecycle. After up-front requirement definition, the Testers would take the baton from the Development Team at the close of the development phase and run lengthy, detailed test scripts, often manually, and usually through siloed teams and groups of SMEs.
Tests cases were meticulously planned in advance, scripts were executed by specialists, defects were detected and reported, and test cycles were run and rerun until the predefined quality levels were achieved.
Most notably there was always a clear separation between developers and testers, with no overlap of responsibilities or activities. Indeed, during the distinct, ring-fenced phase of testing, activities were purely focused on the functional validation of software with the core aim of finding and reporting defects.
QA in the Age of Agile
The emergence of agile methodologies and ways-of-working fused the activities of development and testing to such an extent that software testing was no longer a standalone phase. Instead, testing became an implicit activity during the coding and development of software.
In some cases, it would be hard to see the distinction between a “tester” and a “developer” as each would have the ability to seamlessly undertake each other’s activities.
“Quality” ceased to become the sole responsibility of the testers and became a shared responsibility of everyone involved in developing and delivering the product.
Along with this evolution came a shift of test responsibilities to the left of the development essentially baking quality in from the start.
Focus moved from finding defects in built software to preventing defects from getting into the software in the first place.
With a shared goal to ensure not only that the product or feature was functional and met requirements, but was also fit for purpose and provided a high level of user satisfaction.
Testers’ involvement in story refinements, peer code reviews, unit testing and practices such as TDD, BDD, and Continuous Testing, ensured testing and quality were at the forefront and was embedded into the development.
But, while Agile went a long way to combine the activities and practices of development & testing, the operations team was still siloed. The two streams of work (Dev & Ops) were often unaware of each other’s activities.
If anything went wrong in production, investigation would take a long time. Developers didn’t have the insight into how their application was performing in production in the longer term; there was no transparency or clarity of collaboration between the two teams.
Welcome to DevOps
DevOps refers to the collaboration of Development and Operation teams across software creation, delivery, maintenance and support. It refers to a continual union of resource, processes and the product itself.
DevOps enables methods of continuous integration and delivery of value to the end user.
The DevOps movement has driven a new perspective on testing and created new opportunities for testers themselves.
In this new era testers need to be aligned with both development and operations.
The remit of testing is no longer limited to the product but also the testing of the infrastructure where the product is ultimately executed.
Continuous Integration (CI), and Continuous Delivery (CD), has become the de facto standard in the development and delivery of software, and therefore much of testing effort is now spent on ensuring the CI/CD pipeline, environments and infrastructure.
This is the spine that supports both development and delivery.
If testing of these are neglected, it could result in flaky environments, much effort being wasted investigating repeated infrastructure issues and, ultimately, a high risk to development and speedy delivery.
Modern Testing - Quality Driven Development
Although much has been done to embed quality in every stage of development and, as a result, testing has a much wider scope, I still believe that QAs are spending most of their time looking for functional issues and focusing on the verification of software.
Most QAs don’t realise the importance of their role and the impact they can have on development and delivery.
Despite the considerable shifts in development practices over the past ten years, I feel that testers still take an old-fashion view of their role and are, thus, remaining entrenched in the old era of testing.
Testing as a profession and the role of a tester has been under fire for some time with the rise of “automated testing”. And indeed, many industry professionals still believe that the role of a tester is simply to test the application that the developers build, all of which can be automated.
If developers are better suited and more savvy to write the code needed for automated testing, then what need is there for a tester on the team at all?
It’s about time we changed that perception. We have to acknowledge difference in value and skills between “testing” and “quality assurance” as, where testing is functional verification and validation of software, quality assurance is not a single activity. QA is a series of processes, including testing, and best practices to ensure a quality product is delivered for users.
We have to strive for quality driven development and look at the QA profession as the central and core function in the development and delivery of software, hence Modern Testing.
QA is now a key component of development from start to finish working across the entire process. And, although common parlance says that everyone in a delivery team is responsible for the delivery of a quality product, I firmly believe that it is the responsibility of a QA to ensure that quality practices are being adhered to by the team.
Who is the Modern QA
Where the test profession was often seen as an access route into development, project management or other – usually more lucrative – disciplines, the new QA is a highly-skilled role that demands a holistic knowledge of development practices.
It requires a broad understanding of the challenges of coding practices, an appreciation of deployment methods and environments as well as performance and security standards, methods and challenges.
This is a T-shaped role with the resource able not only to apply their deep expertise and experience to deliver their core remit, but to apply a wider contextual knowledge across architecture and development.
Sitting in the centre of any project, the modern QA should have a good understanding of architecture, performance, security, and cloud offerings, be technically sound and have a thirst for learning new technologies to stay in the game.
The time has come to change the perception of the QA role and what testers do. This has to start from the testers themselves. The starting point is to deeply care for quality.
Testers are not there just to perform functional testing and report bugs. The QA role is much bigger than that. We are put on a project to ensure quality practices.
When we deeply test an application, we have to have an intimate knowledge about the whole operation of the system and not just look at the application as a black box.
In order to have that intimate knowledge we have to continuously learn and keep up with new technologies and ways of working. Most importantly QAs need to be adaptable.
When QAs understand their purpose on a project and start to believe that their role is the centerpiece of software development and delivery, when we embrace the modern testing principles, only then can we change the perception of others.