Fake time, also called mocked time or a fake clock, is a testing technique where the software reads the current time from a controllable time provider instead of the real system clock. Tests can then speed time up, slow it down or jump to a chosen date, so time-dependent behaviour can be checked without waiting for it to happen. Why it matters: Many applications depend on time in complex ways. Tests run far faster than real use, so features that unfold over hours or days, such as request expiry or multi-day transaction processing, can be inaccessible or behave oddly under test. Controlling time makes those scenarios reachable and repeatable. In practice: Teams replace direct calls to the system time with a central time provider that tests can adjust. The change must be consistent across every component in the tested environment, which gets harder moving from unit to integration to end-to-end tests.Examples: Moving the clock forward three days to check that a banking transaction completes and its status changes correctly. Reducing an hour-long session expiry to a few seconds so a negative test for expired tokens can run straight away. Setting the date to 29 February or the night clocks change to find leap year and daylight saving bugs. Common pitfalls: Faking time in one service but not another, so components disagree about the current time and produce failures that never happen in production. Leaving hidden calls to the real system clock in the code, which quietly bypass the time provider and make tests unpredictable. How do you test code that depends on the current date? Pass the time in from a provider or clock object that tests can control, rather than reading the system clock directly, then set it to the dates you need to check. Is fake time the same as slowing down a system? No. Fake time usually speeds tests up, while slowing parts of a system down, such as simulating a slow network, is a separate technique for exposing timing failures and race conditions.

Symptom-based alerting is an approach to production alerting where alerts fire on problems users actually experience, such as failed journeys or slow responses, rather than on internal causes such as high CPU or memory usage. It is sometimes described as alerting on symptoms, not causes, and is a common way to reduce noise in monitoring. Why it matters: A server running at 90 percent CPU while users have a flawless experience is just a data point, not an emergency worth waking someone for. Alerting on symptoms keeps attention on user experience and business impact. It also guards against alert fatigue, because each alert points to something that genuinely needs a response. In practice: Teams start by asking what failure looks like for the user and how they would know it has happened. They then build metrics and synthetic monitors around key journeys, such as sign-in, search or checkout, and alert when those degrade. Cause-level metrics such as CPU or queue depth are still collected, but they are used for investigation through observability tools rather than for paging people.Examples: Alerting when the share of completed checkouts drops sharply, rather than when a database server reaches a memory threshold. Paging the on-call engineer when a synthetic monitor of the login journey fails repeatedly from several locations. Raising an alert when basket abandonment rises above its usual level for an hour. Common pitfalls: Treating green infrastructure metrics as proof that everything is fine, when users may still be unable to complete key journeys. Choosing symptoms so broad that an alert fires without giving any clue which feature or journey is affected. Does symptom-based alerting mean ignoring infrastructure metrics? No. Infrastructure metrics are still useful for diagnosing why something broke. They just are not the main trigger for waking people up. How can testers help with symptom-based alerting? By bringing questions about how a feature will be known to be working in production into refinement, so user-focused metrics and alerts are part of the definition of done.

Boilerplate code, often just called boilerplate, is repetitive, standard code that has to be written for a program or framework to work but contains little logic of its own. In test automation, boilerplate includes initial class structures, setup and teardown methods, imports, configuration and the simplest unit tests. Why it matters: Boilerplate takes time without adding much thinking. Setting up the initial classes and architecture of a new automation project can take days, even for skilled programmers. That time and tedium is one reason teams look for ways to generate or reduce boilerplate, so effort goes into the tests that matter. In practice: Teams reduce boilerplate with project templates, code generators, base classes, shared libraries and IDE snippets. AI coding assistants are increasingly used too: you describe the task in plain language and the assistant drafts the initial code in seconds, which the tester then reviews and adapts. This helps overcome the fear of a blank page, but the output still needs checking.Examples: Creating page object classes with the same constructor, locators and wait logic for every page in a web application. Writing a client class with create, retrieve, update and delete methods for each API endpoint under test. Writing basic unit tests that check getters, setters and default values for a simple class. Common pitfalls: Accepting generated boilerplate without review, so outdated library calls or poor structure become the foundation of the whole framework. Copying and pasting the same boilerplate across many files instead of moving it into a shared base class or helper, which makes later changes slow and error prone. Is boilerplate code bad? Not in itself. Some boilerplate is unavoidable and keeps code predictable. It becomes a problem when it is duplicated widely, hides the important logic, or takes up time that would be better spent on designing meaningful tests.

