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:
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.
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 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