One of the most common challenges of following Scrum is not figuring out how to build software quickly, but how to test it. Many teams that are new to Scrum start by following a mini-Waterfall cycle which is somewhat similar to the following approach:
Week 1 of the Sprint: Design the application.
Week 2 of the Sprint: Code the application.
Week 3 of the Sprint: Test the application.
This phenomena is common to teams that are learning to plan and execute work differently, and some teams never get out of this mode, which means the team is losing out on some of the efficiency gains that Scrum could have provided.
The mini-Waterfall approach is simpler for teams to adopt than truly becoming “agile” because they are accustomed to this way of working and thinking. In order to break out of this mold, finding a different approach to testing is a critical piece of the puzzle that many teams struggle to find.
One of the core tenets of Agile software development is “build a little, test a little”. My view on this is slightly different; I prefer to think of it as “plan broadly, figure out how to test incrementally, build a little, then test a little”.
So how does this work? Here are a few tips that will help explain this approach.
Tip #1 – Plan your tests early; use TDD (Test Driven Development)
TDD is one of the most popular concepts that originated from XP, Extreme Programming. The idea is that you should plan (and write) your tests BEFORE you write code. Why do this? There are many benefits to writing your test case prior to coding. One such benefit is that you think through what “correct” looks like before writing code, so that when your code is written, you can quickly validate it and make sure it actually works as expected.
Tip #2 – Leverage Continuous Integration (CI)
Setting up a CI environment and the corresponding tools is not necessarily simple, but it is a worthwhile investment if you are able to get through the initial challenges. Having a CI workflow will allow your team to identify defects early and often without a lot of effort, which will let the team fix the issues early in the project instead of waiting till much later to find/fix them.
Tip #3 – Engage your test specialists early
Many new Scrum teams struggle to “find work for the testers” early in the project because “there is nothing to test”. The early stages of a project, as well as early parts of each sprint, is where your test specialists should focus on building the test cases and test scripts in preparation for “testable code” to be available. One possible configuration to explore is to pair up a developer with a tester and have them work together as a TDD team; they can develop the test process before code is written, then refine the scripts incrementally as the code matures over time.
Agile testing can be challenging to figure out because it involves many practices that many teams are not used to following. The biggest suggestion I have is to start small; pick something that is achievable in the short term, give it a try, and go from there.
Are you ready for your next Agile Testing steps? Here are a few courses to check out that will help get you started: