We are all on a journey

At some time or another we all lose sight of the fact that each and every single one of us is on a journey.

Life is a journey. Your careers and jobs are just one part of that bigger journey.



  • Some people take more control of this journey than others.
  • Some people have more opportunities to take control than others.
  • Some people are further along their journeys than others.

There are many factors that affect the journey you are on.

These could include some of the following:

  • Your personality
  • Your location
  • Your cultural background
  • Your mindset
  • Your boss
  • Your company
  • Your family
  • Your desires and needs
  • Your passion for the job
  • Your peers
  • Your awareness of the industry
  • Your mentors
  • Your heros
  • Yada yada

The list goes on, and on, and on.

Some people are more open to new ideas, new challenges and new opportunities. This often gives them a wider choice of potential paths.


This opens up great opportunities, but it can also open up choices which are hard to make.

Some people are further behind on their journey than others. That doesn’t make them “rubbish” or “stupid” or “not part of our group”. It just means they are on a different path, are in a different place on a path and maybe they haven’t yet reached a similar path choice that you have gone down.

10 years ago I was on a path of scripted testing, no exploration and all of this in a waterfall death march environment. I’ve heard people say recently, that testers in these environments are “rubbish”…….really? Why?

I’m a better tester now for sure, but I’ve never considered myself “rubbish” – I’ve just gained wider insights and more experience from the paths I have chosen (or been forced down) in my career and life.

Some people choose alternative paths for a variety of reasons. That’s their choice, not ours. They may want different things from their careers. They may want different outcomes. They will have different personalities than we have.

Some people follow career paths that don’t seem logical, that wind and dip and move backwards.


In the end though, they too are on a journey. And that messiness and sporadic direction of travel may suit them well.

In the testing (and wider development community) we are all too quick to assume that someone is rubbish, or inferior, simply because they are on a different path, have not had access to the opportunities we may, may not show any interested in progressing beyond “enough” and may not even be aware of alternative routes they could take.

The work someone did a few years back is often still deeply associated with that person, even though their current work may actually be very good. Work some people do now may be of the same standard that we ourselves may have been doing 4 or 5 years ago.

We’ve grown and taken paths which lead us to now, they may do the same too. In 4 years time they may be doing the same standard of work as we are doing now.

Don’t get me wrong. There are testers who are better than others in certain environments. Or achieve higher marks using whatever yardsticks for measure you are using. There are testers I would hire and who I wouldn’t. But there are also good testers who are right for one context and not for another.

There are testers who, with the right help and support, could become outstanding testers. There are good testers who may not get that help and support…..

There are many routes and paths through our testing careers. The path you choose will not be the one I choose. And that’s ok.

It’s easy to point at someone else and say they are rubbish because they work in X way, or don’t have X skills.

It’s harder to acknowledge the reasons why they are at a certain point on their career journey, to establish whether there really is a problem with them being there (or even if it’s any of your business) and then to support, help and share to guide them down a path they want to go on.

How to gain insights from customers to help your testing

In the past I have talked about the need to find out more about our end users so that we can help to focus our Testing on genuine use cases and problem areas for customers.

One of the ways I believe we, as Testers and Managers, can do this is by doing on-site visits to our customers.

However, I’ve had a number of responses stating that it is not possible or feasible. I agree it’s hard work and not always possible at all work places.

I believe a firm trait for Testers is pro-activity and persistence. I think Testers can explore other avenues to seek out information on products, customer usage and customer expectations.

Understanding end user behaviour doesn’t always rely on field research and observation.

The web is making it much easier to connect and find people, and that also includes people who use the products you work on.

You can connect to people, study the behaviours of people in your domain, or read about experiences through blogs and articles.

The web allows you to seek out deeper understandings of the types of roles, responsibilities and daily frustrations your customers (or potential customers) may face.

We aren’t just Testers, we can also be the researchers who find out more about how our products are used.


When studying data it’s important to look for patterns you can make inferences from, but it’s also important to ensure you balance the research. Don’t just find a good source and use that as your only source of insights.

For example, a power user blogging about how they use a product will give you a different perspective than a novice user.

Always try to find a counter view, or objection to the view/statement/observation made. The more dimensions you can research and explore, the stronger your assumptions and inferences from that data will be.

One of the greatest things to seek out are stories. Stories from people who use the software. Stories from people who don’t use the software. Stories from people who work in the domain.

Stories give you deep insights. Stories are basic human forms of communication. Stories are part of how we make sense of the world. However – accept that stories are often deeply one-sided. Balance is required.


How to do it

The web (social web in particular) is daunting to many people, yet others have flocked to it and adopted it with ease. Generations are growing up with the social web as an extension of themselves.

People are sharing more information than ever before.

Narrative of life is the new focus for many people. The Social Web is a fascinating place to research more about people, tech and culture.

What follows is a very short list of some of the sources of learning and insight I have used.


Research Papers

There are literally thousands of research papers available free on the web. Many of these papers are directly related to the industries we work in. They are often deeply insightful, but often very dry in their delivery.


Twitter/Facebook/Quora etc

Seek out the industry you are working in using your favourite social channel. Search using the relevant search option (for example: hashtags on Twitter are a useful way of filtering the noise) and then start observing the discussions, problems and concerns being raised.

This could be useful information for understanding how people using products like yours perform their day jobs. It can help to build persona details which might give you a richer understanding of what it’s like to work in this domain.

Each social channel comes with ways to filter the noise and ways to search for content specific to the tribe, trend or topic you are interested in. A quick google search will provide a wealth of tools for each of the social channels.



LinkedIn has forums which are one of the best sources of information about a domain or the products being used. Ask a question or sit back an observe. Just be careful of Best Practice pushers (i.e. people who see no way other than their way) – LinkedIn is rife with these peeps.



A quick google search for a blog related to your industry could soon lead you down a path of amazing information. Follow links and click through to other blogs. Read the comments – they are often the really insightful content.

Testing is about information gathering as well as bug finding. It’s too easy to put your hands up and say “can’t be done” when trying to find more information.


It’s a lot harder (but more fruitful) to be pro-active and seek alternative ways of gathering information.


How do you find out more about how your users use your product?

Exploratory Regression Testing

I was chatting through some ideas for “firing” up our regression testing process with one of my guys, Andy.

We already have a good set of the regression tests automated, but there are always some tests that need (or would benefit from) human interaction, especially when phone calls are involved.

We have a regression “pack” of standard tests but as Andy is running these each week (weekly release frequency) you can understand how it might get repetitive…and a tad boring.

So we talked about a few strategies. He and another one of the team, Simon, had decided to switch products every so often to break up the repetitiveness also.

This is a great plan. It means each of them get to see another part of the system and learn about it, it breaks up the repetitiveness and it also has an added benefit of a “fresh set of eyes”.

I won’t bore you with further details on this but one thing blurted our of my mouth whilst we were talking and at the time it made sense.

Only upon reflection later did I start to dig deeper and wonder what I was talking about.

