API Mock image
  • Jose Carrera's profile
An API mock is a simulation of a real API, where one or more endpoints can be configured to facilitate software development and testing.
Shift-everywhere testing image
  • Rosie Sherry's profile
Shift-everywhere testing means acknowledging and practicing testing during all parts of the Software Development Life Cycle. It doesn't just exist on the left (shift-left testing), nor just on the right (shift-right testing). It needs to exist throughout.
Attack image
  • Richard Adams's profile
An attacker who uses an exploit to perform a malicious action and make an attack.
Exploit image
  • Richard Adams's profile
A tool, code, or method used to take advantage of a vulnerability.
Vulnerability image
  • Richard Adams's profile
A mistake is made within code or the environment, creating a vulnerability.
Authorization image
  • Richard Adams's profile
Authorization is having permission to perform actions or see the data I want.
Authentication image
  • Richard Adams's profile
Authentication is "Proving that I am who I say I am"
Shadow Work image
  • Aj Wilson's profile
Shadow work refers to untracked, informal, or invisible tasks that consume significant time and effort but aren’t reflected in official plans, metrics, or ticket systems. These tasks are essential for team success but often go unnoticed in capacity planning and performance reviews. Sometimes called 'Glue work'.Why it matters Hidden capacity loss: teams appear to have full bandwidth, but shadow work can eat up 30–40% of time. Burnout risk: Senior quality engineers often shoulder the bulk of invisible work. Promotion barriers: work that isn’t documented rarely counts toward career progression. Misalignment: business thinks engineering is slow; engineering feels misunderstood. Three types of Shadow WorkInvisible production support Investigating alerts and errors Answering ad-hoc support questions Fixing issues outside ticket flow Impact: wasted hours on recurring problems, skipped Quality steps, stability risks. Technical glue work       Code reviews, mentoring, documentation, coordination Impact: critical but undervalued; creates bottlenecks for senior quality engineers. Shadow backlogOff-the-record fixes and improvements outside the official roadmap Impact: broken capacity planning, creeping misalignment, trust erosion. Shadow work isn’t bad, it’s often the work that truly matters. The problem is when it’s invisible. Make it visible, plan for it, and recognise it.
Handler image
  • Jesse Berkeley's profile
A handler is a piece of code that responds to something happening — like a message arriving, a request being made, or an event being triggered.Think of it like a receptionist at an office: Someone walks in (an event or message). The receptionist (the handler) decides what to do — maybe call someone, give directions, or log the visit. When something happens — for example, a user clicks a button, a message arrives, or a request comes to a web server — the system passes that “event” to the right handler, which knows what to do next.In software, a handler does the same: It receives input (like an API request or a message from a queue). It processes that input — maybe by saving data, calling another service, or sending a response. As a tester, you might encounter handlers in: APIs: A handler processes incoming HTTP requests (e.g., GET or POST). Message-based systems (like NServiceBus): A handler processes messages sent between services. AnalogyImagine a smart home: You press a button (event). The system runs a handler that turns on the lights. As a tester, you’d check: Did the lights actually turn on? What happens if the button is pressed twice? What if the handler fails? Event-driven systems: A handler reacts when something happens (e.g., a user signs up) Understanding handlers helps you: Know where the logic lives — so you can test the right thing. Understand how data flows throughout the system. Spot side effects — like database updates or messages sent. Write better unit or integration tests by targeting the handler’s behaviour.
DevOps image
  • Ady Stokes's profile
DevOps is a way of working that brings together development (Dev) and operations (Ops) teams so they can build, deliver, and improve software through close collaboration and shared goals. It breaks down the barriers between development and operations so that everyone involved takes responsibility for quality and delivery.At its heart, DevOps is about creating faster and more meaningful feedback loops. When teams work together from ideation to release, they can spot issues sooner, learn from real users, and respond more quickly to change.For example, instead of developers waiting weeks to hear if a new feature performs well in production, they can work alongside operations to understand what happens much quicker.This shared approach builds trust, speeds up learning, and reduces waste. DevOps helps teams focus on outcomes rather than handovers, creating an environment where improvement is constant and communication keeps quality at the centre of everything.
RICE-Q image
  • Rahul Parwal's profile
A framework that helps the AI gather the right context and not work as an alien. R – Role: Ask the AI system to “act as a role”. I – Instructions: This is the instruction that you give to the AI system. C – Context: Describe the context about the purpose, feature, application, or system. E – Example: Provide a sample of your expected output. Q – Questions: Tell the AI system to ask you clarifying questions before answering or hallucinating.
SDET (Software Development Engineering in Test) image
  • Ady Stokes's profile
An SDET is a person with coding and developer skills who uses them to focus on creating automation artefacts, such as tests, frameworks, mocks, stubs, and, more recently, CI/CD pipelines. They combine testing knowledge with developer skills to support the creation of automation. Coming to prominence in the late 1990s and early 2000s at companies such as Microsoft, the role was created to allow someone to focus on the key advances in automation happening at the time.The emergence of Agile, then DevOps and even CI/CD pipelines made this bridging role between testers and developers more widespread. While there are still plenty of SDET roles being advertised, these days, many organisations expect testers to have some automation skills, and developers will have some testing knowledge. Indeed, some job descriptions include required skills for four or more 'traditional' roles. In Quality Engineering environments, developers may write the automation, but are supported by those with much deeper testing knowledge to work together in creating valuable automation that supports faster feedback cycles.
Subscribe to our newsletter
We'll keep you up to date on all the testing trends.