Open source software (OSS) is software whose source code is openly and freely available for anyone to use, study and modify, usually under a licence that sets out the terms of use and contribution. It is typically built and maintained by a community of contributors working in a public repository on a platform such as GitHub. Why it matters: Open source projects depend on collective effort, and they need testers, designers, technical writers and translators as well as developers. For testers, contributing is a practical way to build real experience, learn tools such as GitHub and the command line, meet mentors and create a public portfolio that hiring managers can see. In practice: A project usually has maintainers who lead it, contributors who help in any way, and community members who use it and give feedback. Newcomers start by reading the licence, README, code of conduct and contributing guide, then pick a task. Testers often test pull requests before they are merged, report and triage issues, write test cases, improve documentation or answer questions in forums.Examples: Linux, Firefox, WordPress, Cypress and Mautic are well-known open source projects with active contributor communities. A tester checking a pull request against its reproduction steps, then approving it or requesting changes with a screenshot of the problem. A bilingual contributor translating a project's documentation so more people can use the software. Common pitfalls: Assuming open source contribution means writing code, and giving up before discovering the many non-code ways to help. Choosing an inactive project where pull requests sit unreviewed, so contributions get no response or support. Can I contribute to open source software without coding? Yes. Testing pull requests, reporting issues, writing or translating documentation, writing test cases and helping people in forums are all valued contributions, and some projects keep a separate space for low or no-code work. Is open source software free? It is free to access and modify, but the licence still sets conditions, such as keeping attribution or sharing changes under the same terms.

A failure map, sometimes called a failure-first map or failure path map, is a simple diagram or list of a user journey's dependencies that records what the user would see if each one were down, slow or returning bad data. Unlike a standard system diagram, which shows how data flows when everything works, it focuses on how things fail. Why it matters: Architecture diagrams tend to hide failure behaviour. Mapping failure points shows where a system will hurt customers most when something breaks, and turns vague worries about reliability into specific test ideas. In practice: Building a failure map for one critical journey usually takes four steps: Pick one high-value flow, such as placing an order or joining a video call. List every visible dependency for each step: front ends, APIs, queues, caches, databases, third-party services, feature flags and configuration. For each dependency, ask what the user would see if it were down, slow or returning bad data. Turn each answer into a test idea that simulates that condition in a development or test environment. Examples: Mapping a claims submission journey and finding that a slow document storage service leaves users with no feedback at all. Noting that a missing feature flag service would hide the checkout button rather than fall back to a default. Using the map to choose which dependency to break first in a team chaos session. Common pitfalls: Mapping only the down state and missing slow or bad-data failures, which are often more confusing for users. Trying to map the whole system at once instead of starting with one critical user journey. What is the difference between a failure map and a system architecture diagram? An architecture diagram shows components and how data flows between them when things work. A failure map shows what each dependency failing would mean for the user, so it leads directly to test ideas. Who should create a failure map? Testers can lead it, ideally with developers and SREs who know the dependencies and how they are configured.

A swallowed exception, also described as a swallowed root cause, is an error that is caught in code and then hidden or replaced with a vague message, so the real reason for the failure is lost. Users typically see something generic such as "Something went wrong" or "Check-in failed" instead of what actually caused the problem. Why it matters: Swallowing errors is one of the most common error handling mistakes. It leaves users with no idea what to do next and makes problems slower to diagnose, which hurts recovery time. It can also damage team culture: when detailed messages from lower-level modules are always suppressed, developers stop bothering to write useful ones. In practice: Exceptions usually carry a plain-language message plus a link to the earlier exception that caused them. Swallowing happens when a catch block throws a new, generic error and drops the detail, often out of worry that the precise message will be too technical. Better approaches: Pass user-friendly detail upwards, building a message from general to specific. Keep the full chain of causes in logs for support and developers. Test failure paths deliberately to see what users actually get. Examples: A check-in flow that runs identity, age, visa and payment checks but only ever reports "Check-in failed", whichever step broke. An improved version that reports "Check-in failed because the visa could not be verified". A catch block that logs nothing and returns an empty result, so a failure looks like a success. Common pitfalls: Assuming users cannot cope with any technical detail, when many understand more than expected, including error codes. Replacing a swallowed error with a misleading one, such as "Try again later" for a request that will never succeed. How can testers spot swallowed exceptions? Trigger failures in different parts of a flow and compare the messages. If very different causes all produce the same generic message, the root cause is probably being swallowed. Is a swallowed exception a bug? It is usually treated as a quality issue worth reporting, because it slows diagnosis and leaves users without useful guidance.