I suggested to Andy that maybe we do some “exploratory regression testing“.

Sounds good right?

But can Exploratory Testing really be used to do regression testing?

  • Isn’t regression testing “supposed” to be about running already executed tests (that subsequently become checks)?
  • Should regression testing be about repeating already executed tests/checks? Is there value in this activity?
  • Can exploratory testing really be performed to give confidence that nothing has regressed?

The more I explored some of these thoughts the more I realised that I actually quite like the term and concept of exploratory regression testing.

No doubt there are already people using the technique and phrase, and no doubt there will be many people who don’t believe exploratory testing is regression testing, but for now I’m going to keep using it.

Here we all seemed to understand the term and idea and it’s giving us great value.

I just thought I’d get your feedback on it.


Are certifications relevant?

I know many readers of my blog would suggest I’m a hater of certifications for Testers.

That’s simply not true. Despite my ardent fight against them I am pragmatic enough to realise that getting a job often requires getting a certification. And putting a roof over your head often trumps principles and ideals.

I also believe that a certification course, delivered by a competent tutor who has bucket loads of skills and experience, can be very valuable.

I just don’t like what they have come to symbolise in the market place. I don’t like how you DO NEED A CERTIFICATE to get a job (in most cases).

Where did it all go wrong?

I’m not here to bash Certification schemes. Use your own judgment and experience on whether you think they give you insights and learnings or not.

Instead I’m going to ask you a question:

Are certifications still relevant?

  • I don’t believe they have succeeded in making people competent Testers. This is evident from the number of certified people on forums and LinkedIn asking “What is Testing?” or “Tell me how many Tests I should have for X feature!” or “why is testing so boring”.
  • I don’t believe they have succeeded in creating a universal language with which to talk about Testing. This is evident from the fact most Testers don’t know what “action word driven testing” is or what a “Software Failure Mode and Effect Analysis” is OR the fact that I call it a Test Case you call it a Test Script. The big question here is “Do most Testers care outside of their own company and context?”.
  • I don’t believe they have succeeded in promoting the value of software testing to organisations and business. I still come in to contact with a vast array of companies who don’t test, don’t appreciate testing and don’t understand what value testing can bring.

So are they still relevant?

There was a time before the Internet when you had very few places to go to obtain Testing knowledge, training or awareness. When I started out I went to the British Computer Society, a few well known books and the ISEB foundation. The ISEB crowd certified me. I still kept Testing as I had before. I just felt slightly more hire-able.

Only when I reached out to the wider community online did I find a place to soak up information and ideas about testing. I started sharing ideas. I started to meet people who thought the same way that I did. I started to feel like Testing was actually interesting. I started to find people who didn’t talk about standards, didn’t speak in platitudes and marketing pitches and didn’t push certifications at me from all angles.

When access to information is restricted or impossible those that hold the information have the power. If you wanted that information you had to pay. If you wanted to see what the “industry” thought was a good standard, you had to pay to find out, and then pay even more to be accepted.

Social networks and the “digital revolution” has made that information (and a much broader selection of ideas too) available to the masses. Having to pay for access to information is becoming rare.

Yet we still continue to pay for certifications.

We’re no longer paying for the content; almost all of that is available online, for free.

We are no longer paying for the training as it’s possible to sit the course and pass without in person training. (There are also a vast selection of excellent paid and free courses available online and in person outside of the certification schemes.)

I believe the masses* are paying for the right to say “I have a certificate!!!!!”

In a sea of people all shouting “I have a certificate!!!!!” why would anyone pick you?


* There are some people I meet who sit the certification courses as just one part of their continued learning…not the only part of their learning.

Social Media alone will not get you a job

Judging by the swarm of testers trying to connect with me on LinkedIn recently it seems no-where is now safe from those who want a job.

99.9% of those who try to connect with me have never had a conversation with me (in the real world or digital). I see the same thing on Twitter, where I have less control over who follows me and also on this blog, where I delete a huge number of comments from people wanting a job.

It seems many testers are falling in to the simplistic trap of believing that social media will get them a job. It’s not surprising when there are a number of companies, individuals and organisations who are pushing social media (in the Testing world) as the way to land a job.

It’s easy to see why people would sign up for Twitter, follow some people in testing and then directly ask them for a job.

Social Media alone will not get you a job. Social Media, in a simplistic sense, is a communication (and publishing) platform/channel. It’s a way of networking, communicating and distributing content. Social Media may get you connected to people with jobs, or put you in front of people who are hiring, but you’ll still need the skills to see the application through (unless of course the hiring manager is not assessing you on anything). You still need your thoughts, ideas and the ability to articulate these clearly. Social Media alone won’t help you there.

(Note: I do know of some examples where simply turning up to the interview would get you a testing job, but I don’t really consider that testing, or a proper job.)

Here’s some thoughts on why I believe the message is too simplistic.

  • Some companies may see an active social media user as a drain on resource. After all, you should be working instead of tweeting…right?
  • Some companies may see an active social media user as a risk. “What are they going to say that could get us in trouble?”
  • Some companies may see active social media users as a boon. After all, their business may benefit from the thought leadership, experience or free marketing. They may even be working in the social space and demand people who understand and “get” social media.
  • Some testers wield their social presence with great skill and attention, yet aren’t great testers, but great marketeers.
  • Some testers wield their social presence with great skill and attention and are amazing testers, and great marketeers.
  • Some testers don’t wield their social presence well, and are bad marketeers.
  • Some testers sign up to social channels because they think they should and do nothing spam others.
  • Some testers sign up to social channels because they think they should and have no interactions, followers or conversations.
  • Some testers use social media as a platform to sell services and goods.
  • Some testers use social media to communicate ideas and further their skills and thinking.
  • Some testers use social media to build communities.
  • Some testers use social media to destroy communities.
  • Some testers just don’t get it and stay away.
  • Some testers are afraid of social media. Their personalities don’t gel with the public display of thoughts and ideas, yet they can be incredibly talented.
  • Some companies hire very well without social media.
  • Some companies go straight to their social channels for hiring.

I probably know someone who fits all of these, and a whole load more categories too.

I know a great tester who recently landed an amazing job and she isn’t on any social networks. Not even LinkedIn.

I know testers who are on social networks and actively connecting, but they can’t get jobs. They lose out to better candidates.

I know of some testers who have been offered a job directly through Linkedin without even being interviewed.


It’s too simplistic to say that getting a job requires you to be on a social channel and it’s too simplistic to say that being on a social channel will get you a job. It’s clearly not true in either case.

What get’s you a job (apart from “jobs for the boys” mentality) is proving to yourself, your peers and the hiring manager that you can do the job.

Social Media is no different to networking in person at Testing events, presenting at conferences and offering training services to build a wider network.


Getting in front of the hiring manager is easier with more connections, but these don’t have to be online through social channels. Many testers operate very well indeed and that’s purely from the old fashioned face to face networking.

Networking has been the key to getting a job (especially in hard times) for years, and it’s true that Social Media makes that’s easier now for the masses. But any hiring manager worth their salary should be recruiting for the person and their mind, not the number of social channels they are on.

