Tag Archives: testing

conferences, Presenting, Testing

TestBash – The Friendly Conference

1 Comment

It’s taken a while to write this. Not because I don’t have a head full of new ideas from TestBash but simply because it’s taken time to digest everything, put everything into a sensible order in my head, and come to come conclusions about the day.

If you hate long blog post then just read this bit 🙂

The Condensed Version

TestBash is great. It’s one of the friendliest conferences I’ve been to – people talk to each other, most people are really engaged in what they do, and it’s really easy to strike up a conversation with a complete stranger about something that you’ve seen or experienced. You should go if you haven’t already. Plus they video everything (and hopefully it’ll be online here soon).

The Long Version

Still here? Then read on….

I was lucky this year – I had the opportunity to speak again. Last time, in 2013, I was petrified. This time I’d spoken at a few more conferences and so I was altogether more calm and collected. From a personal point of view, one of the main reasons this was great was that it meant I focused more on the presentations that were on before mine. In 2013 I couldn’t tell you much about any of them. This time more of them went into my head 🙂

As usual I tried to write some mindmaps as the presentations took place. One great thing about TestBash is that there is only one track – and this means no difficult decisions about who to see, or annoying clashes. And from a presenters point of view it means you know how many people you will present to, i.e. everyone 🙂

So, here goes, my take on the day and what I saw.

Lean Coffee

If you come to TestBash and you don’t get up early and go to the Lean Coffee then you are really missing out. In fact more this time, there was also bacon 🙂 I love Lean Coffee, it’s a great way for people to get together and talk about what interests the group. We had some great discussion on a variety of testing topics and the whole event was really well attended this year, with lots of tables full of happy testers.

Then it was time to head on into the main auditorium for a day of talks.

 The Rapid Software Testing Guide to What You Meant To Say – Michael Bolton

I started off trying to mindmap Michael’s presentation and then remembered why I don’t try and write mindmaps for Michael’s presentations 🙂 There’s so much information that it’s much better to sit back, watch, and then wait for slides or videos afterwards. In this presentation Michael took us through a whole bunch of statements on testing and software development, then dissected them, put them into Rapid Software Testing context, then reassembled them to show what should have been said. There was some great stuff in there – watch the video from the TestBash website when it is available. If you want to see a very small mindmap then here it is 🙂

What you meant to say

Bug Detection – Iain McCowatt

Iain always gives a good presentation and in this one he took us through bug detection, from the perspective of tacit and explicit knowledge, the work of Harry Collins, and Dual Process Theory. Click on the thumbnail to get a full sized mindmap.

Bug detection

 

Re-running the ‘Are you a mac or a PC? battle … for iOS and Android – Sally Goble & Jon Hare-Winton

Sally and Jon from The Guardian took us through an entertaining presentation about the differences between iOS and Android, and how The Guardian approach mobile testing as a result. There were some interesting points in the presentation, and I really liked the gameification in the presentation as well, even if it did end up as a draw 🙂 Given more time then it would have been great to have seen some more detailed mobile testing information, but it was a fun presentation nonetheless.

Click on the thumbnail to get a full sized mindmap.

Mobile testing

 

What’s In a Name? Experimenting With Testing Job Titles – Martin Hynie

I’d not met Martin before TestBash but got talking to him at the tester meetup the night before. His presentation was fascinating and explained how he had experimented with job titles and the effect that it had on how testing and testers were perceived. The results he presented were really interesting and certainly made me think more about what job titles and names really mean. I’m sure we’d all like to think that being called testers is great and people will always accept the value we know we bring, but perhaps that is not always the case.

I didn’t mindmap Martin’s presentation. It was before mine 🙂

Why I Lost My Job As a Test Manager and What I Learnt As a Result – Stephen Janaway

I spoke about my experiences of losing my job as a Test Manager. and shared my experiences of going through the transition. Being someone who now works in an organisation where there are no Test Managers meant that I was able to give my take on the future of Test Management, a future that I think does not, and probably will not, include the Test Management role in the way that it does today. I spoke about the changes that the organisation made in order to keep a focus on testing; things like test communities, a coaching role, and mentoring.

No mindmap obviously. I was busy 🙂 If you’d like to see the presentation then there will be a video on the TestBash website but why not come and see it live? I’ll be presenting a longer version at both Nordic Testing Days and EuroSTAR this year.

