The inverted test pyramid is a term used to describe when projects have too many e2e or UI tests compared to unit tests or other tests seen lower down the automation test pyramid. Many projects have too many large, slow, flaky tests and few smaller ones. Retrying failed tests and marking known failures introduce risk and waste. Examining the root causes is essential to breaking the cycle.

A matrix is an organisational structure in which two or more lines of command, responsibility, or communication run through the same individual. Matrix management is almost the opposite; an employee will report to two managers, typically a functional manager and a project manager.ExampleIn a previous role, my (functional) manager worked in another area of the business and my (project) manager was responsible for my day-to-day activities. Matrix management was adopted for all testers so that an employee (Emily) reported to a manager in the same project or product area (the tech lead, an experienced developer) and another more experienced person of the same job family within the same office location.When describing my experience in the below article, I described the more senior tester as my “main” manager, however this person didn't have all of the day-to-day context of my project.

Matrix management is a way of organising people so they report to more than one leader at the same time. Instead of having a single, straight-line manager, you might have one manager responsible for your professional skills (like testing or design) and another responsible for the product or project you’re currently working on. It’s a structure built for flexibility. Teams can form, reform, and adapt as priorities shift.Matrix management is commonly used inside matrix organisations, where work cuts across functional boundaries. You’ll see this approach in companies that need to balance specialist expertise with fast-moving delivery. Think of big global tech firms, where an engineer might sit in a central discipline group but spend most of their time embedded in a product team.For testers and quality engineers, matrix management usually means having two voices guiding your work. One focused on how you grow your craft, and one focused on what you deliver with your team. Success comes from clarity, communication, and not being afraid to surface tensions when priorities pull in different directions. The challenge is creating an environment safe enough for that to happen, or else divided or conflicting priorities, communication breakdowns, and cognitive overload, amongst other things, can cause major problems.

Impact statements describe the outcome of your work rather than the task you performed. Instead of listing what you did, they show what changed because you did it. They make your contribution clear, measurable, and easy for others to understand.Example: Task: Created API test suite Impact statement: Improved release confidence by reducing post-deployment API failures

Often Acceptance testing is the final check in software development to ensure the product meets goals and expectations before release.Purpose of Acceptance Testing Validates user and business needs to ensure satisfaction. Reduces post-launch risks by catching issues before release. Acts as a final verification before deployment. Identifies requirement gaps between developers and users. Types of Acceptance Testing Alpha Testing >  Internal testing by developers to catch early bugs. Beta Testing > Real-world testing by external users before release. Business Acceptance Testing (BAT) > Checks alignment with business goals and workflows. Contract Acceptance Testing (CAT) > Ensures all contractual requirements are fulfilled. Operational Acceptance Testing (OAT) > Confirms system readiness and infrastructure reliability. Regulation Acceptance Testing (RAT) > Verifies compliance with industry regulations. User Acceptance Testing (UAT): > Validates if the software meets end-user needs.

The STAR model is a simple structure for explaining real experiences. It helps you tell a clear, focused story by breaking it into four parts:  Situation – The context or problem you were facing Task – What you were responsible for Action – What you actually did  Result – What changed because of it  Example:  Situation: A regression cycle kept slipping because no one trusted the test results.  Task: Improve the reliability of the suite.  Action: Identified the top flaky tests, stabilised them, and moved the suite into CI.  Result: The team cut regression time by half and stopped rechecking everything manually.

A webhook is an automated event triggered when something happens. More specifically, a webhook is a HTTP request triggered by an event in a source system, that will be sent to a destination system, often with a payload of data. For example, when a website goes down, an automated call might send the admin an email. Webhooks are commonly used to perform small requests and tasks that don't need an entire API. They are automated; meaning they are automatically sent out when their event is fired in the source system. This focuses a testers attention on validating all the ways that the event could be triggered and ensuring that the HTTP request is sent and received as expected.

WYSIWYG is an acronym for "what you see is what you get" and is pronounced as “wizzy-wig”.A WYSIWYG editor is a system in which content (text and graphics) can be edited in a form closely resembling its appearance when printed or displayed as a finished product, such as a web page.

CTF stands for Capture the Flag. In the Cyber Security world this relates to events where people aim to use ethical hacking and web exploitation skills to find hidden flags. This may involve hacking into a machine to find the "flag" file or having a series of hidden "flags" (often strings) within a solution designed specifically for these events. Organisations may run CTFs internally or publicly prior to or alongside bug bounty programs and penetration tests. You can also find applications to practice security testing through a CTF game.

Encapsulation is the isolation of code so that it can be used but not accessed or modified directly. One example of encapsulated code is a function. Testers should be aware of the best practices around encapsulation so that they can create more maintainable test automation, especially in the case where it was created from a UI recorder.

Self-adaptive systems are structured to change their behaviour while running. They do this in response to changes in their environment or within the system itself, for example, to keep working properly when conditions change or when unexpected situations occur. The goal is usually to reduce the need for manual intervention and let the system handle uncertainty on its own.

Probabilistic behaviour refers to a system's behaviour governed by probability rather than being fully deterministic. In such systems, the same input or situation may lead to different outcomes, each with a certain likelihood. This approach is commonly used to model uncertainty, variability or incomplete information, for example, in machine learning systems, stochastic simulations or adaptive systems that must operate under uncertain conditions.