Transitioning from Waterfall to Agile Testing
When a company decides to transition from Waterfall to Agile testing, what are the most important areas to concentrate on for effective Agile Testing?
How does Testing in Agile compare to that of Waterfall model? What set of activities are important for testers to know and do?
Testing Throughout the Development
The first thing to understand is that in agile development, testing is integrated throughout the lifecycle; testing the software continuously throughout its development.
In traditional Waterfall model, testing is a large effort and is left towards the end of development, whereas in Agile, testing is small but more frequent and happens throughout the development.
Testing throughout the development also means that the software is in releasable condition throughout the development, so it can be shipped whenever it’s appropriate.
In Waterfall model, we are taught to think in phases, such as design phase, development phase and testing phase. Agile development does not have a separate test phase as such. Developers are much more heavily engaged in testing, writing automated repeatable unit tests to validate their code.
Developer Participation in Testing
With automated unit tests, testing can be done as part of the build, ensuring that all features are working correctly each time the build is produced. With a solid foundation of good unit test coverage, developers will feel more confident to refactor code as well.
Testing in Agile also means starting early. That means the QA would have to be involved right from the design stage, understanding the features and stories and start preparing and even writing tests upfront.
Another important aspect is Test Automation to be able to execute tests continuously as the product is being developed. This is not only unit automated tests, but API and UI automated tests as well.
Integrated and Cross Functional Teams
Transitioning to Agile is cross-functional project team activity. This joint effort is not limited to the testing activities. The developers should assist with testing frameworks and create features, the business analysts assist with refining the story.
Each team member works on a story until the entire story is done, that means developed and tested. Designers, Developers and Testers work together in parallel so achieve a common goal and they all should know what is necessary to get things done.
Performing as a team is the main key point transitioning from Waterfall to Agile Testing. The Company can decide to change to Agile Testing but the people have to support this change to succeed.
There is no test team in agile.
Quality Mindset, Whole-Team Approach
Aim for defect prevention rather than defect detection.
With early participation of testers in the project, they can assist in identifying key scenarios that are required to test a story. Quite often the acceptance criteria is written as a joint effort between a Product Owner, a Developer and a Tester - the Three Amigos.
This ensures that whatever is being built is testable and understood by all stakeholders. Also, as more people are involved in defining the acceptance criteria and the “Definition of Done”, mistakes can be rectified earlier and ultimately the right product is built right.
Everyone is involved and responsible for quality of the product.
Less documentation, More collaboration
In Agile development, there is more emphasis on conversation and collaboration to clarify requirements more than the traditional approach of specifications and documentation.
Although requirements can be clarified to some extent in agile development, it is still possible for requirements to be ambiguous and incomplete, and for team members to have different understanding of the requirements.
So what does this mean for an Agile Tester? A common concern for testers transitioning to Agile development is that they don’t know precisely what they’re testing for. They don’t have a detailed spec to test against, so how can they possibly test it?
You don’t need to have detailed documentation to get started with testing. Many times, decent testers can use their judgement and common sense to validate a product. Domain knowledge becomes crucially important.
Testers should be confident to work more from their own knowledge of what good looks like. It’s certainly not just a case of following a test script, making sure the software does what it says in the spec.