Testing or Rubberstamping that is the Question! | Inflectra

Testing or Rubberstamping that is the Question!

January 5th, 2016 by inflectra

Have you ever been in this situation - the project manager arrives red-faced into the room, looking nervously at the calendar, "why is the testing taking so long? The development is done and we need to go live next week? You have had a good week to test the system, aren't you done yet"

When you are confronted with this situation, what should you do, what should you say? You know that the software is not ready for prime time, not even close! The developers spent months working on it, now you have less than a week before you need to go live.

You were supposed to be using Scrum and the team was meant to have tested everything first using automated unit tests. However time ran short, the user interface wasn't tested by the unit tests and the team found it too time consuming to use Selenium to automate all the UI testing (perhaps they should have tried Rapise?)

Step 1 - Provide Some Visibility

The first thing you can do is explain the process, show how testing fits into the overall software development and release cycle. If you use a test management tool like SpiraTest then you can calmly show your PM  the list of user stories in the release that need to be tested, you can show all of the different web browsers, mobile devices that need to be tested and all of the different use cases that need to be covered.


You can then plan from the amount of testing left what a realistic go-live date will be. Instead of just guessing, you have the evidence right there to show what it will take to actually test the system so that it will be ready for your users.

Step 2 - Let them Enter the Cave of Problems

Sometimes the rational approach does not work, time to move onto the emotive option. Find the worst examples of the bugs in the system, the pages that render in a giant vertical line, the pages that crash whenever you click on a button, sort your incidents by severity and show him/her some of the whoppers that would have gone out the door if the QA team hadn't been doing their job!

Step 3 - Time for Some Scoping

Sometimes there is a hard deadline and the PM will say "I hear what you're saying, we're not ready to go live, we have too many bugs and not enough time. But we have to go live, there is no other choice...". Now is the time to bring out that trusty chestnut from Consulting 101 - the Reverse Planning and Scoping exercise. What you do is look at the Planning Board, see how much time you have available and then scope what are the bugs you can live with, the ones that can be fixed in a point update, and the ones that absolutely have to be fixed, no questions asked.

Hopefully you can narrow down the list to a set of bugs that need to be fixed and tests that have to be passed. Yes, ideally you'd run all 200 regression tests, but using SpiraTest you can see which are the 50 that broke on the last release and the 10 that support all of the new features. If you could run just those, then maybe you can release... Similarly you can postpone certain features in the final release if you know that you cannot get to those tests in time.

The important thing is to align the requirements and tests so that the project management, developers and QA work together to see what can be done in the time remaining that gives the maximum functionality that actually works.

Step 4 - Time to Work on the Resume

Sometimes you will realize that the project manager doesn't actually care about the quality of the product, all he/she wants to do is wrap a nice bow around the system, claim that it has been tested and then release it out to the world, hoping that no one will actually find any bugs. That always happens of course...!

If all else fails and you can't make the team see that even working 80 hours a week isn't going to solve the problem and the release cannot be met, then you probably it's time to work on the resume and look for a place to work that values the role of the tester and truly understands that this is testing not rubberstamping.


testing rubberstamping quality