Social channels and social media can help you amplify your thoughts, build your network, generate content and communicate with those who can get you jobs, but your skills and experience will be what ultimately separates you from others.

http://www.forbes.com/sites/lisaquast/2012/05/21/recruiting-reinvented-how-companies-are-using-social-media-in-the-hiring-process/ http://www.forbes.com/sites/lisaquast/2012/05/21/recruiting-reinvented-how-companies-are-using-social-media-in-the-hiring-process/ http://www.smartcompany.com.au/hiring/048837-the-legal-dangers-of-hiring-through-social-media-2.html http://www.chicagotribune.com/features/tribu/ct-tribu-facebook-job-dangers-20120117,0,1257938.column http://www.therecruiterslounge.com/2011/09/26/be-careful-when-using-social-media-in-hiring-decisions/ http://www.quarles.com/employee_social_networking_dangers_2010/ http://www.inc.com/guides/2010/04/social-media-recruiting.html http://mashable.com/2012/02/11/social-media-recruiting-tips/ http://steveradick.com/2012/05/27/seven-real-ways-you-can-use-social-media-to-find-your-next-job/ http://socialmediatoday.com/fixcourse/564760/3-social-media-mistakes-you-dont-know-youre-making

How to run a proof of concept

When seeking out new tools to aid your testing I strongly believe in doing a proof of concept. It needn’t be anything heavy weight.

In fact, the more concise the better.

What is a proof of concept?

I use the term “proof of concept” to describe the process of evaluating a tool (or service) for suitability against a number of criteria.

This criteria should be specific to your context, although some of the criteria would probably apply across many contexts.

Note: from this point on I will use the word tool to encompass both tools, services and other paid for systems.  Why perform a proof of concept?

I believe it’s important to run a proof of concept for a number of reasons.

Short term reviews of products and more specifically, product specs/marketing material, can lead to a snap decision that might not consider a wider view. This is even more a problem when you have a salesperson pushing at you to make a decision.

You don’t have to look far to find many companies and organizations trying to sell you a solution to each testing problem you may (or may not) have. Some of these solutions are great and right for you. Others are not.

If you don’t spend time trying the tool to see if it solves your specific problem then how can you be sure the product is right? How can you even be sure that the claims in the literature or sales meeting are even true?

Tool usage can often involve people from other departments, either directly or indirectly, so it’s only right to collaborate with them also.  (for example, a bug tracking system is not typically used just by testers).

The initial pricing descriptions or quotes may not actually be the end price you pay after adding on extensions and support contracts, etc. This is a very compelling reason to find out what the tool does and what it doesn’t do before eagerly signing on the dotted line.

The tool needs to solve a problem, but it might cause more in the long run. Snap decisions to solve one problem could leave you with a bigger problem (i.e. -training needs, hardware requirements).

Comparing a number of tools can often lead you to greater insights in to the problem you are trying to solve and you may generate creative solutions to it which might not have come about without proving the tool.

My memory isn’t what it used to be so documenting the proof of concept and having comparison data to refer back to leads me to a more accurate decision.

There are many other reasons why someone might perform a proof of concept, the above are just a few that immediately spring to mind.

When should you run a proof of concept?

In my opinion any tool adoption that impacts a wider audience than yourself should have a proof of concept process.

For example, my decision to start using Rapid Reporter rather than NotePad only really changed my working arrangements. So I didn’t feel the need to perform a proof of concept.

However, a decision to start using a new Test Management tool might impact the wider Test team so this could be a good candidate for a proof of concept.

How long should a proof of concept take?

There is no right or wrong answer. It depends on the tool, the number of people involved, the cost of the tool and the infrastructure to name a few variables.

I try to keep my proof of concepts as short and time-boxed as possible. This focuses the mind and encourages better planning in advance.

I would suggest that if your proof of concept is taking months then you have a problem. Either you are not pro-actively involving the right people and making use of the time available, or you’re trying to assess every angle, feature, component and pricing model of the tool. This *might* be a good thing when opting for the big vendor wallet splitting tools, but for most tools I’d suggest it may be overkill.

How to prepare a proof of concept Scenarios and Problems

My first step is to write down the problem(s) you are wanting to solve. Writing them on paper helps to articulate clearly the problem space. It helps you to work through the problem in your mind.

For this I typically use a mind map, but that’s my own personal preference. Use what works for you.

Once you have articulated your problem clearly you will probably find a natural set of criteria emerges that you can use to judge the tool against.

For example – you might want a tool to aid your test management. You might have a desire to report the number of bugs raised versus the number closed per sprint, or other time scale.

From this problem statement you automatically have some checks to run. (i.e – does the tool generate that report?)

If the tool does not solve your problem and meet your requirement then either move on or re-assess how important that criteria (in this example, the report) is to you.

In defining the problem and some typical uses of the tool you will start to build a handy checklist. Don’t go mad though, you could spend months assessing a tool against lists.


It would make sense to find out what your budget is. Your budget constraints will naturally lead you down certain routes.

There is no point reviewing a big vendor tool unless you have a stack of cash to throw at it. As a manager though, be cautious about blowing all of your budget on a big vendor test management tool.

Firstly, there are many tools for less (or free) that do the job just as well (if not better).

Secondly, there will always be something else to spend your money on further down the line.

Is support included?

It is always worth checking if support is included in the price. And if so, what level of support that provides.

Are there any SLA (service level agreements) against this support contract?

Do you need support?

Are upgrades and maintenance releases included in the initial cost, or charged per upgrade?

I once worked with a Test Manager who bought a giant vendor tool for many thousands of pounds but failed to consider the upgrade licenses. The tool vendor released the newer version about 4 weeks after we started using it, and the newer version obviously had more glossy features and many bug fixes…which we then had to pay extra for.

Always check the pricing structure clearly.

Are you going to need any plug ins or extensions to make the tool work?

If so, how much are they?

How easy are they to use?

Are they widely supported?

Can you try these as part of the free trial?

Do I, or the team, need extra training?

If so how much and is there a cost associated with this?

Would a book suffice?

Are there any user groups or online communities that can help?

What skill sets do we currently have?

Are there open source tools available?

You might find that there is an Open Source tool available that does 99% of what you want with no license costs.

Could you roll your own tool from the Open Source code?

There may be three or four tools that solve your problem available with open source licenses. Could you plug them together with some bespoke code to create a good solution?

Do you have the required infrastructure and hardware?

If not, how much will it cost to get it?

If yes, what is involved in getting the product running? Do you need help from others in the business?

Are other departments or teams looking to use this tool too, or are they impacted by it?

If not – are you sure?

If yes – have you spoken to them? Are they involved in the review?

How long are you planning on keeping the tool?

Could you find a creative work around if your problem is short term?

Are you 100% sure that you want to sign a contract for many many years? What about a SaaS model? Or one year contracts?

Does the tool support multiple ways of working (methodologies/approaches) or does the tool enforce a certain way of working?