Myths and Legends of Software Testing – Vernon Richards

The legend that is TesterFromLeicester confronted some of the myths that we all experience as part of testing. With added tutu gags. Vernon gave us some great ways of confronting common myths and challenging those who share them. Watch the video – it’s great.

Quality doesn’t belong with the tester! – Maaret Pyhäjärvi

Maaret gave a really interesting presentation on how she has tested in a team with one tester. She gave some great hints and tips, and explained how her approach changed as a sole tester, and how the developers also approached quality as a result.

Getting Rid of Release Candidate Testing – Matthew Heusser

Matt’s presentation really interested me because we’d gone through the same transition in the past year and so I’d seen the arguments for and against. Primarily it was the testers who were more concerned about getting rid of release testing, and so it was interesting to see Matt’s take. I also liked his presentation style, using no prepared slides but drawing them on a iPad as he went. Really unique and it worked.

Click on the mindmap to get a larger version.

Getting rid of release testing

Automation in Testing – Richard Bradshaw

Richard took us all through his experiences in automation. I found it really interesting that he had first tried to ‘automate everything’ before understanding more about the differences between checking and testing, and how automation should be used to add value to software testing, not ‘be’ software testing. I didn’t get the chance to mindmap Richards presentation so take a look at the video when it’s available.

The Art of Asking Questions – Karen Johnson

We finished up the presentations with Karen, who sat on the stage and quietly and confidently gave us some great advice. She explained about how to ask questions, gave us a lot of really useful reading material, and explained in lots of details why asking questions in the right way is so important. You can find her slides on Slideshare and I’d really recommend reading them and following the links.

And the Rest

The 99 second talks were really great as usual. A real mix of topics, delivery styles and delivery. If you haven’t presented before then 99 second talks are a great way to get started and seeing so many new people up there and speaking was good to see.

Overall I love TestBash. It’s a conference that is so friendly. There’s lots of social events, it’s single track which means everyone sees the same presentations, and the lunch really helps to get people together. If you went this year then you’ll know how good it was. If you didn’t then why not? You should go next year. You won’t be disappointed.

You reached the bottom. Here’s your ‘prize’. TestBash makes people feel like this sometimes.

testbash

Experiences, recruitment, Testing

A Testers Portfolio

16 Comments

portfolio

I’ve been recruiting for both testers and developers recently and one thing that struck me was the difference between the two disciplines when it came to a body of work.

As a developer you are nothing these days without a Github account. It’s expected that you have one, that it has code in it 🙂 and that an interviewer will take a look. So much so that most developers will gladly advertise their account and repo’s on their CV.

In my most recent piece of testing recruitment I was looking for an exploratory tester and a tester with more automation skills. One automation tester was able to give me a link to her Github account; this was the first time this has happened to me when interviewing testers and was a positive thing to see. None of the exploratory testers I interviewed showed me any links to previous work; now this does not necessarily make those testers better or worse of course. However, as Rob Lambert has talked in his recent series of blog posts and e-book about ‘Remaining Relevant’, as a candidate, you need to stand out, and having a body of work can really help.

For testing it’s a bit different.

So this got me thinking – why is it that testers don’t traditionally have a portfolio?

Is it because more testers are 9-5’ers?

There could be an element of truth here, perhaps there are more testers who are less motivated by their work, with testing being a job they have fallen into rather than a career. If one is not motivated by a job then one is far less likely to want to do whatever is required to remain in that career area.

Are developers more motivated to share their work?

Perhaps there’s a bit of pride in sharing something that one has created that testers don’t have so much. For testers involved in automation, particularly framework design, then there’s something to share, but this isn’t the more general case.

Do they have more to share?

I’d wouldn’t say so, it’s just what is shared is different.

Is it more difficult to build and maintain a body of work as a tester?

I think it is. Since testing is much less about creation then it does make things more difficult. But it’s far from impossible.

What could you do if you want a portfolio of work?

Myself and Dan Ashby touched upon the idea of a testers portfolio in the recent two episodes of Testing In the Pub, where we talked about recruitment. The idea is that, as a tester, you have this body of work, either built up through your day-to-day work, or from experiences in the wider testing community, that can really help you to stand out from your peers, and help when you want to make your next career move.

