Test Escape Reports

We just had a big launch at work, which of course leaves me thinking about test escape reports.

I have mixed feelings on test escape reports, and for a long time I didn’t want to use them here. My reason being that if you have a small test team, and you know everyone is really dedicated and working hard, then the occasional test escape is to be excepted and we shouldn’t harp on them.

However, I think over time I’ve seen the other side of this issue. Test Escape reports ensure stakeholders that you are on top of any issues both before launch and after. They hold the team accountable, not just for the issue but also for the resolution and prevention of it in the future.


The format we use is simple:



Reason missed:

Steps taken to cover functionality:

Test cases numbers for verification:


The point being not to look backward, or to blame someone for missing a bug- but to look forward into how we can test that in the future and how we can avoid over looking similar areas on other projects. The goal is to improve visibility- we admit our mistakes, take steps to correct them and let everyone take comfort in/participate in the improved coverage.

How do you handle missed bugs? Are test escapes’ a whole team problem or an individual tester’s problem? Is there a formal process surrounding them?


2 responses to this post.

  1. Wow ! awesome! This is so much easier then the old way!!!

    Great read!
    ❤ Kelly


  2. Nice post, I liked the way you turned Escaping Defects into ways of using visibility to create accountability and trust, I need to admit I never saw it this way but it is brilliantly simple 🙂 Thanks!

    We also use escaping defects but we use them to review our complete process. Since every company (even us) releases products with known bugs, we use it to validate our release assumptions and so we also review if the bug was known and differed and if the assumption to do so was correct.

    It helps us to understand more than only if we need to improve our test cases (which many times we do). We also try to aggregate these numbers over time and benchmark between projects, this way we try to understand if the stability of the released product was what we wanted to.

    I wrote about it in my blog, one of the posts is this one: http://qablog.practitest.com/2008/01/process-quality-feedback-and-escaping-defects/.

    Again, thanks for helping understand we have something more to gain from them.



Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: