“The quality of the product is the responsibility of the tester.” This is more than a myth. Usually, this is the mental model of the team that works with traditional waterfall projects. In those models, the developer only deals with generating code. Then the test team takes care of the quality. Opposite to cascade projects, in Agile Metholodiges teams, the tester is not the quality police.
Communication and interaction are vital to solve problems faster and to develop teamwork. Flexible environments like Intraway’s, help to keep employees motivated. Know more!
Quality issues are a responsibility of the whole team. All team members must work and test together to make sure each work is of high quality and is deliverable. An example of this is the automation of software tests. There, we can see how the whole team generates tests to improve the quality of a product at different levels of development.
“The team is responsible” may sound a bit worn, but it still works better than other approaches. The testers sit together with the development team. They also attend the same meetings and conversations with the client about functionalities. The last point helps significantly to understand the purpose of the software and, thus what tests are necessary to do.
Ideas to Apply To the Agile Team
Test in Parallel
They used to believe that it could not be tested in parallel. This myth comes more than anything from a mixture between :
1- The belief that exists an enmity between DEVs and testers.
2- The idea that testing has to wait until everything is finished to be able to see what was done.
In agile it is necessary to change our mental paradigm. You need to prevent and detect bugs working near PRD to understand the value and reason of tasks. It is also required to detect bugs working together with the developer, visiting and seeing on your machine the work done. Constructive feedback is a crucial step too.
Automated and do Manual Tests
Automation is NOT the only way to incorporate testing into agile equipment.
The idea that there is no time for manual tests lead us to think that we only automate all and voilá. Everything is magically faster and simpler. Automated tests take time and have a higher short-term cost compared to manual tests. Automation should be an essential part of the testing efforts. But it should not be the only way to test the product on agile equipment. You should also consider manual tests, especially if it is an application that starts from scratch.
Exploratory testing (a manual test technique) is also one of the best ways to learn and test applications. A developer can do this manual testing. It is also necessary to evaluate the cost-benefit in automation. Typically, regression tests and tests on existing functionality (which are least likely to change) are the most suitable for automation.
More Communication Around the Requirements
Is common to feel that testers do not obtain detailed documentation of the requirements to perform the tests. This comes from thinking that agile should not be documented. In practice, the type of work agile framework stand gives more priority to a working application than to a documented application. That is why team members must collaborate and communicate more often, instead of documenting each small detail. That said, it is a responsibility of all team members to make sure they have all the details about the requirements they are currently working on.
The agile testers need to make sure they understand the acceptance criteria well enough. They must work with PRD to refine the requirements and add adequate acceptance criteria to guarantee the integrity of the requirements.
In the agile equipment, the tests must be as early as possible, often, and in parallel with the development. The testers must collaborate with the programmers and verify their developments. The collaboration can include a group of programmers. They work is to identify scenarios of unit tests, integration, and functional scenarios. The tester should start writing the tests as soon as the Sprint planning is finished. Then, close work with the developer (DEV) and Product (PRD) to verify that what is being generated is of value is very important. If we wait until everything is developed, to test it later, we would be carrying out a mini waterfall project within a Sprint cycle. This situation would cause a lack of time and great pressure for the testers.
If we work this way, we can make the quality between all (Testers, Developers, Product, etc.) and build a cool software with high quality.
