Kubernetes, often shortened to K8s, is an open source platform for running and managing containerised applications across a group of machines called a cluster. Teams use it to deploy, scale and isolate software, and testers increasingly meet it when their applications, or their automated tests, run inside a Kubernetes cluster. Why it matters: When the product under test runs on Kubernetes, the environment itself becomes a source of bugs. Resource limits, networking rules and the way containers share memory can all behave differently from a laptop or a local Docker setup. Tests that pass locally can fail in the cluster for reasons unrelated to the code under test. In practice: Applications are packaged as container images and deployed into pods, the smallest units Kubernetes runs. Related resources are grouped into namespaces, often one per customer or environment. Test code can be packaged the same way and run as a Kubernetes job, a short-lived task that starts, runs the suite, reports results and is then discarded. Debugging usually means getting inside the pod, reading logs and copying files such as screenshots back to a local machine.Examples: Running a UI test suite as a Kubernetes job in a customer's namespace just before and just after a major version upgrade. Keeping a debugging pod alive with a sleep command so a tester can run tests by hand and inspect what happens. Finding that headless Chrome fails to load iframes in a pod because of limited shared memory, then fixing it with a browser flag. Common pitfalls: Assuming a test that works in Docker Desktop will behave the same way once deployed to the cluster. Treating cluster failures as flaky tests instead of investigating resource, network or configuration differences. Do testers need to learn Kubernetes? Not in depth, but knowing how pods, namespaces and jobs work makes it far easier to run tests in the real environment and to tell product bugs from environment problems. What does K8s stand for? K8s is a shorthand for Kubernetes, with the 8 standing for the eight letters between the K and the s.

A knowledge silo, sometimes called an information silo, is a situation where important information is held by one person or a small group and is not easily available to others who need it. In software teams it often shows up as a single go-to person for a system, tool or process. Why it matters: When knowledge sits with one person, everyone else has to wait for them, and work stalls when they are busy, on leave or leave the company. Testers feel this sharply, because testing depends on understanding how systems, data and business rules really work. Silos also limit creativity, since fewer people can build on what is known. In practice: One simple habit that breaks down silos is asking and answering questions in public spaces, such as a team channel, rather than in private messages. Once a question and its answer are visible, anyone can find them later, add to them or correct them. Teams also reduce silos through pairing, rotating responsibilities, recording decisions and keeping shared documentation current. Leaders help by making it feel safe to ask "obvious" questions in the open.Examples: An engineering manager who asks people to repost private questions in the team channel so everyone sees the answer. A tester who is the only person able to run the payments test environment, so releases wait whenever they are away. A team that pairs a new starter with the person who knows the legacy reporting service, so knowledge spreads. Common pitfalls: Answering the same private questions again and again instead of moving the conversation to a shared space. Writing documentation once and never updating it, which creates a new silo of out-of-date information. How do you break down a knowledge silo? Make questions and answers public by default, pair people on work that only one person understands, and rotate tasks so more than one person can do them. Is a knowledge silo the same as a low bus factor? They are closely linked. A low bus factor measures the risk, while a knowledge silo describes the situation that creates it.

A knowledge map is a visual or written overview of what a person knows, what they are learning and where their gaps are, used to plan what to learn next. It can be a mind map, a canvas, a graph or a simple list. Why it matters: Testers face a constant stream of new tools, frameworks and AI products, and trying to learn all of them leads to scattered effort and burnout. A knowledge map gives a clear picture of current skills against what work, the market or a promotion needs. That makes it easier to choose a few priorities and say no to the rest for now. In practice: A tester reflects on their skills and builds or updates their knowledge map every three to six months. They note topics they are strong in, topics they need for their role, and areas of interest. Gaps then become learning goals for a month or a quarter, broken into small tasks such as reading one chapter or watching one lesson.Examples: A mind map with branches for automation, APIs, AI tools and domain knowledge, each marked as confident, learning or not started. A simple list comparing the skills in a company's promotion criteria with the skills a tester already has. An AI-generated diagram of how concepts in a topic relate, compared against the learner's own notes to spot what is missing. Common pitfalls: Building the map once and never revisiting it, so it stops reflecting what the tester actually knows or needs. Filling the map only with what work or the market demands and ignoring personal interests, which raises the risk of burnout. How often should I update a knowledge map? Every three to six months suits most people. That is long enough to see progress and short enough to keep it current. Is a knowledge map the same as a learning plan? No. A knowledge map shows where you are and where the gaps lie. A learning plan sets out the goals, tasks and timings for closing some of those gaps.

