Magic values are values hard-coded directly in your tests without any code extra comment or context. These values make your code less readable and harder to maintain. Magic strings can cause confusion to the reader of your tests. If a string looks out of the ordinary, they might wonder why a certain value was chosen for a parameter or return value. This type of string value might lead them to take a closer look at the implementation details, rather than focus on the test.

 A stub is a controllable replacement for an existing dependency (or collaborator) in the system. By using a stub, you can test your code without dealing with the dependency directly.

Impostor syndrome affects a variety of individuals. If you suffer from it, you have an ongoing sense that you are not good enough, leading you to see yourself as a fraud. You become anxious about being discovered as a fraud when you are not in fact a fraud! Even with achievements, skills, and proficiency, self-distrust can arise, causing individuals to question their capabilities and attribute their achievements to mere chance, timing, or external influences. Over time they can completely lose faith in their ability to do their jobs. 

Testionary is a team game based on Pictionary, adapted for software testing vocabulary. If you've never played Pictionary: it's a party game where one person draws a word or phrase on a whiteboard while their teammates race to guess what it is. The drawer can't talk, write letters, or use numbers. That's it. The fun comes from terrible drawings and wild guesses. Here's a quick overview of the full Pictionary rules. Testionary keeps that core idea but swaps regular words for software testing terms. One person draws "regression bug" or "Friday deployment." Everyone else shouts guesses. The game uses 5 categories: UI elements, common issues, user actions, testing concepts, and fun scenarios. You can generate words fast with an LLM or write them on sticky notes during the game. It works for meetup icebreakers, team building sessions, onboarding new hires, or any moment when your group needs energy and connection. You don't need drawing skills. You don't need testing experience. You just need a whiteboard and a willingness to laugh at yourself.

Couple of definitions floating around at the moment.  The process of analysing an AI-generated output to infer the prompt that could have produced it. Also called prompt reconstruction. The AI asks you questions first instead of writing the prompt yourself. Also called AI-led prompting.

Crisis Engineering is a field guide and framework for leading through high-stakes, chaotic meltdowns—such as IT system failures or organizational disasters—to transform them into lasting improvements. It involves proactive sensemaking, identifying crisis signals, and using hands-on tools to move from chaos to resilient, strengthened systems. 

QA usually owns the automated tests. When a company mandates a level of automation, QA spends a part of their time growing the number and scope of the automated tests. Over time, maintenance of these tests can become expensive, and most of a QA teams time can be spent maintaining the existing automation while adding all new tests into the automation. This becomes a perpetual treadmill of building test automation that can take time and energy away from other valuable QA tasks such as design and specification review, functional testing, exploratory testing, interactive testing, etc. "Now, here, you see, it takes all the running you can do, to keep in the same place" - The Red Queen, Through the Looking Glass

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. 

A Sandbox is an isolated environment used to safely run, test, or experiment with software without affecting live systems, real users, or production data. It provides a controlled space where changes can be made, code can fail, and unexpected behaviour can be explored without risk outside the sandbox. For example, a team building an online checkout feature might use a sandbox version of their application to test new payment logic. In the sandbox, testers can create fake users, place dummy orders, and deliberately trigger errors like failed payments or timeouts without charging real customers or impacting the live website. Once the team is confident the change behaves as expected, it can then be safely promoted to production. 

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.