Dear Agony Ant,
I’m working on a project with tight deadlines, and I feel pressured to skip some test cases to meet the schedule.
Is it ever acceptable to cut corners, and how can I balance quality with deadlines?
I feel pressured to skip some test cases to meet the schedule. Is it ever acceptable to cut corners?
6 Likes
Generally speaking, it’s acceptable to cut corners, sure but it depends on circumstances, risks, and the “size of the corner” 
sometimes you have to say NO as a QA professional but you have to be reasonable and provide an explanation, and explain risks. Still, you can be pushed to “cut” significant and critical parts of QA procedures and testing but you shouldn’t accept responsibility for this, we can’t stop all the fools in a company from making mistakes and harmful decisions for the business but we can take steps to give them warnings and minimize risks and take the responsibilities off your shoulders because it wasn’t your decision.
The strategy to balance quality with deadlines might be quite complicated and many things may be taken into account but it depends on the particular context. Just for the sake of example, a couple of posts that I’ve written recently (and these ideas are just the tip of the iceberg) to demonstrate some approaches depending on your circumstances:
4 Likes
I cringed when I saw this question. If I was a crowdstrike employee, today I’d so no. Whether they skipped tests or not, I think it’s better to find a way to execute the identified high risk areas first and if you have low risk areas then you’d have to make sure everyone on the team agrees with cutting.
1 Like
In the first place, try to be in a position where you’re not forced to think of cutting corners.
This is a recurring pattern I see in the IT industry. The AUT comes a wee bit late to the Tester’s table and we’re expected to rush through things in order to meet the deadlines. And if there’s an issue, the blame later falls on the QA.
Ask you manager or lead to stand firm and say that you’ll need more time to test and outline the risks of cutting corners.
Sadly though, we don’t live in an ideal world. And the scenario you’ve mentioned comes cropping up every now and then. When you’re in a tight corner and there’s no room to maneuver then follow this approach:
- It helps to do a risk assessment of the use cases and the test cases. Try and see if you can skip the test cases which might have the least impact on the project.
- Prioritize and skip the low priority test cases (but don’t miss to do a sanity check).
- Here’s where Automation will come in handy. Use Automation to do regression and check other time consuming scenarios and focus only on the current deliverables.
In the end, do let the management know that you were forced to skip some test cases and cut corners due to meet the schedule, so that the blame doesn’t fall squarely on your shoulders in any event.
2 Likes
Cutting corners is very different from making a time and scheduled based decision to actively optimise your testing given your constraints.
Lets say I estimate 5 days to test and app, with that estimate I have given a decent indication to my stakeholders of my coverage and depth of coverage that I’m planning on.
In reality I can test the same app in an hour or in 20 days but the thing that changes will be my coverage and depth of coverage.
We test within constraints all the time. The most important thing is to communicate and make clear what you are testing and what you are not testing as a result of those constraints. Flag risks you feel would be left uncovered if you cut your testing.
Let someone else then make the call if its acceptable.
Sometimes I will make that first round acceptable call myself and go ahead and test within constraints, but I’ll always flag the coverage, depth of coverage and potential risk if no more testing is to be done. This is pretty standard in my view in software development.
4 Likes
As a QA - I would ask “Define cutting corners”.
As mentioned in other replies, it is down to the risk and the size of the cut.
Why schedule specific testing if they are not needed - hence why could you consider cutting them in the first place in that respect?
For me, I would consider the deadline to be inappropriate for the work that is planned - although there has to be ‘give and take’ more likely with business or product owners (depending on the situation), for sure explain the reason for the test schedule, if anything meant you started late, and ensure that you get someone with ‘authority’ to agree to run at risk. (Cover your back).
Big thing - do not get into a situation of ‘learning by mistakes’, and a recovery from a fallout of skipping testing. ‘Learn’ from missed scenarios, not from cutting corners.
Automation and Manual testing are ‘great’ but only cover previously realised scenarios - I would advise directed exploratory testing of affected (and indirectly affected) areas of change. (but will need to be timeboxed)
Structure to the test plan/approach is the key - you will never find ‘everything’ 
(And yes, I had this conversation many times with senior management, which has also been proved correct on many occasions!)
When testing a non-trivial product, the possibilities are infinite. Your obligation is to make the best use of the available time and to inform the stakeholders of the remaining risk. It’s their decision whether to accept that risk or to allocate more time for testing.
Don’t be fooled into thinking that testing is complete when you have executed all your test scripts. In reality, you have done a tiny proportion of the tests that could be done. Doing a few more tests doesn’t change that much. There is no such thing as “complete testing”, and even if there was you would never have time to do it.
Point 1 - If you are the individual making the go-no-go decision, and you have been made aware that corners have been “cut”, then it is up to you to figure out if the risk justifies the reward.
Point 2- If you are testing and have been told not to test things, or to reduce the scope of testing, get it in an email and keep it safe.
Point 3 -Just because a team lead, boss or even the CTO hints, suggests or infers you should cut corners, see point two.
In these situations, for me, the key is communication.
I make sure I communicate the situation in a way that my stakeholders understand. If they still want to cut corners, then we cut corners. But they need to be aware of the risks and potential impact that the corner-cutting will have.
For the second question: Yes it is always acceptable, if the stakeholders have made an informed decision about it. So the key is to provide the right information/intelligence to them. It is not, in my opinion, a tester’s responsibility to balance quality with deadlines - that is a task for the Product Owner/Project Lead/Producer. But they need the right information/intelligence to do so responsibly. It is a business decision.
Those are my 2 cents anyway 
Johan
1 Like
Hi, its all depends on the context and why the deadlines matter.
Some deadlines are arbitrary - we have to pick this date because someone will oose face if not. Others are more fixed - if we dont go now we delay something else/risk competitors getting there first/cant release again for x months etc etc
As QE professionals, our job is to provide information to those who are running projects/workstreams etc with in order for them to make informed decisions based on those facts. I have to agree with previous comments on this.
We never find it easy to cut back on testing but its all a matter of risk. If someone asks you to cut back on testing, always ask why so you understand what’s behind it. Then look at the risks of doing so, and provide them that info, and get any decisions in writing.
Had this many times over my career - the first few times are hard, but it becomes easier once you understand the background and the risks.
Some of our teams work with time-based testing. So instead of estimating how long it will take them, they have 1 or 2 weeks to get the release testing done.
To prevent not getting around to important tests, they rank the tests by importance and start from the top. If they run out of time, only the nice to have/low importance things are left untested.
1 Like
There is a very popular meme that I like to quote at times like this meme
I’m just using this poor person’s blog as an example, but they actually do go on to explain the meme, so worth reading the blog. Basically your DO NOT HAVE TO RUN EVERY TEST for every single one-line code change, it makes no sense to run all tests if only one line changed, so why do we run all the tests if only 100 lines changed? That’s as good an answer as you get on why it’s OK to test less, because when you test less, you allow yourself to find new bugs that nobody thought of yet instead.