In my experience there can often be, especially amongst testers, a desire to hear the bad news, the gossip or the failings. Get to any mainstream Testing conference to hear stories of Testers gleeful at delays, failings and horror stories of late releases; the stereotypes of negative Testers did start somewhere and is very much alive in some industries.

I don't believe this is a good strategy at all, but I'll save that rant for another post. A lot of the negativity, delays and grief can often come from the way we report our testing. Often innocent reporting of findings can result in a witch hunt, panic and stress. I've seen whole management teams mobilised because of lose comments about quality, especially when a product is nearing it's release date.

When we report our test findings we need to be careful not to sensationalise the information, or underplay the importance of the findings.

So in a sense, just because some people crave tales of disaster, rework, bad designs, mistakes and trouble ahead it's not always constructive to give them this news. Now, don't get me wrong. I'm not advocating that we don't give the truth. Not at all. What I am saying is be careful how you deliver this news.

Be careful to keep your information factual. Try not to add a personal or political balance to it (unless you have an agenda) - this is a lot harder than you think.

Becareful of the language used. Emotive words will flavour the meaning.

Think about the information you are providing. Sit and read it and then write down 5 questions you could realistically expect to be asked about this information. Then answer these questions. Add this further information to your reporting. Then try to find 5 more questions. Not only will you prepare yourself for inevitable questions about your reporting, but you will also fine tune your information in the process. It may seem over-kill but I have wasted countless hours in uneccessary meetings because someone over-sensationalised their findings.

Keep the data clean, minimalist, simple and to the point.

Think about what context you find your project in. Is it the last day? Is it the first day? Are you working overtime? Are you under lots of pressure? Is it going well? These factors may make a difference to how your information in interpreted.

Make your information gel nicely with the context. Or make it contradict for a reason.

But always be conscious of the effect your information *could* have. Even stopping to think about what you're reporting is a very effective filter. And remember:

"What interests the project team, might not be in the interest of the project team"

Testing is dead, that's what they said in the news.

I disagree, but I think it's getting confused.

There has been a lot of talk on whether or not "testing" is dead.

At EuroSTAR last year it was an over-riding theme and it generated a lot of talk about what the future holds for Testers.

Trying to predict what Testing will look like in the future will always be limited by our inability to gain an agreed definition of what Testing currently looks like. I don't believe that trying to pigeon hole Testing is a good idea anyway (but that's a different post)

So to talk about a future of Testing when we aren't even sure what the current view of Testing is seems to me to be a fruitless task. I know; I've tried in the past and failed hence I focus now on what trends I see and what challenges we may face.

What becomes so painfully clear when widening your awareness to understand how Testing is done in other companies and domains is that Testing is incredibly diverse (and often surprising).

A future idea about Testing (or techniques for achieving good Testing) for one person could be an old fashioned approach for another person. Both may be valid for their contexts and both may or may not be future orientated; it depends where you personally stand.

For example human tickbox testing (often called "checking") is very much alive and well in some industries and it shows no sign of going away (sadly). It's a very buoyant market and a huge number of "Checkers" are employed doing it. I can't see this market going away soon; so is Testing dead?

I don't believe Checking is Testing, but now we're arguing Semantics when we talk about Testing is Dead (i.e. do we mean Checking is dead?).

Exploratory Testing is the future for some people, but a tried and tested approach for others.

Testing is not dead. It's just changing…for some people, in some industries. Just like the world is changing…for some people, in some industries.

Good Testers will do good Testing no matter how their world changes. They may just approach it differently, with a different mindset and different set of tools and techniques and approaches.

Those that don't adapt will find their value diminishing, but that doesn't mean Testing is dead.

Unit testing is testing. Acceptance testing is testing. UX testing is testing. AB testing is testing. Testing in live is testing. Design reviewing is testing. A Story chat is a form of testing.

Testing is changing (for some people). The people doing testing are changing. But Testing is still happening. And Testing will continue to happen.

Talking to people at EuroSTAR it became increasingly clear there were two very distinct camps of thinking about the death of Testing, with a number of blended ideas in-between.

Camp 1 was people who were terrified of the future and what it might bring. Camp 2 was people who embraced the future and all of the change it could bring.

I for one am firmly in Camp 2. I'm excited about the change and challenges and the technology we've yet to see. Yet I know there are many who are scared. I think a lot of this fear comes from not knowing what the future may hold and not being able to visualise yourself working in these new environments.

