Not quite rugby: features of Scrum methodology
Although the IT term Scrum was borrowed from rugby, you shouldnāt take that at face value. While rugby squads organise in three rows that largely do the same thing, every person on the software team usually plays a unique part with varying tasks and responsibility.Ā
Most features of the Agile Scrum methodology in software testing originate from product lifecycle management. They also have influence beyond that, as specialists from other teams (such as financial auditors or our content team) adopt key principles as well.
ā Scrum is about incremental and frequent deliveries. Teams operate on fixed-length sprints (usually 2 weeks) that result in new feature releases. Some go for one-week sprints or even shorter
ā
Scrum brings flexibility. Waterfall software development outlines the process for start to finish with planning stretching multiple months. It is hard to react to potential delays or a change in market conditions when youāre weeks deep into fulfilling a requirement that may have become irrelevant.
By contrast, Scrum can adjust in a relatively short span. All tasks are added to the backlog, prioritised, and later added into a sprintās scope. Project Managers usually map out the current sprint + oneātwo sprints ahead. This means a non-priority feature request can be implemented in about 2 months, while something more urgent can be conjured in a couple of weeks. Going purely by Agile methodology, Scrum in testing would mean zero changes to the sprintās workload, but most teams constantly observe a balance between the methodology and business needs.
ā
Scrum promotes team work. All team members share their progress and stay vocal about potential blockers, while senior staff specifically takes time to help less experienced colleagues.
The ultimate goal of achieving a fast and feature-rich release requires well-timed collaboration. Although technically possible under Waterfall, the Agile Scrum testing process involves developers writing unit tests so that QA gets more polished and not conceptually flawed code to test.
ā
Scrum ceremonies are observed for practical reasons. Daily standup meetings put everyone in the driverās seat as they share progress and (potential) obstacles. Sprint demos allow everyone ā not only engineers ā to see progress and work on a visualised goal. Retrospectives are a great asset in improving the workflow.
Similarly, the team roles are pretty synergetic as well. Product Owner is free to turn their vision into user stories. Project Manager provides a grounded version of that vision as they split the user story into tasks. Some teams even hire for the role of Scrum Master ā in Agile testing or beyond, their advice keeps everyone to Scrum principles.
How we use Scrum in aqua dev team
We actually moved on from Scrum to Kanban, so we release every day rather than at the end of the sprint/iteration. A feature is released after it goes through one or two reviews and passes automated tests. There is no wait for other stakeholders or any arbitrary cutoff point.Ā
Our team moved to Kanban after visualising tasks on a value stream map. It shows how long it takes to go through all statuses before a task is completed. The results were pretty eye-opening.
Normally, we would:
-
1Create requirement (same day)
-
2Wait for the next sprint (up to 13 days of waiting)
-
3Implement the user story (~13 days of work, ~7 days of waiting)
-
4Do code review (less than a day of review, 1 day idle)
-
5Run QA (~2 hours, 2 days idle)
-
6Wait for the quarterly release (up to 70 days idle)
The obvious bottleneck was to move away from quarterly releases. That shaved off up to two months depending on the task. The next logical step was moving away from end-of-the-sprint releases. Now, we are looking at 43 days from creating a user story to releasing a feature, which is a ~400% boost year-over-year.
Key differences between Agile and Scrum
Technically speaking, itās not about differences. Scrum is an evolutionary subset of Agile, even if it was actually created ten years earlier. So, what is Scrum in Agile testing and development?
- Scrum is practical, while Agile is philosophical. Although both pursue delivering quality products in a flexible manner, the Agile manifesto wonāt actually tell you how to achieve it. All the Scrum features are spiritually Agile but are not mentioned in it.Ā
- Scrum designates team roles while Agile is purely self-organisational. Once again, Agile takes a bit of an idealistic path by empowering everyone to take responsibility but not telling what to do with it. Scrum gives regular team members some agency but also designates stakeholders that guide the project toward success
- Scrum covers product development while Agile is business-wide. Generally speaking, the software team working in Scrum may not affect the workflow of other departments at all. On the other hand, adopting the Agile philosophy is a full company effort
Get a testing strategy template that enables us to release 2 times faster
Go left and right at the same time: tips for Scrum in Agile testing
Now that you know what scrum methodology in software testing is, letās look at some of the best practices.
See whether traditional testing works better
Hereās a bit of a curveball: the best tip for your Agile testing may be resorting to regular testing. It is a much slower, but also more predictable methodology that makes it easier to ensure high test coverage. Have a look at our comparison of Agile testing vs traditional testing before you proceed.Ā
Pilot and Test
Dan Wilson, former End-User Director at Hertz, suggests that companies arrange testing rules based on risks from potential changes.Ā
- Low-risk changes (e.g. consumer app feature updates and security patches) are rolled out with prior beta/insider testing and automated testing. Ring-based deployment is used to gradually increase adoption while using feedback to fix a potential issue before too many people face it
- Medium-risk changes require a suite of automated test scripts executed with proper testing tools (such as aqua). This can be substituted or complemented by a QA professional or even a senior end-user going through documented user scenarios
- High-risk changes that may crash legacy or critical systems should go through the full-scale QA process, including regression testing and user acceptance testing (where relevant)
This approach strikes a balance between speed, quality, and effort. If something slipped past automated testing, it shouldnāt affect too many people.Ā
Take up Continuous Quality
Another prominent specialist recommends taking up the continuous quality approach.
āContinuous quality encourages a holistic and proactive approach, with functional and nonfunctional requirements driving the design, development and delivery of products. Quality is likely redefined for the organisation, as it relates to its digital business strategy. What was once a method of control is becoming more about coaching a team toward achieving business goals, and gaining competitive advantage in the market through superior quality that is measured based on business goals and outcomes.ā
We have previously dived into continuous testing ourselves as well. Find the 10 benefits of adopting it (itās more than āqualityā and āspeedā) in our blog article.Ā
Adopt shift-left testing
Shift-left testing focuses on performing tests earlier in the lifecycle with a heavier emphasis on unit tests rather than end-to-end or UI tests. This often involves developers writing and running tests before the code even makes it to the QA team.Ā
As of last year, our developers would create tests, but they were much heavier than the regular unit tests. This year, we have implemented a tool to track unit test coverage and increase it by 10% every week. We ultimately reached the industry standard of 80% without significantly increasing the time to write code.
Every night, we automatically build the environment to run all tests and see if the upcoming release is shippable. If it is not, the testers and devs work in the morning to resolve bugs and release a new version.
Adopt shift-right testing
Shift-right testing is post-release testing in the production environment. It also works well with our daily release strategy where we may have changes of different risks and/or known errors. Sometimes, these known issues can be severe enough for the new feature to break existing functionality.
Our releases with āundercookedā functionality utilise feature flags that allow us to ship a build with new features disabled by default. Once that build is shipped, we have the next morning to go through tests again and resolve defects. Now that it is production-ready, this functionality can be enabled for individual or all users without us releasing a new build.
Eliminate bias
Gartnerās Senior Director Analyst Mike West highlights the value of black box testing to avoid making tests that are too similar to the code. Although making people unfamiliar with the code create tests is a good tactic, you can do more.
āMany agile teams take this process further by writing the test before writing the code. This reduces the risk that embedded QA resources will be too close ā thus biassed ā to the implementation of the solution when they test it. By designing the test before the code is built, the test becomes a confirmation that the implementation meets the original requirements. It also allows defects caused by misinterpretation of the requirements to be found early, when they can be more easily fixed.ā
Donāt put off covering legacy code
Testing legacy code becomes a huge issue for unit testing, as thatās where you will find the biggest discrepancy in coverage. Unfortunately, there is no simple answer: you will have to cover old code with unit tests of good quality. Relying on end-to-end tests alone is not feasible: this is both time-consuming and expensive.
The good news is that covering legacy code becomes easier as you move, with the team getting more comfortable around test coverage tracking tools. If you have had the proper unit testing for a while, new features will not add up much to the backlog. The light at the end of the tunnel truly becomes closer day by day and week by week.
Get your automated tests straight
Good automated testing goes a long way. We at aqua took an effort to stabilise over 400 automated tests so that it takes a few hours at max to either spot a bug or find a potential issue with the test. From that on, we moved to TestProject for writing and executing new automated tests, a very sustainable and visual solution for testing our application.
Automation done the right way makes a huge difference to test management. This is even more relevant for early testing. For aqua, a full run of automated end-to-end tests takes 12 hours (and that would have been days manually). All unit tests, however, can be executed in as little as 20 minutes.
Adopt Infrastructure as Code
We used to handle test environments the traditional way, which meant a lot of manual work just to keep a single consistent configuration. This was both tedious and not necessarily reflective of the production environment. This approach also limited the QA team to working in the same handcrafted test environment.
Adopting Infrastructure as Code considerably freed up everyoneās work schedule. The test environment is now created automatically upon new code delivery. The same environment can be used by multiple QA specialists in parallel for running manual and automated tests. Such auto-generated environments practically mirror the production environment, eliminating the need for a dedicated replica (stage environment).
Move to Scrum-minded test management solution
Alas, even the most Scrum-ready teams may struggle to follow the principles when hindered by the wrong tools. Using Excel for test cases certainly does not bring the required transparency and flexibility. You need a software test tool that supports one of the practical Agile-inspired methodologies.Ā
It is even better when such a tool can also be used by your entire team. aqua ALM is such a tool: you can use it for all steps of product development, from gathering requirements to implementation and QA.
Conclusion
Scrum is the practical implementation of the Agile philosophy. Using the right manual or automated testing tool for Agile testing can speed up release time for new features by up to 400%. You can achieve sizable improvements as the product development alone, but going Agile the right way is a company-wide effort.Ā
Get the ultimate tool for Scrum testing with industry-leading AI tech
