Remember it is About People: 99 Ways Workshop #10

The Software Testing Club recently put out an eBook called "99 Things You Can Do to Become a Better Tester". Some of them are really general and vague. Some of them are remarkably specific.


My goal for the next few weeks is to take the "99 Things" book and see if I can put my own personal spin on each of them, and make a personal workshop out of each of the suggestions.


Suggestion #10: Remember it is about people. - Tony Bruce

At some point, regardless of where software is deployed, it is written to serve and benefit people. Sometimes those people are abstract, sometimes those people are present and immediately specific. In any case, no matter how deeply embedded in a system, or nested inside of middleware that maybe a half dozen human beings will ever see, real people benefit or suffer. In trivial cases, we may be talking about a momentary frustration. In extreme cases, we could be talking about fatalities. In all cases, human beings consume software and use it to achieve various means to an end. Ultimately, every feature benefits someone, and every bug has the potential to harm someone. Making this connection makes the concept of Bug Advocacy a lot more understandable, even if the term feels awkward or legalistic. All testers are advocates for customers, which is a fancy way of saying "we are the voice for real people". In many cases, we may be their only voice.


Workshop #10: Flex Your Advocacy Muscles

How can we practice advocacy? The first step is to consider any software application you interact with. Remove yourself from the equation. Who is that application for? What's important to those people? Can you visualize who those people are? Can you visualize what they will do with your application? What is their definition of a useful and successful interaction with your product? What is a genuine pain point for these people? How are they impacted by a bug that you find?


These are not arbitrary questions. These are legitimate things to consider, since the impact on one person could mirror the experience of thousands, or even millions, of people. By recognizing the potential impact of an issue, we can better make our case as to whether or not a fix is worthwhile to pursue. The fact is, not every problem can be fixed. There is a finite amount of development time, energy and resources. The development team will focus their attention on areas they are convinced pose too great a risk to not fix. How can you make the case that an issue rises to the level of attention?


One of the ways that I do this is to tie any issue I find to an easy to recognize "Oracle". An Oracle is a tool that software testers use to determine if a test has passed or failed. They can be as strong as rules of mathematics or grammar, official specification documents, and rules of law, to weaker Oracles such as personal preferences and gut feelings to what we believe customers will want to see. Additionally, there are a number of heuristics that we can use to help us strengthen our case that something we have reported could be bigger than others might believe. Some issues are slam dunks. Crashes, exceptions, etc. are usually not too difficult to argue the merits of fixing. Other areas, such as look and feel, or User Experience, are often harder to lobby for since the issues are subjective.

A famous set of "Oracle Heuristics" used in software testing is the "HICCUPPS" mnemonic. James Bach first identified these areas (Michael Bolton wrote the article that references them) as shorthand to say "this is an issue because what we are seeing is inconsistent with [History|Image|Comparable products|Claims|Users Expectations|Product|Purpose|Statutes]. Note: since the original article was published, Michel Bolton has updated and added some additional items we can use as well:

Inconsistent with [Familiarity|Explainability|World] extends the mnemonic to "FEW HICCUPPS".


Sometimes, multiple Heuristic Oracles (i.e. multiple letters of the FEW HICCUPS mnemonic) can be applied. Generally speaking, the more letters you can apply to an issue (the more places that an issue is inconsistent), the better your case that it is an issue that deserves attention.


Think about it.


"This application's buttons are strangely colored, it looks bad"


"The proximity of these two colors for background and buttons will make it difficult to differentiate for a user that is color blind. Since we advertise our high marks for accessibility, this color combination is inconsistent with our own claims, user expectations and potentially could disqualify us with some customers because of legal statutes"


Which one of these is more likely to get your attention?


Bottom Line:

Ultimately, all software is for and about people. Suggestion #1 says to know your customers, and this suggestion aims to make that connection even more personal. Internalize that connection, put yourself in your customer's shoes, and ask yourself "what's the risk if our customers come across this issue I'm seeing?"


Now go and advocate likewise.