What do they know of testing who only testing know?

I know I’m not a particularly touchy feely person. As a child and as a student. I was quite shy and I was more comfortable with books, writing and solving mental problems than I was dealing with other people. In the early part of my career I had a vague notion that my job was all about the technology. Sure, handling people sensitively and with respect was important, but that was so I could get on well with them. It wasn’t really part of getting the job done.

I started to change when I became an IT auditor. It took me maybe two years to get the hang of a job that I gradually came to realise required judgement, experience, intuition and insight; not just technical expertise. Every audit required me to analyse the situation and understand it. “What’s going on here? Why are things being done this way? How could they be improved?”. You can’t answer these questions without understanding the people, and the motives that are guiding their behaviour.

I suppose an important aspect of growing up and maturing is the ability to acknowledge your weaknesses so you can do something about it. Often, if you’re successful, you can con people that your weakness is actually a strength. By the way, I’m terrified of public speaking, but I’ve been able to fool loads of people that I enjoy it!

Client v supplier, or client & supplier?

Thinking about the human side of business proved vital when I moved from internal IT work to a role in which I was a supplier dealing with customers. For many IT professionals this is a minefield. You have to be so careful, and many of us lack the instincts and training to handle it.

Many people have been brutalised by adversarial relationships between suppliers and clients. Some clients see it as their job to challenge suppliers (acceptable), but this can tip over into confrontation, hostility and personal attacks (unacceptable). After some experience of that, supplier staff can start to think that any response short of physical violence is acceptably diplomatic.

When I worked for a big supplier they took care to send the cool heads with long fuses into the more stressful customer facing situations, and to keep the hot heads in the background. I was one of the cool heads. You need people who will be polite and professional, but who are prepared to engage with clients as people first, and clients second. Once you build a personal relationship with the client then the business becomes much easier. It helps if there is continuity on both sides, rather than the supplier rotating key staff every few months.

In my career I’ve met very few people who have been irredeemably unpleasant and obnoxious. Mostly when clients have been difficult it has been in response to pressures from within their organisation. If you understand their position, and understand them as people, then it’s usually possible to work with them pleasantly and constructively. It’s not a fair game, and sometimes client staff will treat suppliers with a lack of respect that they wouldn’t dream of tolerating in return. Suppliers have to be much more careful and sensitive than client staff. That’s just the way it is.

It’s pragmatic, not sentimental

Dealing with people as individuals, understanding their motivation, and showing them respect isn’t just the right way to treat people, but it’s also a highly practical way of handling clients. Once you have persuaded the client that you are doing your best on their behalf, and also of course that you are competent, everything becomes easier. The client perceives that you have hit tough problems that you are trying to resolve, not that you have failed. That’s because you’ve earned their trust and respect. Earned is the key word. It doesn’t just happen. You have to work at it.

There have been many times in my career when the time I’ve invested in early stages of a project getting to know and understand the client staff well has paid dividends later; when we hit serious problems, when I had to persuade the client to change their strategy, when I had to persuade the client that the contract had mistaken assumptions.

I was able to get my way not through bullying, or manipulation, or scare tactics, but because I was speaking to people who already respected, and above all trusted me. If the client had thought I was a chancer, unreliable or concerned only with my employer’s short term interests then discussion would have been closed down. At best I’d have been told brusquely to get on with it. At worst there would have been a shouting match and escalation to senior management to bring me into line.

Obviously, the longer you spend with a particular client the better the personal relationships you can build up. However, even on short term assignments the personal touch mustn’t be overlooked. In fact, the shorter the assignment the more important it can be. If you’re doing a consultancy exercise lasting only a few days then the people might be the highest priority. Instead of a dispassionate analysis of what is being done, and how it is being carried out, you can get a better, quick feel by seeing how people are responding to their environment and gauging their experience and knowledge.

I’ll never be a social worker or a counsellor, and I do screw up, but I think I’ve learnt enough to counter my worst instincts. Homing in on technical issues, statistics and processes might seem rigourous and objective. Often it’s just the comfortable option. In the end, it’s all about people. Come to think of it, they should be the starting point too.

These issues might be more sharply defined in commercial relationships between clients and suppliers, but they are still relevant to internal IT staff who deal only with fellow employees of the same company. They’re also highly relevant when dealing with other members of the same project or team.

What about testing?

What’s all that got to do with testing? Nothing and everything. I’ve quite deliberately reached this stage without mentioning testing.

The purpose of testing is to let the right people have the information they require about the product and the risks. The product is usually destined for people to use. Testing is not a mechanical process of checking the product against the requirements. Ultimately it’s about people, and to understand our role we have to understand the people, whether they are colleagues, managers, clients or end users.

