Strengths, Weaknesses, Opportunities, Threats (SWOT). Four boxes, often in a grid. Can be used individually or for teams. I'd guess some of you have sat through a workshop where someone's drawn it on a whiteboard or handed out sheets, excited to discover root causes, gaps and productivity gains. So why does it so often end up as a box-ticking exercise, particularly for teams, rather than something genuinely useful? If it isn't familiar to you, you may have done something similar with 'What's going well, what's going wrong, and what could be better?' That and similar exercises are essentially watered-down versions of the original SWOT that came from the Stanford Research Institute in the 1960s.  Strengths and Weaknesses look inward. What are we good at, and where do we fall down? Opportunities and Threats look outward, at the world beyond the team or the product. That split matters more than it gets credit for. It's easy to fill the grid with things you already believe about yourself and never actually look deep inside. I'm the same. One done for me looks very different to one done as part of a team.  I've sat in sessions where the "weaknesses" box got suspiciously thin because nobody wanted to be the one writing something uncomfortable down in front of the boss. No one likes admitting weakness. No one likes openly criticising or questioning colleagues. But that's not a SWOT problem. That's a psychological safety problem. In my opinion, it earns its keep first when you are honest, and then when it is used as a starting point for conversation rather than just an answer. Whatever is captured is worth nothing unless it is the truth, and until someone asks what we're actually going to do with that information. 

Work in progress, or WIP, means exactly what it says. Work that's in progress. Started, not finished, sat somewhere in the middle. Simple enough, in theory. But there's more to it than that.  Where it gets interesting, or annoying, depending on your team, is WIP limits. That's a deliberate cap on how many things can be "in progress" at once, originating from Kanban and lean manufacturing. In my experience, most teams have a WIP problem because everyone's trying to help, everyone picks something up, and suddenly there are fourteen tickets half-finished and nothing actually shipped. Because busy isn't the same as done, is it? A WIP limit forces a choice. Finish this thing, or you can't move on. I can't remember when I came across the saying "stop starting, start finishing". I believe it is an Agile principle, or it was originally linked to Kanban, but I'm not sure. What I do know is that for a long time I had a post-it note on my desk with it on, and it helped me focus on the work in front of me.  So next time your board's heaving with WIP, don't just ask what's blocked. Ask why so much got started in the first place and how we can improve the process.

Two factor authentication, or 2FA, is a security process where a user provides two distinct forms of identification before gaining access to an account, system, or application. In identity and access management (IAM) architectures, 2FA acts as a security gate within the authentication workflow, enforcing multi-layered defence.Authentication Factors look to combine two distinct pieces of information. A knowledge Factor, which could be passwords, PINs, or secret answers. A possession Factor, such as One Time Passcode (OTP), secondary apps e.g., Google Authenticator, Authy, etc.  An Inherence Factor is something you are. Your biometric data for Face ID, a fingerprint scanner, or even iris scans for secret agents or super villains!  For testing, you can mock 2FA endpoints in non-production environments to avoid dependencies on third parties. In automation, secret keys can work in test environments to generate valid OTP tokens within end-to-end UI tests. You can also implement conditional test configurations or feature flags (e.g., test-only OTPs or environment-level 2FA bypass) specifically for CI/CD pipeline runs.

An OTP is an automatically generated and secure numeric or alphanumeric string of characters that authenticates a user for a single transaction or login session.  Unlike the usual run of the mill passwords you use to log in to a site or app, an OTP (One Time Passcode) is valid for one use only. They are sent to previously provided details such as a phone number or email address. They typically expire after a short duration. Something like 1 to 5 minutes is typical, but some can be 10 minutes. It serves as a second layer of defence in Two Factor Authentication (2FA) and Multi Factor Authentication (MFA). They can also come from authentication apps or be physical hardware tokens. 

Artificial Intelligence is the broad science of making computers mimic human decision-making and problem-solving. It is a nested family of technologies. At the outer edge, you have general AI. Inside that, you find machine learning, where systems learn from patterns in data. At the very centre, you have deep learning. It tries to mimic the human brain using neural networks. AI is a powerful tool, but it is not a replacement for human thinking, nor is it ever likely to be. It is brilliant at finding patterns in mountains of data, giving simple answers to complex questions (context depending, of course), but it lacks common sense and empathy. Our job is to bridge that gap, ensuring that AI is safe and reliable. 

Default thinking is the natural, preferred approach for a tester when they look at a problem. It is the familiar path the mind takes based on its knowledge and experience. Everyone has their own starting point that feels comfortable. Whatever it is, it is just the first step of thinking. Default thinking is not wrong. It is a habit, shaped by experience, that develops over time. The important part is recognising that this first step is only the beginning of thinking. Testing becomes deeper when you think from different perspectives. Once you pass your starting point, you can choose to explore in other ways. There are many mindsets to learn, and you can strengthen your thinking with practice. The aim is not to remove the natural tendency. It is to expand it. When you understand your default, you can use it as a starting point rather than a place to stay. This gives you the freedom to choose the mindsets that best fit the problem.

