#softwaretesting
I started threading a few thoughts together before my holiday – more as a cautionary tale. However, after the recent outbreak of plagues I thought I’d give it a medical slant….
Who knows, I might start a whole thread of testing pests, diagnosis and treatment!
Description
This is a condition affecting testers and test leaders, commonly in projects/iterations experiencing stress in timescales, build releases or test execution completion. The inducers of these affects come from outside the test team/organization.
This is the occurence of test experts that are not practicing testers that want to dictate/direct the testing effort.
Diagnosis
A non-tester (typically PM or developer) expresses their opinions (sometimes forcefully) about how the test execution (and even design and follow-up) should progress.
Occasionally, this is done in an oppressive manner meaning that they are dictating the testing effort – micro-managing (instead of the test leader).
Treatment
PM’s have the “most” right to say how something should be done. They’re responsible for the completion of the project/phase, including all parts within it.
Do not antagonize or dismiss opinions. Take the opinions on board – within the scope of your remit. Developers have very valuable input into aspects of the testing effort – but you’re the one responsible for the test effort - your team may have a joint dev/test responsibility in some areas and separated in others.
If you can’t reconcile differences with a developer over how an aspect of the testing should progress then discuss with the team leader, test leader (if there is one) and PM, if needed.
If you can’t reconcile differences with the PM then you need to discuss divisions of responsibility – where the test responsibility ends – include the line boss, if needed, to get things clarified.
If you’re unfortunate enough to end up in this situation then think out your game plan first – motivation, problems to your work, problems this causes for the team and project, suggested way of working (emphasis on the team and project benefits) – before discussing with PM or line responsible.
If you can, bring in a real test expert to help put over your case. A real test expert, in this context, being a tester in your organisation that all sides will listen to.
Outlook
Where the cause is an "old-style" PM (not rating the tester very highly) then the outlook can be quite poor. Perseverance is the key here, but usually this type of PM is not going to change very quickly.
Occurences of testing expertitis have reduced in recent years, partly due (but not exclusive) to:
Testers have a weighter role in development projects – they are not the second class citizens that they might have been 10 years ago.Many organizations are more “en-lightened” these days – open to many different development and testing approaches. This isn't just a nicety; the projects have to be efficient - meaning everyone is working from the same storyboard.Many projects/iterations work in more cohesive units meaning there is less of the blame game.
Other Comments
Although I haven’t seen this for a few years – the ingredients for it to occur are not so diverse. A PM from the old-school /pre-enlightenment – they still exist – is probably the main catalyst for this type of event.
NB. Comments, observations and input from non-testers are valuable and should always be appreciated – it’s where the dynamic turns into a directive (that doesn’t come from or with the ok of the team/test leader) that it can be a problem.
Do you suffer from testing expertitis? Do you have any other testing affliction?
It seems like everyone has their own ideas about what testing is and how it should be done. I think many team members don't think they are dictating how to test, they just think that it's how it's generally done and that they're being helpful by being clear about the task.
ReplyDeleteThat said, I did once work for a non-technical boss who dictated how to test every task I had, and would get mad when I tried to explain a different approach. The development lead had a similar problem and, I'm sorry to say, we ended up just nodding our heads and doing our approach anyway. Most of the time the boss couldn't tell the difference and was just happy if there was a report at the end with nice looking graphs. I wouldn't recommend this approach generally - it was an extreme situation - but sometimes there is just no reasoning with some people.
This is a great article by James Bach about explaining testing approaches to non-testers. http://www.satisfice.com/articles/explaining.shtml
Ah, I should probably justify that story with why it was an extreme situation - the approaches dictated by the boss were not just ones we didn't like - they were usually technically impossible or would result in little to no value.
ReplyDeleteGood comments. Thanks.
ReplyDelete"A little knowledge is dangerous..." - that is the root of many conflicts - where the non-tester thinks they understand all the angles. They probably have some very valuable input - it's just a matter of filtering that and dealing with the less-than-helpful input.
So, I prefer a combination approach - count to 10 (at least) before responding to any oppressive remark, being able to explain my own methods/reasoning (both alluded to in James' article) and also managing expectations.
Managing expectations is an unsung art that testers would do well to be able to practice. This sets the tone from day one, stopping opinions (expectations) diverging early on... This boils down to communication - the earlier and clearer, the better.