It is always best to find a solution to allow for future growth and change.

Many of the old-school testing tools enforce a certain order or structure which could hinder your growth or stunt your productivity.

Be sure to assess the tool from your point of view, not the point of view communicated by the literature, sales person or wider community. The tool needs to work for you.

What is the deadline for deciding?

Do you have a deadline that needs to be met. This will give you a constraint, which will help to focus your attention.

Can I try the software?

If not – why not. Come on, it’s 2012, it should be possible to try before you buy, even products that need to be installed client side.

I would suggest you download or sign up to as many tools as possible and run each one against any acceptance/proof of concept criteria you have.

Final Thoughts

The above might help trigger some thoughts for you, or you may already have your own list, but I strongly believe that time invested in the proof of concept could be time saved (and/or cash saved) in the long run.

On a general note I would look for a wide selection of tools and try as many as you can. I wouldn’t just follow what the industry mainstream is doing. Focus on what you need and you’ll certainly find the right tool.

Good testers look behind the screen

The other week I found myself in an exquisite room with a group of like minded testers talking about testing. Exploratory Testing to be precise.

I’m not sure whether I’m allowed to spill the beans on why we were all there, so I wont..just in case.

Suffice to say though I was with some of the most interesting minds in the UK with reference to Testing. Throughout the day I jotted notes and took away a tonne of actions and things to research, but one statement from Steve Green (of Test Partners fame) really struck a chord with me.

We were talking about hiring testers and what traits/skills a good exploratory tester has.

Steve gave a great example of how many testers he meets are stuck looking at the screen and running tests to check/verify/test the capabilities and elements they can see on the screen. This is fine, for some.

For Steve though, he looks deeper than this.

He prefers people who look at the screen and then beyond it.

Behind it, under it, away from it.


For example, what happens to the overall system when I click X?

How is Y working?

What happens if I tweak Z?

I thought about this comment a lot and wondered whether this was actually an example of the difference between Black and White (or pink, grey, blue, tangerine, Alizarin crimson, black olive or …) box testing.

However, I think it runs deeper than this. I think that looking behind the screen is more about curiosity and intrigue (and therefore great testing?) than it is knowing about what the internal system should do.

It made me think hard about the different traits we all look for in a Tester and the words we use to describe these testers.

It was an illuminating day. I learned a lot.

An Introduction to Mind Mapping for more than Test Design

An introduction to mind mapping

Mind maps have long been an important part of my work, right from organising management tasks through to test design and ideas generation.

I’ve learned a lot about how my thinking unravels by using mind maps. Despite my success with them I’m conscious that not everyone works well with a mind map. Here are a number of ways in which mind mapping has helped me. I’d be interested to hear about other ways people are using mind maps, or other techniques for organising thoughts, data and information.

A sample mind map
A sample mind map

Mind maps for brainstorming, thinking and writing

I’ve been using mind maps for about 15 years now for brainstorming and aiding my thinking. I’ve never moved away from them. They’ve been invaluable in helping me to generate ideas and connections.

Most of my blog posts, books and other content comes from an idea which forms the central node of a mind map. The outline of “Diary of a Test Manager” was done in a mind map. I’ve got another book I’m working on that’s been outlined in a mind map also. Some of my more complicated blog posts start out as a random thought that is then structured, explored, exploded and refined in a mind map.

For those new to mind maps they work (at a basic level) like this – from Wikipedia.

mind map

 is a 


 used to represent 



, tasks, or other items related to a central key word or idea. Mind maps are used to 




, and 


ideas, and as an aid to 





solving problems

making decisions

, and writing.

Most electronic mind mapping software allows you to move thoughts (nodes) around, add notes, add hyperlinks, cut/paste and create relationships (links) to other nodes. If you are using paper then this flexibility is less of an option. It is possible to export (from electronic system) the map in a number of format such as jpg or txt.

For me the central idea for my writing typically forms the central point in a mind map. From this central point I can spawn a number of child nodes exploding the idea. I typically don’t self edit at this point, instead I choose to let the ideas flow.

After a while I will start to drag and drop the ideas in to logical groupings before applying edits to the spelling, typos and removing ideas that no longer make sense. New ideas will obviously come to light and can be added quickly and easily to the mind map.

I can quickly spin up new nodes, add web links, add resources and create to-do tasks.

Tool I use for this : XMind

Mind maps for test ideas

I use mind maps to document my thinking around user stories, features or capabilities that I will be testing. I will map out my ideas (no matter how crazy) and then regroup, re-factor and create associations later.

I typically do this during story chats and design meetings. I used to do this process of capturing test ideas in excel which was very effective but the re-ordering and associating process was trickier. It was also slower to brain dump.

I typically export the mind map to text and copy/paste this to excel to give me the reporting and ordering aspects that excel can offer. I know some testers continue to use mind maps for their planning, measuring and reporting too. I’ve found them less useful in this respect but my needs will differ from others.

Tool I use for this : XMind / Pen and Paper

Mind maps for Product Outlining

One of the first things I do when working on a new product is to map out the capabilities and structure of that product in a mind map. This essentially gives me a more visual representation of the entire system (and sub-systems). I can start to build a picture in my mind of how things hang together and what changes/testing might affect different parts of the product. During this mapping I will take notes and typically create another mind map with my test ideas.

I print this out and stick it on the wall for quick reference. (some mind maps don’t print well if they are large though).

Tool I use for this : XMind

Mind maps for Team “Things To Test”

Every team I have worked in has had a number of standard (or regular) areas to consider or components to check for feedback when testing. For example at NewVoiceMedia when we test we always check the “call recordings”, “audit log”, “call quality”, firebug outputs and of course the web server event logs.

We typically check these areas no matter what testing is taking place. These and many more areas give us feedback and clues as to the state of the system, even if they may appear to not be directly related to what we are testing.

These areas are documented in a mind map so that we can quickly see what areas should be consider. It’s a cheat sheet basically.

Tool I use for this : XMind

Mind maps for documenting meetings/gatherings and training/events

I use mind maps for documenting meetings and other gatherings so I can keep my notes short and concise. I have terrible handwriting so I tend to keep my writing limited to nodes in a mind map.

I use paper based mind maps for this task because I prefer the freedom a pen and paper brings when information is coming thick and fast from discussions etc. It’s also less annoying for other people in the meeting as I’m not tapping away at my laptop or mobile device.

One of my team, Simon, showed us in this weeks “tool time” meeting how he used the very excellent “The Brain” to document his teams retrospective. Another really good use of mind maps. BTW – The Brain is awesome….but pricey for the full licence.

Tool I use for this : XMind / Pen and Paper / The Brain

Mind maps for documenting presentations at conferences

Those that followed EuroSTAR 2011 might have seen a number of mind maps from me documenting the presentations I attended. Presentations aren’t typically as fast as meetings hence I get more time to type (and annoy other people with my keyboard tapping).

