How to use your QA Skills in a Scrum-Based Project Part III

<div dir="ltr" style="text-align: left;" trbidi="on"><h2><span style="font-weight: normal;">Read <a href="http://proinformationtech.blogspot.com/2013/02/how-to-use-your-qa-skills-in-scrum_7684.html" target="_blank">Part-I</a> & <a href="http://proinformationtech.blogspot.com/2013/02/how-to-use-your-qa-skills-in-scrum.html" target="_blank">Part II</a> here</span></h2><h2>Test Strategy for Scrum</h2>In this section you will learn how to prepare a test strategy or perform testing in Scrum environment. The following are a few assumptions:<br /> <ul><li>Development Scrum consists of many sprints of 2 weeks each</li> <li>The software is a web-based with certain data in the database. The role of tester will include testing software in a “QA environment”, while developers are still doing unit tests in their environment.</li> <li>The QA Environment is closed to client staging environment. In some cases testing can be performed in Dev. environment as well.</li> <li>The build and deployment process may take up to 30-60 minutes.</li> <li>Build responsibility is of Dev. side but QA can also build the release in case if resources are not available.</li> <li>There two build process <ul><li>Manual Build</li> <li>Auto build, once per night (nightly build)</li> </ul></li> </ul>Using the assumptions above, I have divided a sprint into following segments from a QA perspective:<br /> <br /> <div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg_7WjbyT_yEQR3kxy6nCNUGde76pkvaaO4OEcrYOfBEvWroWNYhyphenhyphenMHSaUUMlumxqPGCq4oMm_MFDA9colUY2sRoprm88Zz28O79oiw2OlC1gBdPBs1otTttrZ3lQ0YfewFueAk4C8yX08/s1600/Untitled.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="154" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg_7WjbyT_yEQR3kxy6nCNUGde76pkvaaO4OEcrYOfBEvWroWNYhyphenhyphenMHSaUUMlumxqPGCq4oMm_MFDA9colUY2sRoprm88Zz28O79oiw2OlC1gBdPBs1otTttrZ3lQ0YfewFueAk4C8yX08/s640/Untitled.png" width="640" /></a></div><br /> <h3>Day 1: Sprint Planning Day</h3>On first day of a sprint, QA will be involved in the sprint planning meeting. Get knowledge of all user stories which are part of sprint. Ask questions if requirements are not clear.  The following are main points which QA should focus on during the first day of a sprint.<br /> <ul><li>Participate in the planning meeting.</li> <li>Analyze and clarify the requirements which are mentioned in user stories selected for the current sprint.</li> <li>Divide the tasks for each user story.  For example: <ul><li>Test Case Preparation</li> <li>Test Case Execution</li> <li>Regression</li> </ul></li> <li>Add estimates for each divided tasks. Then add it to the final estimation of a user story.</li> <li>Prepare the test environment (this should also be added as a task in backlog as well).</li> <li>There may be some user stories which need more testing efforts and a few may have no detailed testing required. So estimate the tasks accordingly.</li> </ul><h3>Day 2: Test Cases Development</h3>The second day of a sprint should be spent developing test cases for all the selected user stories. Try to cover all user stories which are in scope of the current sprint.  If all user stories coverage is not possible, then prioritize the user stories by discussing it with the development team. For example there are 15 user stories in the current sprint. Discuss with developers which user stories will be developed first. Try to cover the test cases for those user stories for which you will receive the first build. Since we are using the Exploratory Testing technique, during the whole sprint the test development and testing cycle will be executed. Try to peer review your test cases with Scrum Master or Product Owner.<br /> <h3>Day 3 – 8: Development & Testing</h3>Since development is started from Day1, there might be chances that on day 3 QA receives a release with developed user stories. Coordinate with the development team, and if they have developed a few user stories, ask them to provide you the release or simply build the release and install it on the QA environment.<br /> The following should be the daily activities of QA during this period:<br /> <ul><li>Coordinate with the development team and decide the release pattern. Daily release or when a few user stories are developed.</li> <li>If you have not received a release , complete the test cases which were not completed in Day2</li> <li>If any user story is updated, update your test cases accordingly</li> <li>If the release process is automated every night, then every day QA will pick the release, deploy the release and then start testing</li> <li>If the release process is manual there may be three cases:</li> <li>If some team member completed user stories he/she will provide the build to QA. QA deploys the release and starts testing.</li> <li>If a single release which includes user stories is developed by development team, QA deploys the release and start testing.</li> <li>If the development team members are busy in development, QA coordinates with development team members if there are some newly developed or updated user stories Then they build the release on QA environment and start testing. <ul><li>When you start testing, first perform sanity test if the release is stable. If critical issues are found, coordinate with the development team to get fixes and perform testing.</li> <li>Try to complete the testing tasks as much as you can because on the last days of a sprint, there may be pressure on QA, (as many development team members will be developing user stories) and QA will receive many builds or a single build having vast implemented functionality.</li> <li>Report all bugs/defects which you found during development on time so that they can be fixed on time.</li> <li>During functional testing, also focus on bugs fixes. Follow-up the reported bugs and verify the bugs that are fixed.</li> <li>Participate in daily Scrum meetings.</li> </ul></li> </ul><h3>Day 9: QA Day</h3>The ideal scenario is that on Day9, no new development should be accomplished. Focus should be to close all issues and re-test bugs. QA should try to close all reported issues on this day.<br /> <ul><li>Try to close all open bugs.</li> <li>Perform regression testing.</li> <li>Go through the sprint backlog and note down the missed user stories for the retrospective meeting day.</li> <li>Discuss with development teams if bugs are still open.</li> </ul><h3>Day 10: Retrospective Meeting</h3>In order to demonstrate a feature in the retrospective meeting, it should be implemented, tested and all the bugs should either be fixed or assigned to the Product Owner for clarification (otherwise feature is postponed to next sprint). The tester should demonstrate that features meet acceptance criteria and demonstrate the issues assigned to the product owner (if any)<br /> <ul><li>Participate in retrospective meeting</li> <li>Discuss what is tested and what is not tested</li> <li>Explain the reason why few features are not tested</li> <li>Explain why all bugs are not closed</li> <li>Close all bugs or assign to Product Owner for next approval</li> <li>Discuss the next plan in meeting</li> </ul>In an ideal environment on retrospective meeting day, development and testing should be closed. However in some scenarios on the retrospective meeting day we closed many items. So be prepared for such scenarios. In this case, before of the end of the business day of the retrospective meeting, you should close all items and a deliverable package should be available that can be pushed to client environment for UAT.</div>

How to use your QA Skills in a Scrum-Based Project Part III

Read Part-I & Part II here Test Strategy for Scrum In this section you will learn how to prepare a test strategy or perform testing i...

Read more »