| || |
Exploratory Testing / Rapid Software Testing
Hi there, my company has been pretty mush traditional-based testing ie. test cases > scripts etc however is wanting to look at bringing in exploratory technqiues. In addition we were wanting to look at perhaps sending some of of testers to a Rapid Software Tesing class.
Has anyone had experience is these areas of testing? What have you found to be the pros & cons? Are there any pitfalls to be aware of? are there better environments for exploratory testing vs traditional?
There's nothing fancy about exploratory testing, and you've probably (hopefully) been doing it already - if all you are doing is following an exact test script to the letter, without deviation, and without attempting to learn anything about the product to discover better tests, then you're not testing....
Your biggest challenge will be to ensure that your line management is on board and they understand what you are doing and why. Management loves to report stuff, and sometimes reports are distilled (rightly or wrongly) down to a couple of metrics or KPIs, so you need your reporting to be able to show that you spent 3 hours on a session-based exploratory session, rather than it showing that you spend 3 hours testing and only completed one test scenario. Getting the way that you report, and the way that your test manager reports to their manager, will be the most difficult challenge. You may need to switch from metrics to meetings, or report on functionality tested rather than lines of scripts, or move to a Definition of Done that looks at test areas.
"Exploratory" doesn't mean random, or unstructured, so you might want to look at processes and groundrules of your testing. Instead of allocating scripts, allocate functional areas and see who can find the most bugs in a given period of time. Can defects only be raised in your tracker if they are linked to scripts? How are your testers recording their progress through the app (Notepad/Word/Excel are all tools that can be used)? Where are their reports stored, and how are they reporting progress / blockers to the test manager? How will your testers report if they get caught up in exploring a specific functional area (detailed testing of an area, vs shallow but broad coverage of a wider functional area)?
Exploratory also doesn't mean unplanned or unscripted, but you might keep any "scripts" to a level of checklists, or single lines of ideas to test, or heuristics, rather than step-by-step instructions for the tester. Plans might also be as detailed as breaking down an application to single functions and allocating these to testers and sessions, or as high-level as "here's an application, you've got three weeks to find all the bugs" (true story).
Your testers might benefit from a RST class, but they can be pretty pricey. I haven't attended one, but I have attended a Rapid Software Testing for Managers class and I have to say I was disappointed, your mileage may vary.
Hi CrazyTester, you can read this book!!
this will help you a lot to understand exploratory testing!!
Thanks for the input. From what I've read isn't exploratory testing more about debugging then? Also spoke with a colleague who attended an RST course & said that the tutor spent more time lambasting ISQTB & scripted tesing than anything else so don't think we'll be doing one of those.
in my view it's more than/different to debugging however our exact thoughts/definitions on debugging may vary. I think it's important to mention that RST is a methodology which uses Exploratory Testing in it. Doing the RST will focus on RST and ET will be a part of the overall workshop.
Here's an example of ET: Evil Tester: An exploratory testing example explored: Taskwarrior
I think the best way to explain this is that with Scripted Testing, all tests are written before any 'hands-on' testing is carried out. With Exploratory testing, tests are simultaneously designed and executed, based on the results of previous tests.
Exploratory methods are not 'better' than scripted methods. They are complimentary approaches to testing.
As mentioned above, the 'Explore It!' book by Elizabeth Hendrickson is a good read. Also lots of stuffy by James Bach on his blog/ site. As alluded to above, make sure you understand the difference between 'Ad-Hoc' testing and Exploratory, as the two are often confused.
Elizabeth Hendrickson's Explore IT! is a terrific read, and is packed with real-world, easy to understand examples. She teaches you how to think about Exploratory Testing, and how to make it a regular, planned, and effective part of your testing practice.
I found it both interesting and fun.
Read my review at All Things Quality: Book: Explore It! Reduce Risk and Increase Confidence with Exploratory Testing
Full disclaimer: I've been a fan of Elizabeth Hendrickson for a long time - from her Quality Tree Software days, to her Test Obsessed blog. I've had a copy of her famous "Test Heuristic Cheat Sheet" (included in the book) pretty much forever. And on my bookshelf, I even have a copy of her Bug Hunter's Journal that she sent me many years ago.
Elizabeth asked me to review a pre-publication version of her book. That said, whenever I am given a book to review, I tell the author that I am always honest - for good or for bad. Fortunately, "Explore IT!" is one of the good ones.