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. 

An LLM is an AI system which is basically a massive, high-speed pattern-recognition engine trained on a mountain of text. It’s not "thinking" in the way you or I do. It tries to produce what it thinks the answer would look like based on everything it’s ever read and the instructions and context you give it. For us, it’s like having a pair programmer who has read every technical manual and Stack Overflow thread in existence, but sometimes forgets to check whether the advice is actually useful, practical, or just 'out there'.  Developers use LLMs primarily as a productivity multiplier. It’s brilliant at the "boilerplate" stuff that usually bores us to tears. For example, you can ask an LLM to "Write a Python function to sort a list of dictionaries by a specific key," and it’ll spit out a working version in seconds. But it can also "hallucinate" (make things up). It might suggest a library that doesn't exist or uses a deprecated method with security vulnerabilities. You still need to be the "Adult in the room" to review the code. Rahul wrote a great piece on this subject, "Human in the loop vs AI in the loop."  For a Quality Engineer, or tester of any kind, an LLM can be a powerful tool for generating test ideas and data, as long as you don't let it drive the bus. For example, you could feed a set of requirements into an LLM and ask, "What are ten edge cases for this login feature?" It might suggest things you hadn't considered, like handling emojis in usernames or SQL injection attempts. But if you use it to generate your automated tests, it might create "brittle" code that looks right but fails the moment your UI changes. The biggest risk with LLMs, as with many things, is a loss of context. The model doesn't know your specific business logic, your security constraints, or your "unwritten" team rules, so be careful how you use it.  Use it to bounce ideas off, draft documentation, or create code snippets. It’s an assistant, not a replacement for the critical thinking and scepticism that a human brings to the party. Just because the LLM gave you an answer doesn't mean it is right, or that you can stop being a thought worker.

JIT Testing is the practice of testing only what has changed, when it changed, to keep the feedback loop as tight as possible. It means creating temporary disposable tests or selecting from an existing automation suite. More tools are using LLMs (large language models) to support this type of testing, and even security tools are using similar practices. It is important to note that this isn't really about replacing or doing less testing. It's a strategy that aims to reduce effort in some areas. Where continuous quality or testing practices are used, JIT testing aligns well.