You may be able to directly share what you are working on at work, but this is frequently not the case. Getting involved outside of work can instead be one key way of building up a portfolio. For example you could consider:

Writing for Blogs and Magazines

Maybe your company has a tech blog. Why not write for that? Or magazines, whether printed or online are always looking for articles. Don’t think that you have nothing to write about – all experience is relevant and there’s some great people in the testing community who will help you edit an article. You just need the idea, and an ability to type 🙂

Starting Your Own Blog

Sometimes you just want to publish something, or you want to say something that’s free from any editorial tone. Start your own blog, it’s really easy and free if you use something like Blogger or WordPress. It’s also great for raising your visibility, especially if you get your blog featured on sites like Software Testing Club or Test Huddle. Add it to the directories.

Talking At Conferences and Meet-ups

Have an idea, submit a proposal, get it accepted and then panic 🙂 But seriously, talking at a conference is a great way of sharing your knowledge, raising your profile, and getting noticed. It’s daunting at first, slightly daunting even when you’ve done it before, but also really rewarding. Conference speaking looks great in a portfolio.

Sharing Your Presentations On Slideshare

Whenever you talk, take time to upload your slides to a sharing site like Slideshare. This makes them available to all and makes you far more visible to search engines like Google. Which it turn helps you build a portfolio of work.

Pulling It Altogether

Pulling it altogether means that you build up a single portfolio. This can take place on your own website or blog and these are easy and free to put together. If you don’t mind a few advertisments then a free WordPress site is a great way to start and you can easily use a theme which makes it look more like a website than a blog.

I have also found that about.me is a good place to consolidate your information together and is widely known. Let’s also not forget about LinkedIn, although I find that it’s better to keep my body of knowledge linked to LinkedIn rather than on the site itself, which allows for more flexibility.

Having a personal brand is an often overlooked but very important differentiator when looking for a new role. It won’t make up for a lack of relevant technical or social skills, but it will help you to stand out from other, similar, candidates.

So think about your portfolio. What would you include?

—-

Update

Thanks everyone who has commented, either here or on Twitter. There have been some great suggestions on other ways you can form a portfolio as a tester. For example:

  • Use Github to store useful resources. It doesn’t have to be code. Thanks to Alan Richardson for the link to this pentest example.
  • Test an OS project that is stored on Github – thanks Michael Bolton, and also @xrisfg.
  • Taking part in activities such as Weekend Testing, podcasting, etc – thanks Dan Billing.

And thanks to everyone who commented below. I’m glad people found the article useful.

Experiences, Exploratory Testing, practices, team, Testing

Experiences Of a Testing Bug Bash

5 Comments

I’m working in a team, that’s developing a mobile application and back-end, that does not have any testers. We didn’t plan it that way, but temporarily, that’s just the way it is. While I can add my testing skills and experience to the team, that’s not the primary reason I’m there, and so I’ve been looking at ways in which the whole team can help to contribute to a quality product.

It’s been interesting. At first, when our tester left then nothing happened. Like nothing at all, tickets moved over to the ‘Ready for Testing’ column and there they stayed. Immobile, ignored and unloved. It was as if all eyes were to the left, where the fun stuff for developers was, understanding designs and coding. Although there are unit tests and some automated integration level tests for our code it clearly wasn’t enough.

Session Based Team Testing – A Bug Bash

I’ve used session based testing in the past when I managed test teams, and have found it to be a very useful way of breaking exploratory testing work into understandable pieces, and distributing that work out to the team. James and Jon Bach explain the approach far better than I can. Ministry of Testing have also got an excellent resource on SBTM.

Having read some articles from people who had broadened their approach then I thought I’d take the session based testing concept and roll it out to the whole team as a bug bash.

The key point for me was that any sort of session had to be fun. Initially I feared that not all the team were going to see the full value of such a session since it wasn’t development work per se,  so keeping the approach light-weight was key. The ideas for our first bug bash had formed.

Organisation

Getting away from the everyday work was important so the bug bash took place in a separate room, close enough to our team area that it was quick to pop out and pickup forgotten devices, etc but away from the interruptions that phones, etc provide. I made sure we had enough phones, tablets, post-it notes, pens and cake to keep us going. I also brought in some popular testing books and the Test Heuristics Cheatsheet from Elizabeth Hendrikson, in case people needed some inspiration.

