A Testing Bash…in Cambridge

One of the things me and Rosie have always dreamed of doing for The Software Testing Club was to host a small event. We wanted to do something for the community and have fun in the process.

We originally thought of doing a big Christmas party but The Testing Planet grew beyond our expectations and took over our lives (in a good way). We also started doing things to build solid foundations that could sustain the club and all of the cool things we offer so we could move forward with speed.

Thankfully, the time has come to announce that we are holding a small gathering in the delightfully English city of Cambridge*.

It is strictly limited to 100 places and these are selling fast. We have some truly knowledgeable and talented people lined up to speak and there is no doubt everyone will come away from the event with more insights, learnings and ideas than they went in with.

There will be interactive activities, games and some cool social activities to build a sense of collaboration and learning. There will be places to chill out and chat about Testing. It’s gonna be great, if I do say so myself.

Just check out the lineup : Steve Green, Alan Richardson, Antony Ribot, Adam Knight, Fred Beringer, Anna Baik, Markus Gartner….and more.

Check out the location : http://www.cambridge.org/pittbuilding/ <–beautiful place full of history.

Check out the price : £99 for all of those early birds.

I for one am very excited to be part of this event. With a limit of 100 delegates we’re aiming to keep the focus on learning and sharing. In keeping with the vibe of The Software Testing Club we want this event to be somewhere where people can share their ideas, make friends and connections and take away something for their own work place.

It’s going to be an amazing way for us to meet even more Testing Club members and create something pretty cool at the same time. We’d love you to attend and we’d appreciate all the help we can in spreading the news about the event too.

Hope to see some of you there.
Rob..

http://www.ministryoftesting.com/training-events/testbash/

* Cambridge’s most famous contribution is of course Cambridge University which has given us the likes of John Cleese, Charles Darwin, David Attenborough, David Starkey, Alan Turing, Lloyd Grossman, Stephen Hawking and yes, even Michael Winner and Vanessa Feltz.

Them and Us and big feedback loops

I presented at a conference last year where I talked about large feedback loops and how agile attempts to shorten these loops. Ideas such as Acceptance Test Driven Development, Test Driven Development and agile sprint durations are *some* reasons why agile achieves shorter feedback loops. (not exclusive to agile though).

I also suggested that long feedback loops make it acceptable to build an “us versus them” environment and to use static tools like Defect Tracking systems as a form of communication.

In environments where we see lots of “Us Versus Them” mentality between Programmers and Testers (and there are plenty of these environments), do we also see large feedback loops and/or system in use that encourage slower feedback?

Or, in environments with large feedback loops, do we see more “Us Versus Them” mentality.

I suspect both are true and I wonder which comes first.

No matter which way the cause and effect is, it’s clear to me that we need to work hard to break down these walls by incressing the speed at which we provide feedback.

For some, this is easier said than done, but I firmly believe that short feedback loops can do wonders for your whole Development team. Thoughts?

 

 

 

What’s in the news today?

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.

4843847291_d44b8b90da_z

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

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/

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

 

Inductions to aid collaboration

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.