The biggest problem for most people around the future of testing is an inability to forecast themselves and their skills into a job they don't believe exists (or are willing to believe exists).

This comes out as resistance to change; Cloud will never come to their domain: Agile will never work where they work: Sitting with Programmers will never work in their environments: Virtualisation will never work because it's BLAH BLAH BLAH.

But the world IS changing and a key skill a good tester needs to possess is the ability to understand how their world is changing, how their skills will be valued in this changing world and what they need to do to future proof themselves. A good Tester will adapt.

At EuroSTAR a lady said that Cloud and Agile would never come to her industry because it's impossible to achieve and the industry wouldn't accept it. Her industry is Call Centre software. Well guess what? I work in the Call Centre Industry and our product is cloud based and we develop it in an Agile/Lean approach. Testing is never as Black and White as we may initial think. There is never a Best and only way.

Refusing the future will not work either. Predicting the future is impossible also. But being adaptable in your approach, your skills, your understanding and your learning will certainly help the future seem less scary.

The only constant is change.

The future will happen.

Testing will still happen.

The only question is: "Will it be you doing this testing?"

More Testing Is Dead posts:

Scott Barber - http://scott-barber.blogspot.com/2011/11/on-alleged-death-of-testing.html

Ben Kelly - http://testjutsu.com/2011/11/software-testing-still-not-going-away/

Matt Heusser - http://www.softwaretestpro.com/Item/5352

Google GTAC conference - http://www.youtube.com/watch?v=X1jWe5rOu3g

Arborosa on Testing is Dead - http://arborosa.org/2012/01/11/is-testing-dead/

Rob van Steenbergen - http://rvansteenbergen.blogspot.com/2011/12/testing-is-dead-because.html

When people start a new job it can often be daunting and for some, a little overwhelming. There is often so much to learn and more often than not, a lot of the information you often need is either not easily available, or is so dull that you stuggle to get through it.

I started a new job many years ago and spent the first week reading a boring document explaining all of the departments, what they all did, what the product did and what was expected of me.

I started on the same day as five other people and the only time we really interacted in that first week was when we were all sat in the atrium waiting for our managers to take us to our "place of work".

This is a shame when new starters don't spend time with each other in their first few weeks/months. When you separate new starters you lose a valuable opportunity to build cross functional friendships and collaboration.

It's also a shame when the information transfer is dull and in-affective. Even worse is when new starters aren't even introduced to the rest of the business functions and areas.

So one of the things we've introduced recently at NewVoiceMedia is an induction process.

I'd seriously recommend this. It was great to see people from Marketing, Sales, Development and Professional Services (PS) all collaborating on team games.

These first few days were an opportunity also for each department to come up with something fun and fresh to tell our new starters and explain how their department functions within the business.

We saw games, visual model building (lego and cardboard boxes), mood board creation, low tech social networks, more games, prezi presentations and a serious amount of interaction. It was great fun presenting on Agile and Lean too and there were plenty of questions about how these techniques and methodologies translate to business value.

This now means our developers, testers, marketing, sales and PS now have 'relationships' with people in other departments and at least a basic understanding of what these other departments do. Communication channels have been created that otherwise may never have existed and a sense of collaboration has been instilled in the first few weeks of hopefully long and valued careers.

Induction days also give your team a sense of purpose and a feeling of belonging. We got some awesome feedback stating that although two days of intensive induction were tough, they were also very rewarding and a lot of fun. This is great news.

I'd recommend that all Leads/Managers consider an induction day to aid integration, cross team collaboration and more inspired communication channels. It doesn't have to be a two day event, but I would suggest that it involves games and visual models and collaboration; activities a Tester has to do very often.

(download)

Click here to download:

inductions-to-aid-collaboration-ijallyehAxrDlutdGxkm.zip (140 KB)

Yet in this instance; when people were desperate to see what time the buses were running, mobile technology became the hub of activity. Myself and two others with mobile internet were tracking the bus times. As more people gathered to find out the times, this in turn attracted even more people.

A few thoughts from this:

At what point do systems we've traditionally relied on become obsolete, and what do we replace them with? (we can't assume everyone will have mobile internet)

Why is testing of these types of systems done during peak time (assuming that the message is honest)?

At what point do we improve the service we offer so we no longer need to track bus journeys and estimate the time of arrival? (I'm thinking on the Japanese train system which is legendary in it's speed, accuracy and reliability - but I guess they still track train times???)

