Process or training?

The raging battle between the process vs non-process people and Michael Bolton’s recent burning issue article got me thinking. If I assume that everyone in the testing field, be it tester, test lead, test manager and the wider software development arena wants to do a good job, why are their points of view so different?
OK, that question is too wide so let’s try again. Why does someone wants to put the process first and someone else the problem first?

In my experience that’s due to at least two major reasons, personality and experience. Let’s look at personality first.

Some people feel trapped by processes and limited in their freedom and abilities. They rely on their skills and abilities and trust whatever comes that they will find an answer even it they don’t know it, yet.

Some feel that with a process and documents in place there is something that they can fall back on to prove that what they’re doing is right. That they can give the process to someone else and that they can then also repeat it providing a base for a bigger group of people to learn from what they did before. 

As a test manager I can’t influence people’s personality, that’s why there’s always an amount of touch and feel in any project decisions. Most decisions are emotionally impacted, I haven’t seen people looking at ROI and NOT decide based on their emotional reaction.

For the experience part, someone might have worked in a big, process driven corporation where there was a reason for processes. Or they worked in a small shop where anything goes and only a result counted, any result. I worked in the pharmaceutical industry and research scientist for a good number of years. GLP was a regulation we needed to comply with and if you ever heard of thalidomide you’ll know why that is a good idea. There’s an interesting article for further reading.

Processes were in place to satisfy these regulations. However having done a lot of the "work on the floor" most of the processes just didn’t make sense to me. After working for several years in the IT industry I now understand what they were trying to achieve, but no one explained it to me at the time. But I also now understand why the processes failed miserably. My point is that if you always worked in process driven companies you don’t know any other approach as very often there is a good reason why the processes are in place. That doesn’t mean they’re always working in practice though. I worked with a lot with red tape, ditched it all, and are now coming out the other end being somewhere in the middle.

Most companies want to be able to run a profitable project, have a satisfied customer and be able to repeat that over and over again. So why not putting your working habits into processes? Wrong, no two development projects are the same and a habit is just that. Wikipedia has this for Habit:

Habits are routines of behavior that are repeated regularly and tend to occur subconsciously, without directly thinking consciously about them.

The question is, do we actually want that? When you document a process and don’t want people to think about it but follow it, that’s fine. But when your next development project encounters an unforeseen problem don’t be surprised that your team can’t deal with it as you created a culture where people don’t think about what they’re doing.

I see the clash not between the process vs non-process approach but if you want to invest into training your people so that the whole team understands what’s expected from them and what’s important; or if you think that this route is too expensive and that you rather tell them what to do and have a few “in the know” who are creating the processes.

I think that training or lack thereof is at the root at the problem when we’re talking about processes as they’re often used to mask that people are not trained enough to do their jobs without them. If a developer doesn’t understand that throwing software over the wall to the testers impacts their work this is essentially a training issue. If a tester doesn’t understand what information is essential to the PM this is a training issue. If the PM doesn’t understand what to ask from the developer or tester, you guessed it, that’s a training issue as well.

I gave my 6 year old son a LEGO game, a Star Wars plane with some Androids to assemble. He was able to do that without help using the instructions. When asked if he could do that without he said that it would be quite hard. In other words, he would need to get out of his comfort zone. I prodded him a bit and he assembled the next one without the instructions. Of course that was harder and took longer. But what he learned there will stay with him, he’ll assemble the next one much easier. And the one after that. If he’s always following the instructions he learns exactly that, don’t think, follow the instructions.
In many ways it was easy for him to do something different as he’s a child and therefore constantly challenging his comfort zones and I’m encouraging that. But if that was never high on your parents agenda and your employers don’t expect that from you I can see why following a process is the easy option.

Comments welcome..

Thomas

Do I have worth?

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.


Thomas

Testers - results orientation or integrity?

Hello,
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?

Thomas


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