I find mind maps to be a good way of documenting the ideas and thoughts from the presenter (especially as some presenters may order their presentations differently to how my mind accommodates the information). XMind also has a cool feature which means I can publish the mind map straight to the web from the XMind client.

Tool I use for this : XMind / Pen and Paper

Mind maps for learning and studying

When I read a book I make notes. Loads of notes. If it’s a physical book I make notes on scrap paper or (much to many people’s horror) inside the book itself, then scan/input these notes to Evernote.

Once in Evernote I add the notes to a topical mind map.

I have a number of mind maps for different areas of learning from “communication” to “Social Media” to “Bento Tips and Tricks”. I can use hyper links and notes to add further context. Mind maps allow me to pull together learning from a number of sources around a central topic, all in one place.

For Kindle/Digital books I can use the highlight option and then pull the text from the text-file to Evernote. I then follow the same process above.

The same goes for blogs, white papers and eBooks. Everything ultimately ends up in Evernote with tags. It then makes it’s way at a later date to the mind map, at which point relationships are created and meta data added.

There is a cool feature in XMind (and probably in other tools also) that allows you to add a new sheet to a node which essentially gives another core node in the same mind map file. This technique makes it much easier to nest notes and ideas without making each mind-map sheet too big to read.

Tool I use for this : XMind

Mind maps for Checklists and To Do lists

I often stick a checklist in to a mind map format and print it out A3 size to remind me of things to do. I posted about the Phoenix Checklist mind map here.

I’ve had very little success with using mind maps for To-Do lists but I know others in the community are using them in that way.

Tool I use for this : XMind

Keeping Mind maps in Sync across devices

One question I get asked often is how to keep mind maps backed up and in-sync across devices.

My approach (and note, there are many others) is to use Dropbox to store the files. This way they sync across many devices. XMind is available on most platforms also so this isn’t a problem.

On iPad I use iThoughts which supports Xmind – although to be honest I typically use Evernote to store the information, or pen and paper then add to a mind map later.

There are a number of cool apps for Android and iPhone also. A quick search will find many. I’ve not personally used mind mapping on my mobile so cannot comment on their effectiveness.

There are a number of file sync services though to help keep your files available and up-to-date across devices. Services such as iCloud, SpiderOak, Wuala, UbuntuOne, Google Drive, SugarSync and Windows Live Mesh.

There are loads more but these are the only I have personally used. Try AlternativeTo for more.

Problems with mind maps

Mind maps are not a Silver bullet. I once spent a long time explaining an idea for a book to a someone using a mind map. They just didn’t understand the structure and the way I’d represented the format, characters, plot and sub plots.

I then exported the mind map to a .txt file and walked through the pure text and they got it right away. Not everyone leans towards visual thinking. Some people don’t find mind maps useful. Some people prefer other mechanisms and ways of organising information and data. Some people don’t find mind maps easy to read.

One of the major criticisms of mind maps (and I would agree) is that they are often poor at communicating messages (to some people). Sometimes the mind map has been crafted in a logical fashion by the author and to the author it makes sense. If that meaning (and context) is missing from the readers mind then that mind map might not make sense at all.

Mind mapping tools https://www.thebrain.com/ http://xmind.net/ http://www.mindjet.com/ http://www.mindomo.com/ http://www.mindmeister.com/ http://ithoughts.co.uk/Start/Welcome.html http://freemind.sourceforge.net/wiki/index.php/Main_Page http://en.wikipedia.org/wiki/List_of_concept_mapping_and_mind_mapping_software Example Mind maps – Software Test Related http://gogeometry.com/software/software_testing_mind_map.html http://www.stickyminds.com/BetterSoftware/magazine.asp?fn=cifea&id=90 http://www.quicktestingtips.com/tips/category/mind-mapping/ http://chrismcmahonsblog.blogspot.co.uk/2006/11/mind-maps-for-testing-and-other-things.html http://www.kohl.ca/2006/modeling-test-heuristics/ http://www.eurostarconferences.com/blog/2011/6/20/mind-mapping-101 Extra Reading http://www.supermemo.com/ http://www.positivityblog.com/index.php/2008/08/18/how-to-accelerate-your-learning-using-advanced-mind-mapping-techniques/ http://www.teachingvillage.org/2010/02/10/mind-mapping-learning-and-teaching-with-both-sides-of-the-brain-by-hobie-swan/ http://judycullins.hubpages.com/hub/organize-outline-book-chapters http://blog.jackvinson.com/archives/2007/10/04/which_to_use_mind_mapping_or_concept_mapping.html http://mindmapsunleashed.com/are-you-still-making-mindmaps-don%E2%80%99t http://www.michaelonmindmapping.com/blog/mind-maps/mind-mapping-doesnt-work-for-me-part-1/ http://www.informationtamers.com/WikIT/index.php http://www.geekpreneur.com/mind-mapping-shows-but-doesnt-inspire http://www.forbes.com/2009/06/09/mind-mapping-wikis-technology-cio-network-mind-mapping.html http://blogs.oreilly.com/headfirst/2007/12/mindmapping-does-it-work-for-y.html http://www.joelannesley.com/creativity/mind-mapping-your-creativity-why-i-dont-make-lists-anymore http://www.studygs.net/mapping/ http://ocw.mit.edu/courses/engineering-systems-division/esd-34-system-architecture-january-iap-2007/lecture-notes/mind_mapping.pdf http://www.geekpreneur.com/using-mind-maps-to-learn-a-niche http://www.mindmappingstrategies.com/learning-mind-mapping.aspx http://angelashelton.com/writing-your-book-or-screenplay http://braindance.com/bdimmap4.htm

It will never work here

I think one of the most fundamental mistakes many people make when talking about testing is to assume that everyone works in the same environment, thinks the same, is testing the same and is at the same stage in their experience and learning.

I remember one evening during EuroSTAR 2011 quite a few people gathered after the day to discuss the Future of Testing. The problem was, there was no point talking about the future of testing as I suspect all present had a different view of what current testing actually is. The current ideas to one person might be the future ideas to someone else.

I have an arch nemesis who occasionally turns up to events and conferences and generally argues with everything I may ever say. My Arch Nemesis works in the same industry/domain as me, yet Cloud and Agile will *never* be accepted in their company. Never.

Yet cloud and agile are at the heart of what I do everyday.

People work in different environments and each environment will have it’s limitations, differences, pros, cons and nuances.

It will never work here” is a phrase I hear all too often from Testers and mostly it is *possibly* true. And that’s cool. There’s a way of working for everyone and as great Testers we seek out these ways. We aim to maximize our strengths, whilst minimizing our weaknesses. This is what we do. Right?

Whether it is cloud, agile, continuous release, testing in live, acceptance test driven development, exploratory testing or any other activity/process you may do there will always be someone who loves the idea, but utters those words; “It will never work here”.

Instead of complaining about people who say this I’ve started challenging them as to why they think “It will never work here”. I ask them:

  • How did they come to that conclusion?
  • Who did they ask?
  • Was that the right person to ask?
  • Did they explore alternatives?
  • What makes them think that?
  • What do they honestly think?

