Is Exploratory Testing Just ‘Playing Around’
Take a moment to think about the importance of language as a tester, especially under the heavy shadows of larger business entities. It’s a topic often discussed in software testing circles when it comes to testing and for good reason. It’s important to bring up the less seemly aspect of this, because language, such as in the title of this post, is sometimes used in documentation describing test activities and planning or in verbal discussions with stakeholders. Have you seen it happen? What is the cost of using such language?
Bureaucracy and Politics #
One of the issues you have to contend with in larger organizations is the bureaucracy and politics that contributes to the officialism within them. Those things are often seen as bad words. That’s because political practices, official procedures and red tape are so often misused or abused that they have become bad words. They have provided an endless list of topics for comics such as Dilbert and TV shows like The Office. Have you ever connected with either of those?
And it’s in this environment that you have to create the perception of value in yourself, your role, your team, your department … you get the idea. Most businesses exist to make money and if an entity isn’t perceived as being valuable to the business, you can guess what’s coming. That’s the ugly part of why the language you use to describe how you analyze, plan, and perform your testing is important. It directly impacts your perceived value to the organization.
The Ugly #
I just played around with the settings.
That’s a perfect example of language you must avoid when describing your activity. This may inform a decision maker within your organization that you provide little value to the business. It’s why the Bach brothers, Bolton, and other well-known testers stress the importance of semantics. Plant enough of those seeds and watch your roles, teams, even whole departments being outsourced, absorbed into other business entities or dismissed outright. I’ve personally seen and experienced all of these consequences unfold. Those are horrible things to happen to people unless, of course, it accurately describes your activity. Then you deserve what’s coming.
The uglier part is that decisions are often made based on the perception of value of those entities rather than their real value to the business. That’s why I talk about perceived value earlier. And that should be why managers make the big bucks. It’s their job to sort that out. When it doesn’t go down well, it’s hard to watch. Especially when valuable entities fall by the wayside because they couldn’t make their perceived value reflect their real value, or because managers think they can make the best decisions simply “by the numbers.” Even uglier than that is seeing entities who have no real value maintain their positions, generally making life more difficult for everyone by not providing much to the business in terms of real value. We all know people or groups who fall into that category.
We have to remember that value can be as subjective as it can be objective. That being the case, the language we use in describing what we do as testers becomes extremely important.
The Bad #
Using the wrong language can also lead to negative effects in a lesser way. You may not lose your job, but you can still suffer consequences. You can lose credibility with the developers you work with on a daily basis. Also the architects, product owners, business analysts, marketing personnel … you name it. Enough of that quickly leads to the ugly scenario.
On the lesser end, bits and pieces of it cause a continuous stream of stress and lack of productivity as others de-prioritize your requests and their interactions with you. Developers turn their noses at your bug reports. The product owners, architects and business analysts don’t keep you in the loop, so you are always having to dig deep to uncover any useful information about a project you are involved in. All said and done, it becomes difficult to accomplish your job and even more difficult to enjoy doing so.
The Bright Side #
Perhaps you came from a less-than-organized exploratory testing background or you never had any serious training in the subject. As a result, you may have made blunders like that. And face it, nobody is perfect, so you might very well make the same mistake again.
That doesn’t mean that you are unable to recover, but rebuilding those relationships can take time. The first thing you need to do is determine what bridges need to be rebuilt. If you are new to an organization, similar efforts will be required to create that initial relationship. Determine the targets. Who responds readily to your calls/messages/emails and who doesn’t? Who always argues with you on your bug reports? Who always forgets to invite you to meetings? Answers to questions like those can help identify hotspots you may need to give special attention to.
Talk the Talk? Walk the Walk? #
No … Walk your Talk.
Your speech should both be heard (talk the talk) AND be exemplified by your behavior (walking the walk). And you should endeavor to be so good that you cannot be ignored. Building relationships with others starts with working on yourself. How well do you know your craft? How well can you speak to it?
Start with an evaluation of your own skillset. Ask for feedback from trusted sources. Are you in a leadership role? Allow your team members to provide anonymous feedback. Better yet, build enough trust within your team that they feel comfortable saying it to your face. Then steadily work to improve those skills. Deliberate practice is necessary.
The same is true of talking about your craft. Practice here if you like. Post a reply. Challenge an idea. I promise I won’t be harsh. Hopefully you can teach me something. Go to other blogs, like Satisfice or DevelopSense and respond to posts there. James and Michael will be more than happy to challenge your ideas if they feel they should be.
To prevent this post from becoming too painfully long, we’ll pick up where we left off here and dive into more specifics soon on how to build bridges and make effective use of language in our testing activities.
Until then,
TestVizor