Importance of a QA team and the DevOps Software Culture

A brief summary of Quality Assurance (QA): 

It can be defined as a set of actions that companies perform with the objective of delivering a product or service with a high level of quality to customers. In software development, the use of QA’s generates confidence and security for customers, indicating that their products will have the expected quality in the implementation stage.

Also, in order for product quality to be maximized, it is ideal that all processes are documented, such as planning, determination of tasks and responsibilities, recording of results, and all inspection mechanisms that apply within the organization.

In summary, the implementation of QA can bring numerous benefits such as:

• Improved customer experience.
• Anticipation of problems.
• Meeting points for improvement.
• Optimization of the work of other areas.
• Cost reduction.
• It allows the work of other areas, such as POs and Devs, to be faster and more efficient.
• Improved quality of product delivery.

Agile methodology and DevOps environment:

With the beginning of the agile methodology and the need to minimize risks and costs associated with problems during software development, the DevOps method comes with the purpose of better integration between teams and shorter feedback to the customer.

DevOps has been gaining strength and being increasingly improved and implemented in companies. As agile methodologies were already being heavily applied, DevOps came to improve agile practices, integrating teams and automating development and operation processes, thus enabling the redefinition of the organizational structure and the traditional IT process.
This approach places great emphasis on building, deploying, and testing automation. The use of Continuous Integration (CI) tools and automation testing tools become a norm in a DevOps cycle.

DevOps involves “Continuous Development”. Where code has been written and committed to Version Control, it will be built, deployed, tested, and installed in the Production environment ready to be consumed by the end user. This process helps everyone along the chain, as the environments and processes are standardized. Every action in the chain is automated. It also gives freedom to all stakeholders to focus their efforts on designing and coding a suitable product, rather than worrying about the various build, operations, and quality control processes.

QA’s role changes with the introduction of DevOps:

In the methodologies previously applied in projects, the testing activities are always carried out at the end of each version, which is the moment when the test team analyzes the requirements from the generated documentation.

Test teams had a bureaucracy in their activities: the creation of plans, generation of documentation, creation of test scenarios, and execution reports. that is, at a certain point, autonomy in their activities, but a high degree of dependence on the team of developers, in which its activities would only start after the entire development process was finished.

With the arrival of agile methodologies, things started to change. Products are now broken down and developed in small deliveries and, in it, the entire development and testing process must be carried out suddenly. In order for these small deliveries to achieve their goals, many methods used during the waterfall methodologies had to undergo changes and required a high degree of automation, an action that needed a bigger involvement of developers in the creation of automated tests.

But, despite we have an “upgrade” in QA activities, we cannot consider that such activities are expendable so that the final product reaches the level of quality sought after each evolution of the methodologies. Therefore, we can consider that testing/quality professional should also go through this “upgrade” process, in which they should consider seeking a change in mentality, expectations, activity, and responsibilities.

The role of the testing professional in agile methodologies has not only changed but has become increasingly important.

This change came with the creation of the Agile Testing Manifesto. In this manifesto, we can see the change in behavior and responsibility that these professionals must seek.

In order to account for a more distributed model of testing experience and responsibilities in a DevOps environment, QA professionals should seek to organizationally position themselves so that their work can add the most value possible across the software development lifecycle. This means gaining significant new responsibility for making higher-level strategic decisions regarding testing and quality issues. This could mean a change in the org chart.

There is an opportunity to embed QA expertise directly into development teams, supporting them in unit test creation activities. This is an area that has been most effective in handling the QA transition so far. There is also the potential to divert QA professionals into tool groups responsible for writing the test or providing tools for the entire process.

So, instead of running tests and dealing with hands-on work, QA professionals will move into a more consultative and distributed role to help developers learn how to write better tests and improve their approach to quality selection. Because, at the end of the day, developers are still developers. They weren’t trained to look for quality issues. And even if they care about it, sometimes better-trained eyes will prevent bugs from going unnoticed.

While in the past QA was focused strictly on defect documentation, now the focus should be on collecting data from a wider range of automated tests and using it to expose the most likely causes for these defects and where they are likely to be reproduced, if the causes are not fixed.

Therefore, in the DevOps cycle, the responsibilities of the QA team are spread throughout the entire process, from the creation of the “Stories” to the “deploy” in production.

After that being said, what does it take to be a DevOps QA?

After all that we have seen, we can conclude that QA has conquered its position of importance within agile. In the DevOps universe, QA has become an increasingly important part of the entire development process and not exclusively in the testing phase. The QA became responsible, along with the entire team, for maintaining the quality of the product during the entire life of the project, from the requirement gathering, through the development phase, construction of the project parts (sprints), and system tests with the user.

For this, QA DevOps must be increasingly qualified and required, which has knowledge beyond what is necessary for testing activities.

Below we’ll talk a little more about what it takes to be a DevOps QA

• Have some knowledge of the application background: Get to know the system, and have at least an understanding of how it is being produced, its language, tools, database, etc. Know at least how it works and what can affect the functionality of the system. This step is very important so that the QA can, in the event of an error, identify whether what happened is a system bug or a malfunction of something, as well as visualize improvements and suggestions to the team.
• Understand how the application’s environment works: Once you know everything behind the scenes of product development, it will be very important to know how each part works in the development process, what each feature does, how it does it, and who to turn to if there is a problem. With this, the QA will be able to anticipate some possible errors and create scenarios to ensure that they do not occur, and if they do, they will be properly identified and corrected.
• Must have some programming knowledge: As much as some companies in the market still work with manual functional testing execution, it is essential that a DevOps QA knows some programming language (especially the system being developed), as software test automation is a day-to-day reality of any QA, and when we are talking about DevOps, automation is fundamental because we are talking about agility, time reduction and short deliveries with quality, where automation is the best way to keep up with the pace of agile development.
• Keep up with new technologies: new tools are always appearing on the market, and projects are not far behind. Often, teams are incorporating new systems to help in the development process, whit that being said, it is important to always update and study them, or at least those that are at their peak, if you don’t know how they work, at least know that they exist.
• Application of the DRY principle (don’t repeat yourself): In the testing area, there is a term often used, which is the Pesticide Paradox, which, in short, is when a tester repeats the execution of the same scenario several times, the tests will no longer be useful and will probably lose their quality, not finding new defects. So, an interesting practice is the “don’t repeat yourself”, don’t repeat yourself, when it comes to testing execution, we can indicate the work “Pair Testing”, where two or more testers take turns in creating scenarios, reviewing, and executing the same, where the most indicated would be who created the scenario not to execute it.