During the investigation of the CounterString search issue, I noticed that the search button displayed for the form I was using did not trigger the search functionality when pressed. In this post I investigate that.
Stay on Track
When testing, you have to know what your intent is.
I have two versions of my MORIM model. One to support hands on technical testing.
- Modelling
- Observation
- Reflection
- Interrogation
- Manipulation
One to support thinking about the test approach I take:
- Modelling
- Observation
- Reflection
- Intent
- Manipulation
I removed Intent from the hands on model because, reflection leads to intent and for me it is part of the reflection process, and has already been encoded in my model that I'm exploring, and my main intent is focused when I start testing. This can be codified in a 'charter', statement of exploratory intent, or my experiment aim and possibly protocol.
Its a loose categorisation and is mainly to represent that I think more about possible intents before I start hands on work, and I keep intent in mind as I perform hand on work.
There are exceptions to this, sometimes I do make decisions to completely change track during a test session. So it isn't a 'rule'.
Stayed on Track
During the investigation of the CounterString I almost got distracted by the Search button.
I kept forgetting it didn't trigger a search.
But I pretty much stayed on track and noted it for future investigation.
Investigating the Search Button
When I did start investigating the search button - and you can see this in the video - I have to be careful about looking at the "why?" too much.
I thought I had written a full description of issues with Why? questioning, but I think I've mainly covered it in conference talks. So I'll point you at this article on The Question
I could try and identify "Why?" would this defect occur?
- possibly devices dropped out of scope and the resolutions are no longer used when testing?
But I'm speculating, and I could have no end of speculation. I need to stay focussed when testing so I consider:
- How? What? When? Who? Where?
What?
- expected search button to trigger a search but it doesn't
When?:
- between resolutions of 768px and 1012px
- when the search input field is present
- when I try to click the search button
Who?
- user using the site
Where?
- Don't know if browser is important
- have seen on both Chrome/Mac and Tablet
How?
- don't know yet
JavaScript?
I first look for JavaScript errors thinking it might be a cross-platform issue with Chrome because it is an obvious problem so perhaps it does work in some environments and I'm using one where it doesn't work.
I don't see any errors in the console.
HTML?
I look at the structure of the HTML and the button is a normal submit button.
When I look at the form the input field is part of.
The submit button is not part of that form, so it won't submit it.
Could it work?
Since I'm in the DOM I can actually conduct experiments.
- drag and drop the button into the form
At which point I can see styling issues that the CSS doesn't handle the button in the form.
And I see that the form will now submit when the button is pressed.
Investigation Ends
At this point I have enough information to discuss the defect, and can even propose a fix, with the caveat that fixing it will also require styling changes to maintain the visual integrity of the page.
Summary
- identify intent prior to testing
- keep your intent focussed as you test
- note down temptations that will take you off track - questions, todos, ideas, defects
- prioritise and use the temptations in future time boxed testing sessions
- focus less on "Why?" and more on "How?" during your testing
The Video
In this video I investigate a secondary defect on Github that I found when creating a demo video for my CounterString Chrome Extension.
You will see:
- using chrome dev tools to support testing
- using Chrome Mobile Simulator to check layout
- manipulating the DOM to create a 'fix'
- using Chrome Dev Tools Console to check for JavaScript errors
Top comments (0)