If it is true, that it would absolutely never work for them, then that’s cool. It probably wont work. Time to explore some other avenue.

If you think “it will never work here” when you hear someone talking about an approach but aren’t sure why it wouldn’t work, then I would encourage you to dig deeper and ask further questions. Are you really sure it won’t work?

And if you think it would work but come up with resistance to change then don’t fear. This happens to almost every person who ever tried a new idea. There are always barriers; technical, people, money, time, red tape, process etc.

What can you do to make realistic changes to your testing? Note: The following ideas are based on the assumptions that changes you make are contributing to the department/companies objectives and goals – you do know what they are…right?

Instigate small changes, one at a time, and observe and measure feedback.

Find people who think the same way as you and work with them to bring about change.

Prove it – Make a change and measure the return on investment (ROI). If you can prove a good ROI for a change then you have a much stronger case. A gut feeling is good, but hard cold facts are better.

For example, let’s say you run a series of tests daily, manually. You prove that with some investment in an automation framework you can eliminate parts of the manual testing, freeing up a tester to do something more interesting and valuable instead.

Document the time saving, the costs, the expected time needed etc and present this to your manager/team. You stand more chance of getting agreement for change than simply saying “I think this would work”.

“But I have no time to make these small changes” – How about outside of work? During your lunch? Early in the morning? Are you sure you’re actually working on important things during the day? Or just “busy”? (busy does not mean you are adding value).

You can focus on your strengths and minimize your weaknesses. Let’s say you have great technical expertise in writing Selenium tests but no experience of the whole grid and infrastructure system behind it. Why not outsource this to a dedicated selenium grid cloud system and focus on what you do best? Or look to someone else in the business to get you going quicker?

Accept that nothing big will change overnight and look for small ways to improve your current situation. By accepting that things are “the way they are” you will approach your work with a different view. Tiny improvements and changes may become more obvious. Routes to new ways of working may present themselves more openly. You will notice ways to make your job easier/more fun/more challenging.

Move on. If you work in an environment where no change is possible (and you need it to change) then move on (easier said than done). When you have reached a plateau, don’t just sit there. The tech world is moving fast, and it’s important to keep your skills sharp and relevant. Move on and seek out something more in tune with your thinking.

Don’t take each approach and model as a one-size fits all solution. If you took each new idea, tried it and and it didn’t work, then try changing the approach. If it’s not right for your way of working then do something about it. All of the training and information on testing can be useful, but your intuition and experimentation are more important. And if you mash another idea to create a new one and it works…please share it with the wider community. 🙂

Are you hiring a certificate or a tester?

I read a blog post recently extolling the benefits that come from having a certificate.

The post alluded to the following:

  • With a certification you are demonstrating your skills as a Tester.
  • With a certification, as a team, you are demonstrating your proficiency to the business, and potential customers.
  • With a certification you open new markets for both yourself and the business you work for.
  • With a certification you can work on international projects or work anywhere in the world because everyone (those who have been certified) has a common understanding of testing.

It got me thinking.

With a certification you are demonstrating your skills as a Tester. I don’t think you are demonstrating your skills as a Tester simply by sitting any of the certification courses alone. I think you are showing you are “willing” and capable of learning more about testing.

I think for some people it shows a deep passion to learn all there is about testing (combined with many other sources).

Yet for many I think you are following the “norm” (which is not always a good or bad thing).

I think you are complying with stereotypes and expectations (but without knowledge of alternatives or awareness of other channels of testing knowledge, this too, is to be expected).

As a hiring manager I don’t see the certification as a “demonstration” of skills. Not at all. Especially when almost everyone has the foundation one.

I do see them as an element or components in a larger strategy of learning but on their own, they are not a demonstration of your skills.

Put another way, I don’t think not having a certification is a negative point, at least for the outlook on Testing I have. (for some companies it is mandatory though)

With a certification, as a team, you are demonstrating your proficiency to the business, and potential customers.

I don’t think you are demonstrating your proficiency as a team to the business and potential customer, however, I realise many people outside of testing may not know or appreciate this. (which is why this idea is flourishing) (isn’t it negligence for us to let this idea of certification=absolute excellence go unchallenged in the business community?)

I worked with a tester once who was fully certified at every level but he had no passion, no engagement in what he was doing and alienated all who worked with him. He dragged the team down and hated every aspect of his job. Was he a great tester? Was he a good advert for excellence?

A Test Manager a few weeks back was speaking at an event. He said he was the manager of 65 testers and was proud at how big his team of certified testers were. As you can imagine I, and a number of others, had a few choice questions for him:

Q : How much automation do you have? A : Umm. None. But I manage 65 testers.

Q : How many releases do you do a year? A : We don’t. We do one every 15 months. But I manage 65 testers.

Q : How do you coach 65 testers? A : I don’t. But I manage 65 testers.

Q : How do you do 1:1 and personal development with that many direct reports? A : I don’t. But I manage 65 testers.

Q : Have you analyzed areas of waste in your testing process? A : No. But I manage 65 testers.

Q : Have you…….(interrupted) A : I manage 65 testers. End of.

I may have exaggerated the answers but suffice to say there was no automation, no regular releases, no performance or load testing being done, no personal development, no lean thinking and waste reduction and a general lack of process improvement.

But….all 65 testers were certified and this was a great selling point. I know of teams with one or two great testers shipping software each week and working for companies that are dominating the markets they operate in. And they are a mixed bag of certified and un-certified (or should that be non-certified).

With a certification you open new markets for both yourself and the business you work for.

I think you can open new markets for yourself with or without a certification. It *might* make it easier with a certificate to be part of a company that places more emphasis on certification than personality, thinking and actual skills, but I think good testers open up new markets all of the time, with or without certifications.

With a certification you can work on international projects or work anywhere in the world because everyone will have a common understanding of testing.

I don’t believe a certification will give people the international standards and common understanding that the certification marketers would have you believe. Just get yourself to any testing conference and listen to the conversations to see that most people don’t agree on much in the Testing world.

People will approach testing (and the terminology and language used to communicate these approaches) in a way that is local to themselves and the context they find themselves in. To get a deeper understanding of how people think differently about testing ask questions to a group of testers from different industries, backgrounds and contexts at the next event you are at.

Questions like:

  • What is testing?
  • What is Quality?
  • Who should make the decisions to ship software?
  • What is integration testing?
  • What tests should you automate?
  • What is exploratory testing?
  • What is agile?
  • What artifacts should a tester produce during a project?
  • Who is in charge of your testing?
  • Should you always produce a Test Plan?
  • When are you ready to test?

I guarantee you will hear different answers from different people.

There is a world of difference between demonstration and assertion, yet certifications have somehow become an assertion of excellence to many. (and scarily a measure of a companies excellence in the wider business world)

This isn’t to say that the actual course, tutoring and learning is bad. Far from it. It could be excellent, valuable and perfect for you, but like most learning courses, some people learn deep insights and others learn just enough to pass the exam. (in fact, some may even be taught to pass the test, rather than deep insights but maybe I’m being too cynical)

