Blog
Mert Özen's blog posts on software development, backend, frontend, and DevOps.
Choosing and Combining Techniques: From Requirements to a Test List, Aligning with Acceptance Criteria and the Limits of AI-Generated Test Cases
The shape of the requirement picks the technique: equivalence partitioning and boundary value analysis for ranges, decision tables for combinations of conditions, state transitions for outcomes that depend on history; combined and deduplicated, they leave one test list. For Bookstore's institutional partial shipment story, five techniques produced 27 conditions, the list came down to 19, and the row where three techniques met caught the bug. A prompt and review checklist for AI test cases.
White-Box and Experience-Based Techniques: Using Branch Coverage for Test Design, Error Guessing, Checklists and Exploratory Testing
In test design, a branch coverage report isn't a target but a tool that points at branches that never ran and yields new test cases; it can't see code that was never written, which error guessing, checklists and exploratory testing find. For Bookstore's coupons, the report found a bug in a cap branch missing from the story, error guessing found the Turkish I bug, and an exploratory session found duplicate orders from double clicks and a negative total; all became regression tests.
Combinatorial Testing: Managing Configuration Explosion with Pairwise, Orthogonal Arrays and PICT
Pairwise testing cuts the cost of every-combination testing by putting every value pair of any two parameters side by side in at least one test; it rests on the assumption that most bugs come from one parameter or the interaction of two. In Bookstore's checkout, each choice's three tests missed the missing English store pickup template; the 11 rows PICT generated from a constrained model caught it. t-wise, orthogonal arrays, seeds, oracles and Playwright projects.
State Transition Testing: Deriving Test Cases from the Order State Machine, Invalid Transitions and 0-Switch/1-Switch Coverage
State transition testing derives test cases from the state diagram and the state table when a system's behavior depends on its history: valid transitions (0-switch), invalid transitions in the table's empty cells, and pairs of consecutive transitions (1-switch). For Bookstore's order, three green tests missed that a shipped order could be cancelled and that an order released from a hold couldn't be shipped; 40 invalid transitions and 10 transition pairs caught both.
Decision Table Testing: Rule Combinations, Collapsing the Table and From Rule Table to Tests
Decision table testing lays out every combination for rules whose outcome depends on several conditions, collapses the table and turns each column into a test. For Bookstore's shipping fee, four green tests written one per sentence missed the contradiction in a Plus member's international shipping and seven undefined coupon cases; the table showed them all before any test was written. Limited and extended-entry tables, "–" and N/A, return approval, and not copying tests from the code's table.
Boundary Value Analysis: 2-Value and 3-Value BVA, Off-by-One, and Date, Money and Length Boundaries
Boundary value analysis picks test values at a partition's boundary and its neighbors rather than its middle; the type's and the rule's precision decide what a neighbor is. In Bookstore, with one green test per partition, free shipping at 500.00 TRY, a November campaign shifted to UTC and a last second closed at 23:59:59 were caught only by boundary tests. 2-value and 3-value BVA, date boundaries with FakeTimeProvider, ISBN length and cart size.
Equivalence Partitioning: Splitting Inputs into Classes, Valid and Invalid Partitions, Coverage and Turning Them into xUnit Theories
Equivalence partitioning splits an input into partitions the code should treat the same way and covers each with one test, while every invalid partition gets a test of its own. In Bookstore's order validator, tests combining two invalid values hid a missing guest payment rule; nine tests derived from the partition table caught it and an undefined enum value bug. Each Choice coverage, output partitions and TheoryData.
What Is Test Case Design? Test Conditions, Test Cases, Coverage Goals and Families of Techniques
Test case design means deriving test cases from the requirement rather than by intuition: a chain from test basis to test condition, coverage item, test case and test data. On Bookstore's institutional order rule, five green tests exercising one scenario missed two bugs; eight tests derived from the rule caught both. Black-box, white-box and experience-based techniques and collaboration-based approaches per ISTQB CTFL v4.0.1.