Scrum Testing Methodology Tutorial

Scrum in Software Testing

Scrum in Software Testing is a methodology for building complex software applications. It provides easy solutions for executing complicated tasks. Scrum helps the development team focus on all aspects of software product development, including quality, performance, and usability. It provides transparency, inspection, and adaptation during software development to avoid complexity.

Scrum Testing

Scrum Testing is testing performed in Scrum methodology to verify that software application requirements are met. It involves checking non-functional parameters like security, usability, and performance. There is no active role of a tester in the process, so it is usually performed by developers with Unit Tests. Sometimes dedicated test teams are needed depending on the nature and complexity of the project. Modern teams often coordinate this work in Jira, Linear, Azure DevOps, or Asana.

Key Features of Scrum Methodology

Following are the key features of Scrum:

• Scrum has a short, fixed schedule of release cycles with adjustable scope, known as Sprints, to address rapidly changing development needs. Each release can have multiple Sprints. Each Scrum project can have multiple release cycles.
• A repeating sequence of meetings, events, and milestones.
• A practice of testing and implementing new requirements, known as stories, to make sure some work is release-ready after each Sprint.

Scrum is based on the following 3 pillars:

Let us look at them one by one.

1. Roles in Scrum

There are three chief roles in Scrum Testing: Product Owner, Scrum Master, and the Development Team. Let us study them in detail.

Product Owner	Scrum Master	The Team
He or she defines the features of the product.	He or she manages the team and looks after the team’s productivity.	The team is usually about 5-9 members.
The Product Owner decides the release date and corresponding features.	He or she maintains the block list and removes barriers in development.	It includes developers, designers, and sometimes testers.
They prioritize the features according to the market value and profitability of the product.	He or she coordinates with all roles and functions.	The team organizes and schedules their work on their own.
He or she is responsible for the profitability of the product.	He or she shields the team from external interferences.	Has the right to do everything within the boundaries of the project to meet the Sprint goal.
He or she can accept or reject work item results.	Invites to the Daily Scrum, Sprint Review, and planning meetings.	Actively participates in daily ceremonies.

2. Scrum Artifacts

A Scrum process includes:

• User stories: They are a short explanation of functionalities of the system under test. Example for an insurance provider is: “Premium can be paid using the online system.”
• Product Backlog: It is a collection of user stories captured for a Scrum product. The Product Owner prepares and maintains the Product Backlog. It is prioritized by the Product Owner, and anyone can add to it with approval from the Product Owner. Modern teams maintain the Product Backlog in Jira, Linear, Azure DevOps, or Asana.
• Release Backlog: A release is a time frame in which a number of iterations are completed. The Product Owner coordinates with the Scrum Master to decide which stories should be targeted for a release. Stories in the Release Backlog are targeted to be completed in a release.
• Sprints: It is a set period of time to complete the user stories, decided by the Product Owner and development team, usually 2-4 weeks of time.
• Sprint Backlog: It is a set of user stories to be completed in a Sprint. During Sprint Backlog, work is never assigned, and the team signs up for work on its own. It is owned and managed by the team while the estimated work remaining is updated daily. It is the list of tasks that have to be performed in a Sprint.
• Block List: It is a list of blocks and unmade decisions owned by the Scrum Master and updated daily.
• Burndown chart: The burndown chart represents overall progress of the work in progress and work completed throughout the process. It represents in a graph format the stories and features not completed.

3. Ceremonies (Processes) in Scrum

• Sprint Planning: A Sprint begins with the team importing stories from the Release Backlog into the Sprint Backlog; it is hosted by the Scrum Master. Testers estimate the effort to test the various stories in the Sprint Backlog.
• Daily Stand-up: Also called the Daily Scrum, it is hosted by the Scrum Master and lasts about 15 minutes. During the Daily Stand-up, members discuss the work completed the previous day, the planned work for the next day, and issues faced during a Sprint. Team progress is tracked here.
• Sprint Review / Retrospective: It is also hosted by the Scrum Master, lasts about 2-4 hours, and discusses what the team has accomplished in the last Sprint and what lessons were learned.

With Scrum roles, artifacts, and ceremonies established, it is important to clarify exactly where testers fit inside this framework.

Role of Tester in Scrum

There is no active role of Tester in the Scrum process. Usually, testing is carried out by a developer with Unit Tests, while the Product Owner is also frequently involved in the testing process during each Sprint. Some Scrum projects do have dedicated test teams depending on the nature and complexity of the project.

The next question is, what does a tester do in Scrum? The following section will answer that.

Testing Activities in Scrum

Testers do the following activities during the various stages of Scrum:

Sprint Planning

• In Sprint Planning, a tester should pick a user story from the Product Backlog that should be tested.
• As a tester, he or she should decide how many hours (effort estimation) it should take to finish testing for each of the selected user stories.
• As a tester, he or she must know what the Sprint goals are.
• As a tester, contribute to the prioritizing process.

Sprint

• Support developers in unit testing.
• Test the user story when completed. Test execution is performed in a lab where both tester and developer work hand in hand. Defects are logged in a Defect Management tool and tracked on a daily basis. Defects can be conferred and analyzed during the Scrum meeting. Defects are retested as soon as they are resolved and deployed for testing. Modern Scrum teams typically use Jira, Linear, Azure DevOps, or Asana for this workflow.
• As a tester, he or she attends all Daily Stand-up meetings to speak up.
• As a tester, he or she can bring any backlog item that cannot be completed in the current Sprint and put it into the next Sprint.
• The tester is responsible for developing automation scripts. He or she schedules automation testing with a Continuous Integration (CI) system. Automation receives importance due to short delivery timelines. Test automation can be accomplished by utilizing various open source or paid tools available in the market. This proves effective in ensuring that everything that needs to be tested is covered. Sufficient test coverage can be achieved with close communication within the team.
• Review CI automation results and send reports to the stakeholders.
• Execute non-functional testing for approved user stories.
• Coordinate with the customer and Product Owner to define acceptance criteria for acceptance tests.
• At the end of the Sprint, the tester also does acceptance testing (UAT) in some cases and confirms testing completeness for the current Sprint.

Sprint Retrospective

• As a tester, he or she will figure out what went wrong and what went right in the current Sprint.
• As a tester, he or she identifies lessons learned and best practices.

Once these testing activities are running each Sprint, teams depend on clear metrics to communicate progress, which is where test reporting becomes essential.

Test Reporting

Scrum test metrics reporting provides transparency and visibility to stakeholders about the project. The metrics that are reported allow a team to analyze their progress and plan their future strategy to improve the product. Tools such as Jira, Linear, Azure DevOps, and Asana automatically generate many of these reports. There are two metrics that are frequently used to report.

Burndown chart: Each day, the Scrum Master records the estimated remaining work for the Sprint. This is the burndown chart, updated daily.

A burndown chart gives a quick overview of the project progress. This chart contains information like the total amount of work in the project that must be completed, the amount of work completed during each Sprint, and so on.

Velocity history graph: The velocity history graph predicts the velocity that the team reaches in each Sprint. It is a bar graph and represents how the team’s output has changed over time.

Additional metrics that may be useful are schedule burn, budget burn, theme percent complete, stories completed, stories remaining, and so on.

FAQs