As a Test Manager I like to look at it another, more simplistic way:

The certification is


the tester, and the tester is


the certification.

Are you hiring a certificate?

Or a Tester?

What makes you less interchangeable?

I was told a really interesting story the other day about a company who remove all obvious identification from CVs during recruitment.

It works a little like this:

  • They get the CVs for an open job position.
  • Someone who is not doing the active hiring removes the candidates name, any company names (of past and present companies) and other personal information from the CV leaving just a set of skills, extra curricular activities (although social space names/handles were hidden) and supporting information.
  • The anonymous CV is then forwarded to the hiring team.
  • The team then review the CV with less bias and prejudice (or at least that is the aim of this process).

To make sure they were discussing the right candidates they would tag each CV with a unique reference number which was tied back to the actual candidate. It worked perfectly for them and they found that each candidate was reviewed on their merits and skills alone, not by any bias or prejudice in the mind of the hirer based on their name, age, sex or other personal information.

This company reported a much higher success rate for hiring. More “A” players were hired and less “bad hires” were brought in. It sounds like an interesting process.

But it got me thinking about the sea of conformity that is happening in the Testing community.

Let’s say 100 testers applied for a testing job and the above system was in place.

  • Would each CV be distinct enough?
  • Would the hiring manager be “floored” by any single application? Or down hearted by the sameness of each candidate?
  • What would be on your CV to make you stand out in the process?
  • Why would your CV be chosen?
  • How would you “win” during the CV review stage, rather than waiting until the interview? (believe me, I know many Testers who submit below standard CVs and aim to do the “wow” during the interview..but what if you don’t get to the interview?)
  • Would all applications (and therefore Testers) be interchangeable?

If the system had a bug and you got somebody else’s CV, would it be vastly different to yours? If yes, how? If not, is that not worrying?

In a sea of conformity the only way to escape is to be different.

  • What are your strengths?
  • What differentiates you from the rest?
  • What makes your application stand out?
  • What makes you less interchangeable?

Update : As Stephan pointed out in the comments…would you want to work for a company that hires this way? 🙂

Testing Sucks. I hate Testing.

You may know the situation; you are at a conference (or meetup) and you get talking to someone who says they “hate testing”. What do you do?

  1. Run away?
  2. Tell them to “man-up” and stop complaining?
  3. Join them in a whinge about Testing?

There are many other potential answers, but another one I’ve started doing recently is asking two simple questions. I’ll come to those two questions later.

Too many people say they hate Testing when in actual fact it can be the software itself, or the domain they are working in, or the methodology they are using. I strongly believe that you do your best testing when you “commit with passion” [1] to doing a good job. I also believe that to “commit with passion” (and therefore do your best work) you have to have some affinity to the product you are testing.

There are a number of factors that affect our motivation towards our jobs and the products we work on. These include, but are not limited to:

  • company culture and ethos
  • peers and co-workers
  • management structure
  • testing approach
  • restrictive systems and processes
  • technology stack
  • company benefits and rewards.
  • and many more

I believe that having an affinity with the product we are testing brings out the best in us. I believe that many testers who complain about testing are complaining about the factors above in varying combinations, but more often than not, they are complaining about the product they are testing.

Over the last few years I’ve made a conscious effort to talk to testers at events/conferences that plainly don’t want to be there. Many of them have indeed indicated that they hate testing.

When asked two simple questions though they fundamentally start to think differently about their “hatred” of testing. It’s not scientific, but it’s enough to give me hope that we can start to change some hearts and minds, one tester at a time.

The questions I ask anyone who says they hate their testing job are:

  1. What is your favourite piece of software?
  2. Would your view of testing change if you were testing this favourite software instead?

Most people smile and answer question two with a big fat yes. Yes it would.

It’s a very leading question and no doubt testing their favourite product conjures up images of a culture, approach and financial situation different to their current one, but a significant part of this vision or thought is most likely that they get to test a product that they enjoy, understand and can relate to in an environment that suits their personal style and preferences. (this vision may never meet reality…but it’s worth a try)

One person I spoke to a year ago was testing banking software and he hated it. I asked him the questions above and he said he liked “social media” software and would love to test it. A month or so ago I saw him again. He’s now working for a start-up blog aggregation company and he loves it.

That’s not to say that working on “social” software is better than banking software, but each of us is naturally more interesting in certain domains than others. Some would never dream of working in the aerospace industry, but others flourish in this industry. Some are drawn to start-ups pushing stuff out of the door and building on modern tech, others are drawn to corporate mega giants with miles of red tape and out-dated tech. Each to their own.

So next time you meet someone who says they hate testing it’s worth asking them whether it is “testing” they hate, or the product they are testing.

[1] – Commit with passion is a term used in the book The Jazz Process – http://www.jazzprocess.com/book/

Getting a grip on exploratory testing

Last week we had the pleasure of inviting James Lyndsay to our offices in rainy Basingstoke for a two day course on “getting a grip on Exploratory Testing”.

The whole test team were there for the two days and we worked through a number of elements of Exploratory Testing, right from time managements and focus to techniques and approaches. James is incredibly knowledgeable and his experience was tapped by the team for the two days.

Each of the team took away a number of insights, but here are my own personal observations:

  • I focus very heavily on the user and their experience of using software
  • I also tend to visualise the problem and walk through it often randomly
  • I also focus heavily on any claims made in any documents, guidance or specifications.
  • The team all approach the same problem in subtly different ways. This is a good thing.
  • Knowing how long we have to test is crucial. It changes our approaches and styles.
  • My approach of using Mind Maps for planning and documenting is a style that works well for me, but not always for others.
  • I tend to use a different map for different problems. I use mind maps, tables, doodles and general free form notes. I also tend to scrap a map if it’s not working.
  • Our judgements on what is an issue and where to focus testing differ between people even in the same business. What I see as issue – other might not and vice versa. This highlights the need to understand your target audience; something we’ve been working hard at here.
  • I need to work on my “straying” from charter. I often get too involved in side paths which are not on charter. This is not always a bad thing but I need to be mindful of it.
  • I often explore the application to drive out charters and ideas for further testing as a form of planning
  • We need to instigate more exploratory testing debriefs

The two day course was insightful, very well delivered and fun. There were lots of hands-on practicals and James tailored the content for our needs here at NewVoiceMedia. Overall it was a great two days and I know the team very much enjoyed it. We just need to put our learnings in to practice, something I am already seeing the guys doing.

Here’s James’ website with course details.

Anchoring and how to use it in agile testing


Imagine you are being asked to give an estimate for the completion of a piece of work. Imagine that this group includes Testers, Product Owners, Programmers and representatives from different departments. Imagine that you are going to have to haggle, negotiate and barter to get the time you think you need to do a good job.

Now imagine that I could give you a little trick that *could* help you get the number of days you actually want.

The above scenario is a common occurrence for many teams. We are often asked to give estimates for work.

