The Essential Qualities of an Effective Software Test Consultant

So, first up... Knowledge

Technical knowledge, product knowledge, system knowledge, previous experience of the solution. All of these are useful.

Nevertheless, the main thing about knowledge in a testing sense is getting hold of it for the situation you are currently in. If you are lucky, your current client will use a product, system or solution in exactly the same way as you've used it in the past. Although, they probably won’t and definitely won’t if you are new to this game.

Usually, every client will use things slightly differently or have processes/ integrations that will be completely different to anyone else. In these situations, you need to gain that knowledge. Be inquisitive. Where is the documentation stored? Can I get access to it? Who is best person to talk to? Has anything been done in terms of testing before?

Once you’ve started asking, be prepared to listen. However good you are, however much you know; be prepared to listen. You never know what information will be useful. Which leads us onto...

Communication - absolutely key in any testing situation. For starters, this is how you get knowledge - learning who are the best/most effective people to talk to.

Then, the second important thing is how to balance your communication skills - communicating your progress or pushing your point of view in meetings. How to do this without preventing you from actually doing the work you need to do and reaching the most effective audience with the minimum of effort.

There are 2 things to keep in mind with communication:

1. Clarity - ambiguity is no-one’s friend here, misunderstandings can be very costly.

This is true for all communications, at all levels and at all times. For example, when writing test cases (someone else may have to run them who doesn't know what you know); raising defects, asking questions and gathering test evidence.

2. Brevity - get to the point

Without being blunt, time is precious on projects. Update, explain clearly and get out. You need the time and the project needs the time. Waffling is not an option – despite how valid your point is and however brilliant you think you are.

Remember... communication may have let Spandau Ballet down but they were a successful 80’s pop band with other ways of earning a decent crust. You might not be so lucky.

So, you’ve got the knowledge and you can communicate effectively. What else do you need?

Patience dear boy/lady, patience...

There will be time when you may be waiting for data, for environments and for information. There may be times where a client or a PM might want to take testing/the project down what you know is a rabbit hole.

There may be times when your project is not the only show in town. Patience... Knowing the right time to voice concerns and how far to push those concerns is key. Alienating people is never a good idea but when you are the last link in the chain and; depending on other people in the project for the things you need to do your job, it's even less of a good idea. Bite your lip, keep the evidence and move on.

Along similar lines, be realistic. As Dean Martin once said "...the world still is the same, you'll never change it." - (one for the teenagers there!). Basically, we are sometimes at the whim of clients or project decisions that we might not agree with. We can make our case but people might not be listening. We need to understand we are there to help them. They are paying the cheques and if they want to crash and burn; as long as we have made it crystal clear how and why we don't agree, there's not much more we can do.

In terms of more technical attributes, attention to detail sounds obvious but it's the little things. Checking all the records, pulling out all the variations, assessing probabilities, not settling for 'well it looks ok, but I’m not sure'. Getting back to the source of the data. Investigating exactly why a program failed and where.
Proving that a test really worked, not just passing it because the end result was right. There are many ways to arrive at a destination but some may be by accident rather than design.

Which is why it's important to have the ability to look at things from a different angle. Ignore the 'we've always done it this way' and look again. There may be something in a fresh pair of eyes that picks up procedural changes that will help the project or prevents disaster! 

Experience will help but if you're new to this game, keep that in mind - there may be another way to do this. Ask questions but be prepared for them not to be answered.

What else? Well, I’ve always found that regardless of the technology, client, project or infrastructure; one of the most important lessons is to keep the user in mind. Fine it works but it's not intuitive - it's cumbersome, complicated and takes too long.

Think about - how will this be used? Who are the people that will be using it? Can they understand the new solution/process and why it’s being introduced?

Similarly, keep 'as live' in mind. Try to replicate as live/will be live in testing. A solution that requires manual intervention or data manipulation to progress through testing isn't going to stand up to much in a live situation. There may be untold issues in the automated stages or interfaces that will be glossed over if we progress with manual intervention in these situations. Testing must be 'as live' as is possible in a test environment.

So, in summary:

• Gain knowledge quickly & listen.
• Communicate effectively.
• Be patient and realistic about your place in the chain.
• Hold an attention to detail and be inquisitive.
• Keep the user and ‘as live’ in focus.

Obviously, there’s more to it than that (I hope so, otherwise the people that employ me might work out that they can replace me) but keep these fundamentals in mind and you can enjoy a productive career in testing.