We use JIRA as our project management tool and since we were testing a whole Epic then it made sense to break the testing down on a story by story basis. Working with our lead developer, we took each Epic in turn and used that to form an exploratory testing charter stored as a Google doc. You can get an example version here. Using charters enabled us to define the boundaries of the testing; ensuring there was not too much overlap. It also meant that people who were not so familiar with the story were able to quickly learn about it, and areas to test, without needing to spend time reading stories and Epics in JIRA.

So, the charters were ready, the room was ready and the people were ready. Time to start.

The Bug Bash Session

We decided on two 45 minute sessions with a tea break in between. The whole team attended; PO, designers, UX, developers and myself. Everyone was a tester for the afternoon. We agreed who would pickup which charters and made a start.

I made a Google doc in which people could record potential issues which I kept projected up on the wall throughout, so that we could all see the progress that we were making and the issues that were being raised. I encouraged the team to add screenshots as well as text and this really helped to make things clear and to prevent duplicate issues making their way into the list. Discussion was also key to the success of the session; having everyone in the room at the same time meant that potential design issues could be shown to designers straight away for review.

The lead developer for the feature was also present, not testing but helping to explain architectural and development decisions, and also to fix some bugs on-the-fly.

The session went well. We got all the charters finished and the session concluded with a quick retrospective.

Retrospective

What Went Well
Charters give structure and prevent misunderstandings

Having structure was critical to the bug bash, given that it was a new activity for the team, and they were not experienced with exploratory testing. It also meant that we got the most from the session and people were not all testing the same thing.

Hints and examples in charters are good

By including examples, and ideas on areas to test, people had a guide to start them off. Given that they were not experienced testers then this really helped.

It is good to have charters split by story

This meant that it was clear what was to be tested and there was a clear link back to the project management tool people were used to.

Some of the bugs were fixed during the session

This clearly shows the value of group pairing for me.

What Could be Improved?
Make the charters simpler

I had hoped we would get some data on setup time and test execution time so had added that to the charters but it confused most people.

Make the process of splitting up the charters and recording who is working on each one, simpler

Although it as clear to them which charter a person was working on, we didn’t keep a visible record of who was working on what. Next time I’ll write this down and pin it up on the wall.

People could swap charters halfway through the session to give multiple points of view

For each 45 minute session one person would pick up and test against a charter. Swapping round could add value and a new set of eyes onto the area.

Comments
Aim to do this for all large stories

This was great to see since it showed that the team saw the value in the approach.

Consider pairing

This will be our next step for the Bug Bash sessions. Pairing people up could help to add more value by giving multiple viewpoints.

Going off charter was a good thing

Some charters were bigger than others. People naturally started to go off-charter once their charter was done and this gave multiple viewpoints across the whole feature.

Being away from the desk is a good thing

By being one team, with one goal, isolated from our day-to-day activities, we were able to effectively test and find many issues in the feature, without the usual distractions that break concentration and flow. Having lots of cake also helped 🙂

Conclusion

We will definitely do the Bug Bash again, and I see it as becoming a really important part of our delivery processes, even when we get a full time tester back on the team. It really helped everyone to understand the feature, to explore it and to test together, giving multiple viewpoints on potential issues.

With some guidance the whole team made a great contribution. I’d encourage everyone to try a similar approach,

reviews, Testing

The State of Testing Survey 2015

1 Comment
It’s great to see thatJoel Montvelisky and the team at Practitest are running The State of Testing survey again this year. Last year they had over 640 people answering, and this year their target is to go over the 1,000 mark, to get an even better picture about what is going on in the Testing World.

Survey’s like this are really important to our community, as they give a view on where we are, our challenges and successes, and a great starting point for more discussion and potential improvement.

The survey is open and you can find it here. I’ll be filling it in, will you?

conferences, Eurostar, Testing

EuroSTAR 2014 – Day 1

1 Comment

I didn’t know what to expect from this year’s EuroSTAR conference. I’d only been once before, and so I wasn’t sure how much a different programme chair and committee, and a new venue itself would make a difference to the EuroSTAR experience. In addition I had the added pressure of being lucky enough to speak at the conference as well.