Knowledge management is the practice of capturing, organising and sharing what a team knows so that it can be found and used when someone needs it. In software teams this covers documentation, wikis, test artefacts, chat threads and meeting transcripts, and increasingly how AI tools can surface answers from all of them on demand. Why it matters: Few people read every page of documentation or listen to every piece of advice. When knowledge is well managed, a tester can pull up the right product decision, past bug or known risk in moments instead of rediscovering it the hard way. Old conversations and recordings can become a source of early warnings about quality problems. In practice: Teams start by exploring the knowledge they already hold, such as chat history, product plans, test plans and transcripts. They look for what is missing or slow to find, then agree a consistent structure for how information is written and stored. Small habits help, such as linking to related material and using clear keywords so things are easier to search later. AI assistants connected to these sources can then answer questions directly.Examples: Connecting a team wiki to an AI assistant so a tester can ask how a feature is meant to behave instead of searching dozens of pages. Searching meeting transcripts for phrases such as "I'm worried" or "that's strange" to find risks raised and never followed up. Agreeing a set of shared quality prompts that help the team start test planning from existing knowledge. Common pitfalls: Expecting AI to produce useful answers from scattered, inconsistent information, when it needs a solid foundation of well structured knowledge. Trying to design a perfect system up front instead of improving the process in small steps. Why does knowledge management matter for testers? Testers rely on context about how a product should work and where it has failed before. Good knowledge management puts that context within reach, which leads to better questions and better tests.

A key performance indicator (KPI) is a measurable value a team or organisation tracks to judge progress towards an important goal. In software and quality engineering, KPIs might cover things like escaped defects, lead time, test pipeline stability or customer-reported issues. Why it matters: Well-chosen KPIs help teams see where they are improving and where they are not, and give leaders evidence for decisions. Poorly chosen ones do harm: when metrics are imposed from above, the people doing the work rarely buy into them or feel accountable for them, and the numbers end up ignored or gamed. The phrase "if you can't measure it, you can't manage it" is often quoted to justify KPIs, though the original idea was closer to the opposite. In practice: KPIs work best when they are built with the team rather than for it. Leaders can ask the team what successes were missed, what failures could have been avoided and where they want to improve, then agree a small set of measures that reflect those answers. The team reviews the KPIs on a regular basis, adding, changing or dropping them so they stay relevant.Examples: A team that agrees to track production incidents caused by changes after noticing too many weekend call-outs. Engineers choosing to measure flaky test reruns because pipeline delays were their biggest frustration. A set of managers' metrics nicknamed after the person who wrote them, a sign the team never adopted them. Common pitfalls: Creating KPIs in a managers-only meeting and presenting them to engineers as finished, so nobody feels ownership. Setting KPIs once and never reviewing them, so they keep measuring problems the team has already solved. What is the difference between a KPI and a metric? Any measurement is a metric. A KPI is a metric the team has chosen because it tracks progress towards a goal they care about. What are good KPIs for a testing team? That depends on the team's goals, which is why the team should help choose them. Common starting points include escaped defects, time to detect issues and pipeline reliability.

Job shadowing, often just called shadowing, is a way of learning a role by working alongside an experienced practitioner and observing how they do their job on real work. In software testing, job shadowing is commonly used to give junior testers and career changers hands-on exposure to projects before they take on testing responsibilities of their own. Why it matters: Entry-level testing roles are harder to find, and many quality engineering jobs ask for experience that newcomers cannot easily get. Shadowing on live projects gives people real-world exposure, builds their confidence and helps them gather experience they can describe credibly on a CV. It also passes on the tacit knowledge that courses rarely cover. In practice: A less experienced tester is embedded in a project team and paired with a more senior tester. They sit in on planning, refinement and bug triage, watch how testing decisions are made, and gradually take on small pieces of work under guidance. Shadowing works best alongside structured training, so the newcomer learns both foundational principles and how they apply on a real project.Examples: A consultancy placing a trainee tester on a client project alongside a senior consultant so they gain experience before being billed in their own right. A developer interested in quality shadowing a tester during exploratory sessions to see how risks are identified. A new hire shadowing the team's release testing for a few cycles before running it themselves. Common pitfalls: Leaving the person to watch passively for too long, without gradually handing over real tasks. Relying on shadowing alone, without structured training to build a solid grasp of the basics. What is the difference between job shadowing and pairing? In pairing, two people work on the same task together as equals. In job shadowing, the learner mainly observes an experienced person at first and takes on more of the work over time. Is job shadowing useful for experienced testers? Yes. Experienced testers moving into a new domain, product or role can shadow colleagues to pick up context quickly.

