Skip to main content

What Are My Main Aims to Exploratory Testing?

The key questions that come up are: what is exploratory testing and how should we do it?

Exploratory testing helps test analysts and others involved in the testing field ensure systems and applications work for their users. Exploratory testing is often misunderstood as an approach but there a number of pointers you can follow to ensure you’re on the right track.

Here are my top 10:

1) Focus on goals

Why would we not have them?

Exploratory testing helps you exercise a system like a user while actively looking to identify bugs. having set goals will maximise the value of your testing and complement other testing methods.

2) Plan ahead

Following a script is not exploring the software. Exploratory testing stills needs an element of control so plan out what you want to achieve.

3) Don't over do it

Its not about coverage stats! it’s to find the defects and issues in a system that you won’t find through other forms of testing.

4) Is exploratory a skilled activity?

Yes.

Exploratory testing needs a greater level of testing skill and experience than other testing techniques. You are explicitly using and relying on the skill of the person doing the testing, so make sure they are the best you can get.

5) Record your results

Always document what you did and what you found. This will give you an indication of how effective the session was, allowing you to optimise the process in the future.

6) Use exploratory to complement your automated tests

Automated testing checks a system performs as the development team thinks it should, according to the identified needs. Exploratory testing checks the system performs as a user might expect.

7) Performance and non-functional testing can be exploratory

Its proven that early and often performance testing can be of great value to a project.

Look at the performance on integration and functional testing environments. For me we have found bugs early and proven that the earlier you start manual inspections the earlier you can plan for future phases.

8) Choose your techniques

There are many ways to approach your exploratory work! Done just wander aimlessly around software... Get Googling! for me the book by "James A. Whittaker" is fab!

9) Exploratory testing is NOT User Acceptance testing

User acceptance is a testing activity that can (and probably should) be performed in an exploratory testing way. Don’t confuse the way of working with the type of test required.

Exploratory testing isn’t a phase of the development life-cycle; it’s an approach and technique that you should use throughout the life of the project.  As soon as your bits of a system under development have a testable flow through them, you must test that flow.  Exploratory techniques are a good way of doing that quickly and with high value output.

10) Lets not go mad on tools usage

There are many different tools you can use to do exploratory testing, from fully automated video capture and logging tools, to planning tools, to walls full of process diagrams and feature descriptions with accompanying time box plans. However, the only tool you really need to do exploratory testing is a pen and some paper.

So, from what i have learnt, whether research online or in books and also from colleagues these are some brief pointers for exploring software.

In August I'm going on an "Exploratory Testing" course and will be sure to blog the results!



Comments

Popular posts from this blog

My Testbash Brighton 2017 Notes

This was my second Testbash... if you ever get the chance in the future these conferences are a must!
I took copious amounts of notes from the 9 talks and tried to highlight my key takeaways here... hope they make sense but please comment if you have any questions :-)
Amy Phillips - Continuous Delivery
A survival guide to joining a fast paced environment/project…
Where does testing fit within Continuous delivery:


As highlighted, basically from start to finish…
There are lots of things we can do when joining a project that is using Continuous Delivery but one of the main points from this talk was to do your research! There should be an element of "Continuous" in every aspect of the project.
·Learning the ling, what's the difference Continuous Delivery, Continuous Deployment, Continuous Integration, Continuous design, Continuous Improvements etc.? ·Understand what your role in the project is going to be ·Understand the teams values, What's going well and maybe what the team p…

Is TestBash an Invaluable experience?

Over the last few years, I’ve attended four single track conferences at TestBash Brighton and Manchester. Most recently, September 2018 and April 2019.

One of the most common questions I get after the conference is, Was it worth it? Especially now given, I’m a contractor, and I attend at my own expense.

In short, Yes It’s definitely worth the trip!

That leads me into my question; does a single-track conference work for me, or could I get more out of TestBash?

Of course, there are pros and cons, some talks may not be as engaging, but this is no disrespect to the speakers, for me, it’s because I probably favour certain subjects and I’m pretty sure others will think the same.

Do I make the most of what’s on offer at TestBash? It pains me to say, No! I don’t make the most of the events leading up to and post the single-track conference so I could get more from the week.

TestBash offers master classes on automation. A full day of workshops. Test.bash() with talks on automation and technica…

The way we work shouldn’t be ‘Alien’ anymore, Should it!?!?

It’s been a good while since I have written anything (Mainly because I’m not that good a writer) but given my 16 months in the public sector I thought it was time… 
For a good number of years now the DevOps trend has given rise of buzzwords and methods aiming to speed delivery and it’s now an assumption of mine that most organisations are au fait with the term ‘Continuous Delivery’.
I was wrong…
Within the organisation that I am currently placed I believe I have a high-functioning collaborative team who work flexibly and in continuous cycle. We also involve the users which is a huge benefit to the development teams, but that’s not saying we get everything right 100% of the time! Teams must continue to learn and evolve to remain productive.
Our team work in one of several delivery groups and with this comes multiple challenges; Silos No single environment strategy lack of communicationsVaried ways of working.  And thats just to name a few, which is interesting when all delivery groups …