Do I want to write this?

I usually keep private and work net presence clearly separated. This one is different but I decided to post it as I couldnt' get the testing mindset out of my private life and it may help. It also explains why I haven't blogged or been active in the testing scene in the last couple of months. Not that I think that needs explaining.


Germany/Wuppertal, December 2012, Intensive Care Unit. I browse through the notes the nurses left for the last two days, noting the structure of it to be easily recognisable for the next ICU nurse. It's easy to see at a glance what drugs and treatments the patient got in the last 24 hours. It has to be, any failure here could be fatal.

Looking at the syringes next to my fathers bed I wonder what they all are and take note of the names. He's been in a coma since before Christmas. Reading the drug names comes easy, I worked as a pharmaceutical research scientist for over a decade. Memories of that come back. At home I find that Ketamine is for disassociating the body from pain and that the street price has fallen over the last couple of years. For some reason that stuck with me. I read up on resuscitation, survival rates and the side effects like personality changes and brain disorders. I read a lot and educated myself but sometimes I learn things that I really don't want to know.

Beds, syringes, forms, power, gas supplies, room layout, etc are all standardized so that any nurse or doctor can take over where the last one left off. In an ICU that's of vital importance. Each shift has a 1 hour handover/scrum to brief  the next shift of what happened. I wonder what would happen if we were to do 1 hour handovers each day.  In my current line of work it's not that important to know exactly where the last person left of. It's useful but no one dies if you miss a piece of information.

Seeing that everyone working in the ICU absolutely has to know everything about each patient/project was an eye opener. Of course that comes at a cost. But in that context that cost is worth paying.
So how much is it worth in our projects that everyone knows everything about the project? How many people in the project have no idea what their colleagues are working on? Is that OK or is that acceptable? How is the risk covered that information goes missing?

I learned a lot more in these weeks. How to recognise if people make mistakes and where the system fails; who puts in more effort than the rest; for some nurses the relatives play a bigger part, for others the patient is the only important thing. Most are somewhere in between. I reckon that's the Manager in me making these observations.
The people who I think of as "best" without defining what I mean exactly all have a passion for what they're doing. They're not only knowledgeable but are emotionally involved. I can say the same about the testing scene or probably any other craft that people are working in.

Of course the "learning" during this time wasn't purely to do with this mindset. Most of it was on the emotional side as can be expected. I learned quite a bit about what my approach to thinking and learning is compared to my parents and what is self-learned. But watching myself making these observations was a convincing sign that I'm working in the right job.

My whole family spent Christmas in Germany (unplanned and at very short notice; 6 hours from getting the call to leaving for the airport with my wife, 8 year old son and all Christmas presents) while my father was in coma all the time. He woke up in January and I flew back to Germany to spend some time with him. He died in February.

You won't be forgotten.

Why using custom pictures in XMind is useful

 I read this Blog from Albert Gareev, thought that's great but there's another way where you can use not only marker packs but also any pictures which is useful as described in my Mindmaps for managing test projects blog.

For example, I wrote the names of my team members in Word, Arial, 14pt, bold and took a picture of the name and now use them as markers. That's very useful when assigning projects to people so I can see at a glance who is working on which projects and where they may be stretched a bit thin.

In XMind this can be done by
navigating to your installation folder, for example
C:\Program Files\XMind\plugins\org.xmind.ui.resources_3.2.1.201011212218\markers

Drop your *.png or even *.jpg files in there.

Open "markerSheet.xml" in the text editor of your choice and add XML entries using the existing entries as a guideline. It's pretty straight forward.
Save and re-open XMind if you had it open before.

Now right click on an object and insert a Marker - voila, your new pictures as markers are now available. You are no longer restricted to pre-designed packs but can cook your own.

Bringing Information Back Into IT

I wrote a bit for the EuroStar blog roll some time ago called "Bringing Information Back Into IT".

Any comments please leave at this post as the EuroStar one is out of date now.

MindMaps for managing test projects

I work in an operational company where the test effort is geared towards in-house projects (see "The need for confirmation" blog for company types).
From a test management view this means that the majority of our time and effort is spent on small version increases of existing software, for example bug fixes, small pieces of new functionality or adding temporary items like pictures and web pages for specific events. Some larger projects, read a few months worth of effort, exist as  well and run alongside the smaller ones.

We usually batch together changes so that we get a decent amount of test time together, unless the projects are decent sized already. I then check what system modules the bug fixes or new functions affect as we always have several of these small projects  on the go, although usually less than a dozen. Once the interaction between these small mini-projects is known I can then decide in which test environment they'll go.