Why, when systems are taken down, are alternatives not put in place?

As testers how can we "test" in live whilst still maintaining a service?

And a million more questions that are flying through my head.

At EuroSTAR last week it was sad to see a "them versus us" culture still thriving in the software development community. I thought things were changing, especially with the on-set of Agile heading mainstream but it seems not.

I got embroiled in a conversation which stole an hour of my life. An hour in which I heard the virtues of "them versus us". An hour in which this "Test Manager" extolled the positives around an "Independent" test team, who "distrusted" everyone and treated programmers with "contempt".

It boosted Testers morales apparently. It made the team function as it should; as a separate, impartial and hated department. A department who would ruin projects. But it was never the Test Manager (or teams fault), it was the project teams or management.

I got the following vibe:

The Testers were frightened of the Management.
The Management didn’t like the Programmers or the Project Team, though they could live with the Testers.
The Programmers were indifferent to the Project Team but were terrified of the Testers and hated the Management.
The Management were seriously affected by the Programmers terror of the Testers.
The Project Team were nervous of the possibility of a Management – Tester alliance, spurred on by the indifference of the Programmers, and they shared everybody else’s dislike of the Management.
Or something like that.

Releasing software seemed to be a constant struggle for this chap. Testing was always an after-thought.

This was a scarily common theme and the blame was always put on other people.

Is change that difficult?

Isn't it better to try and change something (relationships, approach, team, people, environment, structure, etc), than settle for mediocre? What are your thoughts?

It's been a mad few weeks so I'm looking forward to getting back to normality again, both at work and at home.

Here are some thoughts from EuroSTAR 2011:

I was attending EuroSTAR 2011 with a different lens on my views as I sought out fresh and interesting glimpses at where we are heading as an industry. I was sadly dissapointed. There were some interesting things happening but it was mostly a very common story.

A theme seemed to emerge from the event around the future of testing with both Gojko Adzic and James Whittaker suggesting there would be no testing phase, James even going so far as to say there would be no testers too.

Other than that, it was business as usual. Metrics, certifications, Best Practices, Agile Testing and an interesting "people" theme too. Nothing too controversial and an all round good conference, but very little to really inspire me that our craft is changing.

I mostly agreed with both Gojko and James in their prediction of the demise of Testing. It become so talked about that Paul Gerrard organised an open forum on one evening to discuss where Testing is heading. It seemed though, that all of this talk about the future of testing relied on us all having a unified agreement of what Testing actually was. And you know how hard that is. 

There were a few things though that gave me great insight and hope that we are still changing.

• Michael Bolton was talking about dashboards and reporting for Exploratory Testing. 
• People were aware of what Exploratory Testing was and many were practicing it.
• Agile wasn't as scary to many as at most Testing conferences.
• Adam Knight was talking about Specification by Example and people were intrigued.
• UTest were talking about 10 emerging technologies to change testing. This talk was the only talk that felt like it really shone a light on the future of testing. I mind mapped it here (and below)
• There were one or two cloud test tool vendors who stood out for pushing the boundaries of tools and their uses. SOASTA and CloudFlex (by Intechnica) were two highlights for me. 
• There were a growing number of Software Testing Club members at the event.
• The Testing Planet feedback was immense. Many thanks.
• The evening socials were busy with people talking about the conference.
• The Test Lab was there.
• There was a talk on mind mapping.

I actually walked out of one talk with a number of other people, because of the loose comments being made, the assumptions being driven from some research and because it had a general feeling of us versus them (test v programmer). It felt wrong. But hey, it seemed like a popular session for many.

I actually added some mind maps of the talks here for public consumption:

http://xmind.net/share/rob_lambert/

There was a common thread of being embarrassed about being a Tester and a general need to prove yourself with little consideration for the team. I just wish that we'd stand proud of what we do and show respect for the industry and the teams we work in; it sometimes feels like we just concentrate on the "good old days of Waterfall" and the stereotype we have created for ourselves. There is vastly more going on in the industry than many even realise. Wouldn't it be great to stand tall and talk about it; share it and learn from it.

One thing became evidently clear from EuroSTAR. The future is mixed and uncertain and unknown - but we knew that already. That's no different now to 1 year ago or one year from now. But I genuinely believe in the future we will rely more and more on communities of Testers. 

