All posts tagged Scrum

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

by Muhammad Ramzan

Read Part I and Part II here

Test Strategy for Scrum

In this section you will learn how to prepare a test strategy or perform testing in Scrum environment. The following are a few assumptions:

  • Development Scrum consists of many sprints of 2 weeks each
  • 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.
  • The QA Environment is closed to client staging environment. In some cases testing can be performed in Dev. environment as well.
  • The build and deployment process may take up to 30-60 minutes.
  • Build responsibility is of Dev. side but QA can also build the release in case if resources are not available.
  • There two build process
    • Manual Build
    • Auto build, once per night (nightly build)

Using the assumptions above, I have divided a sprint into following segments from a QA perspective:

Day 1: Sprint Planning Day

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.

  • Participate in the planning meeting.
  • Analyze and clarify the requirements which are mentioned in user stories selected for the current sprint.
  • Divide the tasks for each user story.  For example:
    • Test Case Preparation
    • Test Case Execution
    • Regression
  • Add estimates for each divided tasks. Then add it to the final estimation of a user story.
  • Prepare the test environment (this should also be added as a task in backlog as well).
  • 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.

Day 2: Test Cases Development

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.

Day 3 – 8: Development & Testing

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. 

The following should be the daily activities of QA during this period:

  • Coordinate with the development team and decide the release pattern. Daily release or when a few user stories are developed.
  • If you have not received a release , complete the test cases which were not completed in Day2
  • If any user story is updated, update your test cases accordingly
  • If the release process is automated every night, then every day QA will pick the release, deploy the release and then start testing
  • If the release process is manual there may be three cases:
  • If some team member completed user stories he/she will provide the build to QA. QA deploys the release and starts testing.
  • If a single release which includes user stories is developed by development team, QA deploys the release and start testing.
  • 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.
    • 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.
    • 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.
    • Report all bugs/defects which you found during development on time so that they can be fixed on time.
    • During functional testing, also focus on bugs fixes. Follow-up the reported bugs and verify the bugs that are fixed.
    • Participate in daily Scrum meetings.

Day 9: QA Day

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.

  • Try to close all open bugs.
  • Perform regression testing.
  • Go through the sprint backlog and note down the missed user stories for the retrospective meeting day.
  • Discuss with development teams if bugs are still open.

Day 10: Retrospective Meeting

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)

  • Participate in retrospective meeting
  • Discuss what is tested and what is not tested
  • Explain the reason why few features are not tested
  • Explain why all bugs are not closed
  • Close all bugs or assign to Product Owner for next approval
  • Discuss the next plan in meeting

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.

1 Comment
by techwebcasts on February 28, 2013  •  Permalink
Posted in Scrum, Testing
Tagged ,

Posted by techwebcasts on February 28, 2013

https://aajtechblogs.wordpress.com/2013/02/28/how-to-use-your-qa-skills-in-a-scrum-based-project-part-iii/

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

by Muhammad Ramzan

In part one of this blog, I went over a high-level overview of using QA skills in a Scrum-based project. In this post, I’ll be going into more detail on the various testing approaches you can use in those projects.

Testing Approaches/Types used in Scrum

The following are popular testing approaches/types in Scrum:

  • Exploratory testing
  • Regression testing/ Integration testing
  • NFT (non-functional testing)
  • Automated testing

Exploratory Testing

  • Learning, test design and test execution at the same time
  • Analytical approach while executing tests
  • What is the best test to be executed now?
  • Aim is to maximum use of skills
  • It is not important to describe everything in documents

SCRUM Blog 1

 

 When to perform Exploratory Testing:

  • Testing team does not know much about the product
  • There is not much time or resources available to complete testing otherwise
  • Great way to learn and familiarize your team with the new product quickly
  • Feedback on the product / feature is required quickly
  • Diversity of testing is needed
  • Most important errors need to be found in shortest time
  • Continuous feedback received from client on user stories and on developed sprint even when a sprint is not yet pushed to the client environment.
  • Some very specific issue needs to be verified/investigated

Regression Testing/ Integration Testing

  • In Scrum, there is not enough time to perform separate integration testing and regression testing.
  • In my personal experience, I used the Regression Testing technique and performed tests so that regression and integration scenarios both are covered in a short time.
  • Perform Regression Testing:
    • When different User Stories are merged
    • When different sprints are merged
    • When bugs are fixed
    • On QA Day / Retrospective meeting day (if needed)
  • The purpose is to ensure that existing functionality is not broken with new implementation or if new functionality is integrated with existing functionality.
  • New features should be integrated to its final branch before regression testing is done
  • Test automation preferred if possible.

NFT (non-functional testing)

In non-functional testing, the focus is mostly on testing the performance.  If performance testing is part of your project, the best way to achieve this testing is when planning the sprints.   Add a new user story like “As a user, I need to do performance testing so that my application gets successful response from all the users”. Add tasks for this user story and then work on it accordingly.

In my next blog, I will explore the actual test strategies for Scrum-based projects.

7 Comments
by techwebcasts on January 21, 2013  •  Permalink
Posted in All Posts, Scrum, Testing
Tagged ,

Posted by techwebcasts on January 21, 2013

https://aajtechblogs.wordpress.com/2013/01/21/210/

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

by Muhammad Ramzan

How to use QA skills in Scrum

The concept of multitasking and teamwork is very strong in Scrum, but there is not such a thing as ‘specialist in everything’ as people are always better in one area. Even if they know many other areas, they will never have time to do everything. Therefore, there are Developers and there are Testers.

In Scrum there is no separate phase of testing. Rather it is continuous development and testing. In Scrum, nobody is allowed to sit and wait for a delivery. Testers need to be an active member from the sprint’s start and everyone is expected to contribute.

The following are a few suggestions to a be good, proactive tester:

  • Find what requirements mean and discuss the understanding with the development team
  • Start to collect all information and learn. Capture the domain and analyze all the user stories
  • Conduct sessions when you feel there isany confusion. You should have clarity of the business and all user stories
  • Think like a QA, but behave and work like a Scrum Team member. Your  focus should always be on the quality of the product.
  • You should have the skills to know how to build a release and how to deploy the release.
  • Don’t consume much time on formal documentation like a Formal Test Plan or QA Plan.
  • Just prepare a simple Test Plan if all activities are planned in your project.
  • While developing test cases, always focus on business processes. Your test case must cover “Acceptance Criteria” of every user story.
  • Write Test Cases as fast you can, do not waste time on long elaborations / clarifications.
  • Reuse old Test Cases if possible, this can be part of a regression test
  • If daily (or personal) build is possible, start testing and probe the developed functions. If Dev. resource is not available to provide you build/release, do not wait. Build the release and start testing.
  • Make sure that for every task to be executed there is also Test Case to be written and executed.
  • Test coverage is important, so create a model
  • Remember that the sprint has an end time, so make all efforts to fulfill the time line.

Be sure to join us next time when we discuss the testing approaches that can be used in Scrum!

18 Comments
by techwebcasts on January 7, 2013  •  Permalink
Posted in All Posts, Scrum, Testing
Tagged , ,

Posted by techwebcasts on January 7, 2013

https://aajtechblogs.wordpress.com/2013/01/07/how-to-use-your-qa-skills-in-a-scrum-based-project-part-1/