Hey Reader,

I got a question about test coverage recently, so I thought to draft this email.

When you hear “test coverage,” what pops into your head?

Most testers think: “How many test cases have I covered?”

And honestly, that’s not wrong. But it’s also not the full picture.

Test coverage isn’t really about the number of tests.

It’s about confidence - how sure you are that the important stuff won’t break.

So, let’s break it down.

Thinking broadly - that’s about asking: “What all could break here?”

Not just the happy path, but things like:

• Different user roles
• Various data conditions
• Integrations with other systems
• What happens if something fails

If you’re new to QA, it just means: don’t stop after one flow works.

Look around and ask, “What else touches this?”

If you’re senior, it’s more about focus: knowing which areas deserve attention and which don’t, based on risk, not habit.

Now, thinking deeply - this is asking: “What happens when things go wrong?”

Edge cases, failures, weird behavior… things users actually do that we don’t always plan for:

• Empty or invalid inputs
• Clicking twice by mistake
• Slow system responses

Juniors can start with simple questions like: “What if this field is empty?”

Seniors think bigger: “What breaks downstream if this fails? How will customers notice?”

When time is short, I like to think of tests in three buckets:

• Must never fail (Business workflows)
• Can break but not critical
• Nice to have / cosmetic

Focus on the most important things first.

Remember, it’s not about testing more - it’s about testing the right things.

Let's meet in next email

- Swaroop Nadella | LinkedIn​

P.S. I’ll keep sharing short, practical stories and tips often in this email newsletter - no spam, only things that help you as a QA engineer.

You can read my previous email articles published here.