Blind SQL injection is a form of SQL injection where the application does not show query results or database errors, so the tester or attacker has to infer what is happening from indirect signals. The two main types are boolean-based blind injection, which compares responses to true and false conditions, and time-based blind injection, which asks the database to pause. Why it matters: A field that shows no errors can look safe while still being injectable. Many teams hide error messages, which is good practice, but it does not fix the underlying query. Blind techniques let testers confirm the problem without visible output, and attackers can use the same techniques to extract data one piece at a time. In practice: Testers start by establishing a baseline response and timing for a normal input. They then send pairs of conditions and compare the results: A boolean pair such as ' AND 1=1-- - against ' AND 1=2-- -, where a difference between the two pages suggests injection. A time delay such as SLEEP(5) for MySQL, WAITFOR DELAY for SQL Server or pg_sleep(5) for Postgres. A response that takes about five seconds longer than the baseline is a non-destructive way to confirm the issue.Examples: A search box returns normal results for the true condition and an empty page for the false one, despite never showing an error. A login form takes five seconds longer to respond when a SLEEP payload is added to the username. A filter on an API endpoint returns different record counts depending on an injected condition. Common pitfalls: Concluding a field is safe because a single quote produced no visible error. Misreading normal network delay as a positive result instead of repeating the time-based test against a measured baseline. How is blind SQL injection fixed? The same way as any SQL injection: use parameterised queries so user input is always treated as data and never as part of the SQL statement.

An open redirect, also called an unvalidated redirect, is a security vulnerability where an application sends users to an address taken from user input without checking that it is a safe destination. It usually appears in parameters such as next, return or url that tell the application where to go after login, logout or a form submission. Why it matters: Open redirects are a favourite tool for phishing. A link that starts with a trusted domain looks safe, so people click it, then land on a lookalike site that asks for their password. Open redirects can also be chained with other weaknesses, such as SSRF or flawed single sign-on flows, to cause more serious problems. In practice: Testers find every parameter or field that controls where the user ends up next. They then replace the expected path with an external domain and check whether the browser lands there after the action completes. Useful variants include protocol-relative values starting with //, values starting with /\ that some browsers treat as external, and encoded forms that may slip past simple validation.Examples: A login page with a next parameter sends the user to an external domain after a successful sign-in. A logout link accepts //example.org as its return value and drops the user on a site outside the application. A redirect check that only confirms the value starts with a slash is bypassed by a value starting with /\. Common pitfalls: Validating only that the value contains the company domain, which an attacker can satisfy with a subdomain they control. Testing only the visible redirect after login and missing redirect parameters in logout, error and email confirmation flows. Is an open redirect a serious vulnerability? On its own it is often rated low to medium, because it needs a user to click a crafted link. Its real risk comes from making phishing more convincing and from being combined with other flaws.

Failover testing is testing that checks whether a system correctly switches to a backup component, server, database or region when the primary one fails, and how that switch affects users. It is used to verify claims that a system is highly available, active-active or able to fail over automatically. Why it matters: Failover is often designed and configured but rarely exercised until a real outage happens. When it is finally needed, it may be slower than expected, drop sessions or not trigger at all. A system can be described as resilient on architecture diagrams and still leave customers with errors, spinning screens and lost work during a regional failure. In practice: Testers usually ask for a controlled failover in a non-production environment, planned like any other test session with developers or SREs. During the switch they watch from the customer's point of view: latency spikes, errors, whether users are logged out, and how reconnection feels. They also check which alerts fire and how long recovery takes, then record expected behaviour in plain language for future incidents.Examples: Forcing the primary database in a test environment to fail and timing how long the application takes to reconnect to the replica. Triggering a regional failover for a video call service and checking whether people in a call are dropped or reconnected. Confirming that an alert reaches the on-call engineer when a failover happens. Common pitfalls: Checking only that infrastructure dashboards turn green again, without looking at what users experienced during the switch. Testing failover once at launch and assuming it still works after later changes to configuration or architecture. What is the difference between failover testing and disaster recovery testing? Failover testing checks the automatic switch to a backup component during a failure. Disaster recovery testing covers the wider process of restoring systems and data after a major event, which may include manual steps. Can failover testing be done safely? Yes, by starting in development or test environments, planning the experiment with the people who own the infrastructure and agreeing how to restore normal service.

