Requirements Engineering: Every Test Case Design Is a Review
Requirements engineering decides how good testing can be. Test case design exposes gaps, and traceability shows which tests a change affects.
Requirements & Business Analysis
Many defects are born long before anyone writes a line of code: in requirements that are vague, contradictory, or never spoken out loud. This hub connects requirements engineering and business analysis with a tester's perspective and asks how business expectations turn into statements you can actually check.
The articles and podcast episodes cover testable user stories, analysing and improving requirements, domain storytelling, and product discovery, along with security requirements, legal pitfalls in software contracts, and the opportunities and risks of AI in requirements work. Foundation pages on acceptance testing and decision table testing add the matching techniques. The focus is on making sure business, development, and testing read a requirement the same way.
Foundations
Articles
Effort: Why Being Busy Won't Get Us to Our Goals
Software teams reach their goals through real effort, not daily busy work: paying down technical debt, deleting old code and slimming processes.
Testing Principles: Why They Outlast Any Tool
Testing principles and methods last longer than any tool. As testing moves closer to development and tools keep changing, mastering them pays off.
Pilot Project for Test Automation: Three Phases to Rollout
Test automation pilot projects work best with the three top-ranked tools. Phase two covers one department, phase three the company-wide rollout.
Sensory Impressions in Software Design
Software design gains depth when user wishes are captured with all senses. The Walt Disney strategy, VAKOG and the Dilts pyramid help along the way.
Testing Cloud Services: Static Analysis and Dynamic Analysis
Testing cloud services takes two phases: static analysis checks requirements against the interface spec, dynamic analysis validates real responses.
Assessing Data Quality: Three Audits for Customer Databases
Assessing data quality in customer databases: three automated audits of schema, structure and content expose design flaws, invalid data and duplicates.
Test Estimation: Test Points, Test Cases, and COCOMO-II
Test estimation from requirements: count test points and test cases, factor in testability and productivity, then feed a modified COCOMO-II formula.
Requirements Testing: Why Testers Should Review Specs Early
Requirements testing brings testers in early to find incomplete and incorrect requirements in the specification, before they turn into costly defects.
Podcast Episodes
AI in Software Testing Raises the Value of Expert Testers
AI in software testing leaves a faulty fraction: hallucinated requirements, invented test cases. Business knowledge keeps expert testers in demand.
Lean Management: Why Problem Analysis Beats Quick Fixes
Lean management starts with understanding a problem instead of rushing to a quick fix. That breaks the repeat cycle and exposes waste teams overlook.
Quality Sprint: How a Workshop Solves Quality Problems
A Quality Sprint tackles persistent quality issues in one workshop day with all stakeholders, ending in three to four next steps with clear owners.
Positive Leadership: How PERMA Links Well-Being and Results
Positive leadership ties appreciation to measurable results. The PERMA model names five evidence-based strategies for well-being and performance.
Security Requirements: Assets First, Then Requirements
Security requirements stay abstract until a team defines what the system actually protects. CIA goals and threat modeling make it tangible.
Business Value of Testing: Translate Risk into Money
The business value of testing shows up in money: regression time, support costs, failed releases. Automating a product about to change can lose money.
QFD: The Cause-and-Effect Analysis LLMs Can't Deliver
Quality Function Deployment (QFD) links customer benefits to functions and tests, the cause-and-effect analysis LLMs can't do. The result: fewer tests.
IEC 62443-4-1: A Toolbox for the Cyber Resilience Act
IEC 62443-4-1 builds security into the process from the first design step and covers much of what the Cyber Resilience Act will require from 2027.
Formal Methods: Why Is Functional Programming Helpful?
Formal methods sound like an ivory tower, but they provide what testing alone can never do: mathematical proof of correct behavior.
Software Contracts: Agile Teams Often Owe the Whole Backlog
Two missing sentences in a software contract can drive a company into bankruptcy. Why agile software projects end up as contracts for work.
End-to-End Testing Framework: Start with Requirements
Choosing an end-to-end testing framework starts with needs like Safari support, speed and mobile emulation. Cypress, Playwright, Nightwatch compared.
AI in Requirements Engineering Requires Precise Prompts
AI requirements engineering only delivers testable requirements with precise prompts: scope, context, requirement level and templates, refined in steps.
Given When Then: BDD Scenarios Grow from Shared Examples
Given-when-then scenarios pay off when business and tech write the examples together. BDD is not a testing technique: the scenarios drive the code.
Accessible PDFs: Let People with Disabilities Test Them
Accessible PDFs need clean headings, alt text and labeled tables. For contracts, invoices and archives, converting old files is a migration project.
Changing Careers to Testing: An Internship Beats Certifications
Changing careers to testing works without an IT background, as one path from the French embassy shows. An internship counts for more than certificates.
Test Case Prioritization with a Multidimensional Risk Score
Test case prioritization without gut feeling: five levels, Fibonacci ratings and one risk score decide which test cases run first under time pressure.
Product Discovery: Reducing Risk Before Code Is Written
The product discovery process clears up the real problem before any code is written: a kick-off workshop, user research, Crazy 8 and paper prototypes.
Collaborative Software Design: Surface Assumptions Early
Collaborative software design puts developers, testers, architects and business experts around one model. Event storming exposes hidden assumptions.
Holistic Testing: Quality Work at Every Stage of the Loop
Holistic testing makes the whole team own quality, with testing at every stage of the DevOps loop. Shared understanding early prevents costly rework.
Legacy Modernization: Why Missing Experts Are the Bottleneck
Legacy modernization usually stalls on missing subject matter experts. How RAG makes legacy code queryable and why working in slices lowers the risk.
Rosenberg's Nonviolent Communication in Everyday Testing
Nonviolent communication has four components: Observation, feeling, need, request. What this looks like in everyday testing.
What Informal Networks Mean for How Your Company Works
Informal networks are who people actually turn to when things go wrong. Why they decide how fast teams adapt, and why you cannot order them into being.
Requirements Analysis with DEFOSPAM: Finding Gaps Early
Requirements analysis with DEFOSPAM: seven question areas expose unclear definitions, ambiguity and missing parts. AI adds ideas, people judge them.
Business Analysts and Testers: Spotting Edge Cases Early
A business analyst who thinks like a tester spots edge cases before any code exists. A data warehouse project shows why testers should question specs.
Form Testing: Model-Based Test Data via SMT Solver
Form testing for over 255 tax form variants across 16 states: an SMT solver derives valid test data from the model and exposes contradictory rules.
Accessibility Under the BFSG: What B2C Companies Must Do
Since June 2025, the BFSG makes accessibility mandatory for B2C companies, with fines up to 100,000 euros. WCAG-based tasks help teams comply.
Quality Requirements Call for an Adaptable Architecture
Separating functional and quality requirements sounds clean, but in practice the line blurs. Good architecture hides decisions and stays changeable.
Shift Left in Acceptance Testing: Build Trust Early
Shift left in acceptance testing means testers shape requirements early. Acceptance tests then build trust instead of hunting bugs just before delivery.
Continuous Discovery: Domain Expertise Belongs on the Team
Continuous discovery fills the gap Scrum leaves before the backlog. Event storming, story mapping and Gemba walks help the team understand customers.
Fair AI: Assurance Case Makes Fairness Testable
Fair AI sounds good, but what does it mean in measurable terms? Fairness measures contradict each other, so an assurance case breaks the claim down.
Software Metrics: It’s the Context That Makes a Number Useful
Software metrics are often avoided because they reveal inconvenient truths. Yet a simple table can be enough to forecast testing effort and defects.
User Story Testing: Make Stories Testable with Examples
User story testing starts with acceptance criteria written as concrete examples. Add specs only where they help, and use the light Three Xs strategy.
Quality by Design in Software: Prevent Errors Early
Quality by design in software prevents errors before testing has to find them. The pharma-born approach rests on risk analysis and process metrics.
Domain Storytelling: Users and Developers Model Together
Domain storytelling is collaborative modeling: users tell stories from their domain, the team draws actors, work objects and activities as a diagram.
Coaching Lessons for Testers: Clarify the Assignment First
Software testing starts with clarifying the assignment, or errors surface late and get expensive. One of several lessons testers can take from coaching.
BDD Scenarios: Gherkin Written Afterwards Is Not BDD
BDD scenarios look simple, but Gherkin without real team conversations costs more than it brings. Why five to seven steps keep a scenario readable.
Sustainable Software Development: How Testing Saves Energy
Sustainable software development starts with the requirements, long before deployment. Performance, maintainability and lean test pipelines all count.
BDD Testing: Given-When-Then for Business and Developers
BDD testing uses Given-When-Then scenarios so business stakeholders and developers share one understanding of a feature before any code is written.