Skip to main content

Explore/Exploit: An approach to software testing

I recently read a chapter on Explore/Exploit in Algorithms to Live By, and saw how much this concept can apply to software testing.

First, let's define what we mean by "Explore" and "Exploit" in the context of software testing.

Explore: continue to explore the software under test and look into new areas of the SUT

Exploit: Focus your attention on one specific area (or a few areas), based on your findings from the Explore part.


One of the most important factors to consider when deciding whether or not to continue exploring is to consider how much time you have remaining.

Christian and Griffiths advise, “Explore when you will have time to use the resulting knowledge, exploit when you’re ready to cash in.”


Let's say you are given one day to test a new feature. You may choose to plan your day by spending the first half of the day exploring the feature to "get a feel for it"; to see the "general state" of the feature, then you may spend the second half of the day "exploiting" a few specific areas, based on your findings in the Explore part.


It can be beneficial to be purposeful about how you spend your time so you can plan to explore and then exploit accordingly.


Recommended further reading: https://fs.blog/2020/11/explore-or-exploit-how-to-choose-new-opportunities/




Comments

Popular posts from this blog

A reflection on Let's Test 2015: Part II

Here's the link to A reflection on Let's Test 2015: Part I The sessions (Part II) Below does not include all of the sessions I went to nor all aspects of the session I mention Visual Creativity: Using Sketchnotes and Mindmaps to aid your agile testing - Dan Ashby and Christina Ohanian Before this session I stumbled upon Christina drawing out her sketch notes from the previous session and marvelled at how fascinating it was. Sketch notes were only something I'd only ever seen on the net. They were gorgeous and a clever way to communicate information. When she told me that she was going to have a session on this - I was all in. We 'warmed up' by drawing whichever image came to mind when Dan said a word. It was interesting to see how a lot of people could interpret the same word differently. For example: "Time" could be a clock, a watch or an hourglass.

Getting started on a testing project

I started on a new project a few weeks ago and thought it would be a good idea to share a checklist for what new testers on a project need and some good starting questions when you, as a tester, are new on a project Checklist for what new testers on a project need (Note, your project may not include all of the below) Note to check if user credentials are needed for any of the below

My Most Used Test Heuristics (with examples)

First, what is a heuristic? A heuristic is a guideline ,  it is fallible.  Therefore, it will give you a good idea of what behaviour you should see BUT it isn't definitely what should happen - it's up to you to confirm that the behaviour you are seeing is correct.  In a previous blog post I shared a step by step guide on  how to test without requirements/little requirements.    But I figured it's good to share my most used test heuristics that I use for testing without requirements. They are: Consistency with History Consistency with User Expectations Consistency within Product Let's take a look at each of them along with some examples to illustrate the concept. 1. Consistency with History  The feature's or function's current behaviour should be consistent with its past behaviour, assuming there is no good reason for it to change. This heuristic is especially useful when testing a new version of an existing program. (Source: developsense) Example: Whitcoulls, a