In short, this approach helps with resource management, where the resources managed are testers and test environments. I consciously excluded time as a resource (although that could be tracked as well) and only track the priority of a given project.

In order to track what the status is for each project or change I use a Mindmap which is divided into three main parts:

1. Projects that I know about and that are either in analysis or still in development
2. Projects that are nearly development complete or already queuing to get tested
3. Projects that are in one of our test environments and have a tester assigned

A Mindmap makes it really easy to list all kind of information against a mini-project, i.e. content, risks, developer and tester names, etc. Also, once a project moves from part 1. to 2. or 3. it's an easy drag & drop action and the status of that project is updated.
I experimented a bit and found that colour coding the projects and allocated environments works very well to highlight where a particular project will go to and where potentially clashes are when a project in that environment gets delayed. Putting the names of testers on the top level of a project also helps to see how much projects every tester in the team has going on at any moment in time.
Finally, putting numbers in for priority of projects helps to see which projects should go into one of the test environments next.

Here's an example of one of the MindMaps I use, for obvious reasons I made the project and tester names quite generic.

I use XMind in which Flags can be added to an entry which works in most MindMap applications. The flags are all pictures so I created one with the name of each tester, then updated the XMind configuration which is basically an XML file to add the additional folder and tester names. This makes for quick labelling of who's working on which project.

Here's a link to the generic project in case you want to download it (XMind file).

If you have any questions, please do not hesitate to get in touch.

Writing a job description for a Tester Part II

In the first part I described how I started out with the job desciption for a Test Analyst and why the first sentence was so important for me. In this part I'll go through the body of the job description.

This part is both describing what the applicant is expected to do in the job and what working in our company is like.
A new job is always a two way relationship. The employer is looking for the skills, personality, etc to fill a gap in their team. The potential candidate is looking for an interesting and rewarding place to work in so I try and address both.

Again this section is written tongue in cheek to give the potential applicant both an idea of what's required of them and to lure the right people into applying. In that first part I'm describing the part of personality I'm looking for, I mention some skills and hint at what level the candidate should be.
For someone experienced in ET the sentence ..."know your oracles from your heuristics" should be clear. I didn't want to put "Should have exploratory testing experience" as they keyword driven people would just put that in their CV and I'm none the wiser.
Asking the question "If you're not scared away by the above you may want to apply." should convey that yes, I'm asking for a lot but that I trust the applicant to be a confident and good tester and will welcome them with open arms.

The Principal Accountabilities section more closely resembles a traditional job spec. I nearly left it out as an experienced software tester would be able to do these tasks anyway. In the end I left it in as the tasks in there convey that I'm not only looking for a tester but also a facilitator that can make things happen with other teams and people in the business. Many testers do that but not all so I felt that it would explain to the potential candidate that this is a "get out of your chair and make it happen" job rather than one where the test manager or lead tell you what to do.

The Qualification section contains some standard stuff but also some controversial and opposing if not mutually exclusive statements, that Ajay has picked up on. The idea here is that the candidate asks for clarifications or state their opinion about it so that we can then have a good discussion about it during which we both get to know the others skill and opinion better than with standard interview questions. The idea for this came from the book Lessons Learnt in Software Testing which has opposing titles in chapter 6 about whether to use test document templates.

The bonus section for Qualifications is tongue in cheek again. I start that having no ISEB/ISTQB qualification is a good thing for me. The idea here is that
a) it's unusual and people take note - no skimming over this job description, I want your attention here
b) I don't think much of these certification programmes
c) If the tester doesn't have certificates, how do they educate themselves? Another opportunity for a good discussion
d) I want to see if people change their CV when applying for the job or if they send a generic one. Custom build CVs are more interesting to me - I'd like to see if they're interested enough in the job to put some effort into the CV or if they can't be bothered. Since I removed the chance for just putting in the keywords from the job spec by hardly mentioning any the custom CV should more closely reflect their real experiences.
The other items on the list are mostly nice to have's and cover a wide area so that almost everyone can tick one if not several of these boxes.

If the result is worth the effort you ask? No idea, yet, I'll find out soon. From the applications I've got so far I could easily see who read the job spec and who just skim read and send their generic CV. Makes my job easier as I can just bin the latter.

Writing a job description for a Tester Part I

This two part post is about my recent job description for a Test Analyst.

I recently started a new job taking over a team of four Test Analysts only to find that one moved to another position within the company after two weeks. Relieved that it wasn't me but that the move had been planned before I even arrived I quickly had to think about replacing the 7 years+ domain knowledge that just walked out of the door and the nice guy owning that knowledge. Nice start.