Fortunately none of the changes made a difference. It was a great conference, with some excellent speakers, fun things to do when the talks weren’t happening, and lots of opportunity to meet old friends and make new one’s. Paul Gerrard, the programme committee and the EuroSTAR conference organisers did a great job booking a varied programme and a well organised event.

Prologue

I arrived in Dublin on Sunday which meant that I was able to make it along to the early registration. This is a great idea which I hope happens next year, as well as being able to pick-up all the usual conference materials, T-shirt, etc early to save queuing, it also meant that those of us who had arrived early could easily get out and meet people. I had a great discussion with a couple of guys from Ericsson which brought back memories of my earlier career there. I was then lucky enough to bump into a number of people I knew as well. Dinner with Declan O’Riordan and Karen Johnson then followed, at which we had some excellent discussions about testing, contracting and life in general.

IMG_20141123_180430
The conference centre looked very impressive

I spent Monday sightseeing. As an ex Nokian it was great to see this 🙂

IMG_20141124_092610
Someone really needs to update their advertising…

Day 1

Day 1 started with the keynote from Andy Stanford-Clark. I really enjoyed it and it certainly made me think more about the Internet of Things, and the challenge it causes for testers. And also how I could automate my house 🙂

IMG_20141125_142120

I followed this up with Amy Phillips talk about Testing In the World of Start-ups. I’ve recently started working with a team who are effectively in start-up mode and it was very useful to hear Amy’s experiences from Songkick. The main thing I took away was that the testers role within a start-up is very different to a larger company, with a more varied skill-set required and potentially less actual testing. I feel this is the way that testing is going these days anyway, slowly but surely.

IMG_20141125_154005

My next session was from Rikard Edgren who presented about Trying To Teach Testing Skills and Judgement. It was an excellent talk, dealing with Rikard’s experience of training testers. He’s also produced a white paper with a lot more detail, that I’m going to read.

IMG_20141125_164205

The final keynote of the day was from Rob Lambert. Rob talked about Continuous Delivery and DevOps and gave us his experiences from New Voice Media. It was a good talk and built upon previous talks I’ve seen Rob do, giving more detail.

IMG_20141125_172402

Here’s my notes from the session.

IMG_20141203_084710

Then it was time to learn how to pour some Guinness 🙂

IMG_20141125_185014
Well we are in Dublin after all…
mobile, reviews

Book Review: Hands-On Mobile App Testing By Daniel Knott

3 Comments

Hands-On Mobile Testing

Something different for the blog this time – I’ve been reading a new book that Daniel Knott has published on Leanpub. It’s called ‘Hands-On Mobile App Testing‘ and it’s intended to give a good start to those in the software testing industry who are getting started in mobile, as well as those who have been in the area for a while. In fact Daniel himself describes the book as:

“A guide for mobile testers and anyone involved in the mobile app business.

Are you a mobile tester looking to learn something new? Are you a software tester, developer, product manager or completely new to mobile testing? Then you should read this book as it contains lots of insights about the challenging job of a mobile tester from a practical perspective.”

It’s a very well researched book and Daniel has clearly put a lot of time and effort into writing it. As someone who also trains testers who are getting started in mobile then I liked the logical flow through the chapters. The book starts with a chapter explaining why mobile is different and setting the scene for more specific areas that are re-visited in more detail in subsequent chapters. I particularly liked the section “Mobile Testing Is Software Testing” because it’s important to note that testing on mobile is complicated and that should not be overlooked.

Useful Information

The book contains a lot of specific technical information relating to mobile, meaning that it also serves as an interesting read for someone who may want to know more about the subject but not necessarily apply specifically to testing. The section on business models, for example, is certainly widely applicable. Keeping the information in the book updated may well be a challenge, given the pace of change in the mobile world, but by using Leanpub I hope that’s something that Daniel will do.

The Customer

I appreciated the focus that the book puts on the customer; in mobile the customer is so close, and can leave feedback so quickly, that a key testing skill is understanding them and using that understanding to drive testing. The book goes into plenty of detail in this area.

Covering Common Areas

