Most of the time, I am at the edge of the deadline and testing everything is nearly impossible. That moment of choice of what to exclude is hard does one follow risk-based thinking, does one fall back on past experience, or does one sit down with stakeholders and hammer something out?
It would be great to learn how the large community puts these choices into practice and what works best for you!
Hello,
In my experience most of it is based in intuition. Being a part of the team you know for sure, which impacted area I should go after first and which part I must test 100 per cent, now this might be bit controversial, being a tester you also tend to know the work of your team ie: if DEV A has done this there likely will be less issues because you know their work ethics & coding style.
Another important part: to save these hassle, pro tip would be to try test at PR level. Once the PR in review, rule out few issues there and then. (It will come with time)
You can also apply 80:20 rule Pareto Principle. 80 percent of issues could be just in 20 percent of code change. So when time is less, make sure to at least test the impacted areas. Rest you can test later.
Hope it helps!
If tight on time in an ideal situation I would get buy-in from the stakeholders over an agreed plan on what to test based on the identified risks. If that isn’t possible then I would fall back on my experience and test what I personally think are the risks present.
The obvious answer was already given by Adrian: tests should have a priority attached, usually assigned from a combination of frequency of mishaps and severity of those mishaps. And you would test it “down” from the highest to lowest priority. Other criteria could be bugs that happen often, stuff, the stakeholder desperately wants to have and so on.
Usually, I try to find out what’s most important for the business and also try to factor in risk and complexity. Run automation for whatever I can, if there is any coverage for those features, and try to give a bit more attention to newer features, and for older, more stable features, they can be tested more shallowly. Sorry if the answer feels a bit general, but without specifics about the project and the product, this is what comes to mind.
Hi Ramanan,
I believe that testing under time pressure is common and sometimes tricky to decide the way forward. I typically focus on the impacted area since we can determine this based on our experience and set priorities appropriately. The top priorities would be prioritized, and the rest would follow, in order to complete testing on time.
Great question! When I’m under time pressure, I usually lean on risk-based testing focusing on critical paths, high-impact areas, and features that have changed recently. Past experience helps prioritize, but quick syncs with stakeholders also guide what can safely be skipped. It’s always a balancing act!
Working with the business side to know what is a deal breaker vs a “we can live with it” issue. For one of the tools I support, if a user is unable to move forward, that kills productivity, so any “halting” bug is an immediate issue and needs to be fixed. I like to collect the general heuristics of things that are immediately DOA for the business so I can focus on where I think those would come up the most.
Another good rule of thumb from my former CTO: “Where does the dev feel least confident in their code?”. It could be some innocuous method that required more finagling than expected, thats probably a good place to look first.
Speak to the developers. They will (hopefully) already know what has been tested by themselves and may have their own concerns. They’ll have unit tests and (hopefully) further automated tests in place.
Then use that, business priorities and of course my own intuition & experience to come up with a plan. Share that, asking for objections, and crack on.