Some teams use techniques like the Delphi method, rubbing the goat (don’t worry, it’s safe for work), like for like (same estimate as programmers) and a variety of other techniques. These are all valid and I’ve seen each one work; including the goat.

Now imagine this. As you are in the process of estimating you have the direct ability to dramatically influence what others agree on simply by shouting out a number (or holding up a number in Planning Poker (first round)). This number could be anything, but the more extreme the better (at least for this imaginary situation).

Simply by offering a number you have the ability to create an “anchor”.

I’ve been studying a lot about “anchoring” and how this relates to price and numbers. Anchoring is a bias (cognitive one) that occurs when people place too much emphasis on a piece of information. Michele Smith wrote a good blog post on anchoring and testing here.

So let’s look at this from a generic example point of view.

You are looking to sell something to someone. In this instance the price is not listed. You think this “something” is worth about £2000; that’s what you want to get for it.

So you throw in a crazy high price of £5000. The buyer laughs and nearly chokes. So you smile and say comforting words, then come back with a price of £3000.

According to much of the research in anchoring the above scenario would likely end in you selling this “something” for a higher price than if you had opened the pricing at £2500.

According to studies on pricing you have thrown in the anchor of £5000. It is now acting as a reference point in the buyers mind. Your offer to sell for £3000 now seems like a real bargain compared to the £5000. The same applies when buying. Go in low and then move up from there. This offer that no-one is ever likely to accept is curiously known as a “dead dog”.

When I read more around price anchoring I see this in everyday life.

You’ve surely seen the adverts: “Was £100 – now only £25” or “Reduced for a short time only from £100 to £25”. In these instances the £100 is an anchor. The fact that the product might only be worth £25 anyway is why anchoring is used in the first place.

Another technique is to offer your products (with slight variants in deals) for different prices. One incredibly high price which no-one would likely buy and a lower price which is really what you want to sell your services/product for. In this example the research suggests that you will sell more of your “lower price” service because people are using the high price as an anchor. High end designer shops go mad with this technique.

Every day you are exposed to anchors in pricing.

So what has this got to do with Testing?

A lot really.

Going back to the example earlier, let’s say you want to get an estimate of 10 days to be accepted. So you throw in an estimate of 25 days and give a list of reasons why this might be a good estimate.

Lots of smirking, muttering and breathing in air through teeth. You sense the discomfort.

So you now go for an estimate of 14 days and give some reasons why you could achieve this and why this might still work for you. According to the anchoring theory it seems likely that this estimate could very well be accepted. In comparison to 25 it’s a good deal.

In a sense this is the interesting side of Planning Poker. The first round is intended to be called at the same time, for the very reason that anchoring plays a large influencing effect in estimation. Yet the first round can often throw in curve balls. Three people give 5 points, one person gives 1 point and another person gives 10 points. The second round often has people gravitating from their original number to either the higher or lower; a lot of this gravitation depends on the negotiating skills of the outliers.

A counter to anchoring is something called an Adjustment Heuristic which is essentially a mechanism we use to adjust to the anchor to get closer to our estimates/outcomes.

Anchoring is complex, complicated and very intriguing. I haven’t done it justice here, but it’s an area that I believe warrants a lot more reading about (and experiments). Over the next few months I’ll hopefully share some of what I am learning with you and no doubt fine tune my own thoughts on how anchoring plays a part in Testing.

If you’re interested then here are some resources on anchoring: http://en.wikipedia.org/wiki/Anchoring

Priceless by William Poundstone Short but interesting links from Behavioural Finance Anchoring and Adjustment at Less Wrong


Photo by David Feltkamp on Flickr.


Testers Learning To Code

One of the topics that always pops up in conversation with Testers is whether or not we need to know how to code.

I think a lot of this depends on your context and your career goals and aims, but really it pays to at least understand how the code is hanging together and to get a sense of what it’s doing. It would undoubtedly be useful to code at a basic level to help build tools and programs to help you and also to crack Test Automation (i.e. not relying on Record and Playback as your strategy).

I often hear the excuse that there isn’t time to learn, but I don’t think this is true. I think we could all snaffle 10 minutes a day to work on some code. The time argument depends greatly on the importance you place on learning to code. There are lunch times and after work and weekends too.

One of the things we’ve got set up within our team is two 30 minute sessions each week where the whole test team sit together and work through coding katas with our tech tester and programmer. It works really well but still needs each Tester to spend a little extra time each week re-enforcing the learning.

I thought I would collate together some resources that might help and inspire you. Oh yeah, and deciding which language to learn is often the hardest decision. I can’t offer any guidance on that really, it’s what works best for your environment, your product, your goals and your interest in each language.

So here are a few resources I’m finding helpful:

So you want to learn programming basics?

There are loads of resources for learning basic programming (try a Google search for it) but the one that stands out from the crowd is Code Academy. It’s a great interactive tutorial teaching you the basics using JavaScript as it’s main language. The lessons are short and the guidance is awesome.

So you want to learn Python?

Python is a really powerful scripting language and you would be surprised at how many of your favourite sites are running on it on the web.

There are a number of great resources available on Python but one of my favourites is this very straight forward guide called “The Programming Historian“. The lessons are kept simple and you’ll be writing Python to manipulate files and text in no time.

If you’re in a .Net environment then IronPython might be the way to go.

So you want to learn C#?

There is a pretty good course here at Programmer’s Heaven on C# basics.

CSharp-station also has some good tutorials.


So you want to learn Java?

By far the most relevant and intuitive book on Java for Testing is Alan Richardson’sSelenium Simplified“. The guide is very straight forward and in no time you’ll have some tests running on your web site. It’s obviously aimed at getting you started with Selenium but Alan introduces you to Java as part of the journey.

Update – Alan has also now released

Java For Testers

. Head over to the site and check it out.

Here is an introduction to Object Orientated Programming in Java.

Learn Java Programming with Green Foot. This is a really great program for learning about Java and Object Orientated Programming. You get to build a world where Wombats eat leaves. Great fun.

So you want to learn Ruby?

I would recommend to you dive straight in to Brian Marick’s excellent book “everyday scripting with Ruby“. It’s partly aimed at Tester’s so it’s a great read.

Ruby for Kids is very cool also. Don’t be put off by the title. The lessons are great and the basics can be learned very quickly indeed.


Why’s Poignant’s Guide to Ruby is a cult classic in the Ruby domain. It’s a crazy story that introduces Ruby and general programming ideas. I actually enjoyed reading this. It’s a PDF –> http://www.rubyinside.com/media/poignant-guide.pdf

Ruby in Twenty Minutes offers snippets of learning. A good resource for getting started and getting it all installed etc.

If you’re in a .net environment but still want to use Ruby then check out IronRuby.

Each of these languages is typically coded in an IDE (Integrated Development Environment) although you could also use something low tech like Notepad. A good list of IDEs is here on Wikipedia.

There are also other languages I’ve not covered here like PERL, PHP, C++ and many others.

Any other sources I might have missed? Let me know in the comments.