Software Engineer in Test, a term used more in Europe that the UK.See also SDET.https://www.ministryoftesting.com/software-testing-glossary/sdet-software-development-engineering-in-tests

Canary Release (noun 😉)A real world production deployment strategy that involves rolling out a new software version or feature to a small, select subgroup of users before making it available to the entire user base. Often incrementally. This can be used as an early warning system (risk mitigation). Incremental rollouts this way, can enable automated roll backs if paired with monitoring tools if predetermined error rates are detected (the canary part).Unlike staging environments, a canary release tests how the update interacts with actual production data and diverse user behavior. 

A business model where humans and intelligent AI agents work together to improve efficiency and decision-making.Unlike traditional automation, agentic AI doesn’t just follow rules - it can reason, adapt, and act autonomously. These AI agents handle complex, multi-step tasks through a continuous cycle of perception, reasoning, and action, enabling dynamic problem-solving.For quality engineers and testers, this means: AI agents assist in testing and quality processes, reducing repetitive work. Humans focus on strategic, creative, and high-value activities. Potential impact - it is proposed that there will be better employee experience, faster delivery, and improved customer satisfaction.

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.

Develop the mindset and practical coaching techniques that help teams build shared responsibility for continuous quality

What is it?Hidden text in emails using font-size:0 or similar CSS tricks. Appears in preview pane but not in the visible body to falsely reassure recipients.Testing? Inspect raw HTML > Look for <span style="font-size:0px"> or display:none tags. Compare preview vs body > If preview mentions “secure” or “verified” but body doesn’t, flag it. Search for suspicious phrases > Hidden text often says “This email is safe” or “Verified sender.” Automation > flag any zero-font or hidden text in email HTML. Cross-Client checks > test in Gmail, Outlook, Apple Mail - as we all know behavior varies. Educate users and peers > remind them 'Preview text can be manipulated - verify sender and links before clicking.' See also - how to identify people using AI when applying for jobs...

Boost your career in quality engineering with the MoT Software Quality Engineering Certificate.

Cloudflare went down again today and half the internet with it. Nothing like a global outage to remind us that we're all just one code or config change away from cup of tea time chaos.

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.

OKRs are a directional and aspirational system intended to stretch teams and individuals. They balance ambition with measurability and provide a flexible framework whose interpretation can vary by context.The classic OKR philosophy emphasises "Measurable Key Results". As Dev Experiance, Quality or Testing leadership hold the teams accountable for behaviors and culture  - they make room for "Qualitative Key Results". Qualitative Key Results are for these objectives that are hard to quantify (e.g., “Improve team morale” or “Strengthen cross-functional collaboration" or in the case of most new Quality Engineering Leaders - "Build a strong quality culture" or "Build a community of practice" as part of the behaviour sections of company values.  This is often seen in more 'next gen' progressive organisations.  Qualitative = descriptive, harder to express in numbers. Measurable = can be counted or calculated. Many companies also encourage personal OKRs focused on skill development or career growth (e.g., “Complete advanced cloud certification”), which may not have an immediate business impact but still align with long-term organisational goals.

A quality engineer makes sure quality is built into every stage of software development and everything around it. They're not gatekeepers, and they work closely with the software engineers or developers, product managers, and even operations to prevent defects, improve observability, and support continuous delivery. Quality engineers bring technical skills like writing code, building test frameworks, and integrating tools into the CICD pipeline for fast, actionable feedback via exploratory testing and observability as well. Their mission is simple. Make sure quality and risk is not an afterthought.

A Quality Engineer is a pivotal role in engineering quality into every layer of the software development lifecycle. Rather than acting as a gatekeeper, the QE partners deeply with developers, product managers, and operations teams to proactively prevent defects, enhance system observability, and drive continuous delivery of reliable, scalable software.The “engineering” in Quality Engineering is not metaphorical, it’s grounded in technical fluency, systems thinking, and automation craftsmanship. QEs read and reason about code, architect robust test frameworks, and integrate tooling into CI/CD pipelines to provide fast, actionable feedback. They surface insights through monitoring and trend analysis, and influence architectural and deployment decisions to reduce risk and improve resilience.Ultimately, Quality Engineers design for quality as a shared, systemic responsibility, not a phase, not a checklist or afterthought, aiming to remove unnecessary friction where possible.