Larvae Hunting - heuristics and cheat sheet

By Gerard McCann

Larvae Hunting Background: The impact and cost of bugs is said to increase the later they are found within the software development lifecycle. Related to this is shift-left testing, an approach in which testing is performed earlier in the lifecycle and ideally with whole team involvement as opposed to just dedicated testers. The concept of larvae hunting complements these by aiming to prevent bugs, i.e. identifying larvae that could grow into bugs.

Purpose: This cheat sheet is a concise aide memoir and set of notes aimed at outlining several loosely grouped larvae hunting concepts, concrete ideas and heuristics. The aim is to offer stimulation to folks perhaps unsure of how to proceed or who are seeking new ideas. The full masterclass is available on the Ministry of Testing website with much more detailed information.

Suggested usage: Cheat sheets and heuristics work well when they are easily accessible and when they are dipped into lightly, as opposed to being pored over in a detailed fashion like a checklist. Simply stated, there is no right or wrong way to use them; usage could be as simple as briefly considering several points from the cheat sheet during a meeting which could result in a new take on a requirement, or to give inspiration to have a future meeting to discuss how several bugs could have been found earlier in the lifecycle, i.e. while still larvae.

Larvae hunting definition: “the practice of identifying potential bugs in software before the change is implemented”

Larvae hunting opportunities at a high level: scrutiny of requirements, spec and design, observation of people and their interactions, imagining of customer-software interactio

Larvae hunter skills and abilities

  • Strong product, domain and customer knowledge (helps you gain deep insight into the requirements and be able to take a helicopter view of user-system interaction)

  • Able to take a contrary/different perspective than other people involved with the project (e.g. wearing a different ‘thinking hat’ from the others, being from a different team/area, prior experience from another company, explaining the user-system requirements and interactions to someone with no/low knowledge and see what questions they ask)

  • Experiential knowledge (i.e. having almost a sixth sense about likely bug cluster points or user-system interactions that haven’t been smooth based on your tester experiences to date)

  • Ability to detect what may be missing (e.g. elements missing from spec/requirements/design, stuff that people are not talking about, maybe because they are assuming others know about it already or everyone is on the same page, are the documents accessible to all appropriate stakeholders, are they complete and up to date)

  • Willingness to take risks (e.g. daring to ask questions that people may think are obvious but no-one else has asked, to ask for additional details when people are being terse, to ask for an interactive demo of certain system elements, or that someone walk through the requirements/wireframes with you so you can deepen your knowledge in a collaborative way)

What to watch out for in specs/designs and interactions

  • Ambiguity, weasel words (like could, should or may)

  • Fudge (e.g. statements like ‘this will be resolved at a later date’, but no specifics around who and when)

  • Confusing terminology, jargon or obscure acronyms

  • Actions without owners, or indeed actions not being determined

  • Favouring the abstract over the concrete (when folks could, for example, bring up an application web page and talk through a user interaction, but instead rely on memory or explanation only)

  • Oversimplification (e.g. stating something like ‘this will need to be performant’ as that begs many questions on what precisely ‘performant’ means to stakeholders and anything to help with test planning)

  • Incorrect meeting attendees (e.g. a key stakeholder has not been invited)

  • Insufficient meeting length (which could lead to discussion getting curtailed)

  • Meeting attendees not focused or contributing to the meeting

  • Meeting follow-up not arranged

  • Meeting minutes/notes not circulated (in which case can you consider doing this if appropriate?)

  • People-pleasing (e.g. volunteering to take on more work than possible if the team is to maintain sustainable pace, work that is doable in an aggressive timeframe but which would result in quality being sacrificed)

  • Estimates being understated (meaning the team will be under pressure later)

  • Overcomplication (useful to ask if the team are operating to the principle of least surprise)

  • Views and opinions sought out and appropriately considered (as opposed to just those of the HiPPO (highest paid person’s opinion) and or where there is inappropriate deference to certain opinions)

Work culture

Start, improve or continue doing the following

Create low-friction ways to ask and answer questions, e.g. dedicated Teams channel with appropriate stakeholders for a project; include time and flexibility in your plan, especially in the early stages for handling big issues for when they are found, encourage people to speak up, to ask questions, to point out things that are not working well, basically create a psychologically safe space where the norm is there is loads of feedback as some of this may prevent bugs.

Consider stopping or doing the following differently

Stop thinking if we keep bringing up issues that it’s making work or problems for people because the issues will likely be found later anyway and it will cost more to fix then; stop requiring people to prove there is a problem, instead explore the potential issue with them and take a view on it together; stop giving negative feedback on issues unless really warranted, instead welcome issues, however small,  because if people are encouraged to regularly bring up issues, some day they’ll find something really big and important.

Other ideas

Practicehumble inquiry’, which is the fine art of drawing someone out, of asking questions to which you do not already know the answer, of building a relationship based on curiosity and interest in the other person; Keep a larvae log (maybe just as a simple spreadsheet - see example here) to help evidence the value larvae hunting has added by saving bugs from ever forming; In retrospectives take a random sample of bugs and for each ask how bugs could have been found as larvae.

Related testing wisdom

  • “Tell me and I’ll forget, show me and I may remember, involve me and I’ll understand”

  • “If you ask a question, you may feel a fool for a minute; if you don’t ask, you may remain a fool for ever”

  • “Fresh eyes find failure”

  • “The phrase ‘it works’ can be ambiguous without qualification … take it to mean ‘it appears to meet some requirement to some degree’ and figure out the specifics”

  • “Confusion is a test tool, e.g. saying ‘I don’t quite understand how this works, please could you give some more details?’”

  • “When you miss finding a larvae that later becomes a bug, consider if the miss is surprising or the natural outcome of your approach”

  • “The sooner you ask for testability features, the more likely they are to be budgeted for and scheduled into the plan”

  • “Don’t confuse speed with progress”

  • “Asking questions is safe, making statements is dangerous, e.g. how do we think a user with accessibility needs would feel if they used this part of our software?”

  • “If you become aware of any unknown problems during larvae hunting, make sure they’re visible to the team, especially bigger (potential) problems”

Author Bio

Gerard McCann, was inspired to create this having watched Jen Kitson’s Larvae Hunting Ministry of Testing Masterclass. Never in 15 years in IT have I seen a single article, presentation or idea that resonated with me to such an extent as Larvae Hunting. Simply put, it encapsulated what I’ve been trying to achieve over recent years as I’ve become a more seasoned software tester: moving from bug catching to bug prevention. It also integrated very well with and supported shift-left testing, which I’ve been trying to encourage my employer and colleagues to embrace. However, shift-left remained to me at that time somewhat of an abstract concept that was more at a strategic/tactical level. What I sought was more at an operational level, i.e. I wanted a bunch of specific actions I could take. So I was delighted as Jen’s Masterclass offered these in abundance, along with the inspiration to get to it! I’m therefore delighted to have the opportunity to share this with you and I hope it helps others in their quest to become better software testers and to add value through bug prevention!