It was a good conference though and it felt more balanced than last year, but it still felt heavy on metrics and best practices. But what an excellent choice for next years Programme Chair - Zeger Van Hese - awesome choice in fact :)

Here are my slides from this years talk at Agile Testing Days.

Click here to download:

ATD2011-AwarenessFields.pptx (9.13 MB)

(download)

Click here to download:

ATD2011-AwarenessFields.pptx (9.13 MB)

I've been lucky enough to attend Agile Testing Days in Germany for 3 years now.

This year they moved it from Berlin to Potsdam (not too far from Berlin). Unfortunately I didn't get much chance to see Potsdam, but it looks like a beautiful place to visit with sightseeing in mind.

As usual Jose and his team create an amazingly welcoming and friendly event. The food and drink is top class and the entertainment is excellent. It seems to be one of the few events I've attended where there is as much emphasis on socialising and having fun, as there is on the speaking. Almost everyone I talked to said the same thing; the talks sow the seeds but the true learning happens during the conversations at the social events.

The Keynotes were great, the sessions were brilliant and as usual the Test Lab was great. I managed to stay around this year and catch some of the Open Spaces which appeared to work well.

One of the keynotes that really got me thinking was Michael Bolton's talk. During the talk he talked about science and testing science using scientific methods. When he moved to social sciences though was when I really started to make some notes. I think this is going to be an amazing area of learning for many testers. The field of social science is vast but there are pockets of interesting work going on. It's the start of potentially the new direction for testing; a direction where we look at what it is that we do when we test, how our work affects people and how we can use social science research techniques to aid and understand our testing.

Expect to read a lot more about the social sciences from many sources.

I've been writing about tech in society with a group of people interested in ethnography and social change through design and I intend to fold some of that work here, so expect a slight change in direction as I bring my blog more in-line with my current work, ideas and main social science interests. It will obviously still be about testing.......

But that's the point. Testing is changing (or we're looking at it differently)

At Agile Testing Days I saw how other people were altering their outlooks and approaches, and this gives me a warm fuzzy feeling; it feels like we're talking less about the "good old days". (which I believe weren't as good as many people think)

And when you come away from a conference feeling like change is in the air and people are ready for the challenges, then that's the sign of a good conference.

I'll be at EuroSTAR conference next week. I'm looking forward to meeting many people who are already doing some really exciting things in the Testing world.

I'm still processing my notes from this weeks Agile Testing Days, no doubt I'll have loads more next week too.

I believe that one of the biggest mistakes a Hiring Manager (Test Manager etc) can do for a team is to hire in people with the same set of views and opinions. I'm not talking about "Yes" people who don't have the confidence or inclination to disagree. I'm talking about people who are pretty much in line with your thoughts and thinking, or don't have any particular views they want to air.

It's natural for people to gravitate to those who support your ideas. It's natural to want support for your ideas and respect for your approach; but that's only valuable if your approach and ideas are right.

Instead I think it's important to hire in people who are in alignment with your Goals and Objectives, but don't necessarily hold the same views and opinions of how to get there. Sure, you need some form of alignment in your approach, but to have no criticism, no objections and no discussions about the 'right' way is to fall in to the trap of Group Think. To have a team incapable of thinking up new and interesting ways to solve problems is to create a group who will forever need your guidance. And is that really want you want?

So when recruiting a team it's always a challenge to take a step back from your point of view on Testing and hire in the "right" people for the job. People who have a point of view, but have the personality to discuss constructively.

I worked somewhere where the Team Lead said something along the lines of

"We tell them what to do, and they will do it".

I disagreed with this approach then, and I still do now. As a manager (or Leader?) it's important to be able to ask your team for their points of view, thoughts and opinions.

Each team member will have a different view, a different perspective, difference experiences and skills and a different way of thinking about a problem. Truly diverse and creative solutions will emerge (assuming you have an environment that supports that process). Diversity is a good thing. Right?

I think it was Adam Knight the other week who said on Twitter that he is struggling to find Testers with diverse enough skills and thoughts. I absolutely agree. There's one thing standardising yourself to conform to the mainstream testing industry (a stereotype?), but for many jobs now the fact you have something different to offer is a positive trait.

So my advice is don't hire people who are just like you; seek diversity.

And as a Tester, don't be just like everyone else.

Of course, I may not be right at all and may spend all of my day arguing...time will tell. :)