First, just wanted to say thanks so much @jen_k for such an inspiring Masterclass! It was really interesting stuff and I’m going to go back to my company reinvigorated to shift testing left … the wonderfully catchy “I’m going larvae hunting boss, hope that’s OK!?” shall become my mantra to justify asking additional questions as inspired by your slides on “Sensing What’s Not There”!
I’ve always asked lots of questions … developers frequently comment on how many questions I ask. I always think “like what else would I be doing … heck, test execution is the easy bit … the art is preventing bugs and ensuring we’re doing the right testing in the first place! So work with me here lovery developers!” Your presentation has confirmed that whilst I am in the minority of testers in my experience by asking so many questions, the fact is that, assuming the questions are good ones, then they should be asked … and more importantly, answered!
I feel I have a very good bullsh1t detector and it frequently goes off in my job at exactly the stuff you had on your slides: ambiguity, weasel words, fudge, confusion, actions without owners, or indeed no actions even being determined. So as I say, inspiring stuff as I now feel I can push that little bit harder to get answers with the concrete justification that I’m larvae hunting … and I think I’ll start making a log of how this activity has saved a lot of bugs! So, many thanks again for the inspiration!
In terms of some examples, here goes:
- A developer recently shared screenshots with me of swagger pages as he’s building a new API that is currently only on his machine. I identified that maybe POST and PUT could be getting used in a non-standard way (i.e. per Microsoft’s recommendations). He replied that we have a simple rule: POST is for create, PUT is updates. I said that sounded like, as in your presentation, an oversimplification and quoted Einstein to him , i.e. “Everything should be as simple as possible, but no simpler” and that PUT requests are supposed to be idempotent whereas his are not, hence why they may be more POST than PUT. RESULT: a new company Wiki page will be created and the company guidance on POST versus PUT will be clarified and recorded there
- Off the back of the above swagger stuff, I identified some improvements that could be made to the swagger page and these were done before the code was pushed to an environment saving time to create bugs and update them later. The larvae were around the swagger page and how intuitive it was to use. For example, we stated “This GetEvents endpoint takes input of comma-separated values like this: meeting, review”. The larvae was that the comma-separated list has a space to improve readability, but if a space is passed to the endpoint, it considers the request as " review" which would not match “review” events
- In terms of requirements, I find so many larvae around ambiguous requirements it’s almost unreal . Same goes for missing/incomplete/out of date wireframes. Each time I insist (hopefully in the right way ) on clarifying the ambiguities and/or getting wireframes, it saves lots of hassle down the line. The best savings have been around when the developer says something like “ahhh, that’s how we want the page to look/behave, I was going to do it differently”. Big saving each time there!
- Final example, acceptance criteria. Our company had been allowing developers/product owner to write acceptance criteria. I and other testers proved the value of writing acceptance criteria during a 3-amigos meeting instead as evidenced by many instances where testing asking for additional acceptance criteria and/or additional detail in the proposed criteria which identified larvae and thus saved bugs. Brief examples are things like form/element validation that would not otherwise have been considered by the developers till bugs were created, accessibility which is almost always an afterthought by developers, but which testing push for from the get-go, and replication of issues for bug fix tickets to ensure all folks are on the same page - it seems almost crazy to me that acceptance criteria would have been created without the folks looking at the application to replicate a bug, but that’s what used to happen and the result was acceptance criteria that were superficial due to less-than-thorough application knowledge and/or assumptions about applicaiton behaviour
Thanks again for a great talk!
By the way: in terms of the Larvae Hunting Heuristics, does anyone have any thoughts on same? I can have a wee go at it if that sounds interesting? Will assume the positive and give it a go and then post here in due course sure…