Provocative advice for testers who don’t know what to do
Dear Evil Tester…
“My team only seems to care about defects, they don’t seem to care about testing, what should I do?” Signed, (I can’t read that, it doesn’t matter, let’s call you…Earnest)
Answer…
Well Earnest,
(This really is a valid technique for coming up with test ideas, I might have just twisted it a little.)
Yeah that happens. You spend all that time writing test cases and scripts and producing a big test plan (that they still haven’t signed off!) and then all they care about are results! Well they count it as results, you count it as one of your many valuable outputs. And if you spend all of your time raising defects you’ll never get any testing done.
It’s a strange life we testers lead. Defects stop us achieving coverage. Coverage leads to more (and presumably ‘better’) testing and yet people only care about bugs.
Well here’s what you could do. Yes, I don’t recommend this. And yes I haven’t tried this. But hey – you caught me in a good mood. So I’ll tell ya.
Options:
- Buy lots of bugs, you know those creepy crawly, 6, 7, 8, 9, 100 legged beasty things, and just leave them running about the office and see how they like them apples.
- Find an open-source project’s bug database and just screen scrape the defects into your tracking system – Bam! Hundreds of defects from one automated script (see, learning automation has its uses)
- Just keep raising the same defect over and over again. At least this way you can tell if they’re even reading the things!
Ha. But of course I’m just kidding. They are all ridiculous suggestions.
So seriously now… In the testing world people spend a lot of time talking about metaphors, and heuristics, and similes. You know stuff that is like the thing, but is not the thing, but seems like the thing, and reminds you of the thing in ways that the thing is kind of like but isn’t. Stuff that triggers thinking and imagineering but isn’t really test design, you know, that voodoo hoodoo testy magic stuff *they* talk about but isn’t *real* test design. Yeah. Yeah. You with me. Yeah sister. So how does that help you here? Well. You know how people go on, and on, about requirements? And how the software has to do all the stuff that the user wants? And requirements are supposed to represent what the user wants? But when you implement the requirement and the user sees it and they are all like “hey what is this” and all “I don’t like this” yeah, and even “I didn’t say that, who said I said that, did you add that one when I wasn’t looking, who signed these off” etc. etc. etc. (But we all know how much fun it is to sneak those extra requirements in, so we don’t want to stop doing that, otherwise software development just wouldn’t be fun any more)
So really, we could think of requirements as metaphors or similes, you know, then dev teams can riff off them to come up with software that is kinda like the requirement, so it might come close to filling the users need, without all the hassle of really dealing with the requirements, which let’s face it, no-one knows the requirements anyway. Well we can do that too, to find bugs. So. Here’s what you do.
Pick some software, any software. Say, oh I don’t know… a search engine. And let’s say you’re testing a, oh I don’t know… an accounting package.
Well what you do is look at the functionality of the search engine, identify all the functionality in that, and then try and do the same stuff in the accounting package that you are supposed to be testing. And if your accounting package doesn’t do the thing- hey, you just found a defect.
So try and search for “evil tester” in your accounting package and see how far that gets you. It didn’t work! Bug. Type in “evil” and look for the quick tip completion drop down. What, it didn’t appear? Bug. Try and click on the “I feel lucky” button in your accounting software. What, you can’t find it? Bug. See – three bugs in 30 seconds. And you could keep going, just look for another piece of software and map it on to yours. Bug Bug Bug.
Of course you’ll get the normal objections from the dev team “The requirements don’t say that!”, “The user would never do that!”or “It works on my machine!” But hey, you’ve heard those excuses before; they won’t stop you. Keep going. Your bug count goes up and up and up. And that was what they wanted! Right! Great – go do it.
WARNING
This advice might even get you fired – but what do you care? If you’re writing to the Evil Tester then you probably hate your job anyway.
So…
So hey, go do your… testy stuff. Hope that helps with your problem Earnest.
Yours sincerely, all the best, Hugs and kisses, etc. from all @ EvilTester.com
“If you have a question that you would like The Evil Tester to answer then please head over to the following form : https://softwaretestingclub.wufoo.com/forms/ask-the-evil-tester/ and submit a question.
If your question is selected you can read the answer from The Evil Tester in the next edition of The Testing Planet.“
No comments yet.