You’ll also find some very useful information on the areas that I typically get asked about by testers who are new to mobile; areas such as device fragmentation, hardware dependancies, using simulators and automation. The book is full of helpful hints and tricks, and is also a great reference source. There’s also a whole chapter on mobile test strategy that would help both test managers and testers who are new to mobile.

Mobile Automation

Automation is an area where mobile is relatively immature when compared with desktop, and I was pleased to see a whole chapter dedicated to the subject. If you are choosing a tool, there’s some great hints on how to go about making that decision, as well as information on the current tool landscape.

Conclusion

The book then concludes with sections on important skills for mobile testers and a look to the future of mobile. Some of the important skills explained are just as applicable to software testing in general, rather than mobile specifically, but the chapter does then get more mobile specific. It was also interesting to read Daniel’s thoughts on the future; the mobile world moves so quickly that what’s future now very rapidly becomes present, and already we’re seeing some of the future technology described being available for us to test (and buy).

Overall I found the book to be a really useful addition to my library. There are not enough books on mobile testing as this is certainly one I would recommend. It’s not just about mobile application testing either, there are sections on mobile web as well as information about the mobile world in general. Hopefully Daniel keeps updates coming via Leanpub to keep it current.

If you want to know more about mobile testing then I would certainly recommend that you take a look at the book.

You can get Hands-On Mobile App Testing from Leanpub.

Note: I was provided with a free reviewers copy of the book for the purpose of writing this review.

 

 

 

conferences, Experiences, mobile, Presenting

I’m At Mobile App Europe – Day 1

1 Comment

I’m at the Mobile App Europe conference in Potsdam.

This morning I gave my presentation ‘Mobile Testing, That’s Just a Smaller Screen, Right?’ – you can get the slides on slideshare.

I’m here for the rest of the conference and I’ll try and mindmap a few sessions.

Martin Wrigley is now talking about ‘Effective QA – Is It Really Necessary?’ Hint, yes it is 🙂

image

This afternoon I spent some time in Bill Matthew’s Security Testing Workshop. I mindmapped his slides.

Next Up – Christian Kaar from Runtastic with 10 Ingredients to Rock the App Store with Your App. Here’s my mindmap.

wpid-img_20140929_140549.jpg

The first one is ‘All Together Now – Apps for the Next Platform: Making Watches, Wearables and Web Work’ which was presented by Lars Kamp. A very interesting and informative presentation about wearables.

mobile, Presenting, Testing

London Tester Gathering Workshops 2014

1 Comment

The London Tester Gathering Workshops 2014 are nearly here. Last year I had a great time at the event – it had a really inclusive feel and I learnt a lot from the sessions that I attended.

My review is here, if you want to read about how good it was last year 🙂

This year I’m running one of the workshops. It will be about Testing Mobile Software, and promises to be a lot of fun (I hope).

Want to take part in a hands-on workshop and get an overview of mobile testing? Stephen Janaway will explain some of the common mistakes that are made when starting to test mobile, and will give you the opportunity to put into practice what you learn straight away.

We are increasingly moving towards mobile devices to fulfil our day-to-day computing needs. More smartphones are sold than PCs but many people are unclear on what changes to test strategies are needed when working with mobile.

We’ll spend a majority of the session testing a mobile application across a variety of platforms, and reporting the results in real time to the rest of the group. All you need to bring along is an open mind and as many mobile devices as you can get your hands-on.

Tickets are currently a bargainous £250+VAT until 19th September, and for that you get two full days of workshops, covering everything from mobile to automation, exploratory testing to creative thinking. Well worth it.

What are you waiting for? Sign up 🙂

podcast

Episode 10 of Testing In The Pub – Interview With Tony Bruce

Leave a comment

I’ve just uploaded episode 10 of Testing In The Pub, the regular podcast about software testing which I record with Dan Ashby.

It’s an interview with Tony Bruce about testing and test communities. Tony organises the London Tester Gathering and the London Tester Gathering Workshops, as well as having spoken at a number of testing conferences and events. It’s well worth a listen.

Head over to the Testing In The Pub website to download, discover the RSS feed, or search for “Testing In The Pub” on iTunes or YouTube.

Enjoy 🙂

Experiences, practices, team, Testing

Exploring An Existing System

3 Comments

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.

Recon Testing

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 🙂

Ding ding!
Ding ding!
Easy to test?
Easy to test?

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.