Reply to: Permie surrealism

[Mich the Tester]

Seeing as I only started a couple of weeks ago, I'm taking over a test process which has been, to say the least, problematic. Here are the roots of the problem;

1 Clientco failed to specify the software on time for the developers and testers. Developers therefore started building without a spec.

2 Clientco chose plenty cheapness above quality for the testers; they tried to test everything with users, and only now have realized that you need professional testers if you're going to test complex interfaces properly.

Users wrote the test cases such that there are too many dependencies on the whole process working; a professional tester would try to avoid this and ensure that one finding doesn't block too many cases.

In other words, the usual story.

[worzelGummidge]

It sounds like you have only found seven errors because a number of those seven errors are preventing you from accessing functionality within the software that would highlight other inconsistencies between the specification and functionality that would highlight further errors, about 243 by the sound of it.

[HeadOfTesting]

I feel Mich is possibly not thinking sufficiently outside the box here.

If one or more errors prevent most of the app from working, then any test that relies on that unavailable functionality fails by default. So if the test plan involves hundreds of "blocked" test cases, all these have automatically failed ness pah?

And with that blinding flash of insight I'm off to bed. Must be on tip-top form for the client tomorrow don'cha know.

alas, "failed" and "not run" are treated as distinct states in testing land

[NickFitz]

Indeed. Once the small number of blocking issues are out of the way, you'll be able to expose the remaining 240 issues. Unfortunately this will be the day after he has to deliver his report.

Then he'll have to deliver a report explaining why he didn't anticipate such a large number of issues.

And round and round it goes...

If you feel like lending this chap a hand in explaining why he can't write a report about things that haven't yet happened, without getting too Wittgensteinian about it, you might want to point him to the field of motoring analogies:

How comfortable are the seats?
We don't know, the doors won't open.

How bright are the headlights?
We don't know, the battery won't charge.

How does it handle under braking?
We don't know, the engine won't start.

He might be able to convey the significance of your seven showstoppers to them that way.

[NickFitz]

I suspect the huff was because you are unable to access the other 240+ errors yet.

Indeed. Once the small number of blocking issues are out of the way, you'll be able to expose the remaining 240 issues. Unfortunately this will be the day after he has to deliver his report.

Then he'll have to deliver a report explaining why he didn't anticipate such a large number of issues.

And round and round it goes...

[OwlHoot]

I feel Mich is possibly not thinking sufficiently outside the box here.

If one or more errors prevent most of the app from working, then any test that relies on that unavailable functionality fails by default. So if the test plan involves hundreds of "blocked" test cases, all these have automatically failed ness pah?

And with that blinding flash of insight I'm off to bed. Must be on tip-top form for the client tomorrow don'cha know.

[d000hg]

"Forget the number 7. The software is so broken we can't get far enough to test anything."

I'm not sure what the permie did wrong. He told the higher-up people the deadline was unrealistic and now wants to give them the kind of evidence he thinks they'll understand - a big number of errors.
The whole "Well, as long as it's not my problem I don't give a crap" response puts Mich in the wrong unless I missed something.

[Not So Wise]

PTL; 'because the board of directors gave me an unrealistic deadline'

MTT; 'and you didn't tell them their deadline was unrealistic?'

PTL; 'I did, but the problem is I need to prove that to them now and I need many more issues to prove that I was right about the deadline!'

Response at this point should have been:
'Unfortunatly you did such a bad/great job we cannot access your other 243 errors because the first 7 are so big'

[mace]

If you find 250 errors, you'll upset some of the developers plus the CIO. If you stick with 7, you upset the technical architect. I'd stick with 7.

[dozer]

250 you say? you can do a lot of invoicing retesting all of them, good times

[Zippy]

I can see where the PTL is coming from. But why they got in a huff I cannot imagine. You're doing them a favour.

I suspect the huff was because you are unable to access the other 240+ errors yet.

If the directors are too thick to accept the estimates of the people they pay to develop the interfaces, they are going to be too thick to grasp that blocking issues are as bad as it gets. Only 7 errors - great - we were expecting 250.

Had that stupid f-ing conversation. Utterly pointless

[swamp]

Does he sign your timesheets?

no

smile and think of the money

[RichardCranium]

I can see where the PTL is coming from. But why they got in a huff I cannot imagine. You're doing them a favour.

I suspect the huff was because you are unable to access the other 240+ errors yet.

[Mich the Tester]

Does he sign your timesheets?

no

[swamp]

Does he sign your timesheets?