5 Rules for an Agile Test Strategy
5 Rules for an Agile Test Strategy
We like to say that agile developers are quality-centric and in most cases, that is true. Agile test strategy is simply a change in mindset when it comes to producing software. The quality of the software belongs to the entire team, not just a few members. The agile team owns the system and strives to find ways to bring testing and best practices into development.
How Testing Fits in Agile
The first thing the team needs to understand is how testing fits in agile. The best way to look at this is to understand the SDLC process and recognize how the testing activities fit in the methodology.
During the Inception phase, also known as Initiation, the goal is to get the entire team working together and in the same direction. The key aspect about agile is that the whole team has the power to make decisions. In addition, it is also important to understand that agile is a project management discipline. Project Management has been about planning and control until agile changed things. Now, it is about team collaboration, communication, and delivery. This phase, commonly known as Iteration 0, is used primarily to steer the team in the right direction. People may not want to talk about it as much but this phase is not about developing and testing. In fact, it is about learning to work together for the health of the project.
Simply told, this Inception phase could stretch from a few hours to weeks, depending upon the size and nature of the project, the team’s attitude and the direction.
The second phase known as Construction is considered the build and test phase. Developers and testers work very closely together. Alongside the business analyst is formulating the requirements.
The third phase known as Transition is when the system is released to market. Following that phase is Production, where the system is supported and maintained.
5 Basic Rules of Agile Test Strategy
There are 5 basic rules of agile testing in order for teams to be successful. It is key to note that unlike the traditional methodology where requirements are built out over time, agile is much more different. In addition, design and test planning are structured and appear in a more “handoff” or “silo” type of approach. In agile, things are more fluid and flexible. Requirements, Design and Test Planning happen at the same time.
Rule #1 – Defining the Test Strategy
Due to the nature of agile, it is not necessary or crucial to identify the scope of testing but it is fundamental to identify key aspects in the test strategy. The test strategy is not necessarily a written document closely resembling a design document but instead, it is a logical approach to testing. Testers need to know the answers the questions like who will control the QA build?, What is the defined scope of testing? and the list continues.
Defining the test strategy involves test data creation, what tools are going to be used, what will integration testing look like? Testers and developers work together to identify the answers and from there, the system is in process. Test documentation like the Test Plan will need to determine the test data as well as the approach to be taken.
Rule #2 – Defining the Scope
The scope of the testing is an important undertaking in terms of the efforts that will be used. Agile requires that the testers identify the areas that are in scope as well as out of scope. Typically, QA is allowed only a few days for testing along with defect fixes near the end of the sprint. With that in mind, testing needs to identify the boundaries for that scope. While it is known that new features are introduced in the beginning sprints, testers adhere to the more “happy path” or positive testing approach. With this in mind, the latter sprints tend to focus on the regression as well as integration testing.
Rule #3 – Rescope
Be prepared to rescope often and change your testing plan as necessary. Testers must be flexible and this is a “quiet” requirement of agile testing. The test plan must be a living document and will change as development changes scope. These things require rescoping of the testing effort and considered to be par for the course. Such flexibility is almost a requirement of any testing professional in the industry.
Rule #4 – Identify Risks and Mitigation Strategies
Another responsibility of QA is to identify the risks that become or will become a problem in the system as well as the testing plan. Because of this, the earlier the tester can identify the risks and offer mitigation strategies, the better the team will be. This allows everyone to own the risk(s) and help work together towards a common goal. One such mitigation strategy would allow the addition of extra resources in short bursts of testing as the risk is identified. Such a strategy would be identified in the Test Plan.
Rule #5 – Continuous Testing
The final rule of an agile test strategy is to test continuously and test often. This behavior is an expectation of the agile test strategy. Requesting builds either everyday or every other day is part of the process. Considering that testing is only afforded sometimes 2-4 days per sprint, it is imperative to test continuously. The more experienced test teams will even establish a way to utilize automation either for test data creation or to run regression tests. Code must be pushed on a continuous basis based on this mindset. Otherwise, this won’t be considered utilizing the agile process.
From continuous testing comes the feedback loop. There has to be an open dialog between all members of the team in order to succeed.
While there are other countless rules of the road in agile per se, these five are the most important. The key things to remember about the agile test strategy are the continuous testing, the test plan and the mitigation strategies. With these three identified, the rest, as they tend to say, will fall into place. And once they fall into place, the system and it’s agile team will be successful.