Sunday, 28 February 2010

Set Phases To Stun

A rigid waterfall style project can still present a tester with opportunities for mischief. Or a chance to educate people about other ways.

A good opportunity is when you find defects away from running scripts. Even better is when you find them when the official testing phase is over ( maybe not better for the project but better for the education opportunity )

Tester: Hey, boss, I found a couple of defects
Boss: How could you do that, we've run all the test scripts
Tester: I wasn't using following a script, I was exploring the system and found a coupla problems
Boss: < silence as he tries to get to grips and understand how it is possible to do this >

So this is Opportunity #1 to do some education about testing. You could always wave a copy of "Perfect Software" and say "as Jerry says in this book..."
Probably not the best idea, though, to ask The Boss if his illusion has been shattered

Now, having found a defect it has to be logged

Tester: So, boss, what test phase should I log this under ? System test ?
Boss: System test is over, we've run all the tests and had it signed off as complete
Tester: But it's the same code base. How about UAT phase ?
Boss: Well that doesn't start til next week
Tester: ( to himself ) Right, the daily reports would look strange with no tests run and 2 defects found

Opportunity #2 - an explanation of exploratory testing and might it be a good idea to schedule some at the end of scripted testing.

All done ? Not quite, one more opportunity whilst the boss is feeling vulnerable as he's just realised the security guard in the red shirt has just been bumped off

Tester: So, boss, if I log these 2 defects then wont our defect count be over the entrance criteria for UAT ?
Boss: ( checks the figures ) yes it will
Tester: Remember that conversation we had at the start of the project where you asked if there was an industry standard for the number of defects and how the test plan had to have a specific number...

Opportunity #3 - an explanation of how a simple defect count does not really provide the information you need to make decisions

No comments: