The ministry of testing have a bloggers club, and each month they post a different prompt. I’ve not written anything for the bloggers club for a while, and decided to give this months prompt a go.
The prompt: How do you reduce Scope?
Disclaimer: The first part of this post is an example of a bad way to reduce scope and purely satirical. DO NOT take it seriously. Scroll to the end of the article for some ‘better’ ideas for reducing scope.
Bad Idea: Reduce scope by giving in to the demands of management
Testing is a bottleneck! All testing does is delay releasing essential features which costs the business money. Regardless of the amount of testing that takes place, bugs still occasionally make it through. Why didn’t these issues get picked up by testing? What is the point of all this testing?
Testing needs to be reduced so we can release sooner. This can be achieved by doing only the bare minimum. Think MVP (Minimum Viable Product) – what is the minimum amount of testing that can be done ensure that the feature ‘works’. Can the application be launched? Does the feature ‘work’? Forget bugs, forget risks, if the feature ‘works’ then it can be released. After all, developers will have tested their own work. What is the point in asking some ‘testers’ to test it as well?
It does seem to be that even when enough time was allocated for testing, the testing team still seem to want to delay release. Why hold things up? Testers need to organise their workload better so that a deadline can be met. Just because the developers took longer than expected to complete their work doesn’t mean that a release should be delayed just because the testing was not completed in time.
Delaying a release can cost businesses a lot of money. Testing is usually what holds up release so is the obvious place to descope the work. Testers often complain about having too much work to do and constantly being under pressure. They should take their jobs less seriously then they would find the amount of pressure they are under greatly reduced.
What will happen if a bug is found post-release? Duh, it’ll be fixed! The development team will drop everything and fix the issue. This may cost more in the long run, and delay other essential development work, but the chances of this happening are actually quite low. Work has been released before with little or no testing, and no issues have been reported. Besides, testing can always be descoped again so the team can catch up.
Why do companies even have testers? Let’s entirely descope testing!
Better Ideas For Reducing Scope
Introduce Automated Tests…
Make sure that automation is included in the definition of done. This should include updating any tests that may be impacted by a change, and developing new tests so a new feature is covered by the automated tests.
It may seem like introducing automated testing is increasing scope, however it can help reduce scope for future projects. It means that if a feature is identified as low risk, and there are already automated tests that cover that feature, then testing this feature manually can be descoped. This frees up more time for testing areas identified as higher risk.
…But Keep Automation Brief
Automation will increase the scope, but don’t increase it unnecessarily. By creating complex automated tests that cover an excessive number of scenarios, you are unnecessarily inflating the scope of the tests. It would also make the tests difficult to maintain, further increasing the automation scope for future work. Make sure the tests only cover a few essential scenarios, enough so that if something went seriously wrong then they’d pick it up.
Automated tests are unlikely to test an application as rigorously as a human tester might. However, in the case of features that are unlikely to be impacted by a change, such in-depth analysis isn’t always necessary. Automation can be used to check that no unexpected bugs are introduced when a change is made to a seemingly unrelated feature. If a particular feature is likely to be impacted, then this risk can be mitigated with additional manual testing.
Speak to colleagues
Developers know the most about the code they are writing, therefore will know the most about what is most likely to be impacted by any changes to the code.
Managers will have first hand knowledge of the needs of the business, and could provide details of reputational or financial risks.
Customer support teams actually speak to customers and understand the challenges they face.
Building up domain knowledge from all areas of the business can help testers understand what is important and what is less important, and identify what could be safely descoped.
Shifting Left – Testing Sooner
This isn’t so much about reducing scope, but better managing the workload. Start planning what to test as soon as possible, ideallybefore the developers have even started the work. Once the work is complete you will be ready to jump straight in. Furthermore, having a plan already in place will enable you to provide more accurate estimates to management about when the work will be complete.
It isn’t just planning that can begin before the development work is complete. You can also start testing earlier as well. Asking developers for a pre-release build provides the opportunity to get an initial look at the feature and provide some early feedback. Bugs found earlier in development will be cheaper to fix. A bug found post-development will need to be fixed and retested, adding to both development time and testing time during and delaying the release. If the bug was found during development, the developer could fix it while they were still working on the feature, limiting the overall impact.
No matter how much we try to descope the work, if bugs are found that have to be fixed, then all these attempts at reducing scope will be for nothing.
Breaking Down The Work
Anyone who works in teams that use the Agile Scrum framework will probably have good experience of this. Breaking down the work into smaller increments, makes everything much more manageable. The main idea, break down the time into smaller sprints of about 2 – 4 weeks long. Each sprint contains a small chunk of the work, with a shippable product being produced at the end of the sprint.
With smaller chunks of work which have been tested and signed off, and a shippable product already available, it is easier to identify additional work (not necessarily tests) that can be descoped. This also reduces pressure on testing as certain components will have already been tested. A large chunk of testing can be descoped if something has already been tested, and the changes made since are low risk.
Bloggers Club April 2022 – How do you reduce scope?
A link to the discussion in the Ministry of Testing Club. See what else people have posted in response to this months bloggers club prompt.
7 Reasons to Skip Tests
An article I wrote a few years ago where I discuss reasons why sometimes its good to skip tests.
Shift Left or Shift Right
Another blog post I wrote in response to an Ask Me Anything event run by the Ministry of Testing. Links to the recording of the AMA, and the additional discussion can also be found here:
- Ministry of Testing Club – Shift Left and Shift Right discussion
- Testing Ask Me Anything – Shift Left, Shift Right – Marcus Merrell
A useful article published by Agile Alliance which describes gives some more information about Agile Scrum.