7 Changes Scrum Made To The Tester’s Role

In the last decade, Agile methods went from quirky and novel to essentially standard practice. Scrum has been of the strongest proponents of the agile methodology throughout, but one question remains. How have methods like Scrum altered the tester’s role in development organizations? Ulf Eriksson from ReQtest, the on the cloud bug tracking and requirements management solution, gives us some answers.

1: Testing is Closer to Development

The Scrum philosophy dictates that a team should be as self-sufficient as possible, meaning that collectively, the team members should have every skill needed to complete a task. Since very few functions can be considered complete without testing, most teams need testers. In complete contrast to traditional development methodologies, Scrum pushed testing into development teams, both physically and procedurally. No other facet of Scrum methodology has had a bigger effect on the testing role than this one.
Traditionally, development and testing have been separated by an organizational chasm which persists even in some companies that have adopted Scrum. However, by planning and conducting testing in close conjunction with development work, these organizational boundaries are fading. Testers now enter the team earlier, very often at the same time as developers. Traditionally, testing tasks were an external activity consisting of planning tests, executing them on an ongoing basis, and reporting results. Nowadays most testers sit scattered across development teams, and each team shares responsibility for software that is coded, tested, and ready for delivery.

Naturally, some testing activities should stay separate from development, partially to maintain objectivity but also because these activities come later in the sequence and hence can’t be planned at the same time.

2: Testing Starts Earlier

Scrum automatically includes testing in the development process as early as possible, which is undeniably positive and something that most organizations strive for. Only by testing can we review the business requirements early on, and then based on the testers’ skills, influence the system design. This gets the testing discussion started early – even before the team starts writing code – while keeping testability from falling into the background where it frequently gets forgotten. Without this focus, teams often forget about testing during the requirements and design stages.

Defects, also referred to as bugs, design errors, or other terms, all signify something that’s different from what is expected or required. The earlier you detect defects, the cheaper they’ll be for you to fix. Correcting these deviations late in the cycle costs the team dearly, in the form of extra work such as additional documentation, regression testing, and potentially expensive re-delivery to the customer. Cost, stress, and embarrassment are all excellent reasons to introduce testing early in development, as well as to keep trying to discover errors as early and often as possible. There are countless cases where during an early requirements discussion, a tester’s simple question made a client or coder rethink a critical point. Discovering defects at the design stage is considerably less costly than fixing failures found later.

3: Iterations

When testing and development teams plan work together, the development team can deliver work more frequently for testing. If team members are allowed to hand over internal deliveries informally, they can spend less time on the detailed documentation normally required. Assuming that the team has flexible build and deployment tools, the development team can deliver work to testing frequently, with very small iterations inside the sprint. Of course, in a highly functioning scrum team , development and testing are not two separate entities, and are, for all intents and purposes, one, single development team, while in other team set ups, testers are not necessarily always involved.

Close collaboration between development and testing also creates opportunities for continuous learning within the team. Testers deepen their technical knowledge about the product being developed, making them more effective at planning the testing strategy, and resolving the few bugs that will inevitably get through. Developers who are unschooled or inexperienced in testing can get a better grasp on how testing works, and can take better advantage of testing environments, testing data and other assets that the testing team possesses. Of course, in many cases, developers are highly attuned to the needs of testing, and in cases such as these, testing becomes an activity in which programmers and testers work together as a group and learn more about their respective areas, as well as others’.
Continuous delivery iterations are worth striving for, for several reasons. For starters, testers see software that’s similar to previous iterations and isn’t as “jumpy”. Developers get feedback earlier, when they’re still developing the software and can quickly correct bugs while they’re actively working on the code.

With repeated sprint iterations, the product owner also gets insight into how the work is progressing. By adding, removing, and prioritizing tasks from the product backlog, the product owner can continuously control how the product evolves.

4: The Tester’s Job

The “purest” version of Scrum recommends that anyone on the team should be able to take on any role. In reality, this is very rare in medium to large-sized organizations because employees are usually either developers or testers, so teams typically have dedicated testers who are usually encouraged and even expected to ask tough questions. Doing so during design and development would have been overstepping boundaries even just a few years ago, before testing became well-rooted in the development process. Organizations traditionally expected testers to objectively examine the deliverables they received, and report back on the quality (or lack thereof) they found.

In Scrum, testers are an integral part of the team, and provide feedback on pre and post delivered work in a close relationship with developers. Some teams even test on the developers’ own machines so as to ensure basic functioning before even deploying to the test servers.

Scrum is occasionally said to introduce a new challenge to the testers’ role: the risk that testers get too “chummy” with developers and don’t fully expose the defects they uncover. While this may be true in a small number of cases, anyone will agree that it’s certainly easier and faster to successfully explain defects or issues to someone face to face, rather than through an endless stream of emails. Personally, I find that the advantages gained this way far outweigh any risk of developers and testers covering up for each other.

5: The Test Manager’s Role

Among these broader changes, the test manager’s job has shifted into more of a coordinating role, responsible for strategically planning testing across various teams. Testers take on tasks such as planning, reporting, and documentation in the team, and the test manager compiles and synthesizes their work. The test manager also has to coordinate different types of testing activities to keep major differences between teams from arising and collects and compiles test results on the team level. In large projects with parallel Scrum teams, it’s easy for teams to focus solely on the one part of the system that they themselves are building, so the test manager has to ensure the integrity of the system, long before integration formally starts.

6: Automation

Agile methodology provides only the preconditions for shortening the time it takes to transform an idea into software. In Scrum, you expect that what the team produces in a sprint (1-4 weeks of development time) will naturally be high-quality enough to deliver to a customer, production, or end-users. This requires the testers to examine components newly developed in the sprint, as well as preexisting code that may be affected – which may be impossible without automated regression testing if the existing body of code is large. An additional advantage of automation is that it allows programmers to have the confidence to make changes as tests covering existing functionality are readily available. When combined with CI and overnight builds this approach can be crucial for really early feedback.

Testers should focus manual efforts on newly developed components, where it’s most useful and is most likely to detect defects. You can save significant resources if the team of testers knows how to build automated test suites that can be continuously executed – even if it requires help from the developers. Of course this is not to say that the integration between components should not be seen as crucial, as often this could bring older and already tested areas to the spotlight when analysing how they now interact with other components within the system.

7: Value-Adding Activities

According to my perspective of Lean and Agile methodology, organizations should continuously seek to eliminate waste, so no one does work that doesn’t add value. This is especially important from a tester’s perspective, since testers, understandably, would prefer to have the project deliver smaller chunks of functionality with few defects rather than huge, bug laden releases. Project planners usually prioritize bug fixes over other tasks that the team needs to perform, but testers may be forced to tolerate defects going uncorrected, since the trouble to repair them simply does not create enough net value for the business. On the other hand, it can be less costly to the organization to make even small bug fixes with very little beneficial impact, if the developers simply perform them on their own initiative. If the team has to document, discuss, and then prioritize defects, they can waste hours just in administration tasks before they can even attempt a fix. This approach obviously requires that the project has come to a stage that allows “open season” on bugs.

What’s next?
• Scrum borrowed its basic principles from Lean. Read more in the article “Lean and Mean – Requirements management and testing that means business” in the ReQtest monthly newsletter.

Author Profile – Ulf Eriksson

Ulf Eriksson heads ReQtest, an online bug tracking software based in Sweden. ReQtest, which is the culmination of Ulf’s decades of work in development and testing, is a very handy and simple tool to track bugs, list requirements and better manage all communication by anyone involved in any project. Ulf is also the author of many white papers and articles, mostly on the world of software testing. He is also slaving over a book, which will be compendium of his experiences. Ulf lives in Stockholm, Sweden.