Scrum is an Agile approach to software development, which focuses on delivering valuable business features in short development iterations of 2 to 4 weeks. Scrum teams have two defining characteristics – they are cross-functional (i.e. they include every skill set necessary to get the job done) and they are self-organizing (i.e. the team is expected to figure out how best to get the job done). After working for nearly two years as a quality assurance (QA) analyst on a Scrum team, I have learned that the role of QA in Scrum is much more than just writing test cases and reporting bugs to the team.
Contrary to the synchronous activities of a traditional Waterfall project, Scrum expects development activities to be performed in the order they are needed – i.e. asynchronously. This break from tradition raises a common question by many of the clients, developers, and business stakeholders new to Agile – “How can testing professionals engage effectively during a sprint before anything has been built?” This article focuses on explaining how the QA role performs agile testing and the place of importance they hold on a Scrum team. Much of what I have learned about the roles and responsibilities of QA on a Scrum team I will be sharing with you throughout this article.
More Than Just Building Test Cases
On traditional Waterfall projects the QA role is only involved at the very end of the project – once all coding is complete. On these projects, the QA role would typically be given a requirements document and the completed code and would be expected to write and execute test cases which verify that the application does exactly what the requirements document says. However, the QA role in Scrum is not just about executing test cases and reporting bugs .On a Scrum team the QA Analysts participate and fulfill a variety of responsibilities conjointly with other team members. They are involved right from the very beginning of a project where they work closely with business analysts and developers. In Scrum, the QA role is not a separate team that tests the application being built. Instead the Scrum team is a cross-functional team where developers, business analysts and QAs all work together. Apart from building test cases, QAs can also help the Product Owner (PO) write acceptance test cases by playing the role of proxy product owner. Having QA fill in as a proxy for the Product Owner when they are not available helps keep the team moving forward at all times. They can also interact with the Product Owner by asking questions and challenging assumptions to help clarify the business requirements.
Participate In Estimating Stories
Quality assurance analysts are typically very good at creating test case scenarios based on user requirements. They also excel at identifying and capturing complex and negative test case scenarios. In fact, they are typically much better at it than developers, who tend to focus mostly on the “happy path” of the user story. Including testers during Release and Iteration Planning, when user stories are estimated, can help the team think beyond the happy path. This helps the team produce a more realistic estimate since both “happy” and “unhappy” paths have been considered. Estimation is a tough task and it is good practice to have the whole team participate in coming up with the estimate.
Help Keep Vision And Goals Visible
As the team works through the testing and stabilization activities, QAs should take the lead to plan, organize and involve the whole team in the testing work and to keep people motivated just as the Scrum Master (SM) does. Since very few developers enjoy testing work, the QAs , along with the Scrum Master, must make the testing vision and goals visible to the whole team and help to keep the motivation level of the team high. Sometimes it helps to be creative when testing scenarios require help from developers or other team members. Try making the testing activity fun by using amusing test scenarios, funny test data, fun competitions, etc. Do what you can to help the team enjoy and contribute to the testing work.
Collaborate With Customers And Developers
One of the primary responsibilities for the QA role is to provide feedback from their testing experience to the Product Owner as well as collecting feedback from them. QAs work closely with the Product Owner to help them develop detailed acceptance criteria for their user stories. Based on what the team learns during each sprint, QAs can also help the Product Owner modify or enhance existing user stories to better reflect the true requirements.
On occasion, the quality assurance analyst may be asked to act as a proxy for the Product Owner. In these situations, QAs and developers will sit and work together as a team to help improve the quality of the project. The QAs can pair up with developers for writing unit test cases and for discussing acceptance criteria. The more these roles work together, the greater the shared clarity will be on requirements. The increased clarity that results from working together will reduce the questions and doubts developers often encounter during coding time, which produces greater efficiency and a big time savings for developers and testers alike.
The whole team should be expected to pitch in and assist with testing whenever required based on the needs and the availability of team members. This practice helps create balance in the team and a shared responsibility for getting the work completed. It also helps produce the required pace to move faster with early testing feedback and increased quality.
Provide Fast Feedback
The build-test-fix cycle that traditional Waterfall teams repeat endlessly produces a lot of extra work for the team and usually ends up wasting a lot of time. This activity is much simpler in Scrum as QAs and developers work together throughout the entire process. Developers can consult the QAs about acceptance criteria or the expected behavior of any functionality from the user's perspective while working on the feature, which results in saved testing and bug fixing cycles.
Automate Regression Testing
It is often said that automation is the tester’s best friend since it provides repeatability, consistency, and better test coverage over the software’s functionality. This is particularly true on a Scrum project with small sprint cycles of 2-4 weeks, since QA generally has even less time to test the application. During each 2-week sprint, QA must perform full functionality testing of the new features being added during this sprint as well as perform full regression testing for all the previously implemented functionality. As would be expected, this responsibility grows significantly with each passing sprint so any automation that can be applied to these tests would greatly reduce the pressure the QAs feel.
Automated tests are particularly helpful in providing rapid feedback when teams implement Continuous Integration (CI). Each time there is a new build, the automated tests can be executed and provide immediate feedback as to whether the new features are working correctly or whether there have been any regressions of previously working functionality. Without automation, QA must perform these tests manually, which becomes a very monotonous and error prone task. Automation can help detect the defects early and give QA more time to explore the edge cases of the new features being developed. Automation can help QA deliver testing work much more efficiently and effectively.
Participate In Release Readiness/Demos
At the end of each sprint, the team holds a Sprint Review meeting where the team must demonstrate the user stories completed during the sprint to the Product Owner and other interested stakeholders. This Sprint Review meeting provides a healthy dose of accountability to the team and motivates them to complete as many user stories as possible.
With small sprint cycles of 2-4 weeks, everyone on the team must stay focused on his or her respective tasks in order to complete them on time. Developers stay busy developing their assigned user stories and fixing bugs while QA stays busy writing test cases, clarifying questions from Product Owners, and automating previous sprint stories. Having short sprint cycles also means that developers have less time to explore the complete functionality of their user stories on their own. As a result, developers typically consult with QA to better understand the user stories since they are the ones aware of the complete functionality and know each and every requirement and acceptance criteria. As a result, it can be a good practice for QA to perform the demo at the Sprint Review meeting and field functional questions coming from business. That can free up the developers to handle any technical questions that surface.
Analyze User Requirements
QAs are the proxy product owners of the Scrum team. QAs are generally good at understanding the business requirements from the user's perspective since they are often asked to use the application as the end users would. QA can help provide feedback to the Product Owner based on their testing experiences and can help the Product Owner better understand the application from the end user's point of view.
Enforce the Definition of Done
Having a clear Definition of Done (DoD) is important to a Scrum team. A DoD is nothing more than a simple list of team defined completion criteria - all of which must be completed before the user story can be considered done. This list typically includes things such as writing code, performing functional and regression tests, and gaining the approval of the Product Owner. A very simple DoD might include the following:
- Code Complete
- Unit Test complete
- Functional / UI Test Complete
- Approved by Product Owner
While it’s not the sole responsibility of QA to define the DoD, it is often QA’s responsibility to monitor the work being performed by the team and to ensure that each completed user story meets the benchmark DoD. An efficient Scrum team will review their DoD before starting each new user story to make sure they know what is expected. A team’s Definition of Done is not static and may evolve over time as the Scrum team needs evolve. DoDs can be defined for sprints and release as well.
Always Plan Testing With Testing Strategies
Since there is not a test lead or even a specific test team in Scrum, building a test plan or following specific test strategies on a Scrum team can be an issue. Scrum believes in preparing only enough documentation to support the immediate needs of the team. As such, QA will prepare just enough high-level documentation for test strategies and plans to guide the team. Since there are no QA leads in Scrum, the QA analyst typically decides the test strategies.
Tester and Analyst Roles Converging
On Scrum teams it is common to see the responsibilities of QA and those of the business analyst begin to converge. The Business Analyst role is typically responsible for creating and maintaining the sprint and product backlogs, analyzing the user stories from the business perspective, and prioritizing the backlogs with input from the Product Owner. The QA role, on the other hand, is typically responsible for defining / refining the acceptance criteria for each user story, testing the completed functionality each sprint from the end user's perspective, and ensuring all previously completed functionality has not regressed. As QA tests each user story and verifies the defined acceptance criteria has been met from the end user's perspective they are also analyzing the user stories in term of the business as well. So, in many ways the QA role and the business analyst role share many of the same responsibilities, required skills, and overall objectives.
Normally, a Scrum team gets their user stories and the pre-defined project scope from the Product Owner at the beginning of a project. However, in Scrum the team is encouraged to suggest new features or changes to existing features if it will improve the end users experience. The team is also encouraged to recommend changes to the priority / sequencing of user stories in the backlog when they find technical dependencies that suggest a different implementation order would be more efficient. Whether its defining requirements, analyzing user stories, defining / clarifying acceptance criteria, building acceptance test cases, or closely working with customers, the roles of tester and analyst are clearly converging. While this offers many advantages – particularly for small teams - it also has its disadvantages as well. The biggest concern is that neither the tester nor the business analyst role will get as much attention as it would with a team member fully dedicated to that responsibility.
Conclusion
While QAs still write tests and report bugs, they also support many other roles and responsibilities on the team. They are an important part of the team and are involved in the project right from the very beginning.
Working as a QA Analyst on a Scrum team for the past two years has been a great experience and has provided many learning opportunities. I have filled many different roles and responsibilities including QA analyst, proxy product owner, helping developers write unit test cases, acting as the team's quality conscience, and keeping track of problems and software bugs. In short, this experience has added many wonderful skills to my toolbox and has helped me learn how to play many different roles – all at the same time. Most importantly it has taught me to ask questions rather than just follow the documentation and do whatever it takes to help the team succeed.
While QAs still write tests and report bugs, they also support many other roles and responsibilities on the team. They are an important part of the team and are involved in the project right from the very beginning.
Refrence : Articel by Priyanka Hasija is a Test Consultant at Xebia IT Architects.
C2) 
C3
