When your stats are telling the Test Manager a glorious lie…Jump Ship

Last night I was told an incredible tragic story. With kind permission of my friend I will summarise it here. I will also apologise now, for my version will not be as funny as the original. It was tragic, but told with great enthusiasm and with

My friend, a senior tester in a large organisation, was asked to explain manual testing (and justify the need for it) to the Test Manager. Yep. You read that right. The Test Manager was asking a Senior Tester to explain testing.

In essence the Test Manager was probing for reasons to keep (or not keep) the test team. It looks like budget cuts and other financial pressures were demanding a drop in head count. After a rather good description of why testing is important and why skilled individuals are needed the Test Manager got hung up on the idea of Test Cases. It turns out the Test Manager couldn’t detach testing from the Test Case or the tests container to be more precise.

It seems obvious to me that this Test Manager believed testing was nothing more than a Test Case. The person running the Test Case needed no other skills than maybe a little domain knowledge and the ability to operate a mouse. It’s a common view held by many in and out of the testing world. It’s a view that irritates and mocks me but none-the-less it’s a view that exists, rightly or wrongly. (That rhymed by the way. By accident)

After my friend explained testing to the Test Manager he was pleased. And rightly so. He’d done a good job. His explanation would have won awards from the Plain English Society.

He explained the human critical thinking side to testing. The experience a tester can bring. The levels if investigation a tester will go to, to root out a bug. The awareness levels a tester has. The unique thinking a tester can bring to the table. He’d expertly described Exploratory Testing (by paraphrasing a few testing gurus)

He’d not forgotten to mention the ability to make judgement calls in the face of changing priorities and commercial pressures. He’d woven in a nice little thread on being able to look past the facts and see the truth (I’m doing a blog post on this soon…). He’s waxed lyrical about testing early through automated tests leaving highly skilled testers to explore and feedback. He’d mentioned how testers approached software development from a unique angle.

His outline of why testing is important and why human testers are needed was award winning. He’d Incorporated testing in to the delivery of good software and without an ounce of “Gold Plating”, “Blinging” or “Bigging Up”. I gave him a standing ovation.

Apparently after this mini training session the The Test Manager sat back in his swivel chair (James Bond Villain style) and laughed “muhahahahahahahah I admire your arrogance” <– Note – this bit is actually true.

The Test Manager, it seems, didn’t share the same view. He was still hooked on Test Cases being the testing. “Get some seniors to write the tests and juniors to execute” was what he said. “We can cut costs even further by automating everything”.

This whole incident happened about 3 months ago. Since then they’ve got rid of some good senior testers and brought in juniors to do the manual work. It seems they are continuing the extraction of human thinking by going down the QTP automation route too. The Test Manager appears to still believe that the actual test case is the test. That the actual automation test is the test. And now these “tests” are being run by juniors or machines his testing world is sweet.

My friend doesn’t share the Test Managers enthusiasm. He’s already seen a decline in quality as the Seniors are being stretched and the juniors don’t have the same people skills and experience to work closely with the rest of the development team. Things are slipping despite the code coverage and the number of tests executed stats going through the roof. The stats are telling the Test Manager a glorious lie. But he seems happy with this. He hasn’t a clue to be fair.

My friend is not at all happy with this hence him handing in his notice a few weeks back. In fact, it could well be the beginning of the end of this company’s quality output as two other seniors have jumped ship leaving just three seniors. These other three hate it too. Sinking ship anyone?

Anyway. I guess the moral of this story is “If you have a Test Manager who doesn’t know anything about testing, has an evil laugh and your stats are telling a different story to reality then jump ship. Jump ship fast. Or push everyone else over board”

Image from the cool galleries of : http://www.flickr.com/photos/wili/

Just making an observation part 1

I can’t help but wonder why so many people feel so passionately about their organisations appraisal process yet are accepting of long feedback cycles in project work? I see too many similarities

Why do we hate one yet are accepting of the other when in reality they exhibit the same problems? Do we enjoy working for so long with no-one offering any feedback? Do we enjoy derailing projects? Do we enjoy seeing misery and anguish on the face of management the week before release? Do we enjoy the pressure of being the bottleneck with only days to go? I know the answer is “YES!” for some.

Long feedback cycles…….vague goals aimed at being relevant over a long and changing period of time…..last minute feedback…..no time to make changes…

I know I prefer the regular feedback cycle of the new wave of appraisal schemes (not new wave to some…) and the regular feedback cycle that agile offers me and the team. I guess I just like to know where I, my career and the project stand.

Just making an observation that’s all……:)

Don’t be a follower, be a tester.

I’ve had this blog post in draft for about 5 months now but yesterday morning a twitter post inspired me to finally get it published. It was a link to an article from Yvette Francino and included in it was a video interview (brief one) with James Bach. http://itknowledgeexchange.techtarget.com/software-quality/james-bach-the-buccaneer-tester/

I would suggest anyone who has even the slightest interest in testing reads this article and watches the video. The video is inspiring; it’s direct, it’s James’ usual straight talking no nonsense stuff and it’s also incredibly motivating.

A few months ago I put out a blog post about plagiarism and copyright that generated some incredibly heated comments as well as direct mails and tweets along the same topic. I studied the comments and concluded that they all alluded to the three following sentiments:

We should not challenge the best practices of testing We should not challenge the experts in testing We should not talk about testing publicly unless we are an expert or we know the experts.

The comments left on the post intrigued me. It re-enforced my belief that many people in the testing community simply follow the leader. They love best practices. They love the norm. They do what others say is right. They strive for conformance. They don’t ask “is there a better way of doing this”. They don’t challenge things.

I had a fairly heated exchange at a testing conference with someone who refused to believe that testers should ever make suggestions for new ways of doing thing, improvements to workflow, improved designs, enhanced usability or the changing/modification of features in the software they test. They didn’t think it was their job. For real? Not your job? Then what is your job? It turns out that running scripted test cases based on a spec written months ago, that had locked in a whole load of ignorance with a design created to solve a problem that actually didn’t exist, or did exist but now doesn’t. That’s what a testers job is apparently. Not in my book.

I believe that when a team/tester doesn’t question the norm it leads to stale testing, uncreative work environments, bored staff, uninspiring tests, dull testing jobs. Sadly that’s the stereotype image of testing. In fact, it’s not just a stereotype, it’s a reality for many.

So I bring you this advice:

We absolutely should challenge the best practices of testing (if they actually exist) We absolutely should challenge the experts in testing (it’s good for the industry) We absolutely should talk about testing regardless of whether we are an industry expert (who says we are/are not experts…is there a list? How do I apply?)

So why not write that blog post, submit your talk to that conference, challenge the Best Practice at work, challenge the heavy scripted testing, introduce some exploratory testing sessions, drop a metric in your report, provide something different to the people that matter, learn some coding, challenge the experts if you don’t believe they are right……….?

To sum up what this post is saying:

Don’t be a follower. Be a tester.