In a fast-delivering agile world, there is a need for increasing the speed of the testing without compromising the quality. Sometimes, MVP (Most Viable Product) releases have a timeline of 45 days. In such a short span, requirements, wireframes, solution design, build, testing, SIT, UAT, security testing, and implementation should happen in time.
Also, as part of cost-cutting well established organisations are reducing testing costs by performing sprint testing in a “one layer above and one layer below” passion. SIT and UAT are combined as IAT (Integrated Acceptance testing). So, there is a lot of emphasis on sprint testing in an agile world for delivering a quality product.
When can we start sprint testing??
We can start sprint testing from the very early stage of the project life cycle i.e right from the program increment (PI) planning by considering dependencies/blockers and risks.
Inflight testing
Before the start of a sprint, we may be given a demo of requirements and solution design. We need to perform an impact assessment of new features to the existing code/systems/data and then plan inflight testing accordingly.
Static testing
Performing static testing on the requirements, solution, and wireframes can help to uncover bugs in the early stages of the life cycle.
Test preparation- “Three Amigo session”
Business, Developers, and testers use a different lens while digesting the requirements. If we allow all of them to work independently, they may blame each other for the understanding gaps at the end. “Three amigo session” is one solution for this. It is a meeting set up by a tester where a quick test preparation is done on the fly under the presence of BA, dev, and tester.
Automation
BDD framework like cucumber is the most suitable automation framework for sprint testing. If UI is unstable then we can go one level below and automate the API testing. Based on cost and time parameters, we can do progressive automation and integrate with DevOps pipelines.
Test Execution:
We can start testing whatever that’s readily available. Sometimes, back-end changes get delivered by other scrum teams in future sprints. We can still test UI/API code built by our scrum team by stubbing the back end. Once, full integration is established we can do early integration testing by covering a few important features and handover the build for further testing like IAT. However, it takes a good coordination effort between testing teams to start IAT testing in parallel with sprint testing.
Sprint Demo:
To uncover UAT bugs upfront, a sprint demo can be given to the business at the end of every sprint.
I wanted to conclude by saying “Sprint tester needs to have craftmanship in every role while building a project.”