Imagine driving with a GPS that updates every second versus one that recalculates every ten minutes. Both eventually get you to your destination, but one helps you correct mistakes almost immediately. Feedback density is how frequently your team receives useful information that helps it make better decisions.This is what feedback density is. It is the amount of useful learning a team generates over a given period of time. A team with high feedback density learns continuously through questions, reviews, testing, monitoring, and collaboration. A team with low feedback density spends the same amount of time working but learns much later, making mistakes more expensive to fix.Hanisha Arora

A dark pattern is a horrible thing. They are designed in forms and journeys to trick you. It is the practice of prioritising business over user experience by using underhanded means. Instead of helping the user complete their journey, the design exploits cognitive biases to steer them toward choices that benefit the company's bottom line. Here are a few examples. Pre-ticked boxes: This is a classic trick when a box is already ticked for you by default. It assumes you want to agree to something. It could be simple marketing emails, but the worst ones are when the opt-in costs you money. Visual misdirection: This happens when a company uses larger or brighter buttons for the action it wants you to take. The opposite or negative option may be a duller colour or smaller in size. Confirm shaming: This is the emotional manipulation side of dark patterns. Instead of a simple 'No' button, you are forced to click language like 'No. I am happy to pay the full price, or 'Are you sure you want to pay more later?' It is designed to make the user feel foolish or guilty for making a logical financial choice. When you are refining a user story, look closely at the wireframes and acceptance criteria. If you see forced choices or sneaky visual weight, raise a red flag. Quality is not just about checking that the code functions. It is about checking that the software treats the user with respect. Dark patterns might boost short-term numbers, but they destroy long-term trust. 

The Testing Mindset (in my humble opinion) is an umbrella term that covers a number of different mindsets, or ways of thinking about a subject. As I said in my September 2025 article (see reference), "From the beginning of my software testing career in 2003, I’d repeatedly heard about the ‘tester's mindset.’ There were very few actual definitions and none that I felt fit well. I did some research to see if someone specific coined the term, but it is more likely that it evolved over time." In that article, I suggested that, as testers or quality professionals, we should have more than one mindset. I gave 11 examples of software testing mindsets, and since then, I've added another. I asked in the article for people to suggest their own or expand on them. Maybe you can add to this glossary term with your own ideas and mindsets. Or, you may see it differently, which is great. Debate pushes the craft forward. Here is the latest list as of April 2026. They are now grouped and I hope to share them as a model in the future.  Visionary and open Blue-sky (innovator)  Creative (visionary)  Exploratory (investigator)  Inclusive (ally)  Analytical and grounded Scientific (realist)  Sceptical (analyst)  Critical (evaluator)  Risk-based (strategist)  Philosophical and connected  Ethical (moralist)  Holistic (connector)  Collaborative (partner)  Dark and aggressive Malevolent (saboteur) 

Grey box testing is a method where the tester has partial knowledge of the application's internal structure. It is the middle ground between black box and white box testing. You might have access to the database schema or the API documentation while you test the user interface. This allows you to write better test cases because you understand the underlying logic.It is particularly useful for integration testing where you want to see how data flows between different components. During refinement, you might use your knowledge of the system architecture to identify specific risks. By looking at the acceptance criteria and the technical design, you can ensure that the tests cover both the user journey and data integrity.It helps to find bugs that a pure black box test would miss, such as a record not being updated correctly in the background or an API returning more data than it should. It is a smart way to test because it combines the user perspective with technical insight. You aren't just clicking buttons. You are verifying that the entire system is behaving as it should. 

Sad-path testing is a very general term to cover testing the unexpected. It involves verifying how an application behaves when it receives invalid data or encounters an error. It is the direct opposite of happy path testing, which only follows the intended user journey. When you perform sad-path testing, you are checking that the system handles exceptions as required. This often means looking at acceptance criteria to see how the system should respond to incorrect logins. timed-out sessions. or empty fields. It is a critical part of making a product robust and reliable for real users. You are essentially trying to find where the logic breaks down when a user does something unexpected. By identifying these scenarios during refinement, you can ensure the developers build in proper error messages and recovery steps. It helps to move beyond basic functionality and ensures the software can handle the messiness of the real world. As a general term, it can cover many areas, but is a simple way to explain testing if for more than confirming software does what it is supposed to do. 

A backlog refinement is when the team gets together to review the work waiting in the queue. It is the time when a user story is reviewed to make sure the requirements are actually understood by everyone. You can spend this time adding acceptance criteria, so there is no confusion about what 'done' looks like. 3 Amigos sessions are similar but a more focused deep dive, with a smaller group which can include product owners or people not directly involved with the team. It can also be when you break down larger requirements into smaller, more manageable user stories or tasks. You are effectively checking that the user story or requirement is solid and good to go. This prevents the team from picking up a ticket in a sprint and then realising they do not know how to start, or will know when they are done.