Joep Schuurkes (Posts about exploratory testing)https://smallsheds.garden/categories/cat_exploratory-testing.atom2023-11-26T10:50:52ZJoep SchuurkesNikolaSolving Black Box Puzzle 31 with data analysishttps://smallsheds.garden/blog/2019/solving-black-box-puzzle-31-with-data-analysis/2019-04-28T13:16:34+02:002019-04-28T13:16:34+02:00Joep Schuurkes<div><p><a href="https://twitter.com/workroomprds">James Lyndsay</a> has created a number of amazing <a href="http://blackboxpuzzles.workroomprds.com/">Black Box Puzzles</a>: tiny applications that challenge you to figure out what they do. (You can support him in creating more of these at <a href="https://www.patreon.com/workroomprds">his Patreon page</a>.) Two of these Puzzles, <a href="http://blackboxpuzzles.workroomprds.com/puzzle29/">29</a> and <a href="http://blackboxpuzzles.workroomprds.com/puzzle31/">31</a>, not only have a GUI to explore, but also an API.</p>
<p>And that gave me an idea. If you explore these Puzzles through their GUI, you start from the inputs. You try out different inputs in the hope of discovering a pattern in the outputs. And then that pattern feeds back into your exploration.<br>
With an API, however - and because of the nature of Puzzle 31 - it becomes easy to get the outputs for all possible combinations of inputs. Which means you can start your exploration from the outputs instead of the inputs.</p>
<p>Before I tell you how and what I did, three important remarks.<br>
First of all, I will be spoiling the solution to the Puzzle in this blog post. So this is the right moment to go and solve <a href="http://blackboxpuzzles.workroomprds.com/puzzle31/">Puzzle 31</a> for yourself first. Or at least go play a bit with it, so you have an idea what the inputs and outputs are.<br>
Secondly, I had already solved the Puzzle through the GUI a few months ago. So it was more of a "Can I find the solution this way as well?" than a "Can I find the solution?" thing.<br>
Finally, the code and the spreadsheet I created (linked throughout, also available on GitHub <a href="https://github.com/j19sch/blackbox-puzzle-31">here</a>), are not very clean. I thought about tidying them up, but my two reasons for not doing so are (1) laziness; (2) the way they are now gives a more honest picture of what I did.</p>
<p><a href="https://smallsheds.garden/blog/2019/solving-black-box-puzzle-31-with-data-analysis/">Read more…</a> (18 min remaining to read)</p></div>Some thoughts after attending the 'Getting a Grip on Exploratory Testing' workshophttps://smallsheds.garden/blog/2012/some-thoughts-after-attending-the-getting-a-grip-on-exploratory-testing-workshop/2012-04-29T19:55:30+02:002012-04-29T19:55:30+02:00Joep Schuurkes<div><p>About two weeks ago I attended <a href="http://www.workroom-productions.com/">James Lyndsay</a>'s 'Getting a Grip on Exploratory Testing' workshop in Amsterdam. So it's about time to write something about it…</p>
<p>Now one of the things I dislike about workshop blog posts is that people will say "It was great! And person X is such a good trainer!" without saying much about the content of the workshop. However, I find myself now writing this post and thinking: I shouldn't post a full summary of the workshop. Not that it would spoil too much for any future attendee: most of the workshop consists of exercises and discussion. But posting a summary of the workshop that James has put a lot of effort in to create, just doesn't feel right. So let me just say this: the workshop was great and James is such a good trainer! :-D</p>
<p>Now that's out of the way, there are a few things from the workshop I'd like to share. Of course, the usual disclaimer applies: these are my thoughts on what was presented during the workshop. Any misrepresentations are my responsibility.</p>
<p><a href="https://smallsheds.garden/blog/2012/some-thoughts-after-attending-the-getting-a-grip-on-exploratory-testing-workshop/">Read more…</a> (4 min remaining to read)</p></div>The irony of scripted testinghttps://smallsheds.garden/blog/2012/the-irony-of-scripted-testing/2012-04-09T23:16:17+02:002012-04-09T23:16:17+02:00Joep Schuurkes<div><p>A bit over a week ago, <a href="https://twitter.com/jamesmarcusbach/status/185816224075227137">James Bach posted on twitter</a>:</p>
<blockquote>
<p>"This video shows a nice simple contrast between heavy scripted testing and exploratory testing <a href="http://youtu.be/PxTqjAwM2Pw">http://youtu.be/PxTqjAwM2Pw</a>"<br>
- James Bach (@jamesmarcusbach) March 30, 2012</p>
</blockquote>
<p>So I watched the video, hoping to see something that would make me go 'Cool!', but instead I went 'Hmmm.'</p>
<p>First let me say that this video does get a few things right:<br>
- Exploratory testing can be structured by using charters.<br>
- Exploratory testing allows you to easily change your test approach based on your test results.<br>
- Exploratory testing is very adaptable when confronted with inaccurate or changing requirements.<br>
Yet notice how the above only talks about exploratory testing, because for every thing the video gets right about exploratory testing, it gets something wrong about scripted testing – or rather about how scripted testing works in practice.</p>
<p><a href="https://smallsheds.garden/blog/2012/the-irony-of-scripted-testing/">Read more…</a> (4 min remaining to read)</p></div>