Recently I’ve been reading Elisabeth Hendrickson’s excellent book ‘Explore It!’. For anyone who has an interest in exploratory testing it’s a must own. I wish I’d discovered it earlier to be honest, since it gives so many useful hints and tips, as well as confirming that the ways of working that one has chosen are also recommended and used by others.
As well as using it for my own learning, I’ve been slowly going through the book and working out what parts I can use in the regular lunch and learn sessions that I run at work. While we practice exploratory testing, in fact it’s the cornerstone of our sapient testing strategy, there are some areas where I feel we could take approaches that could benefit not only testing, but also the wider business.
Working With Legacy Systems
We frequently work with legacy systems and so one chapter that was of immediate interest to me in Elisabeth’s book concerned exploring an existing system. When one has an existing system to test I find it’s all too easy to become primed by what others have already discovered, and to fall back on existing test cases (whether physically written down or in someone’s head). This can bias you, resulting in less effective testing.
Elisabeth makes the point that an existing system may well be unknown to the tester, but also may well be unknown to the whole team, or at least contain parts that are unknown. While the software fulfils a business need, how it actually goes about doing so may be less clear. That makes it ideal for exploration.
James and Jon Bach like to call the initial exploration of an existing system ‘recon testing’. I like this term, by taking an initial session to explore and discover the basics of the software under test then one can then plan more effectively for future sessions, and write future charters in order to drive those plans (if you want to know more about the concept of session based testing and how charters fit in with this then have a look at James Bach’s explaination). Recon sessions help to map the territory and give insight.
During a recon session you can learn a lot, but the most important areas to ensure that you have gained insight into are:
The ecosystem in which the software under test resides.
Touchpoints to other systems.
Variables (things we change or can change).
Obvious vulnerabilities and potential risks.
Our Training Session
During our training session we carried out recon testing on the Staples ‘Easy’ button, and a standard service bell. This no doubt annoyed those in the room next door
By starting training with something simple, and not software based then it’s easier to pick up and learn the basics of a new technique without bias or the complication of software. We then compared our experiences, testing, (and the charters produced), with those that the Bach brothers produced when they carried out an exploratory testing exercise using the same product. Fortunately for us, their session is available on youtube, so it was an excellent addition to our de-brief. In it they explain the different testing techniques they use, and why. It’s well worth watching.
Enough Recon Testing?
One area to focus upon when conducting recon testing is whether one has conducted enough recon testing. Fortunately ‘Explore It!’ has this covered, recommending you ask yourself questions about the system that you have been exploring. If you don’t understand what the system does, how input and output works or how the environmental configuration affects the system for example, then it’s probably time to think about more recon before you move into more focused test sessions. Fortunately for the ‘Easy’ button and bell testers, (and those sitting near the meeting room where we had the lunch and learn), then this was not necessary
A Useful Addition
Recon testing is something that I think we’ll find is a really useful addition to our strategy. I’d certainly recommend that you check it out, and that you check out ‘Explore It!’ which contains much more useful information and techniques to use in your exploratory testing. I’ll certainly be using the book to inspire some future training sessions for the team.
I spoke about why I believe that Testing As An Activity is important, and why we should all test. The old axiom that “Testers Test and Programmers Code” is so outdated now and everyone needs to change. Testers are the testing experts in a team, and can help enable the whole team to own quality but they are certainly not the only one’s who should be testing.
I was interviewed recently for the uTest blog. I’ll be speaking about ‘Testing As An Activity’ at the forthcoming Next Generation Testing Conference, and so they asked me some questions about the topic, as well as some more general one’s about my thoughts on testing and how I started in the industry.
I’ve just got back from the Romanian Testing Conference which was held in Cluj-Napoca. It was a great couple of days, talking testing with a lot of new people, and some friends from the UK and further afield.
If you get the chance then I would definitely recommend the conference. There was a good mix of presenters and presentations, and the event was very professionally run. They even had their own RTC2014 branded cars!
Next up, Nordic Testing Days in Tallinn in a couple of weeks. I’m talking about ‘Testing Your Emotions’, which will be a change from the mobile software testing area that I normally present on. I’ll also try and live blog as much as possible from the event.
At the start of this year I made a conscious decision to try and speak at more conferences. I think it’s important that those of us who feel happy standing up in front of crowds of people and talking about testing do so; it helps spread ideas and keeps things fresh. I also find it’s a great way of meeting new people, exchanging new ideas, and doing so while keeping the costs down
So, I’ve been making a real effort with my abstracts and submissions this year (a topic of a future blog post). And I think I’ve also got a bit lucky as well, since I’m speaking a few conferences this year. It’s all really rather exciting. The full list is below:
I’m at the Pipeline continuous delivery conference today. I’ll try and mindmap as many sessions as possible and post updates here. Scroll down to see the earlier sessions.
It’s All About the People
Last up – Tomas Riha, talking about why its All About the People. A good presentation about moving to Continuous Delivery at VGT. My mind map is here.
Big Ideas, Small Company, Moderate Heresy
Next up, Big Ideas, Small Company, Moderate Heresy from Alex Wilson and Benji Weber from Unruly. A very interesting presentation on their approach, particularly their synchronous processes. My mind map is here.
Next up is Phil Wills from The Guardian, talking about “Ship It!”.
I spent a very useful and interesting day at SIGIST on Tuesday, presenting a talk on mobile testing, and listening to a number of talks from other speakers.
Simon Stewart’s presentation on how they test they Facebook Android application was very interesting. There is no Android team at Facebook, with all feature development taking place in the same team, irrespective of the platform. This helps ensure that the offerings are consistent across platforms.
They make a lot of use of test automation, (something that Facebook are famous for), and this applies to Android as much as other platforms, in particular a focus on unit testing and functional test automation using Selendroid.
Facebook have two main guiding principles for their test automation:
Signal > Coverage – ensure that the results of running tests are acted upon, and failing tests are fixed or removed.
Speed > Coverage – ensuring nothing takes more than 10 minutes to rub, and running tests in parallel.
Facebook also use a lot of dog-fooding and make use of Google’s Alpha and Beta test programs to ensure a wide coverage of devices and test scenarios, in particular to fill gaps between their primarily automated test strategy.
I drew a mind-map of the talk which explains everything in more detail. Click on the image to get the full size version.
I work with groups of people who break the illusions that people have about software. I'm intrigued by software testing, test strategies and techniques, and organising everything using Scrum and Kanban. I have also been known to talk about mobile devices and mobile testing a lot.