Software Quality Assurance and Scrum: A Struggle to Coexist In the Same Sphere
As many may already know, Scrum is an approach to software development that, rather than being a full process or methodology, is a framework that utilizes the Agile scheme to develop software. Instead of providing a complete, detailed description of how everything is to be done in a project from the beginning, much is left up to the development team. Scrum projects progress in a series of sprints, which are also known as iterations no longer than a month. At the start of a sprint, team members commit to delivering a number of tasks listed in the project backlog list. At the end of the sprint, these features are considered done if everything within the task is fully coded, tested and integrated into the evolving product or system. At the conclusion of each sprint a review is performed to demonstrate the functionality of the newly developed feature and feedback is given that could influence the next sprint.
So where does a Quality Assurance (QA) team fit into the Scrum approach? Some have argued that Scrum allows the developer to do QA on their own work or team member’s work. In addition, some feel that having a QA team only staggers the progress of development, in that developers have to wait for feedback regarding their work before they can proceed, whereas a developer can write scripts and test their own work in a more efficient way. To spite the aforementioned arguments, most would agree that having a team solely dedicated to quality assurance is a more efficient way to produce an end product.
The following attempts to provide an approach to integrating QA into Scrum. First, the QA team should be made part of the Scrum Team, meaning that they should take part in planning and Scrum meetings. During the Sprint planning, as tasks/backlog items are being distributed to team members, QA could be creating “Acceptance Tests” or “Test Cases”, describing what QA believes the functionality should do. In the Sprints, the QA team could be utilized to clarify or provide input on any functionality or UI concerns. Finally, once the Sprint has ended, the QA team can test the finished features and provide feedback before the next Sprint.
In conclusion, although it’s difficult to find a way for QA and Scrum to coexist, without causing delays in production among other issues, it is clearly important to find a way to integrate QA into Scrum. The above approach is based on what I have observed works during my assignment to the MASS LEG project Having a QA team dedicated to solely testing, assures that only the best software is pushed into production. In addition, the term “Done”, in reference to finished task, could be clearly defined utilizing a QA team. Using the aforementioned approach or another effective way to integrate QA into Scrum can only result in quality software being developed.