Jailbreaking, in the context of AI, is the use of crafted prompts or techniques to get a large language model to bypass its safety guardrails and produce output it is designed to refuse. Common methods include role-play, hypothetical framing, encoding requests in formats such as Base64, and step-by-step pretexting that hides the real intent. Why it matters: Safety guardrails are only as good as their resistance to people trying to get around them. A model that refuses a direct harmful request but complies when it is wrapped in a story is not safe in practice. Jailbreak testing is central to evaluating whether an AI system is harmless, and to protecting the organisation that deploys it. In practice: Testers and red teams build collections of jailbreak techniques and apply them to a model's known refusal areas, such as weapons, malware or private data. They track which techniques succeed, how often, and whether fixes hold across model updates. Automated tools can generate many prompt variations, while human testers explore creative approaches that tools miss. Findings feed back into prompts, filters and training.Examples: Asking a model to play a character with "no rules", such as the well-known DAN prompt, to unlock restricted answers. Encoding a harmful request in Base64 to slip past keyword-based filters. Building up to a dangerous request over several turns so no single message looks harmful. Common pitfalls: Testing only direct harmful requests and concluding the model is safe because it refuses them. Treating a fixed jailbreak as solved, when small variations of the same technique often still work. What is the difference between jailbreaking and prompt injection? Jailbreaking is a user trying to bypass a model's own safety rules. Prompt injection hides malicious instructions in content the model processes, such as a web page, to hijack its behaviour. Is jailbreak testing legal? Testing your own or authorised systems is a normal part of AI safety work. Testing other providers' systems should follow their terms and any responsible disclosure programmes.

Round half to even, also known as banker's rounding, is a rounding rule in which a value exactly halfway between two numbers is rounded to the nearest even number. Under this rule 0.5 rounds to 0 and 1.5 rounds to 2, whereas the more familiar round half up rule would give 1 and 2. Why it matters: Different languages, libraries and database engines use different rounding rules by default. When one layer of a system rounds half up and another rounds half to even, the same calculation can produce different answers. Over large datasets those small differences add up, which is a known source of discrepancies in financial reports and reconciliations. In practice: Testers find out which rounding rule each part of the system is supposed to use, then test values that sit exactly on the midpoint. Useful checks include: Entering values such as 0.5, 1.5, 2.5 and 2.675 and comparing results across the UI, API and database. Summing many midpoint values to see whether totals drift between layers. Checking that displayed values match stored values after rounding. Where the requirements do not say which rule applies, that is a spec gap worth raising before the feature is built.Examples: A report generated in the database rounds 2.5 to 2 while the web front end shows 3 for the same figure. Monthly invoice totals differ by a few pence from the finance system because each line was rounded with a different rule. A grading tool rounds a score of 69.5 down to 69 and fails a student who expected a pass. Common pitfalls: Assuming every layer of a system rounds the same way because they produce the same result for most values. Testing with values that are not exactly on the midpoint, so the difference between rules never appears. Why is it called banker's rounding? Rounding halves to the nearest even number avoids the slight upward bias of always rounding half up, which matters when many values are summed, as in banking and accounting.

ISO/IEC 25010 is an international standard that defines a product quality model for software and systems, breaking quality down into characteristics and sub-characteristics that can be used to specify, evaluate and discuss it. It belongs to the SQuaRE (Systems and software Quality Requirements and Evaluation) family of standards and describes quality as the degree to which a system satisfies the stated and implied needs of its stakeholders, and so provides value. Why it matters: Ask a product manager, a developer, a tester and a user what software quality means and the answers often differ. A shared model gives teams a common vocabulary and a checklist of perspectives, so attributes such as security or maintainability are not forgotten while everyone focuses on functionality. In practice: The current version of the product quality model groups quality into nine characteristics: functional suitability, performance efficiency, compatibility, interaction capability, reliability, security, maintainability, flexibility and safety. Teams use these to shape non-functional requirements, plan test coverage and structure quality reviews. Testers often walk through the list to ask which characteristics matter most for a given product and where the risks lie.Examples: A team writing a test strategy uses the characteristics as headings to make sure reliability and security are covered alongside features. Before a release, a tester checks maintainability and compatibility concerns that would never show up in functional test results. Common pitfalls: Treating the model as a universal definition of quality, when what matters most still depends on the context, the purpose and the people involved. Trying to test every characteristic equally, rather than using the model to prioritise the ones that matter for this product. Is ISO/IEC 25010 a testing standard? No. It is a quality model that describes what quality is made of, while testing standards describe how to test. How many quality characteristics are in ISO/IEC 25010? The 2023 revision lists nine product quality characteristics. The earlier 2011 version listed eight, so older material may show a different set.

