Communication and Testing

In yesterday’s test team meeting we did an interactive sessions around communication. Stickies, pens and a whiteboard were all we needed to have a fun session talking around communication.

We started by brainstorming what communication is. Then what factors affect communication. We talked about feedback.

And of course we talked about PAC – Purpose, Audience and Context.

(Those who’ve known me for many years might remember that PAC Testing was my very first testing blog all those years ago in 2009. It’s still running and getting traffic! The links are all wrong on it and the images are no longer there but the site is still up!

We also talked around some specific examples of communication failure. It was a fun session thrown in at the last minute. It’s always good to throw in some soft skills sessions.

By the way – I’m recruiting for testers!

If you’re interested in coming to work at NewVoiceMedia then drop me an email, or even better – connect with me on Twitter (@rob_lambert) and DM me.

Managing exploratory testing

One of the perennial challenges I have faced with exploratory testing is how best to manage it and then report on it.

I’ve hacked around with many different systems for years and never quite felt happy with any of them.

As most of the testing that the team do here at NewVoiceMedia is exploratory testing I’ve needed to find ways to understand how much testing we are doing and which bits of the product we are spending our time testing. The numbers alone wont say we’ve got stuff covered but when combined with metrics from across the entire Dev process I can start to piece together where our testing is focused and where we might need to make changes.

An Idea

The other month though I stumbled across an idea in my mind which felt right. I spiked it out and gathered some initial feedback from some of the team. I concluded it was worth a go and so far, when used in anger, it seems to be good. I thought I’d give it a few weeks before I blogged about it – so here it is – a hacked together system to manage the reporting of our exploratory testing.

The Beginning

During a story chat we look to put as much of the checking under automated test as possible. However, during the chat the Testers will be doodling, mind-mapping or jotting down ideas about what to test; ideas that often warrant a little further exploration. These become Exploratory Test charters.

We write our charters in the Explore [something] WITH [something] TO DISCOVER [something] format as described perfectly in Elisabeth Hendrickson’s awesome Explore IT book.

These charters are just wishes at the moment – they haven’t been run – and truth be told not all of them will get run. We’ll also add further charters, or delete existing ones, as we progress through the life of a story.

Running an Exploratory session

2013-08-23 15.42.56

Each tester will run a session in a different way, to suit their own preferences and style. They will also store their notes in different ways. Most of the team are using Rapid Reporter, I personally use Evernote and a couple of peeps are using Word and Notepad++. No matter what program they use they are creating detailed notes of the session they are running. These notes are personal to them, but public for others in the business to view. They may not make sense to others, but as long as they make sense to those who created them, then that’s cool.

The notes from the session, in whatever format they are in, will eventually make their way in to our social wiki system Confluence. In Confluence we have a space dedicated to Exploratory Testing. In this space we have a simple hierarchy of Year > Month > Test Charter.

The charters are named [TesterInitials]_[DDMMYYYY]_[SessionNumber]. For example: RL_16062013_1 and RL_16062013_2.

When creating this charter page we use a template so that all charter pages in Confluence are consistent and easy to navigate around. On this page in Confluence is a table which simply requires the charter name, testers name and date.

The rest of the page is then free for us to copy and paste our session notes, or attach files such as CSV or txt files to the page. This Confluence page essentially becomes the final record of the exploratory session. It becomes a reference point to link Pivotal Tracker stories to and it also becomes an audit point (version and permission controlled). We might never look back at it – but we keep it just in case we should ever need to.

Part one done – we’ve got the session recorded in a consistent manner. Now we need to get some metrics recorded.

Reporting the session

I created a very simple Google Form for recording results.

Once the team have completed the Confluence page they can open the form and fill it in.

The form asks for basic information such as tester name, main area of test, charter title, confluence link (back to the session notes), how many hours of testing was done (to nearest hour), any story links, browsers, operating system and environment. All of the fields are mandatory.

Once submitted the details are stored in a Google spreadsheet. Bam – basic test reporting.

I can now see how many sessions we have run against which main functional areas of the product. I can see the links to Confluence. I can see which browsers we are exploring against and I can see how many sessions we are running across different time scales. I have created a series of graphs showing sessions per tester, session per browser, sessions per functional area and average sessions per day

The next step is to pull this data down in to our bigger management dashboard and make it visible. This can then be tied to cycle time, velocity, scripted test case reporting (from a different system) and the automated tests that are running.

With all of this data we should be able to see trends and patterns which will inform our next moves. Are we covering enough of the product? Are we moving too fast? Too slow? Are we covering the right browsers? How can we improve the testing? Is the data itself providing value in decision making?

The numbers alone don’t mean anything – but as a whole they may give us enough information to ensure we keep delivering the right thing for our customers.


It’s not a perfect system but we’re using it and it was super simple to get rolling. We’ve struggled with other systems and other hacks to organise our ET and although this one means we’re hopping around a couple of different systems it is indeed suiting our work. We are in these system anyway so it’s not a major overhead.

This system will be changed up and hacked around further for sure – but right now we’re testing it and seeing what value it’s giving us.

What system are you using and is it working for you?

certification of awesomeness

Could not having a certificate make you stand out?

Many years ago when I sat the foundation certificate it made very little difference (if anything at all) to my day to day work. I remarked to a colleague though that the certification would make us all “more employable”. I was right.

certification of awesomeness
Certification of Awesomeness

Back then not many people had the certification so when you saw it listed on a CV (complete with required logo) it made that CV and candidate stand out. Had they taken their learning more seriously? Were they prepared to see what this certification lark was all about? What was this certification thing?

Soon though, everyone had a certification and you no longer stood out from the crowd.

Thankfully though – along came more higher rated (and presumably higher valued) certifications. Great. You could stand out again. Until of course – most people started to get these too.

Now you need something more to stand out. I wrote a whole book to help you work out what I think you need to do. But one thing came to mind* the other day that I realised I missed from the book.

What if your CV was the only one that DIDN’T have a certification?

That would make you stand out.

And any good hiring manager might start to ask “I wonder why they felt the need not to get certified, or list it on their CV?”. And that is an excellent starting point for a good conversation about you, software testing, certifications and your learning.

Note: Although this blog post is a flippant approach to the challenges hiring managers have of finding good candidates – it could actually be a useful approach to standing out.

* I recall some Twitter banter around certifications and why you don’t need them but can’t recall (or find) who actually made a statement along the same lines as I have. If you know who it was please let me know.

– I’ve since been informed that it was Michael Bolton via Twitter who said to leave the cert off the CV – sage advice indeed.

Remaining Relevant Front Cover

How to remain relevant and employable

Like many people, you may be struggling to find a job, get an interview and then ultimately land the job. It’s hard work trying to find work and even harder work trying to stand out (for the right reasons) from the masses.
I wrote this book to help anyone who is wanting to find good jobs, excel in an interview and improve their chances of getting a job by developing the right skills.
Remaining relevant is a collection of information and advice that I’ve accumulated over many years of enjoying going to job interviews (weird I know) and then lately in interviewing many hundreds of people. More recently I’ve been coaching people on a 1:1 basis with remarkable results.
The advice in this book is focused around helping you upskill, understand the job market, become an expert at applying for jobs and learn the right skills to excel in an interview. In a nutshell I hope this book will help you to remain relevant and employable.
NOTE – This is a new book and is NOT the testers edition. I have since retired that version for the first half of this year and this book will replace it. If you bought the testers edition I thank you immensely and I do not suggest you buy this version – it’s 99% the same book but with some minor sentence changes and a couple of new paragraphs. Of course, you’re welcome to buy it if you like 🙂

Where can I buy the book?

The book is published on Amazon – You can buy a copy here on Amazon UK (aff link)
The book is also on Amazon across the globe. Search for Remaining Relevant and it will pop up 🙂

Why did you write the book?

The book started at a quick 10 chapter book about getting good jobs and writing good CVs.

I aimed to have it released in January 2013. I released it in September 2013 initially on LeanPub and then again in February 2015 on Amazon.

I wrote the book during my lunch breaks at work. I’d shuffle off to the the 7th floor to an empty desk space and spend an hour writing. I’d often be surrounded by other escaped artists trying to grab some quiet time to get projects finished.

I wrote the book to help people understand how they must remain relevant, to provide advice on how to find good jobs and how to rock the application process.

Blurb from the book?

Blurb from the book
The following is from the book introduction:
“I can’t find any good jobs,” someone said to me at a conference recently.
“I can’t find good people,” a hiring manager said to me at the very same conference.
So what’s the problem?
Is it because the hiring manager and candidate don’t know each other exist?
Is it because the expectations of the hiring managers are too high, weird, or abstract?
Is it because the candidates simply aren’t good enough?
In many cases the answer is yes, but it’s not always the case.
Or is it because many candidates don’t know how to get themselves in front of hiring managers, show the best side of themselves and then get hired?
In my experience, this is the most common answer.
The world of employment is changing, and changing fast.
Getting a job (and keeping a job) in this fast changing world requires hard work and a commitment to remaining relevant to the needs of the company you work for and the changing demands of your industry.
Sometimes this commitment is a commitment too far for some people.
For others it’s a commitment they didn’t know they needed to make.
The job market is swamped with average people creating a sea of conformity and standardization.
In this sea how will you stand out? How will you get your next great job? How will you differentiate yourself from the next candidate? How will you add value to a business? Why should someone pick you?
The Internet, improved communication channels, cheap global travel and the ability for people to relocate easily (or work from home) has meant that you’re no longer competing against people in your local area; you’re sometimes competing against people from all over the world.
It’s not all bad though.
I believe that there are people standing out from the crowd and filling the void that many hiring managers talk about.
Some already have the skills and ability but lack the tools to communicate effectively, promote themselves and interview well. Others need to learn lots and commit to self-improvement.
That’s why I wrote this book.
I wrote this book for those people who want to forge a good career but feel stuck in a dead end job.
I wrote this book for those people who don’t want the next standardized job where they are simply treated as a resource. They want more.
I wrote this book for those people who want to up-skill but lack the insights, structure and drive to do so.
I wrote this book for those great people out there who aren’t projecting themselves well and creating compelling reasons to get hired.
I wrote this book with the hope that many hiring managers may also read it – after all they are often the ones creating the demand for standardised people.
But mostly I wrote this book to help people, whether employed or not, remain relevant in a changing world by giving them the tools, approach and skills to wow hiring managers.
I sincerely hope this book will help to provide some enthusiasm, inspiration and ideas to help you remain relevant and employed in a fast changing world.

What’s actually in the book?


The following are the some of the main chapters from the book with a little text explaining what to expect in each chapter.
  • How to get started – Why are you job hunting?
  • Is there really a career in my industry? – Many people believe that jobs in their industry are simply stop-gap jobs, something to do until something better comes along. The reality is there are some great careers to be had in almost any industry.
  • What Skills Do I Need? – Do you really need to upskill to get good jobs…….yes, yes you do.
  • Learning – How to learn and why learning should be core to your self improvement strategy.
  • Organising Your Learning – ideas for organising learning.
  • Communicating Your Passions and Values – How to communicate to other people what value you offer.
  • Creating Your CV – Lots of hints and tips on how to create a good CV.
  • Creating An Online Presence – How to create a validated online social presence.
  • Networking And Connecting – Why networking in person is so important to getting a good job.
  • Finding Good Jobs – How to find good jobs.
  • Understanding Job Adverts – How to make sense of boring, dull and misleading job adverts.
  • Applying For Jobs – How to do an awesome job application.
  • Speculative Applications – ideas on how to apply speculatively to companies meeting your criteria.
  • Phone Interviews – Ideas on how to rock a phone interview.
  • Interviewing – Ideas on how to rock a face-to-face interview.
  • Accepting A Job – How to accept a job like a pro.
  • Dealing With Rejection – Hey, it’s going to happen, but how you deal with it matters more
  • Patience Is A Virtue – Slow down. Give it time. Patience is indeed a virtue when job hunting.
  • Never Give Up – Don’t stop. Ever. Not until you get the job.



You can buy a copy here (aff link)

Word. Search.

Whenever you encounter a new word you’ve never heard before, or a word that you don’t know what it represents then go back to your desk and research it.

Do a word search. Find out what it means.

Word Search Image
Word Search Image
Image from Sergis Blog “Sopa de letras” October 29, 2007 via Flickr, Creative Commons Attribution.

A key aspect of being a good tester is being able to understand, decipher and communicate in the language of your business. The jargon that your business uses is an important aspect of the way your team members communicate. Embrace the jargon and learn to use it – it often makes communicating within your own social or business group more effective.

As a tester you need to know what other people are talking about.

You need to know the technology they are talking about.

You need to know the approach they are taking and the way they are articulating what they are doing.

The most valuable way to understand the business you work in and the product you are testing is to do your research about the words and phrases being used.

Don’t come away from any meeting not knowing what a word means without it being an action for you to research it. Don’t encounter a word or phrase that you don’t know more than once. Research it and understand it.

You might not need to know the ins and outs of the words meaning or what that word represents but you should at least be aware of it.

For example. In a typical meeting here we might mention some or all of the following:

  • API
  • UI
  • Stack
  • SIP
  • SIPp
  • WireShark
  • Trace
  • Cold Transfer
  • Call Leg
  • Proxy
  • WAF
  • App Firewall
  • Burp
  • VoiceXML
  • NewRelic

This is a tiny tiny subset of the words we use. Some represent technologies. Some represent aspects of a system under test.

As a tester we need to know what each one means. We need to know how each one works.

So how do I find this out?

Search the web. Find resources and read about each word or phrase.

Ask. Ask your peers. Ask your colleagues.

Decipher. Work out what it means by deciphering the context in which it is being used. For example if you hear the words “run a wireshark trace” you should be able to decipher that Wireshark is some sort of tool or technique for tracing something. The more you listen, the more clues you’ll get; you’ll soon have a mental picture in your mind of what a wireshark trace is.

You can then join in and understand the conversation – and then confirm your assumptions with some research after (or even better – a question to clarify during the meeting).

I make a point of jotting down any word, phrase or description I hear in any conversation. I then search, ask or decipher.

What do you do?

Find out what the word means? Or ignore it and hope you’ll never need to know?

The rise of the technical tester, and other thoughts from the UKTMF

The UKTMF this week was very good. Lots of interesting discussions to be had.

Being at the event triggered some thoughts about testing that I have been meaning to air for some time now.

Mastered Functional Testing

There were strong arguments by a few influential people that we, as testers, have mastered functional testing.

I don’t agree. I think we’ve got lots to learn.

I don’t believe we can ever master something as everything is forever changing; software changes, contexts changes, we change.

There’s also no single source of right (despite what some certification boards may tell you), which means that we’ll never truly know whether we have ever mastered functional testing.

I think we have a long way to go as testers before we can say we’ve got close to mastering functional testing.

Testing is only done by testers

This is a common misconception we have when talking about testing; that testing is done just by testers.

We are quick to put the tester at the centre of the development lifecycle when in reality we are just part of a wider team. The team will typically do testing of many different types.

The discussion at UKTMF centred around technical testers and the assumption was that technical testing was done by technical testers. Not so for many companies. We need to separate out the role of tester and the act of testing. Developers test, customer test, product owners test, testers test. Not all testing needs to be done by testers. Therefore not all technical testing needs to be done by technical testers.

All products must have uber-quality

Many statements and discussions centred around the product quality and how it must always be amazing. This is not true.

As much as we would like to think all companies need testers (is this us putting testers at the heart of the process?) and need to create high quality products it’s simply not true.

There are many companies producing software with no “testers” (although they do testing) and there are many products on the market (doing well) that aren’t (or weren’t) great to use.

Products, like humans, go through life stages and quality isn’t always important at all life stages of a product. Sometimes market share or a proof of concept is more important than a quality product.

Early adopters of Twitter will know the “Fail Whale”. Years ago about 3 in 6 tweets I posted would result in a Fail Whale – yet Twitter itself is now thriving, and I’m still using it. I’m happy to live with poor quality (for a period of time) if the problem the product is solving is big enough.

We often lose sight of the context the product is used in when talking about testers and testing. We are not the centre of the Universe and we are not always required on all products.

Testers are not generic

Another point I observed was that many people spoke about testers as though they are resources. Just “things” that we can move around and assign to whatever we want and swap as we please.

It was refreshing to hear a few people telling stories about the best teams being made up of a mixed bag of people from many different backgrounds, but they (we) were in the minority. A good team, in my experience, has people with very different backgrounds and approaches. We are not carbon copies of each other.

Testing (Or more to the point, social science) is not technical

Many people seem to be quick to replace the word”technical” with “being able to write code”.

It’s almost as though “programmer” is a synonym of “technical”.

So specialists in exploratory testing, requirements analysis, negotiation, marketing, technical writing (there’s a clue in the title) and design are not technical…..really?

It actually lead to a great comment from Richard Neeve who suggested that actually a technical tester (and tester in general) could actually be described as a scientific tester. I like the thinking behind this and I need to ponder it further.

The whole “technical tester” discussion is interesting as it often takes hours just to agree on a general definition of exactly what a technical tester is – something Stefan Zivanovic facilitated very well.

And finally I thought it prudent to mention the views I aired at the UKTMF on why “technical tester” is becoming increasingly common and prevalent in our industry.

I believe that the clued up testers are the ones who realise the future is bleak for those who simply point and click. A computer is replacing this type of testing.

The switched on testers are learning how to code, specialising in areas like accessibility, training and coaching, UX, performance, security, big data and privacy or they are expanding their remit in to scrum master, support, management, operations and customer facing roles. They are evolving themselves to remain relevant to the market place and to make best use of their skills and abilities. Some of these people are differentiating themselves by labelling themselves as technical. I believe this is why we are seeing a rise of the technical tester. And just as a side note, not all of those who call themselves a Technical Tester are all that technical (in either coding, or other technical skills). As with all job labels there are those who warrant it, and those who are over inflating themselves.

I think it’s important that testers diversify and improve their technical skills (and I don’t mean just coding skills) to remain relevant. After all, if you’re interviewing for a tester and they have excellent testing skills then you’ll likely hire them (assuming all other requirements and cultural fit is right). But what if a similar candidate came along who was also excellent at “testing” but was also skilled and talented in UX, ethnographic research, performance testing or security testing……which one would you want to hire now?

Remaining relevant in the marketplace isn’t about getting another certificate, it’s about evolving your own skills so you can add even more value than simply pointing and clicking. You need to become a technical tester (as defined above) – in fact, scrap that – you just need to become a good tester – because after all, good testers are indeed technical.

Ice Cream Sauce and Cigarettes

I’ve recently been doing my food shopping online. No more wandering around the store and queuing. This week though I swapped online supermarkets in a bid to save some money and all I did was waste a load more time.

 4063031766_451be82993_bImage from kardboard604 “Groceries” October 31st, 2009 via Flickr, Creative Commons Attribution.


In my opinion search is at the heart of everything in the world of online shopping. I search for stuff to buy. I search some more. I search again. I find things to add to my basket via search.

Sure, i could use the menus and structure the company have added to the site but I don’t usually. Or I try not to. I search.

So it was a great surprise to find that my newly chosen supermarket’s search failed my expectations.

Ice Cream Sauce and Cigarettes

The first search I did was for “ice cream sauce”. It’s been crazy hot here recently and my kids are getting bored with plain old vanilla ice cream.

The results of the search surprised me.

There was no ice cream sauce in the top ten results but the returned list did include green tea, yoghurts, dark chocolate and cigarettes.

Search Results

Yep, you read that right. A search for “ice cream sauce” returned two different brands of cigarettes but no ice cream sauce.

Ironically ice cream sauce was listed at the bottom of the page where suggested products (based on what other people bought after searching for “ice cream sauce”) are shown. Are they taunting me?


As you can see it lists a number of ice cream sauce products all of which contained (in either the title or description) the words “ice cream sauce”. Yet they were not returned in the main search…….cigarettes were.

I then did a search based on the exact title of the “Toffee Ice Cream sauce” that other people bought (I also included the brand name in a second search) and still I didn’t get the product returned in the results. Eh?

So what is the search algorithm using to find products?

It doesn’t seem to be using the title or the description otherwise it would have returned the sauce…right?

Is it using keywords? Or tags? And has someone got it wrong and labeled cigarettes as “ice” or “cream” or “sauce” in the database?

I then searched for “blueberries”. It didn’t return a direct hit.

I then searched for “eggs”. The first pack of eggs was about 6 rows down in the results grid. Not exactly what I would call a direct hit.

I then searched for “children’s toothbrush” and didn’t find one.

I started using the menus to find the toothbrush.

Children’s toothbrushes didn’t exist under Dental > Toothbrushes, or Dental > Children. Neither did they exist under Baby and Child section either. So they basically don’t appear to sell them, yet they do sell them in-store.

Should they have tested more?

To say that they should have tested more, or done more of X testing is a statement too far. I don’t know that they didn’t do the testing, find the bugs and then a product owner say “ship it” anyway.

What I do know though is that the search was not throwing an error. It handled all of the stuff I threw at it, but it didn’t return what I wanted.

Would this have passed a functional test? Maybe..probably. Depends on who ran it, what values they used and what their level of engagement was.

As a user I wasn’t frustrated because of crashes or exceptions or errors; things we typically talk about finding as testers. I was frustrated because I couldn’t do my shopping. The result of this was that I went elsewhere to do my shopping. I went to my usual supermarket where I found 100% of the items I searched for straight away.

If the site is well designed in the background and people are keen on improving the process then I suspect they are tracking the success rate of searches and tweaking the algorithms over time. I hope they are doing this.

What is your product’s main purpose?

Your product doesn’t have to just work it has to serve it’s main purpose.

It’s much easier now to switch suppliers or providers or services, so as testers we need to make sure that when we test we’re testing that the product is fit for purpose, not just that it accepts £%£@$@££!@@£@@FFDSIFJE21398389198237 as an input to a field.

I see testers digging around in the detail, trying to find the exceptions, the errors and the data misconfiguration and missing the big picture. It’s good to find the gnarly bugs things, but pointless if the basics don’t work.

How useful is a functionally spot-on working product that is used by no-one?

This week when I did my online food shopping I didn’t find any exceptions, or stack overflows, or errors using the search, but I also didn’t find my groceries. Which result is more important?

T-shaped Tester, Square Shaped Team

This is a guest post by Adam Knight who’s blog (A Sisyphean Task) is a must read testing blog.

I was pleased when Rob asked me to write this guest post on the subject of T-shaped testers. It is a subject which I have a strong affiliation with, and which is integral to my approach to management. I’d discussed the subject with Rob previously, having encountered the term ‘T-shaped’ from reading Jurgen Appello’s post on the subject.

Whilst the concept is an interesting one on an individual level, and Rob covers this really well in his previous post, what I really like about the idea of the T-shaped Tester is its implication for teams.

Not all T’s are the same

Whilst providing a simple name and model for people with broad knowledge and deep key skills, one or two important concepts are not well represented by the T model.

– the first is that, individuals can have more than one deep skill. The T shape tends to imply broad knowledge with one deep core skill. What I have found is that the best individuals possess multiple deep skills, combined with the broad skill base to ‘glue’ these together. Less a T and more like a city skyline.

– the other is that , not all T’s are the same. Each T-shaped individual can have different core skills that have arisen through their experience, interests and self learning that make them unique shapes. It is the variety of skills and shapes that, for me, presents the most important aspect of hiring generalising specialists, the ability to put the individual ‘shapes’ together and create amazing teams.

Piecing together a Team

One of my earliest blog posts was on the subject of how I felt that a Testing team worked best when comprised not multiple individuals all possessing equivalent skills, but when each individual in the team possessed specific both a general set of skills, then specific specialist abilities that benefited the team.

I presented the idea that, in the context of testing the software, the presence of a range of skills and experience in a team allows the testing operation to critique the product from a range of subjective viewpoints. If we populate a team solely with testers produced via the same training process then the testing will be limited from the perspective of insight and empathy for the stakeholder.

Beyond Testing

The benefit of having a range of deep skills in a team extend well beyond the ability to test the product more effectively.

– self sufficiency

Having a wider variety of skills contained within a team can help to make a team more self sufficient. This can be a distinct advantage in removing the friction caused by external dependencies . Testing teams can suffer being at the bottom of the priority list when it comes to internal IT infrastructure. Having one or more team members who are proficient in setting up operating systems and virtual/cloud test environments reduces this friction and allows the team to be more autonomous and less subject to organisational inefficiencies elsewhere.

– multi-tasking

In the world of small companies and startups particularly it can be a huge benefit if individuals and teams can take on additional responsibilities. In our earliest customer engagements my organisation really benefitted from myself and some of the other team members making use of good communication skills to take on the role of customer support. Other members used their diligence and management skills to maintain and manage the automation processes during periods of support activity. This allowed us to successfully progress through these early engagements and support the customers until such time as the company could expand and bring devoted support staff on board.

– co-operation not competition

One of the problems that I have seen in teams populated with multiple individuals all with the same skill set is that , all of the individuals in the team share common goals, and often the act of achieving these goals by one individual will implicitly exclude others from doing the same. When a team is made up of individuals with mixed skills and interests I feel that it is easier to build up unique personal development goals for each member which are less likely to conflict with the interests of others.

– this is how we want to work

I have never seen a film involving a team where every member of the team had the same skills. Take any famous ‘team’ movie and you’ll most likely have a story where individuals have key skills which contribute to the eventual success of the team. If art holds a mirror to life then our cultural subconscious gives us a pretty strong message that the best teams to work in are those where individuals have unique skills which are valuable to the goal of the team overall. As I wrote recently here, motivation is an important factor in work success. Feeling that your skills and contribution are valued is an important motivational factor in thought work such as software development.

Whilst extending ones own skills as an individual tester is a noble endeavour, for the test manager the implications of hiring T-shaped individuals take on a whole new dimension. By combining the unique skill sets of different team members we can construct powerful and dynamic team units that are autonomous in operation, with mutually beneficial personal goals, and can extend their remit to take on a range of tasks. Each team within an organisation may have slightly different make up but each will possess deep skills and knowledge. Each skill set pieces together to form a final picture of both breadth and depth, the Square Shaped Team.

EuroSTAR 2013 – The Unofficial Guide

It’s here.

The Social Tester’s Unofficial Guide to EuroSTAR 2013.


I thought I’d get the guide out early this year. Hopefully I’ll see you all there.

Note: Since I completed this I’ve been informed that there is no gala dinner…..I have yet to confirm or deny this. If there is, the section on dressing smart still stands, if there isn’t….well….we’ll find somewhere to go on that night 🙂

Click the image above or here for the PDF download.

A conference story

Across the world there were similar journeys taking place.

Delegates are boarding planes, trains and automobiles to attend a European conference in the wonderful city of Amsterdam. For some this journey is short. For others it’s epic.

Some delegates would be travelling on their own. Others would be travelling with people they know; colleagues, friends, peers or family.

For the first time conference attendee the journey can be daunting and nerves can start to form around what to expect.

Some journeys go better than others.

In England one conference delegate is flying from a small city airport in a tired looking Bombardier Q400.

2012-11-05 14.18.07


The noise on-board is deafening, the coffee cold and the seats cramped. Despite these downsides the delegate can’t help but notice that the flight staff are welcoming, well trained and during the safety overview, incredibly well synchronised. He notices the menu in the seat-back and does some impromptu testing of the contents. The first obvious bug he spots is the use of the word “gourmet” to describe the microwaved cheese toastie.

Those who often attend testing conferences are somewhat obsessed. Testing isn’t just a career – it’s a calling (or a lucrative business). It’s something they’ve been doing their whole lives. Some might call this devotion to it strange, weird or sad. Others just see it as a way of life.

Over the Atlantic ocean is one of the conference speakers, asleep on a Virgin Atlantic jet. His journey started several hours ago. It won’t end for a few more hours yet. Tiredness is inevitable.

In Amsterdam there are already a large group of delegates descending on the city’s hotels, hostels, rentals and flats. Pockets of testers are occupying three or four of the main hotels. Many don’t know each other and are destined to spend the rest of their stay oblivious to the fact that the person next to them at dinner is a tester and attending the same conference.

All of the delegates share something in common; testing. They may approach the subject differently. They may oppose each others views. They may dislike each others personalities, but they all have a common thread to at least start a conversation. Yet many won’t. Many will spend the entire time alone. Some may enjoy this, others will inevitably feel isolated.

Some delegates arrive on the Monday, others wont turn up until the start of the presentations on Tuesday. The Twitter stream starts to fill with people discussing meet-ups, comments on the tutorials already taking place and general banter about the event.

Chat sessions fire up, text messages are sent and tweets are broadcast to arrange meals, drinks and gatherings. Many of these people are meeting others in the flesh for the first time. Relationships on social channels have paved the way for a seamless ability to meet-up in person. The hard work is done. The relationships can flourish further in person, or dwindle away at the realisation that online personas don’t always match reality.

As the evening comes around small groups of Testers are travelling to bars, hotels and restaurants to catch up and relax before the conference starts.

In an Indonesian restaurant in the city centre, a group of testers are gathered around vast quantities of food and beer. Conversations are flowing about testing, life and work. People are getting to know new people or are refreshing relationships with people they met at other conferences. As more beer flows the conversations become more lucid and discussions about the state of testing inevitably crop up.

As this particular group discuss certification schemes, standardisation and best practices, in the context of them destroying the industry, it is oblivious to them that across town, in a posh hotel where Heineken is served in impossibly tall glasses, there is another group of testers talking about how context doesn’t matter and best practices are what the testing world needs.

Just down the road in a small bistro is a group of well funded testers talking about how maturity models are the future for their giant consulting business. They are busy putting the final touches to new methods of quantifying the true value of testing to an organisation.

Across Amsterdam that evening there are many tribes of testers discussing testing. Some with polar opposite views, some in perfect alignment and some who are too tired, or drunk, to talk about testing. In hotel lobbies and rooms across Amsterdam there are also testers with no-one to talk to.

As Tuesday afternoon spins around the conference centre starts to get busy. In the corner is a tester filming the queues forming using a time delay app on his iPad. Upstairs are testers sitting around talking about strategies for handling regression testing and exploratory testing. Meetings are happening and discussions are flowing.

Many testers are pacing around the venue embroiled in conversations to someone on the other end of a phone call. Are they conducting business? Speaking to relatives? Pretending to speak to someone to look important?

In the Test Lab the lab rats are getting ready for people to do some testing at the conference – a concept that is alien to some delegates.

In the expo centre are salespeople and demonstrators trying to draw attention to their products, services and goods. Some are doing better than others. Some are more involved than others.

For some of the vendor representative it is their 20th conference this year. Some of the vendor reps haven’t been home for the last 8 months, their life is a constant cycle of conferences.

Throughout the event some presentations go to plan, some of the speakers don’t quite communicate their intended message well and some experience a few technical glitches.

Some talks are funny and insightful, others masked in terminology and concepts that aren’t appealing to everyone. Some are about systems, some about space rockets, some about video games and some about standards.

There’s a talk for everyone. Many delegates are complaining that there is too much to see and they are having to make tough decisions on which talk to get to. Some consider that struggle to decide the marker of an excellent conference.

This year sees a real sense of community and involvement. The community hub took a day to get going. But on the last day was well attended with delegates wanting to listen to lightning talks, chat to new people and contribute their views and ideas to the Testa Mappa.

It’s in the community hub that delegates get to talk to the speakers and other attendees in a welcoming and safe environment. Many delegates are changing their mind about the presentation after discussing the topic further with others. Many speakers are learning a lot about themselves, their presentations and their ability to communicate their core message.

Throughout the event there are many smaller and much more focussed meetings happening, some private and by invite only, some open to a wider audience. There is business happening, friendships being made, social connections starting and also ending.

As the conference comes to a close the delegates, speakers, organisers and vendors travel home, many leaving with new friends and connections. Many will return home to families, friends and colleagues more tired than they thought they would be. Conferences take their toll both physically and emotionally. The challenge for many will be filtering and putting in to action many of the interesting ideas they took away from the conference.

The challenge for some will be working out how they can talk to more people next time and how they can ensure they are invited to the many social gatherings that are happening.

For many though the conference didn’t end when the doors closed and they travelled home; the conference continued on the social channels for many more months. And that is often the real marker of a successful conference.

(I wrote this short observational story at EuroSTAR 2012 last year. It was a great conference and this years looks like it will another great conference too – see you there hopefully.)

Using Videos to demo

For the last few sprints we’ve been demonstrating our user stories (i.e. completed work) using the medium of video. It’s been really interesting to see how the teams have moved to video with ease.

The videos are often hilarious, some featuring more tech wizardry than others but all of them a great show of creativity.

I tweeted about this a while back and a couple of people asked why we would go to the effort of creating videos to show our features. Well here’s some reasons:

The demonstration were choppy during switch overs as teams had to sign in, get the system to the right state to show the new work and articulate clearly the story to the audience.

All demonstrations are at the mercy of the demo Gods. Sometimes they work, sometimes they fail – even though they may have been working just moments before (mostly it was due to logging in to the wrong accounts, dialling the wrong number, slower connection in the meeting room, nerves, data now in the wrong state after practicing the demo). We now simply line up each video and play them one at a time pausing for questions in between.

If you miss the demo you miss the demo. So for those that can’t make it to the meeting they don’t get to see the demo of the product. Videos let us post them somewhere central for the business to view at their leisure.

Also, as we move forward we will be starting to add the video demos to a central source when the feature is actually finished, which could be just a day in to the sprint. As we release to live weekly when we demo the feature to the wider business it may already have gone live. With regular release comes a new set of communication challenges! This allows the business to see the features as they become available, not just in one big chunk at the end of the sprint.

So the videos have helped this greatly. They have also been a great laugh to create and they are brining out the creative juices in the team. Not only are they experimenting with new video techniques but they are also working hard to communicate the right messages to the right audience, which is a great skill to have.

The only constraint we’ve currently set is that the videos shouldn’t take more than one hour to make. Ideally they will take just 30 mins or less, but some of the features are tricky to explain. We’ll see how it goes. Like most things here we are constantly tweaking and optimising.

Ha ha – told you so

Quite often I hear presentations and discussions from testers who talk about those moments when they feel it appropriate to say “Ha Ha, Told You So”.

You know? Those moments when the testers advice was ignored and it all went pear shaped. Or the time a tester said the company should be testing earlier, only to find a boat load of bugs too late in the day.

Over the years I’ve heard loads of people saying “ha ha – told you so”.

Sure it’s gone pear shaped, but it’s often at these times that you are needed the most; when your skills and ability are required by the business to get software out of the door.

If all you have to say at times like this is “ha ha, told you so” then you will appear petty, annoying and arrogant.

We shouldn’t be offending people and making them resentful because a decision was made that frustrated us. We need to step up and take ownership. Step up and contribute. Step up and make a difference.

At a conference a few years back a tester was presenting on how happy she felt when the project crashed and burned because they had ignored her advice. The crowd were joining in talking about “wiping the smug look off the developer’s face” and saying things like “at their peril will they ignore the tester”. It’s poisonous, unhelpful and downright ridiculous to think like that. (I was in the minority in the room btw – I walked out with a few others who found that session just too much).

So when you hear a tester shout “ha ha told you so” as a project takes a downward spiral, offer them some constructive feedback and ask for their support. Motivate them to act, not gloat in the destruction. How is that negativity going to help the business release good software.

Releasing software is a team effort. And tester’s are a part of that team.

A Social Intranet

A few years back I spent some time helping a company move to a social intranet. Here is the old mind map I put together to help explain why a social intranet is so valuable to a company who mainly work in the knowledge industry.

Identifying why something could work and what benefits it can bring is the foundation of making changes in your organisation.

We’ve recently moved forward with Confluence here at NewVoiceMedia as a social intranet and I used this basic mind map as a starting point for helping to bring about this change.

It’s great to see how people are now collaborating on work items and sharing ideas. It’s not just the Development team that are using Confluence, the wider business have picked it up with Gusto also.


For those who find mind maps tricky to read in this blog clicking on this link will take you to the mind map on the Xmind website.

There is also a text only version of this mind map here. (the text only versions loses the concept of nested ideas and essentially reads as one a large flat file)

The Tester Types – Friday Fun

Seeing the feed coming through on Twitter about Test Bash has got me all nostalgic for those good times I had working with Rosie and team behind the scenes at The Software Testing Club, over the last couple of years. It was a blast while it lasted and we created some amazing content for the community.

I’m proud of a lot of the content we created but it was the Tester Types that I enjoyed the most. In actual fact the Tester Types that kick started mine and Rosie’s working relationship. Such fun.

During that time a friend of mine, Richard Ellis, created a short but wickedly sweet video of The Tester Types which I’ve included below.

This years Test Bash appears to be a resounding success (if the Twitter feed is anything to go by). Great stuff – a testing conference the UK has desperately needed and can be proud of.