QA: yesterday, today, and tomorrow

The world of software is evolving very fast and it is difficult to keep up to date on all practices and their evolutions. In recent years, the development world has undergone major upheavals with the arrival of agility and DevOps. Naturally, the way of testing has evolved, even changed radically to adapt to these new ways of working to create a product.

Although agility and DevOps have been applied for a few years now, I very often see a huge misunderstanding and misperception of the roles of testers and Quality Assurance:

• Testers are often seen as simple functional testers who test only after the developers have finished working on a feature.
• Quality assurance is seen as the search and reporting of bugs and the green light for release.

These outdated views of software quality, which consider QA or testers as the result, are discouraging. The fact that they are seen as final phases in projects is dangerous, as they often serve as an adjustment variable to respect the roadmap.

Yesterday!

Before agility and DevOps, development cycles were composed of large cascading steps.

At that time, there was a clear separation between developers and testers, with no overlapping responsibilities or activities. Testing was on the far right side of the development cycle.

After project requirements are defined, after design and implementation, testers take over to run a series of test scenarios (often manual). The test cases were prepared in advance, specialists executed the scenarios. Test cycles were executed and re-executed until predefined quality levels were achieved. The test goals were purely focused on functional validation of the software with the main goal of detecting and reporting defects.

Ok, but testing at the end of projects is a serious problem. If I don’t satisfy the initial requirements, what happens to the project that took 6 months of development?

Do I throw it in the trash? Or do I deliver it as is and take the risk that it doesn’t meet the customer’s need?

What is the situation today?

With the Agile context, software development and testing activities have merged, to the point where they now form a single phase. Test phases have become implicit activities during product development. Compared to yesterday’s methodologies, the responsibility for testing has shifted to the beginning of the cycle. The focus is no longer on finding defects in products, but on preventing them. The main goal is to ensure that the product is functional and provides a high level of user satisfaction.

Quality and validation have ceased to be the sole responsibility of the testers and have become a shared responsibility of everyone involved in the development and delivery of the product. The testers influence the quality. They have an indirect force (If the team doesn’t play the game, nothing happens). The testers are involved at all levels, in requirements definition, code review, unit testing, and practices of TDD, BDD, … to ensure that quality is at the heart of the product and development.

But that’s not enough, we have to go further in the process. The project must be deployable in an environment. And for that, we need ops. They too must be involved as early as possible in the process to ensure that the product developed can be brought into service. They must be able to anticipate project needs but also put in place the tools needed to monitor the proper functioning of the product or feature.

This is the DevOps movement. DevOps is the collaboration of the development and operation teams for the creation, delivery, maintenance, and support of the product. DevOps allows you to develop, integrate software continuously and deliver value to the end-user. At ManoMano, we talk about DevOps culture.

You build it, you run it

And the tester in all this?

With DevOps, the tester’s job evolves a lot. Test missions are expanding from the product to the infrastructure, where the final product will be deployed. Product responsibility also extends to OPS. Automated tests, deliveries are ensured by a continuous integration (CI) and continuous deployment (CD). A large part of the work is dedicated to the pipelines, environments, and infrastructure, as this is the backbone of the project.

If these tests are neglected, this can lead to unstable environments or it becomes difficult to investigate product bugs and defects. At ManoMano, we chose to use Gitlab, which provides us with the tools we need to version the code until it is delivered to production.

The role of the tester has been under threat for some years. Many people have this outdated vision where the tester simply checks the application built by the developers. Others think that if developers are better suited and more knowledgeable to write the code needed for automating tests, what need is there for a tester on the team?

Today it is time for us to change this perception. We must recognize the difference in value and competence between “testing” and “quality assurance”. Of course, the tests are the verification and functional validation of the product. But quality assurance is much more than that! It is a series of processes, including testing, best practices, to ensure that a quality product is preserved throughout iterations.