The use of agile development methods and practices has become something increasingly more natural in companies' daily lives. Some of these companies, although they do not admit it, implicitly end up applying some common practices, with the aim of obtaining results sooner.
These practices tend to stimulate and enhance the team and the constant interaction among its members, constant collaboration with customers, the functioning of software in development, and the ability to respond to change. However, what many agile development teams have not clearly defined, it is how to control the quality of what is being developed in an agile way or how to practice agile software testing.
Unlike a traditional Waterfall project, where there is strong dependency between activities, agile development methods believes that development activities must be done on demand - asynchronously. This paradigm breach raises a common issue being asked by many of the customers, developers and other business stakeholders who are new to agile methodologies - "How to effectively engage test analysts during a development iteration, since nothing has yet been built?"
Beyond elaborating test cases
In traditional Waterfall projects, QA is only involved at the end of the project - when all coding is complete. In these projects, the requirements document and the produced code are usually delivered to QA, which is expected to write and execute the test cases that will verify that the application is doing exactly what is determined in the requirements document. However, in agile development, QA is not expected to only run test cases and report software defects but also perform the duties below.
In an agile development team, QA analysts participate in events and perform a series of responsibilities in conjunction with other members of the team. They are involved from the very beginning of a project and work closely with developers and business analysts. The QA is not a team apart, which just tests the application being built. Rather, it's a cross-functional team in which developers, business analysts, and QA analysts all work together.
The concept of Agile Testing
In agile development, some principles defined through the Agile Manifesto are used with the purpose of guiding the production line, such as:
● Individuals and interactions between them rather than processes and tools;
● Software in operation rather than comprehensive documentation;
● Collaboration with the client rather than negotiating contracts;
● Ability to respond to changes rather than following a plan.
Although the items on the left are valued more highly, the items on the right are not disregarded, instead they are applied in a weighted way and according to the need of the process, without affecting the deliveries to be performed, established deadlines and quality of the final product generated.
The same principles used to guide agile development should be considered when agile testing is applied, that is, agile testing requires a strong adaptation in the routine and dynamics of the test team, in relation to the development process adopted, with the objective to provide a relatively simple process that can be executed with great ease and agility, covering the greatest number of risks, with a level of quality that is appreciated and valued by the client or end user.
Through the definition of the process, where the agile test is supported, a set of practices that provide the time reduction between the error and its discovery tend to be established together with a systematic work that allows the test process be more proactive than reactive.
The Differences Between Traditional Testing and Agile Testing
Let us analyze some of the practices of the traditional test process applied in the attempt to manage the "chaos", or at least avoid guilty:
● The Software Testing Area assuming the position of "Last Defender of Quality";
● Restrictions on change management;
● Detailed preparation and planning above all else;
● Heavy documentation set for outsourcing test efforts;
● Rigorous entry and exit criteria with approvals;
● Automation of heavy and regression-focused tests;
● Attempts to execute the process.
When it is an agile test, these same practices do not adapt to the desired dynamics. In an agile quality control environment, you should consider deadlines and test activities from beginning to end of the iteration. Unlike the traditional test, it is not expected that a single team will be responsible for the final quality of the deliveries, but rather than all the teams have their collaboration in controlling this quality, from the survey of the needs of the client, to the deployment of the final product.
In the traditional testing process, defects are expected to be identified at the last level by the QA team, while when applying agile testing, this is anticipated by the development team itself through practices such as pair programming, continuous integration/continuous deployment, small deliveries, constant refactoring and coding standards, techniques such as TDD (Test Driven Development) and through the automation of generated tests.
When working with agile tests, we can observe some changes of concept in relation to the traditional model, such as:
● Changes are inevitable, and based on that, all staff, including programmers, testers, and customers, are responsible for the end result;
● All staff should be accessible and actively communicating through the project;
● Software testing becomes more preventive, that is, programmers test earlier, more frequently, and aggressively;
● Every team actively solicits feedback from others;
● Testers and programmers tend to be more proactive (direct stakeholder participation) and technical (applying XP practices and techniques like TDD, ATDD and BDD);
● Testers need to know how to automate, in order to keep the test delivery cycle always on time and with updated regression testing. It just does not automate, which really cannot be automated or is not worth being automated (e.g. Usability Testing);
● The tests become a routine that is born and dies next to the planned iteration.
The importance of tests automation in agile development processes
Automated testing quickly returns results when teams implement the Continuous Integration (CI) process. Whenever a new version of the product needs to be built, automated testing can be performed, returning results immediately to indicate whether the new features are working properly, or to tell if there were problems with features that were working in previous versions. Without automation, QA would need to perform these tests manually - a monotonous and error-prone task. Test automation is useful for detecting defects as early as possible, and to give QA more time to test the boundary cases of new features being developed. Finally, the automation of the tests helps QA perform the tests much more efficiently and effectively.