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. :)

The need for confirmation – why checking against requirements is not going away

I was thinking what prompts the need for traceability and ensuring that the final application actually satisfies the requirements that were captured at the beginning of the project. Who needs that traceability? I then thought about different companies. The type of company a tester works in has a huge impact on the approach of their testing. Broadly speaking (read: this is a gross generalisation) we have these types of companies:


1. Product companies selling shrink-wrap software. This is anything from operating systems, games, tax return helpers, computer helper apps (Adobe Reader), etc.

2. Consultancies developing a bespoke application for their clients to address a specific business problem

3. Hybrid between the first two, for example further developing/configuring a shrink-wrap application, for example SAP or other back-office systems.

4. Large company developing a bespoke application in-house for internal use only, for example banks or insurance companies.


Let’s have a look at each from different angles.

The first type of company producing products is somewhat unique, as there is not one, single client that determines the requirements. They need to rely on Product Managers or other staff who can guess or work out that there is a target audience who’s likely to use and/or buy their software. Anticipating what the market needs determines the requirements.
Many products, when selling well, will have several versions and releases. That’s good news for the automation people as products often need to be regression tested for a variety of platforms, i.e. different operating systems, hardware configurations, or when new functionality is added over time. The quality necessary for their products depends on the market they’re selling to.


The second type is very much focussed on the one client they’re selling to. What’s in the contract will get built (and tested if the contract specifies it). What’s not in the contract depends on the good will of the consultancy. If a client just spent £3M with you and you wave the contract instead of adding a 2 day RFC that’s probably the last big contract your company got.
Automated regression testing depends wholly on the client – have they specified that they want it, is the application large enough to warrant it for just the one version, are there likely to be more version of the software and contracts coming in from the client? Then it might make sense building something automated, otherwise forget it, time is money in this setup.


The hybrid company is closer to the Consultancy but with the added complication that now there is third party code to be considered for testing. More often than not that has already been tested but one has to be careful to exclude functions as they may be used differently in the context of the re-developed/configured new solution.

The in-house development test efforts very much depend on the company, however there usually are requirements that have been developed by internal groups. This type is usually similar to the Product companies in that software developed is there to stay for probably more than one version. That means more effort can be spent on testing it properly and with a long term view.

To come back to the need for confirmation – if you’re working in some sort of Consultancy, traceability is a no brainer. You’ll need to confirm that what your company is delivering is adhering to the requirements that were set out – and by extension that you fulfil the contract. From the Consultancy point of view satisfying the contract has to come first, otherwise the business would leave itself wide open to being sued or just not paid for breaching the contract. So once the confirmation is out of the way there might or might not be time to test the application in detail.

If you’re working in a product company or in-house development effort it’s a bit different. There are other factors to consider though. Are there any legal requirements to adhere to certain standards? Does the software need to be certified against particular standards? GLP or GCP comes to mind. Traceability is maybe not so important in this setup compared to the Consultancies, unless the PM or project owners insists on it, I’d argue out of the false hope that the system will then actually deliver what was expected when the requirements were written.

There was an argument on one of the LinkedIn groups if checking/testing against requirements is a hoax or if it adds value. As always, the answer is, it depends. If you have a 1:1 relationship of tests vs requirements I’d say it’s a hoax. All requirements need more than one simple test. So saying that a particular requirement has been tested against, then ticking the box, fine, that’s implemented is giving a wrong picture.
Imagine you have a requirements that says that you need to have several user roles in the system. Would you confirm that with one single check? You could, but would it actually give you the information and confidence in the application that the stakeholders ask us to provide? I don’t think so. Why artificially tick a box and say, yes, there are several user roles in the system if you’re telling a white lie if you haven’t tested the around that requirement?

I can see why checking against requirements is popular as it’s easy to put into contracts. The effectiveness of it from a quality point of view is almost non-existent, so it might help the sales and legal people (and not even that if the customer is set on suing a non-compliant company) but the PM should be looking elsewhere for confidence that the final product is actually what the customer wanted in the first place.