Wednesday, 20 January 2010

Testers - results orientation or integrity?

this is my first blog post, I'd like to encourage you to leave criticism or feedback. I know I have a lot to learn so don't try and spare my feelings ;-) Here we go..

I started thinking about the importance of integrity for software testers after exchanging opinions on SoftwareTestingClub with Matt Heusser.

To me integrity has always been important but it was always a bit hazy and not very specific. I recently worked at job descriptions and put Integrity high on the list. It was later replaced with “Results Orientation” and “Planned and Organised” by the powers that be.

It could mean that these are a) more important or b) easier to understand by management. I argued for leaving integrity in but was overruled. In that case that wasn't a big issue for me even though I didn't like it.

If I say “Integrity”, what do I mean? I like the Wiki definition:

“Integrity is consistency of actions, values, methods, measures, principles, expectations and outcome.”

If a tester makes himself a name for having integrity what does that mean for their clients or employers? According to that definition it’s both clear and predictable what to expect from this person. By having a short discussion the values, methods, measures and principles can quickly be established. Or, in other words, integrity instils a sense of trust at the basic level. It still doesn’t mean that the tester in question is a good choice for a particular job, he might not have the right skillset, availability, etc.

In a software project context integrity is threatened in various ways – pressure from team members, Project Managers or people higher up in the food chain, customers, etc.

Project managers might ask testers to take shortcuts in the agreed test approach. When asked to mark tests as run even if they haven’t been executed or bugs not being reported as found; the tester will find themselves under a lot of pressure. Do you stand your ground and risk being shouted at, threatened or ridiculed? Or do you give in and take the shortcut to reduce the pressure? Under what conditions would you go against your values and principles?

Team members can put pressure on the tester to not log bugs as they might have run out of time to fix them before the deadline – anticipating pressure themselves from the PM.

In situations like that I found it important to remind myself that there is a two way relationship. One person asking to take the shortcut (maybe for a good reason) and the other person who can agree or disagree. Even though it doesn’t look like it at the time, one always has a choice.

For permanent staff and maybe even more so for contractors their integrity is an asset. If a contractor gets a name for not having integrity their career will quickly be at an end. Bowing out of the project might not be a good idea short term, long term that decision is invaluable.

Testers are not the gatekeepers of quality, even if it may sometimes feel that way, see the Enforcer in Rob Lambert’s light-hearted approach to tester types. Maybe there’s a reason why people are putting pressure on the tester and threaten their integrity.

Weinberg’s Rule of Three from his book “Secrets of Consulting” states "If you can't think of three things that might go wrong with your plans, then there's something wrong with your thinking." Finding out what the real goal is should be if not the first, but maybe the second reaction. Integrity might not be threatened at all.

The reaction to outside pressure is, of course, depending on the situation and personal values, methods, measures and principles. If the agreed test approach is no longer viable, maybe a new one should be agreed and documented.

If a project goes down that route there is a visible trace of why decisions have been taken and when. The tester protects themselves by getting agreement from the PM and other stakeholders which should be good engineering practice. The end result is the fear that comes with pressure – fear of not hitting the deadline resulting in loss of face, money or job – is removed by taking a realistic and professional stance.

Do I believe that integrity is important for a tester? Yes, of course. We’re some of the last cogs in the software development wheel who can highlight some of the things that might reduce the value of the product or solution our company is trying to sell. Should a tester be results orientated? Yes, knowing how to get the best results fast is important for the business. Let me ask though, when sitting in a plane waiting to take you on your holiday, would you rather have an airplane engineer with results orientation or integrity working on it?


PS: Thanks to Rob Lambert for his help to get me started and kind words. I appreciate it.


  1. Integrity can be a difficult word in job descriptions - it's probably too far displaced from many people's everyday usage that the meaning becomes different to different people. The ones that over-ruled you probably didn't have the same wiki definition in mind.

    But I like integrity and consistency as a way of building your test brand. This is what will eventually help you through a tide of difficult (or micro-managing) stakeholders. I can relate to some of the examples you quote - where the test activity is just a point on a checklist for a PM for the product moves on: ie "has the product been tested?", "yes", "ok, next question..."

    This probably says more about the process involved... It could also be that the PM has asked for some testing without really considering what that means/entails - they have an idea of what it means but it might not tally with yours or anyone elses - I've seen this also.

    I was once asked to "reduce a test scope" and my follow-up questions started in the area of "would you like to know less about the product?" (before presenting "my" interpretation of a reduced test scope...). But the fact is some PM's really would like to know less - especially if more means more problems...

    As someone who's worked on problems of aircraft aerodynamics I'd always insist on "integrity" in those situations ;-)

    Good post Thomas! Look forward to reading more...

  2. Simon,
    thanks for the comments. I agree with your view on building your test brand.
    Our PM experiene seems to be quite similar as well. After I worked with a PM for a while a working relationship develops and they think more about what it is they want on their project. There's an aspect of teaching and mentoring some (not all)PM's for the first time I work with them and I like to invest the time as it will make both our lives easier in the long term.

  3. Good to see you blogging - and a good post to start with. looking forward to reading more