Since I didn't know yet the strengths and weaknesses of the team I decided to get the skill matrix out that I used in my last company. In short, it's a table that lists all sorts of skills and knowledge areas against a column for each tester and values ranging from 0 to 3. Zero meaning no knowledge, three meaning mastered that skill. It's a quick and dirty way to get a feeling how people see themselves and if there are areas that no one in the team really has knowledge of. This is worth a blog in itself but I don't want to overburden this one.

After discussions with the team I then found that structured exploratory testing was new to them so I decided that I wanted to get someone who's got some experience and interest in that area, maybe someone who took part in weekend testing sessions. Automation was another "no knowledge" area but there are other problems that we need to solve before I'm prepared to tackle that one.

Armed with that knowledge I then trawled the internet for job descriptions of Test Analyst, QA Engineer and whatever other job titles people gave to software testers. The majority I found were generic, non-descriptive documents that were interchangeable or they were looking for programmers in disguise.
Most used keywords and things like "experience with Quality Centre". I never understand that one as any tester worth their salt should be able to learn that within a couple of days. One of the requirements for the job is that we learn quickly how to use a new piece of software so why make it a requirement for a job?

I can understand it in specific cases if you're using a specific tool and your expert just left, you may want someone with that knowledge to pick up where the old guy left off.Or you need help implementing a specific tool or need certain skills in your team. Generic statements don't help in this area though IMHO.

I then had a think of what it is that I really wanted, what I didn't want to compromise on, what's my most important requirement. I then put that as the first sentence of the job desciption for a Test Analyst.


"We need someone who knows how to test software first and foremost."


This sentence is very simple but has several functions, similar to the "Pricing has many functions, only one of which is the exchange of money" which was coined by Jerry Weinberg. I heard that first at the Rapid Software Testing course with Michael Bolton. One is that it's a non-standard way to start a job description. As any successful novel writer will know, you need a strong first sentence that captures the readers attention and creates a feeling of wanting to know more. I believe this one qualifies.

It also makes very clear what's required of the applicant - people blindly ticking of scripts need not apply.
It also conveys that the person writing this knows what he wants and that this description hasn't been written by someone in HR who doesn't know about testing.

Of course the sentence is cheeky with a touch of humour as stating the bloody obvious is done in many CV's - need to be able to write test scripts, test plans, work with developers, etc, but not in such an extreme way. That software testers should actually be able to test doesn't appear in any CV's I've seen so I thought I'd put it there.


Testers who take pride in their work and want to learn more about their craft should get the feeling that there is a Test Manager who cares about these things rather than asking "How many percent of the test scripts have you written/executed" or "How many bugs have you found today?".

I want these testers to apply.

More to follow tomorrow in part II

I'll try walking in your shoes

I recently attended a Project Managers meeting where PM specific, day to day problems were discussed.

Some were quite generic in nature and similar to a tester meeting, for example how do we make sure that people are properly trained, dealing with communication problems, etc. Others were more specific, for example talking about managing customer relationships, how a customer may perceive problems in a project from a completely different angle (for the better or the worse for the PM in question).

What occurred to me there is that we put a lot of emphasis in testing on adding “value for the customer”, however most testers that I know have no idea about customer management, and how our customers priorities might be different from the ones that the development team (programmers and testers) are thinking of. Managing that relationship sits squarely in the corner of the PM or Account Manager (where available). In a way it’s good that the Project Manager is shielding the development team from sometimes difficult customers, but to what degree can a tester really say that what they’re doing is actually adding value for the client?

That reminded me that what we think of as “adding value” is actually based on a model. To quote George Box “All models are wrong, some are useful”. Is our model built on validation and verification – in a broad way ensuring that the system works as intended and works without glitches? But what do we base that on since we all know that requirement documents are notoriously lacking? The argument I often hear is that testers bring their experience in adding what they perceive to be of value to other customers so it might be of value to the current project as well. With no knowledge of the customer or our relationship with them how can this be true?

At the next team meeting it might be an idea to invite the Account Manager as well or, if the PM is fulfilling that role as well, ask him about our relationship to the client. Is it perceived to be a difficult one? Have we worked with that client before? Is the project seen as a start of many others to follow? Do we know of particular things that “bug” the client that would help us direct our test effort?

I don’t know how other people address that but these are not questions that I have asked in the past but maybe I should. I attended a Project Management course and think that all testers should do that sooner or later, ideally followed with actually managing a project or two as well.
Many testers have an idea of how programmers think, many having a background in programming themselves. Maybe it’s time that we start to look through the eyes of a Project Manager as well and walk a mile in their shoes.