Tuesday, 26 January 2010

When pondering the training plan for my team I remembered this question from Terry Pratchett’s book Unseen Academicals as the underlying driver for one of the main characters. In the book the character is constantly concerned that he doesn’t have “worth” and tries his best to prove, according to the guidelines he was brought up with, that the world is a better place with him in it.

In context with training a team of software tester I thought, who’s asking? Who does a software tester provide with something that is useful? And who decides what’s defined as useful? Depending on who’s doing the answering I’d get different responses. So I had a look at what job sites are looking for and compared that to what I’d be looking for in a tester in our company. Most job sites put an emphasis on the Skill and Domain section but leave out the business side. I had a picture in my mind how these three areas should overlap and it helps me to ponder the problem further, see below.

For clarification what I mean with Domain is knowledge as a subject matter expert (SME) – knowing about financial systems and accounting in banks, phone networks in telecommunication, etc.
Skill for me would be everything on the more technical side, ie writing test plans, scripts, test techniques, writing SQL statements, knowledge of particular tools, etc.
That leaves the Business side in this triangle with which I mean anything to do with working as part of a project team in a company. For example, knowing what to report to a Project Manager, when to report, knowing when to escalate matters , where to archive your test data, how to contact your system administrator, etc.

As a test manager, a lot of issues that I’m dealing with are NOT in the domain or skills section but the business area, still, no jobsite thinks it’s even worth mentioning. People not raising project risks at the time, telling PM’s about holidays they booked, etc is a common complaint I get, am I alone in that?

This diagram is a gross simplification and ignores things like experience and ability to communicate effectively. The latter I think is specific for each area as someone might be able to communicate rather well on a technical level but would be lost to explain the same thing to a senior manager. I rather see these unwritten parts like experience or communication as flowing around all three areas. In my opinion, if someone is very good in one area it makes up for weaknesses in others – to an extent.

I could extend it and use colour gradients or additional parts to signify experience, communication skill in that area but to me it’s not about making sure that I don’t miss anything or that I measure exactly the proficiency level. I don’t believe that this can be done reliably but it can be of help to remind me of the different areas that a tester should be competent in.

This diagram isn’t really restricted to testers, it’s more generic and could apply to any profession, really. I just started from the tester’s perspective as that is my background.

Now with the yearly appraisals around the corner (yes, I do work in a reasonably sized company), I will use this diagram and discuss how my team would like to expand their knowledge in each area.

I’ve got this nagging feeling that I’m overlooking something big as this diagram seems to be quite generic and wiser people than me must have done written something about it. If there are any links that you know of that go a bit deeper, please do let me know.

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 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’slight-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?

Thomas

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