Article summary
In an ideal project set up, as a tester, I would be involved from the start. That way, I would know what the project goals were, and what the tech was, and I could test stories as they were delivered. For many reasons, this does not always happen, so there are times when I can be brought on near the end of a project. Sometimes, they ask me to “give it a lookover” to see if I can find any serious issues.
With a limited time and budget it’s impossible to test everything so this post outlines the approach I take when brought into such a situation.
Client Concerns and Focus
What is the client most concerned about, and and why? Is it functionality, browser compatibility, responsiveness, accuracy?
Maybe they are happy the app is solid but want an accessibility check and report on any weak areas. Maybe they were only able to test on iPhones and want to know how it behaves on Android. Testing these areas would also bring to light any functionality issues. So, although the client may think the app is stable, doing additional types of testing can potentially reveal other issues.
They might also be unaware of some types of testing that could be done so this would be an opportunity to ask them about it and see if any gaps in testing need to be filled.
The Pareto Principle
The “pareto” principle is also known as The 80/20 Rule. What do, or will, the app users spend most of their time doing? If it’s an existing app then there could be analytics that point to what parts of the app customers are using the most. If it’s a new app, what are the most common expected use cases? And, of course, keep in mind that customers are always going to use the app in unexpected ways.
Alos, don’t forget to ask yourself: What parts of the app make money for the client? When testing an app it can be tempting to take diversions and test out the road less traveled (or tested). But, when your time and budget is limited, knowing the main areas can keep you focused.
Risk Areas
What parts of the code have changed the most? This could point to areas of weakness/uncertainty and an area to focus testing on.
Which are the newest parts of the code and so are likely to have been tested the least? Which areas were the most complex and gave the developers headaches? If it’s an existing app, are there areas where most bugs have been reported?
Happy Path
The areas outlined above should give testing some focus. If you don’t get any specific directions and have been given a general mission to “just test,” then go along the main happy path. As you go, note your testing ideas. Then bring these to the client’s attention and see which they would like to focus on.
With a little bit of prep, you can make sure your time testing the app is being used to its full potential. If you find any serious issues, then this can be the start of a conversation about why they should bring in testing earlier in the process.