So you are working on a project, large or small and you are working with a variety of stakeholders, some may know what testing is, some may think they know what testing is, and some have never even thought about it.
So what do you do?
For me this one is an easy thing to address, I tell them all what testing is to me, in small bit size pieces. Using plain English, and alway checking back with them about what they mean when they use technical language, always phrased as " just so I can understand.." not so I can correct them, so I can make sure I really know what they mean, This goes for technical people more than any, I sat in a meeting with a system architect lead, interface lead and developer lead, and they all had a different definition to unit testing (or developer testing). If I hadn't asked it would have gone unsaid, assuming they all meant the same things.
People who don't know what testing is, you have to show them the value you bring, demonstrate why what you do, makes their lives easier. Telling them isn't enough, they have to see what you bring to the table otherwise you are just some strange IT role.
Be open and inclusive invite people to see what you do, help them see why you ask the questions you do, and never fear being challenged, just make sure when you respond to that challenge its positive, clear, easy to understand and relevant, they aren't saying your wrong, or not needed, they are really saying I don't understand why often with little realisation that this drives what they are saying.
If you want to do well in the professional world being able to demonstrate your worth is a skill that is worth developing, as the way you demonstrate it has to change according to the audience, you have to be able to explain in terms anyone can understand and defend why you have done or are doing what you are, especially if they come with preconceptions about what it is you do.
James Bach and Micheal Bolton tester story is an invaluable tool here (These are the people who I first saw this from not sure who's idea it was first) It gives a framework within which to think about the differing side of what you are doing, and how to address questions about it to support why you have chosen to do what you have, when you have.
It's all about understanding, what the concerns are, and how you can provide assurance to the stakeholder who raised it, that you will be able to provide them with proof/information/demonstration of that area so they can make a judgement on how happy they are with it, for example, in my current project the speed of order entry for the trade sales team is very important, they need to be able to work through an order flow, including placing individual lines on an order at the speed of speach. We are addressing this through demonstartaions and timings of screen loading, so the Trade sales manager can see how fast it is and make a judgement of if they are happy with that.
