When to stop testing is the big question. How do you know? Should you ever stop testing?

Yes – over testing is real, and isn’t a good use of anyone’s time. I admit, when I first start any job I’m guilty of over testing as I learn the products, and I think that’s very normal for most of us. But, it’s important to be comfortable with your product and know it well enough to know when to call it good.

For me, a test plan really helps me to know when I’m done testing, or nearing the end. I also like to ask myself questions as I test that help me keep track of things as I go.

• Notice edge cases and write them down to look at later rather than losing track of where you’re at
• Keep an ongoing todo list of all the happy and sad path things to test
• Pay attention to permissions – if permissions play a part, what are the different states that are possible with your changes?
• What else does this touch? Write it down as you’re going along so you don’t forget and can come back to it with testing.
• What are likely things that could go wrong? (For example: maybe deleting/editing records puts the app into a bad state. Updated information may not display accurately (with/or without refresh) such as dates, amounts, budgets)
• How could a user break something related to your change? (You’ll want to test multiple paths to figure this out, not just happy path. I find that the way with the most clicks possible is what they tend to take 😂)
• How could a user use your code maliciously? For example: how could a user take advantage of our code to do something bad, like put in negative money in order to allocate themselves money if they can’t
• What absolutely has to work, that has no work around if it breaks? What is a nice to have, that can still have customers able to do what needs to be done without it working? What is extra, that has plenty of work arounds, but is just an added bonus if it works?

These questions, combined with good designs from UX, thorough acceptance criteria from PMs, and a good understanding of the targeted regression testing needed helps me know when I’m done. When I’ve done my functional, integration, regression, and smoke testing I’m done. But, how do you know when you’re done with each of those?

For my functional testing I am relying heavily on the acceptance criteria and designs. I check all of that very thoroughly, and look for edge cases that should be covered with other types of testing, such as boundary testing, exploratory testing, and negative testing. Once I verify the function (and hopefully my acceptance criteria has a definition of done to help me have further clarify), I am done with functional testing. For my integration testing I am relying again on acceptance criteria as well as knowing what else the code touches – is there anything not obvious? Does this new piece affect any other parts of the app, or is it more of a stand alone change? Then, I test all of those pieces, and when I’m done, I move on. For targeted regression I talk with the developers, and go to them with a game plan. I plan to verify x, x, and x. Does it touch y? Does it touch/affect anything else? I also will check things that tend to break each release, even if I’m told they aren’t touched and verify they are still working. I keep track of what has been done, and write a brief description of what I verified on the ticket. If it’s a high risk ticket I’ll ask for a second set of eyes to be sure I didn’t miss anything, and if it’s a feature that has gone back and forth on how something should work I’ll also sync up with the PM when I’m done and tell him what I verified and the functionality I saw along with any concerns I have.

Once I feel confident, I ask my self what the worst thing is that could happen if this new feature doesn’t work, and as long as I’ve accounted for that and tested thoroughly, and any risk left is minimal and known, I call it good. If I’m ever uncertain I speak with the devs and PM on my team, and they can help alleviate my fears, or agree that it’s worth delaying the release a bit longer while I verify A, B, and C. Communication is key in feeling confident in knowing when testing is done.