Scrum Testing: Process, Methodology & Roles

Testing is not typically the first thing that comes to mind when considering Scrum. Sure, the framework is usually adapted to work with software development processes, but testers may feel neglected.

The official Scrum Guide barely mentions software testing or scrum testing, even though it is a crucial part of the Software Development Life Cycle. Considering a relative lack of sources on agile testing, this article is, in a way, a venture on the uncharted seas as we explore how agile testing fits into Scrum methodology. 

What is Scrum? Scrum Testing Basics

Scrum is a process framework designed to facilitate teamwork while managing projects. It can be used in any business where projects must be coordinated and planned, especially if immediate results are required.

It is often described as lightweight, as it has few elements. Some key roles, tools (known as artifacts), and meetings (called events or ceremonies) exist. The organization is simple because Scrum is meant to be uncomplicated and adaptative.

Difference between Agile and Scrum framework

Currently, Scrum is one of the most popular Agile frameworks, used primarily for managing software development. The key difference between Agile and Scrum is that the first is more of a project management philosophy. At the same time, the other is a specific framework that falls under the Agile umbrella and is used to practically improve workflow in a project. Effectively, it is a set of roles, tools, and meetings designed to help teams collectively manage their work.

Scrum Workflow

The Scrum framework is based on dividing work into manageable, incremental releases, known as Sprints. Every Sprint lasts from one to four weeks. By the end of that time, a potentially shippable product had been created. "Potentially shippable" means meeting the acceptance criteria and definition of done. "Done" deliverables should work as expected. As mentioned before, the Sprint is loosely organized around the roles, artifacts, and ceremonies one must know about to understand the whole process.

The three roles in Scrum process are:

• Product Owner - a person who defines the features needed in the product and brings ideas to the table,

• Scrum Master - a servant to the team, they are responsible for the process, running meetings, and generally keeping things going,

• Scrum Team Members - consists of software developers, testers, technical writers, etc..

Three Scrum artifacts

• Product Backlog - created by the Product Owner, it is a prioritized list of features, for example, User Stories,

• Sprint Backlog - ranks User Stories, it is used to estimate and prioritize what needs to be done during the Sprint, contains requirements taken directly from the product backlog,

• The Increment - the sum of the completed Product Backlog items during the current and all previous Sprints.

The artifacts revolve mainly around User Stories, which serve to put oneself into the end user's shoes and anticipate their possible actions. User Stories are a set schema for this practice, containing one action each.

The schema goes as follows: as a [type of user], I need [the software to do a particular thing] so that [I can achieve my goal]. This practice may be beneficial for testers, who need to anticipate and test possible scenarios of the software's use.

Scrum events

• Sprint Planning - pretty self-explanatory - it is set up to discuss the User Stories and estimate their relative sizes.

• Daily Scrum - a brief stand-up meeting; the development team discusses what they have completed, what they are working on, and if they need any help in case they are stuck.

• Sprint Review - development team demonstrates the completed work to the Product Owner.

• Sprint Retrospective - discussion on what to improve on going forward.

To summarize, Sprint's life cycle starts with the product backlog, from which the tasks are selected during Sprint Planning. Once the smaller Sprint Backlog is created, the Sprint itself is in full swing. During that time, everyone takes part in the daily stand-ups. They use the Burndown Chart to monitor progress.

After the Sprint is over, it's time for Sprint Retrospective to think about ways to improve future work. Lather, rinse, repeat. This cycle continues until the product is done, the budget is spent, or the project is closed. 

Why is Scrum effective?

Ultimately, is Scrum just the good old "planning one's work" under a new fancy name? Well, not really. The scrum framework is often set against traditional methods, such as the Waterfall approach. It means planning everything (or at least most) in a project up-front, followed by executing the pre-planned tasks.

Testing in Waterfall and most traditional methods is typically relegated to the end of the SDLC. This is not the best approach in a rapidly changing modern environment, especially for large-scale projects. There are several reasons:

• Modern customers might require immediate results to see how the work progresses and if the product is worth supporting. A tested product has a better chance of making a good impression!

• The customer's needs might change rapidly, or the vision of the product the team has created might prove to be ineffective or impossible to fulfil. In such a case, planning everything and testing only once the plan is completed might not be the best approach, as it would require all the work to be redone.

• There might be a need to scale the project rapidly. Again, that would mean re-arranging the whole painstakingly prepared plan of action.

Adapting Testing in Scrum

As for the practice of testing in Scrum, the main difference compared to the traditional methods is that instead of finding bugs and defects when the product is done, the Agile tester is supposed to find them along the way.

The second crucial change is that every team member is responsible for the quality (development and testing), not just the testing team. Let's see how it works in the sprint cycle.

For Sprint Planning, the obvious first steps are picking which User Stories should be tested and estimating their complexity. To speed things up, it is essential to use project management tools. Let's use JIRA as an example.

In Sprint Planning, you may add a "testing" column between "code review" and "done" (even though Scrum doesn't include it). One of Agile's staples is prioritizing working in software over documentation, but that doesn't mean you can't add a "How to test?" text field to the User Story. This practice helps keep everything in one place and ensures transparency and simplified communication.

Before any deliverables are made by the developers (usually during the first few days of the Sprint), the testers prepare test cases for each User Story. The rule of thumb is to test User Stories as soon as they are completed and appear in JIRA's "testing" column. If a bug is found, it goes into the Sprint and has to be retested as soon as it gets fixed. After the deliverable has been produced, the testers may also perform acceptance testing.

Speed and adaptability are keys to success. That is why automatization, including regression testing, is preferred over manual testing whenever possible.

As for the Sprint Retrospective, it is so case-specific that it is the same for everyone - whatever your role is, at this point, your task is to reflect on the process, learn from mistakes and identify best practices for future Sprints.

Summary of Scrum testing

By focusing on small parts of the production process, Scrum gives immediate results. The product is easily scalable and adaptable to changes. That makes the process Agile in its most basic sense - as adaptable as possible to changing customer needs.

The framework can make sense when applied to testing a small part of the product (such as a deliverable created during one Sprint) because the sooner bugs are found, the more cost-effective the method is.

As mentioned before, a potentially shippable product in Scrum means a tested product that can be safely put into the hands of the client. This is one of the most significant advantages of Scrum.

During the project's first week, a deliverable can already be written, tested, improved, retested, and released to the customer. This is a crucial advantage in the context of QA work in Scrum, as testing takes place from the first moments of the project instead of at the end.

The flip side is that adapting to Scrum may take some time in itself, and it is bound to be a trial-and-error process for those accustomed to traditional methods. Therefore, before diving into Scrum, consider whether this is the right approach for your team and the software you want to build - and test.

Happy (automated) testing!