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.

The pictorial challenge answered

After a short discussion with Zeger (TestSideStory) on Twitter about the pictorial challenge it was time to do some work but I came back to the picture later. Have a look at it first before reading on.


I sat back and thought “How would I test this if I don’t know what’s important and don’t know to whom it will be important?”

I then collated some high level areas of approach

• Death by Goggle:

   o Searching the net for the names on the signs to give me more avenues to consider

• Technical: It’s a .jpg of a certain size, resolution and colours used

   o Is that on purpose, in which scenarios could it be a problem?

   o Are there parts of the picture that look cut off, is there too much sky, etc.

   o Are there hints that this is a collage of pictures or is it one photograph

• Emotional: How do I react to the picture when looking at it first.

   o How does that change when picking out more details?


I started with the emotional part first because a) I can’t help it and b) to me testing a picture is more akin to criticizing a painting so I wanted see if the artist/photographer got an immediate emotional reaction from me. The signs look rusty and barely legible. Rust to me indicates age so I assume they’ve been there for a long time. The house looks like it has seen better days, my first reaction is that it’s been taken in a poor part of whatever town/country. The boy on the roof (I assume it’s a roof) would be unusual in a UK town, maybe it’s not where this picture is taken? Filed away for future consideration.

I then searched for “Zanchett” and “La Mejor Ropa”, the latter of which is Spanish for “The best clothes”. But maybe it's not "Zanchett" but "Zanchetti". That's where the font type could throw a spanner into the tester's work. You live and learn. Again, more pages but I didn't follow them up too closely as I'm more interested in the picture rather than where  it was taken. Zanchett seems to be quite a common name, there are several facebook sites, a Portuguese Tourism page to name a few. I also found links to a breastfeeding site in Brazil, so maybe it’s not Spanish but Portuguese. The boy (man?) on the roof is wearing a t-shirt, short trousers and sandals which indicates a warm country. At a guess I’d say the photo was taken in Brasil or Argentina.

The breastfeeding site also made me look at the photo closer, maybe the blue plastic bowl hanging at the outside of the house is actually a baby bath. The bike on the left, caged birds on the right and the boy on the roof could mean it’s a nursery or orphanage (because of what I assume is a poor area, I could be wrong here). In my experience Mediterranean houses don’t give the impression that they’re looked after from the outside, that doesn’t mean that they’re not in very good condition from the inside. There’s an angle of cultural differences here and since I assume Southern America here as the location I’ll have to question my assumptions. The boy/man (I'm not able to clearly distinguish the features to say for sure) is wearing sports clothes which seem new or in good shape at least so maybe poor isn't actually correct here.

I didn’t go into the technical details other than noting that the size is 601 x 776 pixels – the 601 seems odd to me, maybe it was converted from a different size or type?


I’ll get in touch with Zeger to see what he thinks about it. :)