Building Your Test Brand

#softwaretesting #SocialMedia

Or... "Everything you wanted to know about being a trusted tester but were afraid to ask!" (nearly)

Is this something for me?

If you’re a test engineer – at whatever level of experience in whatever field of work – I’d say yes.

What?

Building your brand can be interpreted in many different ways. Some of them being:-

• Self-promotion
• Becoming a trusted source of information
• Bragging

I’m really only interested in the 2nd point – there's a fine, but distinct, line between the 1st and 3rd point, but those are probably more useful if you looking for a job or selling something – and that’s another story.

So, I’d think of building my (or anyone else’s) testing brand as point 2 – being a reliable, consistent and, ultimately, trusted source of information – i.e. opinions, test results, reports, data, interpretation along with conclusions and recommendations.

Being a trusted source is not about being an expert (experts can build their “expert” brand) – it’s more about describing the world as you see it and being accepted/known that that is what you do.

Why?

Every tester can probably tell an unhappy story involving tight timescales, project/customer pressure, etc, etc.

Pressure is always placed on the “test organization” – whether it’s a development project, customer roll-out activity or even customer demonstrations – you could say it almost goes with the territory.

As the tester is usually placed in this situation then it is very important that they are a constant in a sea of variables – that their assessments and reports (even problem reports and observations) are consistent and reliable.

The reports from the test organization are an input (nothing more grand than that) to the decision makers (project and product owners) about whether sufficient criteria have been met to progress to the next phase with this release.

Therefore, it is very important that the results and reports from the tester/test organization are consistent and reliable. It’s just as important that your views are known to be consistent and reliable.

How?

Consistency and reliability are key factors.

Consistency

Consistent in approach, reporting of results, observations and issues.

Reliability

Telling the “truth” as you see it – or what you believe. It doesn’t matter if no one agrees with it (although if you’re outnumbered 100 to 1 it doesn’t harm to double check your conclusions) – you’ll be trusted more for an honest opinion rather than stating what you think someone wants to hear.

Lack of information?

If you’re unsure about something, then say so. If a recommendation can’t be made due to lack of data, say so and if further investigation is needed then state it. If the information is incomplete, then communicate this.

Open Questions?

It’s better to give an answer with a caveat of a lot of open questions (if that’s what you think is relevant) – it might be frustrating to the recipient to get more questions than answers – but describing the world as you see it will bring you more “long-term” friends.

Remember: Question to clarify, question to investigate, question to progress and question to learn.

Social Media?

In today’s world of increased use of social media it’s possible to ask if there is a separate dimension here. In some respects your brand is what it is “perceived” to be – i.e. your interaction in/with social media can affect how you are perceived.

The use of different electronic media can be used to build a brand – in terms of self-promotion.

However, the bottom line remains true – consistency and reliability – whether you are interacting by email, message boards, wikis, online forums or any other electronic media.

If you apply the ideas of consistency and reliability to your communication then you’ll also be perceived by those principles (maybe not by all and not at the same time.) That’s the future-proof route for self-promotion.

These ideas can equally apply to more areas and roles than just testers…

How do you build your brand?

Blue-sky thinking with Social Media (part 1)

The spread of communication in test teams has long been essential in the smooth functioning of the activity. This may be to distribute activities, test campaigns, troubleshooting, collating progress reports, latest known problems, etc, etc.

With the move towards increased use of social media there are many opportunities for improved effectiveness in the team structures and dynamics.

Information exchange via informal and more formal networks in test groups has always existed.

• Formal: Due to the project/team/unit organisation forming a semi-rigid reporting/information chain.
• Informal: For example whiteboards, emails and wiki pages.

With the increased use of social media there are many opportunities that test engineers (whether in teams, intra-team or management) can grasp to aid communication exchange.

Increased effectiveness will probably come from a hybrid use of the formal and informal channels.

In this team working context the social media could be wikis, webpages, some collaborative software, amongst others. Many of these have existed for some time but are quite often just used as a dumping ground for information - libraries, records, how-tos etc.

So, with all these different ways of communicating what do we do? Let's do a bit of blue-sky thinking...

Dynamism?

A more fluid/dynamic team set-up? Something more evolutionary? This is an idea that will probably scare the socks off project managers used to more rigid team set-ups.

Suppose team A & B are working on two different areas. During the course of their execution they hit a problem (affecting both teams). Traditionally, there are several ways this can be approached - a sub-team (from both teams) is set-up to trouble-shoot, one team focusses on the problem whilst the other works around it or the troubleshooting is handed over to someone/team external to A or B.

Well, suppose the trouble-shooting group formed dynamically. This happens either via IM, wiki post, blog, email etc - certain team members (spanning the two teams) decide that the problem should be worked on jointly.

The idea here is that the network exists (the pool of test engineers) and forms a team dynamically (eg two people discover they're stopped by the same problem and join forces, even calling in external help) - this joining of forces aids the problem solving (in most cases)

This type of team dynamic probably needs to be ok'd/coordinated - but as the teams/network gets more and more used to it then the team formation should become more "natural" or "self-selecting".

This dynamism is meant to only create temporary teams for as long as they are needed!

Another example of dynamic team formation is a group forming from a given network to do some brainstorming on improving a process - the interested parties initiate the activity, setting up the group dynamically and kick-starting the work.

Tools for all of this - to help facilitate it?

I think some of best tools are the collaborative SW tools (project web pages with directive, status, discussion boards and team calendars), linked in with blogs (eg for thoughts/opinions on what went good/bad in a project), wikis & webpages (resources for how-tos) and email (ad-hoc questions/requests or inspiration).

When I say evolutionary I don't mean that the "weak" are left behind. This activity has to be inclusive - adoption and usage rates will always vary, and there is no place for exclusion.

Dynamism continued?

What about fluid team structures dictated by the problems in front of them? This is about moving towards collective intelligence! More of that later.

Other benefits & problems with social media and team dynamics in a later post.