I’m assuming this is a piece of software/website/app (I’ll use “software” from now on) that I’ve been testing and am generally familiar with, and that a feature has been added and tossed to me to examine.
As an exploratory tester, the first thing I’d do is grab a mug of tea because the next hour will be frantic!
I’d start to explore by simply using the feature as I believe the end user would. If it’s obvious how to use it, then fine; but if not, we have a potential UX issue. Is it just me? To make sure, I’d make a note that we may need some beta testers to give honest feedback about the affordance of the feature.
As work through the feature, I’ll be making notes about all the options and alternative paths I can take, any input fields, if there’s a breadcrumb trail, any confirmations that pop up, etc. Unless something is obviously wrong, I’m not looking to find problems at this point; merely mapping the territory and noting what it contains. I just want to know what it is supposed to do.
I also want to know about the logical states the feature seems to embody, what triggers the transitions between states, and how they flow together. I also want to know what conceptual entities are apparent, and what attributes they contain. This is all to check consistency later, and also to see if states and entities can be manipulated during reasonable use into becoming in some way unreasonable.
I also need to know if the feature can be used as a guest, or if the user must be logged in. These are important meta states. Is the feature different for guests and logged in users? Should it be? Can I only do things as a guest that are logical for a guest to do, and vice versa?
Assuming all is well, I will now revisit the feature from scratch armed with what I know. I’ll use the feature again, but initially, I’ll seek to explore how it knits into the rest of the software to see if there are any problems there, such as data format or validation issues.
Next, I’ll check basic input field validations and so on, just to see if the feature catches them and if anything obvious pops out. I’ll also methodically click all the links to find dead ones, or ones that go to the wrong place. People find all this stuff tedious, but I find it exciting to be the first to discover a 404. It’s all surface stuff, but it only takes a few minutes.
I’ll want to see what happens if I do unexpected things that the user might reasonably do because they’re a user. I might click the browser’s back button or the device’s back button, for example. You’d be surprised how many pieces of software I’ve tested that can’t handle simple yet unexpected state transitions like that – especially during lengthy searches or database updates over bad connections where the user becomes impatient!
If there’s a breadcrumb trail, I’ll methodically click elements of it at different stages of the flow through the feature to jump to potentially unexpected places. Where do they take me, and what’s the functional result? Does one jump re-run a database search, but with the wrong or no data leading to an error? Do the cookies become corrupt leading to an error? Does functionality get retriggered inappropriately? (I recently tested a site where the happy path saw customers having a necessary base system automatically added to their cart, and then adding options to it, but jumping back to the wrong place in the breadcrumbs added a second base system to the order, and a third, and so on)
Let’s assume everything looks OK, the feature is basically robust, and does what it says on the tin.
It’s time to be a complete A-hole. Field validation triggers when I click away from a field, but what if I tab away? What if I use the browser’s back and forward buttons, discover the field is still filled when I return, and then click another field? Is validation still triggered orhave I got invalid data into that field? What if I copy and paste invalid data? What if I must input my name and insist it is Jon O’Malley? Can the validation handle my proud Irish heritage? What if I don’t have a mobile phone? What if I prefer you to contact me on a landline at work, with the wrong number of digits or some invalid characters involved because there’s an extension number?
What if I double click a button by mistake? (I recently locked myself out of a travel site by doing that on a search button – wall-to-wall application errors ensued instead of the homepage until I cleared cookies!)
Whoops! Time to pick the kids up! What if I suddenly close the software while in the feature and try to come back to it later? Oh no, I’ve gone into a tunnel and lost connectivity! What happens when I get it back?
And so on and so forth until the clock runs out.
Hopefully you can see the way I’d approach this as an exploratory tester is that every shift in emphasis is a little mini charter, covering a logical aspect of the feature. Every little series of tests either passes, exposes a “That’s odd” moment to explore further, or highlights a problem to report. Done this way, you can organise things to make sure you get maximum coverage in the time allotted with minimum time lost to planning.
This is obviously a hypothetical answer to a hypothetical question, but it felt good to get it down on paper. I think a t-shirt is called for: “I’m not crazy. I’m an exploratory tester!”