A suitcase word is a word that carries many meanings or invites multiple interpretations, so that what it means depends heavily on context. "Intelligent" is a classic example: calling a person intelligent and calling a dog intelligent describe very different things, even though the same word is used. Why it matters: Language is ambiguous by nature, and suitcase words make that worse. In talks, documentation, requirements and bug reports, they let each reader unpack their own meaning, which leads to misunderstandings that surface late. For testers, spotting suitcase words is a quick way to find hidden assumptions and gaps in shared understanding. In practice: Avoid suitcase words where precision matters, or give enough context to pin down the intended meaning. When writing or presenting, replace a vague word with what it actually refers to. When reviewing requirements or user stories, treat words like "fast", "secure", "simple", "intelligent" or "user-friendly" as prompts for questions: fast for whom, measured how, compared with what? Writing the agreed meaning down stops it drifting later.Examples: A story asks for an "intuitive" sign-up flow, and the tester asks the team to describe what a new user should be able to do without help. A conference slide promises "smart" test automation, and the speaker adds a sentence explaining that the tests pick data based on recent production failures. A bug report says a page is "slow", and the reporter adds the measured load time and network conditions. Common pitfalls: Assuming everyone in the room shares the same meaning for a familiar word, so nobody thinks to check. Replacing one suitcase word with another, such as swapping "robust" for "resilient", without adding any real detail. Why do suitcase words matter for accessibility? Clear, precise language helps everyone, including people reading in a second language, people using captions or transcripts and neurodivergent readers who may take words literally. Unpacking suitcase words makes content easier to follow for the whole audience.

The FAB framework, also called the FAB method, is a prompting structure for using a large language model (LLM) in boundary analysis, where each boundary value is described by its Field, Advantage and Business value. It turns a generic list of minimum, maximum and invalid values into context-rich boundaries that are tied to product risk. Why it matters: Asking an LLM for "boundary values for the login feature" tends to return the same tidy, generic list every time, with no reasons behind it. Boundaries are everywhere and no team can test them all. FAB filters the noise: the Advantage explains why a value is worth testing, and the Business value links it to real users, risks and goals, so testers can prioritise. In practice: The three parts are: Field: the variable or input under boundary analysis. Advantage: why exploring its edges reveals something other values might miss. Business value: why the test matters to users, risk and the business. A typical prompt names the feature and product, asks for the most important boundaries using FAB in a table, and ends by inviting the model to ask a few questions about the context first. Those questions surface assumptions and constraints the tester might otherwise miss.Examples: Testing a driving licence application's date of birth field one day before and exactly on the minimum legal age. An LLM asking whether learner and full licences have different age rules before proposing boundaries. A junior tester using the Advantage column to learn why a value matters, not just what it is. Common pitfalls: Dropping the request for the model to ask questions, so it fills gaps with generic assumptions. Accepting the business value statements without checking them against the real rules, such as the legal age in the target jurisdiction. What does FAB stand for in testing? Field, Advantage and Business value. It structures LLM prompts so each boundary value comes with a reason. Can the FAB framework be used without an LLM? Yes. The same three questions work as a checklist for any tester prioritising boundary values by hand.

Big up-front documentation (BUFD) is the practice of producing long, detailed documents, such as test plans, specifications and test cases, before development or testing begins. It is closely linked to waterfall-style projects and to big design up front (BDUF), where most planning and design happens at the start rather than alongside the work. Why it matters: Lengthy up-front test plans can take months to write, and busy managers and teammates often don't have time to read them. Requirements also change during development, so detailed documents written early can be out of date by the time they are used. Understanding BUFD helps testers decide how much documentation their context really needs, rather than following a template by habit. In practice: Many teams have moved away from BUFD towards lighter, living documentation and earlier conversations about quality. Common alternatives include one-page test plans, mind maps, dashboards, wiki pages, whiteboards and test charters. Some up-front documentation remains necessary, especially in regulated industries, contractual work or where a regulator expects formal evidence, so the aim is to match the level of detail to what readers actually need.Examples: A team on a waterfall project spends months writing a 70-plus-page test plan template that few people read in full. An agile team replaces a long master test plan with a one-page summary covering scope, risks, assumptions, environments and tools. A tester sketches a mind map of test areas with the team instead of writing detailed test cases before the feature is built. Common pitfalls: Filling every section of a template because it exists, rather than asking whether the reader needs that information. Swinging too far the other way and producing no documentation at all, even when regulators, customers or new team members need it. Is big up-front documentation always bad? No. It suits contexts where requirements are stable or regulation demands formal records. It becomes wasteful when documents are long, rarely read and quickly outdated.