Agile testing is a testing method that follows the rules and principles of Agile software development. In contrast to the waterfall method, where the QA team does not participate until the end of the production, Agile testing begins at the beginning of the project with continuous integration between development and testing.
Agile software development acknowledges testing as a fundamental part of software development. Using an "entire-team" approach ensures quality. Coding and testing are done iteratively and incrementally. The feedback and collaboration between the testers and the developers is crucial to make this testing work.
Agile testing differs from waterfall testing in several ways. With Agile testing:
This approach suggests the development of the tests before the development of the code. Kent Beck, the creator of Extreme programming (XP), said, "We never have enough time for testing, so let's just write the test first."
The tests once written are often automated for unit tests. Even when the tests are not automated, they help the team develop as per the requirements and remain focused on users' needs. The approach creates a better understanding and reduces rework. It also results in higher quality code.
In projects where there is not enough time for extensive regression testing, there is a need to emphasize test automation. Test automation does not mean only functional or end-to-end test automation. The test strategy should consider unit, integration/component tests as well. Relying solely on end-to-end tests (E2E) is not a wise strategy. We recommend a test pyramid wherein there are many unit tests, fewer integration tests, and even fewer functional/ E2E tests.
The proper framework must be in place. Record and playback, or automation without any framework, may be a low-cost option, but it does not work from a maintainability point of view. A good framework enables rapid script development, understanding, deducing why one may fail, and maintaining working scripts.
Agile testing can be very beneficial in speeding up development. To make it work well, teams must overcome some challenges.
Requirements are gathered in the form of user stories, so they may not contain the implementation details. Also, requirements may be refined once development starts. This could mean some work already completed needs to be discarded or modified. This can all change the scope of testing unexpectedly.
Solution: In Agile projects, change is standard. Testers should be able to react and modify their processes. When requirements change, testers should share as much information as possible about what tests they have conducted, and which areas of the application have not been tested yet. This can help the team understand how to make the required changes to the sprint without hurting the quality of the release.
Developers may have "parental feelings" towards their code. Their focus can be on the "positive paths." They are emotionally linked to their work, and it may be difficult for them to find the bugs in their own code.
Solution: Developers need to switch from a positive mindset to a cautious, or "what can go wrong" one. This is not a trivial task. While necessary, it can be challenging to change a mindset in a short span of time.
Agile teams may not have the luxury of time to execute a complete regression test suite in every sprint.
Solution: Agile teams need to understand and focus on the impact areas. Then test those.
At Infogain, we believe that while Agile methodologies were designed for software development, the process -- with its iterative and incremental approach -- can be applied to many aspects of product development.
To speak to one of our Agile experts, email us at: email@example.com