How Long Will It Take You To Test…? – Part 2

“Do you have enough time to test?” 

Every time I hear this question, I can almost hear Admiral Ackbar yelling “It’s a Trap!”

As if we’re going to get more time if we need it.  Or, if the release date does actually slip to allow more testing time, inevitably scope creep comes into play and we’re back where we started; too many things to test and not enough time to test them.

“It depends” comes back into play as the “go to” response to the question.

“It depends, how much testing needs to get done?” 

This is a great opener to start the conversation on testing breadth versus depth.  Some managers or developer leads might start to get glassy-eyed as you ramble on about being able to execute dozens of test cases to ensure that one API is bullet proof but, in the time it takes to execute them, no time if left to test the 20 other APIs.  The other option is to take the same amount of time, and execute one test case against each of the 20 APIs.  This ensures that, in that one case, they all work as expected, but leaves a large risk as to how resilient the code actually is. 

Can you say that the code has been tested?

Sure!

But tested well?

Not really.

So, if you had more time, would you test more? 

I would hope so.

“It depends, is there something that doesn’t need to be tested so I can spend more time testing something else?”

Now, it’s the manager’s turn to hear Ackbar’s famous line from Return of the Jedi.  You’re asking for a pass; absolution if you will, on passing over chunks of code and functionality in favor of giving your time to some other features more deserving of your attention.  If a bug gets past you and it’s found in this “Manager Approved Pass Over Area” of the code, you can at least say “You told me not to test that.” 

Personally, I hate letting any bug get past testing and into Production, but it happens.  I’m sure to cover that topic in future postings. 

But overall, the conversation of “What are the risky areas in this build?” is one that all testers should have with their development counterparts.  It’s a conversation that I myself have almost daily. Seriously, just today, I asked this question to three different developers.  I got three different responses and cried a little inside, but the conversation was good!

Overall, letting the team know what was tested, how much testing was done (depth versus breadth),  and what was not tested or not tested as thoroughly due to time constraints, is highly recommended.