Skip to main content

3 Things to a Remember While Doing Exploratory Testing!

Here is a post I found interesting... 

While doing exploratory testing it’s often difficult to decide what to start with since the opportunities abound.

In order to do it effectively we offer testers to concentrate on the three starting points to keep in mind all the way through.
Don’t follow the documentation.
Exploratory testing is something you can perform without any specification and scripted test cases. However, if such handy guides are at hand, it’s always tempting to resort to their instructions. This is the mindset you have to avoid. While checking in with the documentation, you tend to rely on their standpoints and assume the tactic of confirming that everything works as expected. Instead your role now is the opposite, because you have to find the points where the system fails. It’s better to do cross-reference using documentation afterwards. Without resorting to it you think broader, you may even unintentionally discover some undocumented implicit requirements, errors and inconsistencies in documentation etc.
Question rather than verify.
When there’s a need to test some feature, we are naturally inclined to make prove that it works properly. This inclination is likely to restrict our interaction with this feature and place in focus only its positive responses. Our mission here should start with breaking the traditional frame of mind and try to contradict the expected rather than verify it. While testing, ask yourself negative questions such as “In which case it wouldn’t work?” or “In which case it couldn’t work?” to question the expected order of things and test it properly.
Be Persistent.
Since the temptation to believe that everything works right is strong, we often give up our hunt for bugs after several tests indicating none. To test more thoroughly, here are some additional ideas to dig up more bugs:
  • Explore the type, length, formats and other properties of complex input data.
  • Test the product’s performance on computers with different capacity, in an environment under different data production quantities etc.
  • See if it’s possible for malicious users to use the given feature or its parts in non-provided ways.
  • Test it against different browsers, platforms, databases etc.
  • Check if the actions performed by several users conflict.
  • Test how the feature reacts to the missing external components.
  • Try out how different users handle the feature and what can be improved for better usability.
  • Check if non-English users understand everything and if something needs localization.
The ideas for effective exploratory software testing are infinite if you assume the given mindsets.


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 …