If we only know testing as a technical, dispassionate process then we don’t really know what we’re doing. That’s why I mangled Kipling’s quote about England for my title. What do they know of testing who only testing know?

Advertisements

8 thoughts on “What do they know of testing who only testing know?

  1. Great adaptation of Kipling!

    There is a very appropriate title for an appropriate message.

    Understanding the motivations, frustrations and needs of our customers (or stakeholders) is key to getting on that wavelength of being able to exchange information – being a reliable and trusted partner keeps you on that wavelength.

    A while back I reflected on building one’s testing brand
    – being a reliable and trusted partner in test. There I was looking at some aspects from the technical side. If I wanted to give a more rounded slant on them then I’d marry them with the customer/stakeholder aspects that you raise.

    Good stuff!

  2. Thanks Simon. Yes, your blog was relevant to my thoughts. It was interesting, and I’ve added a comment, even after all this time!

    I could have written about any number of different topics under the same heading. That’s one of the beauties of testing. There’s so much you can learn that will benefit you. There’s so much to know. We’ll never run out of things to learn that will help us; technical, social, psychological, organisational.

    I used to get frustrated sometimes because I was spending too much time on stuff that wasn’t “real testing”. It was. It just wasn’t testing as envisaged by the ISEB Foundation syllabus.

  3. Pingback: Tweets that mention What do they know of testing who only testing know? « James Christie's Blog -- Topsy.com

  4. Hello James,
    A good posting to show human understanding is also important to become better in testing. In my opinion it is more then just focusing on delivering value by testing. it is also important to increase value using the proper personal skills. These are necessary to ensure you are able to emphasize with the customer. Perhaps it is not “the customer” it is “you and the customer”.

    There is indeed more we can focus on and we will face those bully testers who believe it is different, it is about processes, it is about certification, it is about delivering value in abstract sentence. I think it is more about accepting the way people are acting, not forcing to do different, instead try to adapt and learn.

    Thanks for sharing your thoughts.
    Regards,
    Jeroen

    • Thanks Jeroen. We might deliver value, but it is value to someone, or to a group of people. We can’t know what the value is unless we know the people.

      Developers might think they know, but if they expect people to conform to their assumptions then almost inevitably they will end up forcing an inappropriate solution onto the users.

      Testers might also think they know what they’re delivering, but unless they know the people who receive the information, their needs, problems and motivations, then the danger is that the testers will be going through the motions; following the process, not testing!

  5. Hello James,
    Thanks for response. I agree with you that there is a crowd addicted to follow processes. There is also a shift from others towards only testing. Testing can be explained delivering value to people who concerns. In my opinion there should be a mix of processes and testing to deliver the value in a proper way to make it acceptable by the recipients and also the organization. To enable testers to do so understanding of certain level of sociology, psychology and other “soft-skilled” areas is helpful. Like you mentioned “learn the people” to understand the people. I think this needs another approach of testers to be aware of keep on learning and also learn from adaptations.
    Thanks for triggering me!

    Regards,
    Jeroen

  6. As Jerry Weinberg says “No matter what the problem is, it’s always a people problem“.

    Excellent post – how did you go about changing from being a book person to learning to deal with people and gaining their trust and respect ?

  7. Thanks Phil. How did I changed from being a book person to being able to deal with people and gain their trust and respect?

    Firstly, I didn’t just change. I’m still a work in progress.

    I think the big thing is recognising the need to change. It all flows from that. Fortunately I was forced into situations where I had to confront my weaknesses and think about overcoming them.

    If I’d landed a role as a systems programmer then I might easily have gone through my whole career in a technical comfort zone.

    As I said, working in IT audit was crucial to my development. One of the lessons that was drummed into me was that I must never try to fight technical people on their own turf.

    Interviewing people was similar to a forensic cross-examination by an advocate (barrister or attorney, depending on your country). Lawyers make sure they’re well briefed, but their role is to handle the witnesses and steer the questioning to get to the truth.

    To get back to your question, I think the most important point is to make time for people. In IT we’ve got a weird attitude to time.

    A couple of days at the start of a project locking yourself away with a few key users can pay huge dividends. You get to know the people, then you understand their business needs, and then the requirements start to make sense as they come out.

    However, spending a few days like this seems like fannying around, not doing much that’s visible. On the other hand, hitting technical problems, or slight over-runs by a week or so is seen as inevitable and hardly worthy of comment.

    If your users see that you’re making the effort to know them and understand their needs then they should start to see you as someone who’s there to help them; not just as someone who’s going to dump a crappy system on them and shoot off to the next job.

    It’s harder for testers, who’re often wheeled in too late in the project. Ideally, the key testers will be involved in those initial sessions getting to know the users. Sadly, I’ve never had the chance to do that. I’ve only been involved in that way when I’ve been the project manager and able to do things my way.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s