Role-based testing is testing that checks what each type of user, such as an administrator, an editor or a standard customer, is and is not allowed to see and do in an application. It verifies that permissions and authorisation levels for each role work as intended, and is closely linked to testing role-based access control (RBAC). Why it matters: Many applications grant very different powers to different users. If a reader can reach an admin page, or an admin action fails silently, the result can be a security breach, data loss or a broken workflow. Testing each role, and the interactions between roles, catches those gaps before real users find them. In practice: Testers list the roles and the actions each should be allowed or denied, then run checks logged in as each role. In automation, a common pattern is to authenticate each role once, often through an API for speed, save the session, and reuse it across tests. Some tests use several roles at once, for example one user creates something and another must be able, or unable, to act on it.Examples: Logging in as an admin and a reader and checking that only the admin can see and edit every customer's orders. Confirming that a standard user who types an admin URL directly is refused rather than shown the page. Testing that an item approved by a manager becomes visible to a staff member in the same test run. Common pitfalls: Only checking what each role can do, and never checking that it is blocked from what it should not be able to do. Testing every role through the user interface login each time, which makes suites slow and brittle when many accounts are involved. What is the difference between role-based testing and authorisation testing? Role-based testing focuses on the permissions tied to each user role. Authorisation testing is broader and can also cover permissions based on ownership, attributes, tokens or other rules.

ISO 8601 is the international standard for writing dates and times as text, ordered from largest unit to smallest, such as 2024-01-05 or 2024-01-05T14:30:00Z. It is widely used in APIs, JSON payloads and databases to avoid ambiguity between formats like dd/mm/yyyy and mm/dd/yyyy. Why it matters: JSON has no native date type, so dates travel as strings and parsing depends on the library at each end. ISO 8601 gives teams a shared format, but it allows several variants. A system that accepts one variant and rejects another, or quietly drops the timezone, can produce bugs that only appear in production data. In practice: Teams agree which ISO 8601 form they send and accept, including whether an offset is required. Testers try the basic form without separators, the extended form, a Z suffix, an explicit +00:00 offset and no offset at all. They also check that timezone information survives serialisation and that edge values far in the past or future are handled.Examples: One service sends 2024-01-05 while another expects 20240105, and the import fails silently. A timestamp ending in Z is parsed correctly, but the same instant written with +00:00 is rejected. A value with no offset is treated as server local time, shifting records by several hours after a migration. Common pitfalls: Assuming every ISO 8601 string is interchangeable, when libraries differ in which variants they accept. Stripping timezone information during serialisation, so the original instant can never be recovered. Is ISO 8601 the same as UTC? No. ISO 8601 is a format for writing dates and times, while UTC is a time standard; an ISO 8601 timestamp can carry a UTC marker (Z), another offset, or no offset at all.

The RICCE framework is a structured approach to writing prompts for large language models (LLMs), named after its five parts: Role, Instructions, Constraints, Context and Examples. Testers use the RICCE prompting framework to get more precise, usable output from AI assistants, such as test automation code that fits their project rather than generic snippets. Why it matters: Vague prompts tend to produce vague or wrong answers, which then take time to review and fix. Covering each part of RICCE gives the model the information a human colleague would need to do the job well. That matters most for testers new to coding, who may not yet spot when generated code is subtly off. In practice: A RICCE prompt covers each element in turn: Role: who the model should act as, for example an experienced test automation engineer. Instructions: the task, stated clearly. Constraints: limits such as the framework, language, coding standards or what not to do. Context: background about the product, the existing codebase or the scenario under test. Examples: a sample of the expected output, such as an existing test written in the house style. The output still needs a human to review, run and adjust it.Examples: Asking an AI assistant, acting as a Playwright expert, to write a login test in TypeScript that uses the existing page object classes and follows an attached example test. Constraining a prompt to "no hard-coded waits" so generated tests rely on the framework's own waiting behaviour. Supplying the acceptance criteria for a story as context when asking for a list of test scenarios. Common pitfalls: Leaving out context and examples, so the model invents structures and naming that clash with the existing framework. Treating a well-structured prompt as a guarantee of correct output and skipping review. Is RICCE the only prompting framework? No. Several similar frameworks exist, and most cover the same ground of role, task, context and examples. Do you need coding skills to use RICCE? Not to write the prompt, but you do need enough foundational knowledge to judge whether the code that comes back is any good.