After concluding numerous service and field service projects, throughout the world, working with customers from various industries, using agile methodology here is our unique point of view and methodology on how to QA such projects.
Due to their iterative and fast nature, Agile projects require a predetermined meticulous QA process to ensure all requirements are filled during the designated timeline. However, even the strictest QA process can encounter challenges during the project life cycle. In the following article, we will be going over the possible challenges and how to overcome them.
One of the most difficult challenges that the QA encounters, is the partial or incomplete requirements that are being assigned as a part of the sprint scope. These oftentimes unclear requirements may affect the entire project team, from developers and implementors through to the QA engineers and can cause the final feature to be implemented partially or incorrectly.
To overcome it, prior to sprint initiation, the solution architect or technical consultant responsible for the requirement must verify that the story is approved by the product owner (that can be internal, or part of the customer’s project team). Conducting a grooming session to review the requirement and get feedback from the QA team or the developers can help refine the story and ensure all relevant implementation aspects are addressed. Lastly, if the story being assigned to the sprint remains incomplete, the QA team must keep a direct line of communication with the product owner via preferred communication channels (Jira comments, Slack/Teams, etc.) and tie up any loose ends to make sure the requirement is clear.
Another Agile project well-known challenge is the pressing timeline which leads to Constant Testing.
The first action that we recommend for addressing this issue is to use a dedicated test management tool such as XRAY or Zephyr for test case creation. The first action we recommend for addressing this issue is using a dedicated test management tool such as XRAY or Zephyr for test case creation. These tools seamlessly integrate with Jira, allow quick defect creation, and provide robust reporting capabilities to provide a better view of the testing progress of the project. It also allows the lead QA of the project to quickly perform a test case review to ensure all story scope is covered and that the requirement is clear to the QA team.
Constant Testing can also result in an overload on certain QA resources. To facilitate this challenge the QA lead can try to allocate different types of tasks to the QA team members every sprint. For example, James has gotten multiple complex tasks to test on sprint 5, while John had a much simpler task on the same sprint. When sprint 6 will start, James will get fewer stories in the sprint, or less complex stories while John will be assigned to more complex tasks. This will not only allocate the resources evenly to reduce the effort, but it will also make sure that the QA team has additional knowledge on various features and requirements while keeping them somewhat “fresh” and reduce “tunnel vision” in the project – provide another set of eyes to the problem.
Another aspect of the pressing timeline is that any delays can affect the timeline directly and risk the project’s completion. It is therefore critical that the QA team will communicate and elaborate on progress daily. Furthermore, to reduce the risk, the QA needs to raise any concerns on issues that can affect the timeline of the sprint. For example: highlighting questions that were left unanswered for specific requirements, stories that have not yet been delivered to QA in the later stages of the sprint, and too many defects on a single story that is yet to be handled, etc. These concerns need to be handled by the project manager to ensure the project stays on track.
Since requirements and features are implemented gradually during the agile project life cycle, some features are implemented later in the lifecycle and can affect the functionality of earlier implemented features. Meaning that during the sprint, the QA doesn’t only need to check that the new features are implemented correctly, but they also need to test end-to-end business scenarios of earlier features in a testing cycle called Regression. The start of the regression cycle can vary depending on the project timeline, but it is essential to ensure the system’s stability. To perform effective regression, we recommend running the regression suite using test automation. Automation does not require any resource to run and can run quickly in multiple environments and using it means that regression can run parallel to manual feature testing and as a result increase the test coverage of the system and its stability.
At the start of this article, we discussed how requirements can sometimes be unclear or partially written, but during the agile project, another rising concern is the Frequently changing requirements mid-sprint. First and foremost, whenever stories are changed, they should be documented in the communication channels to the entire project team, however, this is not always the case. Each QA should have ownership of his assigned stories and should pay attention and communicate if stories are changed. As a best practice we suggest that if requirements are changed, the change should only take place from the next sprint and not affect the current sprint scope as additional changes put the sprint initial scope at risk.
In conclusion, agile projects are complex but with proper management and a refined QA process, we can make sure the actual requirements implemented through it are delivered on schedule and match the customer expectation and satisfaction standards.
Have any questions or want to get our experts on board your project?
