Our world is full of different people, cultures, and experiences. If we are building software for everyone, then it only makes sense that the teams creating and checking that software should represent that diversity.
That same critical need for varied perspectives applies equally, if not more, to our quality folk who are considering the risks that might affect the software we put out into the world.
The impact of our experiences on what we check
Every one of us brings our own unique lived experiences, assumptions, and biases to our work. It is simply part of being human. When the members of a team are largely the same in terms of ancestry, first language, and upbringing, sharing similar backgrounds and perspectives, they will naturally check for things that align with those shared experiences. This can create knowledge gaps and weaknesses, leading to bugs that could be quite obvious to someone with a different perspective but completely invisible to the team that built them.
Think about it this way: if you have only ever driven on smooth, perfectly paved roads, you might not even consider checking if a vehicle can handle potholes or rough terrain. But if someone from your team regularly navigates unpaved tracks, they will immediately ask, "How does it handle the bumps?" That is the power of diverse insights in action.
Real-world examples of what gets missed
We have seen numerous examples of how a lack of representation in development and testing teams has led to significant bugs and poor user experiences. These are not always malicious oversights, but rather a consequence of not having a broad enough range of perspectives involved in the creation and checking process.
Facial recognition technology
One of the most widely discussed examples comes from facial recognition technology. Studies have repeatedly shown that these systems often perform poorly, or even fail entirely, when identifying individuals with darker skin tones, especially women. The BBC reported on research showing how some commercial facial recognition systems had significantly higher error rates for women of colour, sometimes over 20 percent, compared to less than 1 percent for white men (BBC News, 2019). Amnesty International highlighted that research suggests the poor performance on darker-skinned faces is due to datasets used for training often being overwhelmingly composed of light-skinned individuals (Amnesty.ca). If the teams building and checking these systems do not include individuals from underrepresented groups, these critical bugs are less likely to be spotted, prioritised, or fixed before deployment.
Data input fields
Another common area where shared assumptions in teams lead to bugs is in data input fields, particularly names. Many software systems are built with an implicit (European) assumption about what a "name" should have: a first name, a last name, and maybe a middle name.
Some cultures do not use last names. Others use incredibly long names by Western standards, some include special characters, and some names might change. If a testing team does not include individuals whose names follow non-Western naming conventions, they might not think to check for issues like:
- Forms rejecting names because they are too long, like Hubert Blaine Wolfeschlegelsteinhausenbergerdorff
- Too short: Li, Ng, Bo, Jo or A
- Not allowing hyphens or multiple hyphens, apostrophes, or other common characters in names, such as umlauts (¨) and accents (´, `, ^,). Some of these characters are diacritics (marks added to letters to change their sound or meaning)
- Enforcing a "first name" and "last name" when the user's name does not have that structure
- Incorrectly capitalising names can be seen as disrespectful
- Only using one type of alphabet or character set
- Ignoring common but not specifically country or region-based alphabet or character sets, such as Cyrillic (Eastern Europe / Central Asia), Arabic (Middle East / North Africa), and Kanji / Kana (Japan)
These seemingly small issues can create enormous frustration and a sense of not being recognised or understood by the software. Emily O’Connor has an excellent article on this subject and her experiences called “Making registration easy: Understanding the complexities of online forms”. You should definitely give that a read.
Accessibility
Consider also the broader scope of accessibility. An individual who relies on a screen reader, or who navigates using only a keyboard, will interact with software in profoundly different ways than someone who does not. If a testing team does not include individuals with disabilities, or at least someone with a deep understanding of accessibility needs, critical bugs that prevent these users from interacting with the software will almost certainly be missed. These are not just minor inconveniences. They can completely block access for a significant portion of the population.
The power of an inclusive testing team
When your company and testing team are a melting pot of different genders, ethnicities, ages, abilities, socioeconomic backgrounds, and other diverse characteristics, it naturally brings a richer set of perspectives. As Riri Nagao eloquently explains, “By seeking diverse perspectives, we expand our scope of knowledge which directly contributes to logic and design.” (Riri Nagao, Medium 2024).
Testers with varied lived experiences are more likely to:
- Question assumptions: They challenge the "norm" and ask "what if?" from a different angle.
- Identify edge cases: They consider scenarios that might fall outside the typical user journey because users' journeys can differ.
- Spot unintended biases: They can recognise when language, imagery, or functionality might be exclusionary or inappropriate for certain groups.
- Champion inclusivity by design: They encourage the team to think about diverse users from the very beginning of the development process.
According to the mthree (previously Wiley Edge) report of 2023, diverse teams are more likely to be innovative and perform better. This innovation is not just about new features. It is about building more robust, resilient, and inclusive software that truly serves everyone. McKinsey’s report, Diversity matters even more: The case for holistic impact, found that companies in the top quartile for racial and ethnic diversity are 35 percent more likely to have above-average financial returns. (McKinsey and Company is a globally recognised consulting firm, founded in 1926 by James O.McKinsey, a professor and expert on management accounting who established a commitment to rigorous research and training.) These are, of course, only a couple of studies, and big Fortune 500 companies will still make profits regardless of their hiring policies and team dynamics.
Inclusive testing is more than just checking that a feature works as intended. It is about checking if it works for as many people as possible who might use it. An inclusive testing team provides that crucial lens, ensuring that the software we release reflects the world it serves.
To sum up
Building and testing software is a complex endeavour, even if we have lots of experience doing it. We strive to create products that are robust, reliable, and delightful to use. To achieve this, we must recognise that the quality of our software is intrinsically linked to the diversity of the minds and experiences of the people behind it.
Meaningful representation in teams, especially quality folks, is not just a moral imperative. It can absolutely be a strategic advantage. It helps us uncover more bugs, build more resilient systems, and create truly inclusive products. By embracing a wider range of perspectives in our investigative testing efforts, we move closer to building software that genuinely works for everyone, no matter their background or how they choose to interact with the world.
What do YOU think?
Got comments or thoughts? Share them in the comments box below. If you like, use the questions below as starting points for reflection and discussion.
- How much time do you put into thinking about other people's experience with your software?
- Have you been involved in internationalisation? If not, how much might the information here influence your approach to it now?
- What are your thoughts and takeaways?
For more information
- Biased and wrong? Facial recognition tech in the dock - BBC News 2019
- Racial bias in facial recognition algorithms - Amnesty International 2023
- Why is there still a lack of diversity in tech - Research.com 2025
- Diversity matters even more: The case for holistic impact - McKinsey report
- McKinsey and Company History since 1926
- mthree 2023 diversity reports
- Building Diverse Design Teams To Drive Innovation - Riri Nagao
