Friday, 26 February 2010
Tuesday, 23 February 2010
There were a number of people who didn't get the cartoon about differentiating between a good and a really good tester. For those who didn't get it or like the cartoon, thank you for return to this blog again :o)
The idea behind the cartoon is that it can be very difficult to assess the performance of a tester, this can be specially hard during the recruitment process. For example, a tester with a testing qualification (ISEB/ISTQB) does not necessarily mean they are a good tester (nor does it mean they're a bad tester!).
I’ve been recruiting testers for around 4 years and it’s not getting any easier. It can be very hard to determine if the candidate is actually any good at testing, it's one thing giving answers to questions in an interview but it's completely different testing real applications. If I had to give any advice, I would recommend employing testers who you think are suited to the culture of your work place; would you get on with them? Would other testers/developers get on with them? Also, for our workplace, it’s important that the candidate understands what type or style of testing they are getting into: is it heavily documented? What SDLC is used? Is there a requirement to use automated test tools sometimes/all the time?
I could give you more advice on recruitment, but I'm afraid I would have to charge you and I couldn't guarantee the advice would be of any use.
Friday, 19 February 2010
Monday, 15 February 2010
Thursday, 11 February 2010
Monday, 8 February 2010
Thursday, 4 February 2010
Every so often, you hear a manager or developer or even a tester saying: “Lets migrate ALL the manual tests into automated scripts. This will be better because blah blah blah”.
To combat such foolishness, I have designed a picture to print out and pin up by your desk so all your visitors can finally understand the truth; it’s brain power of a tester that identifies and reports bugs and a developer who removes them, and not an automation tool (unless of course someone else identifies the bugs, but I don’t want to talk about that right now).
To add even more impact to the print out, you could colour it in :o)
Monday, 1 February 2010
Here's the second one in the series on "No user would ever do that!" (or "that's not a bug, it's a feature!" or "that's not a bug, it's a user error!")