go back to the blog

Taking small steps in a big organization

  • 29/07/2013
  • no comments
  • Posted by EuroSTAR

In the Beginning

I came to my current company over six years ago and noticed that a lot of the projects appeared to be run in an agile/scrum/waterfall way *.

There was a large amount of scripted tests held in a HP Quality Centre repository and it ALWAYS took the team six weeks to test the release regardless of what changes or features were in the release. It should be noted that the project was very complex and not a UI system. The reasons given for taking this amount of time was the need to run regression against everything in the release (There was no automation). It appeared that there could also have been trust issues amongst test and development. I had already had experience of working in a semi exploratory way before joining the company (ad-hoc / free testing) and I decided to use my own (after work hours) time to learn more about it. This was after somebody at the Eurostar conference in 2008 suggested it would be worthwhile me looking into this and if I need any help then get in touch. That somebody was Michael Bolton and this was my first contact with him.

First Steps

So I went away and during the evenings I started to research exploratory testing and came across a lot of information, some good and some bad. I came across James Bach and his website ( which was a great place for resources on exploratory testing, context driven and session based testing management along with a whole raft of other very useful information. From here I came across Cem Kaner and Lessons learnt in software testing and the Association for software testing and the free BBST course material.

I took the information I had started to learn and looked at how I could this into practice on the projects I was working on. The first steps I took were not really about exploratory testing but more based upon common sense and looking at how things could be improved. This was done by doing the following things:

  • Talking to development and asking what code had been changed
  • Talking to project team and highlighting where everyone thought the high risk parts were
  • Engaging with development teams and building up a relationship of mutual trust
  • Asking the development teams what the testing tam could do to support the development teams
  • Getting earlier involvement with the development /analysis side

This helped to build up the confidence of the teams so that each could see what skills and support they could bring to the project.



At the same time I tried to implement a somewhat semi structured exploratory testing approach based upon my understandings of what I had learnt. We managed to reduce the amount of testing for the release from six weeks to an average of two weeks. We did this by using a mixture of scripted regression tests based upon risk of what had been implemented or changed in the project with some time set aside to do exploratory testing.


The next stage was to communicate what we had done on this project and look how I could expand it to more projects. It was a difficult task to try and get buy in on the approach and I struggled to explain clearly how this was the right approach to take. I did learn that effective communication is crucial if you what to try and change how things are done. There is a need to prove what you are saying by doing it and then use that as evidence. To some this may seem like common sense but to me at the time it was a case of me saying well it works for me so why not do it, which was not the right tactic to use.
I was asked to prove the approach on other projects and provide evidence of its benefit.


I realised that I may be out of my depth and I would need to learn a lot more to adapt the approach for use in a large organisation it was at this time that I reached out to the testing community and asked for some support and help. I was very fortunate that Michael Bolton responded and he gave up his own time to chat with me via Skype for quite a few evenings and weekends. Since this will appear on the Eurostar blog and Michael Bolton is/was program chair for 2013 I would like to state publicly how much I am thankful for his generous offer and giving up his own time to mentor and training me in aspects of the Rapid Software Testing course.

From these sessions I managed to put together some training material that could be used internally and creating an approach that would suit the organization. This material could then be used to help train other testers for projects.

Large Project

I was asked to ‘prove’ the concept on a larger scale highly visible project, working alongside another tester. My first task was to ‘test’ the training material out on the other tester and alter and adjust the material where it did not fit our needs. We made the decision that all our testing would be of an exploratory nature for all manual testing (there was some automation)

Small Success

This project is due to go live soon with the customer and some of the feedback we received was that we had very few customer specific issues raised against the release in comparison to other previous project delivered. This I think is a reasonable measure of success for the approach. From this I was contacted by a team within our company based in Israel to see if there was a possibility to do some exploratory testing training with their teams.

Faltering Steps

So I went to Israel and deliver the workshops to about 50 people and I used this as a trial to see if the approach could be adapted to work with different projects outside of my direct influence.

Once the workshops had been delivered I returned back to the UK to work on other projects. I found that the approach had not been adopted very well in Israel and that some teams had given up trying to use the approach and resorted back to scripted tests. It puzzled me why this was the case and it was only after some investigation that I discovered that I had made some mistakes in delivering the workshops. The summary of these can be seen below

  • No follow up with teams to ensure questions could be answered
  • No application in workshop to real work been done by the teams (no connection between what was being said and how they do their job)
  • The workshop was more a lecture rather than a learn by doing set of exercises (not experiential)

From this feedback I started to redesign the workshops so it was more hands on, practical and group work lead rather than trainer lead. This was an important lesson for me to learn.

Not in your own backyard

Another issue that happened was I had delivered training to the UK teams and found that there was a less than positive response to the approach and I could not work out the reasoning why. Was it a case of not in your own back garden? Whatever the reason, I needed to find a way to resolve it. Michael Bolton came to the rescue and we organised an internal 3 day rapid software testing course for the teams run by Michael himself. This as a great success and people within the teams started to talk and discuss ways in which they could use the approach on their own projects. We had started to gather some momentum for adopting the exploratory testing approach.

Starting to Run

Using this momentum I worked closely with our internal training division and reached out to other regions who had expressed in interested in learning more about the approach. I delivered the ‘new’ workshop on exploratory testing to the following regions:

• Israel (Using new workshop)
• India
• France
• UK
• China
I looked for people in these workshops who showed interest and passion about the subject. I approached them to see if they would like to become ‘experts’, the ‘go to’ people in their region when people ask about exploratory testing. I would act as a mentor and support person and they in turn would act as mentors and trainers in their region. We now have over twenty experts across the regions. I found some very passionate testers in each of the regions and their passion and enthusiasm has help to drive the approach into more and more teams, with some of the experts now training others in their regions.

Some successes include the following:

  • India over 200 testers now regularly using the approach
  • France – over 50 people trained in using the approach
  • UK – More and more teams becoming aware and 20-30 testers using the approach
  • China – Still early days
  • Israel – Started to revisit and retrain

Full Steam Ahead

Our company was acquired in 2012 and we are now part of a much bigger company (70, 000+ people) this has given me more scope to expand the approach into other teams. Some of the future plans include:

  • More workshops done by internal experts
  • Expand use of outside agencies to deliver rapid software testing workshops
  • Look at the BBST course and see if we can get our staff trained as instructors to deliver this internally
  • Using internal communications system to spread knowledge and expertise of the approach
  • Intern schemes
  • Apprenticeship schemes


Lessons Learnt

The key lessons I learnt from this experience are:

  • A single individual can make a huge difference within any organization big or small
  • Have a passion and find others who share your passion
  • Embrace mistakes (you will make them)
  • Be prepared to learn
  • Do not tell people what to do but show them

*Disclaimer: Some out there may gasp at that statement but there are many companies who work in this way. Sometimes it works for them and sometimes it does not and all that matters is making whatever methodology you follow fit and work for your business needs.


john stevenson_120x129“The opinions expressed in this article are my own views and not those of any company I have or do work for”
Having been involved in testing for over 20 years and within the IT industry for more than 24 years I am still surprised with how exciting I find it and how much I continue to learn about things that are new. I have a passion for learning and love to learn about new things. I have an interest in many things such as social science, psychology, photography and gardening. I keep involved within the testing community and write a testing blog ( and can be found regularly tweeting (@steveo1967). I am keen to see what can be of benefit to software testing from outside the traditional channels and as such I like to explore different domains and see if there is anything that can be linked back to testing. I care about the testing community, like to be involved and like to be social. I feel I have a wide variety of experience within testing and currently I am mentoring and training others in exploratory testing and SBTM whilst looking for opportunities to introduce approaches from other crafts such as anthropology, ethnographic research, design thinking, cognitive science and many others.

Twitter: @steveo1967

Blog post by

go back to the blog


Leave your blog link in the comments below.

EuroSTAR In Pictures

View image gallery