Module 3 · Testing fundamentals

Edge Cases and Corner Cases

By the Mutqan Soft QA team · · 17 min · Beginner

An edge case is a test in which one input or condition sits at an extreme — nothing at all, the largest allowed value, the first or last valid day — while everything else stays ordinary. A corner case puts two or more extremes together. On a gift card form, a message of exactly 150 characters, the maximum, is an edge case; the same message on a card delivered today, the earliest allowed date, is a corner case.

Both are industry terms rather than ISTQB techniques, and teams draw the line a little differently. What counts is the habit: after the typical positive and negative tests pass, push each input to its extremes, then combine the extremes that interact.

Why it matters

Features are built and tried with typical data, so extremes reach code that rarely runs: the branch for an empty list, a length counted in the wrong unit, a date calculated in the server’s time zone instead of the user’s. Such defects survive every ordinary test, then cause a failure for the first customer whose order falls on 29 February.

For the tester, a few deliberate extremes reach code that ordinary data never touches, and they expose gaps in requirements, which rarely say what happens to empty, huge or combined extremes.

One extreme, or several at once

Picture each input as an axis from its smallest to its largest value. A typical test sits in the middle of every axis. An edge case moves one axis to an end, so a failure points to one input. A corner case moves two or more axes to their ends together; that is where interactions hide, when each extreme works alone and the combination does not.

On the gift card form, the message is optional, up to 150 characters, and delivery runs from today to 90 days ahead. An empty message is an edge, delivery today is an edge, and both together are a corner. Edges can be valid or invalid: 150 characters must be accepted, 151 rejected with a clear error.

Corners multiply: ten inputs with two extremes each give 1,024 combinations in which every input is at an extreme. Test the corners where inputs meet in one calculation, record or output.

Gift card form, message length × delivery date: the typical case sits in the middle, four edge cases move one input to an extreme, and four corner cases move both.
Message lengthDelivery date
Todayearliest dateOrdinary dateinside the rangeDay 90latest date
Empty0 charactersCorner casetwo extremes togetherEdge caseone extremeCorner casetwo extremes together
Ordinarya short messageEdge caseone extremeTypicalno extremeEdge caseone extreme
Maximum150 charactersCorner casetwo extremes togetherEdge caseone extremeCorner casetwo extremes together
  • Typical: no input at an extreme
  • Edge case: one input at an extreme, the other ordinary
  • Corner case: both inputs at an extreme together

The grid shows the valid extremes. Each edge is also tested just outside the range: 151 characters, yesterday, day 91.

Where to look: five families of extremes

Finding edge cases needs a checklist, not inspiration. Walk every input, stored value and output through five families.

  • Empty: an empty string, only spaces, 0, an empty list, a 0-byte file, a blank date field.
  • Null and missing: "note": null, "note": "" and a request without note are three different API inputs. None may crash the service or show "null" on screen.
  • Minimum and maximum: exactly the limit and one beyond, a single item, the largest allowed count or file size, a long word without spaces, the largest number the data type holds.
  • Unicode: Arabic and Devanagari, mixed text direction, diacritics, a zero-width space, Arabic-Indic digits such as ١٢٣, an Arabic file name, and an emoji with a skin tone. Thumbs up with a medium skin tone, U+1F44D U+1F3FD, is one visible character but two code points, four UTF-16 code units and eight UTF-8 bytes, so limits counted in visible characters, code units or bytes disagree on the same text.
  • Time and date: midnight, month and year ends, 29 February (2028 is a leap year, 2100 is not), the first and last allowed day, another time zone, a daylight saving change. Asia/Riyadh (UTC+03:00) and Asia/Kolkata (UTC+05:30) have no daylight saving, so a team testing only there never meets one.
The five families of extremes applied to text, numbers, dates and lists or files: what nothing, smallest and largest, and unusual content mean for each input type.
Input typeNothing thereempty, null, missingSmallest and largestminimum and maximumUnusual contentUnicode, time and date
Text"", only spaces, null, no fieldExactly the limit, one beyond, a long word without spacesArabic and Devanagari, mixed direction, an emoji with a skin tone, a zero-width space
Number0, null, no fieldThe limit and one beyond, the largest value the type holdsArabic-Indic digits ١٢٣
Date and timeA date field left blank, nullFirst and last allowed day, end of month and yearMidnight, 29 February, another time zone, a daylight saving change
List or fileAn empty list, a 0-byte fileA single item, the largest allowed count or sizeA file name in Arabic

Try it: Edge Case Generator Try it: Unicode Dataset Generator Try it: Date Test Data Generator

Edge cases and boundary values are not the same

In ISTQB terms, a boundary value is the minimum or maximum value of an ordered equivalence partition. An equivalence partition is a group of values the system should treat the same way, such as all valid message lengths from 0 to 150 characters; ordered means its values can be ranked from smallest to largest. Boundary value analysis, the technique built on boundary values, comes in the test design module. The two ideas overlap, but neither contains the other.

  • Many edges are boundary values: 0 and 150 characters are the ends of the valid message length; 151 is the first invalid length.
  • Some edges have no order, so no boundary: null, an emoji, mixed-direction text.
  • Some boundaries are not extremes: a delivery fee that changes at 100.00 SAR has a boundary inside the valid range.
  • Boundary value analysis is systematic and lets you measure coverage. Edge cases come from checklists and experience, like two ISTQB experience-based techniques you will meet in the test design module: error guessing, which anticipates likely errors, defects and failures from the tester’s knowledge, and checklist-based testing.

Worked example: the gift card

Requirement: "The message is optional, up to 150 characters. Delivery is from today to 90 days ahead. The card is e-mailed at 09:00 in the recipient’s time zone on the delivery date." List the edges of each input, then combine the extremes that meet in one output.

  • Message edges: empty → no message block, never "null"; 150 → shown in full; 151 → rejected, stating the limit; Arabic text and an emoji with a skin tone → displayed intact.
  • Date edges: today and day 90 → accepted; 29 February 2028, whenever it falls within the 90 days → accepted; yesterday and day 91 → rejected.
  • Corner, length × Unicode: 150 visible characters, several of them emoji. If the counter shows 150/150 but the server rejects the message or cuts an emoji in half, the counter and the server count in different units — a defect.
  • Corner, today × sending time: delivery today, ordered at 11:00 in the recipient’s time zone, when 09:00 has already passed there. The requirement is silent: send at once or refuse? Ask the product owner.
  • Corner, day 90 × time zone: at 23:30 in Riyadh a sender picks day 90 for a recipient in Kolkata, where it is already 02:00 the next day. Do the 90 days count from the sender’s today or the recipient’s?

Try it: String Length Counter Try it: Timezone Converter

Common mistakes

  • Treating "edge case" as a name for invalid input; many edges are valid and must be accepted.
  • Testing only English text, so byte and code-unit limits and mixed-direction display are never exercised.
  • Testing extremes only alone, or combining all of them instead of the corners where inputs interact.
  • Testing dates only in the team’s own time zone, on ordinary days.
  • Treating null, an empty string and a missing field as one case.
  • Guessing the expected result when the requirement is silent, instead of asking and recording the answer.

The QA perspective

Edge cases start in refinement: for each field, ask what happens when it is empty, what the largest supported value is, and in whose time zone a date is read. The answers become acceptance criteria. In the worked example, two of three corners ended as questions, which is common: requirements describe ordinary cases.

Record exact data: the string with its length and how it was counted, the time with its time zone. "A 150-character message ending in two emoji" can be reproduced; "a long message" cannot. Keep a team checklist of the five families and extend it whenever a production defect reveals a new extreme.

Practice exercise

Find the edges and corners of a booking form

Your task

A clinic app says: "Patients enter a full name (2 to 60 characters) and an optional note (up to 300 characters), and book a slot from tomorrow up to 30 days ahead, every 15 minutes from 08:00 to 16:45 clinic time (Asia/Riyadh). A reminder SMS is sent 24 hours before the appointment."

List at least eight edge cases and three corner cases, each with an expected result or, where the requirement is silent, a question.

Steps
  1. List the inputs and outputs, including the reminder SMS.
  2. Walk each input through the five families.
  3. Write the expected result of each edge, valid or invalid.
  4. Combine the extremes that meet in one calculation or output.
Show the model answer
Model answer

Edges: names of 2 and 60 characters accepted; an empty name, 1 and 61 characters and only spaces rejected; Arabic and Devanagari names shown correctly. An empty note shown as no note, never "null"; 300 characters accepted, 301 rejected. Tomorrow, day 30, 08:00 and 16:45 offered; today, day 31, 07:45 and 17:00 not offered; 29 February of a leap year offered whenever it falls within the 30 days.

Corners: (1) the 08:00 slot tomorrow booked at 10:00 today — the reminder time has passed; send now or never? (2) a 60-character Arabic name in the reminder — a single SMS with Arabic text usually holds only 70 characters, so it may split or be cut. (3) a phone set to Asia/Kolkata books the first slot, 08:00 — it must be booked as 08:00 clinic time (10:30 on that phone), not 08:00 Kolkata time, which is 05:30 in Riyadh and before opening; the reminder follows the clinic time.

Questions: the late-booking reminder, how emoji count in a name, whether a split SMS is acceptable, and the time zone of "30 days ahead".

Frequently asked questions

What is the difference between an edge case and a corner case?

An edge case puts one input or condition at an extreme while everything else is ordinary. A corner case puts two or more at their extremes at the same time. Test the edges first: if a corner fails while each of its edges passes, you have found an interaction defect.

Is an edge case the same as a boundary value?

Not always. A boundary value is the minimum or maximum of an ordered partition, used by boundary value analysis. Many edge cases are boundary values, but null, an emoji or mixed-direction text have no order, and a boundary in the middle of a range, such as a fee that changes at 100.00, is not an extreme of the input.

Are edge cases the same as negative tests?

No. A negative test checks that invalid input or misuse is handled well. Edge cases can be valid or invalid: a 150-character message must be accepted, a 151-character message rejected. Treat them as a separate way of choosing test data that you combine with positive and negative tests.

How many corner cases should I test?

Not all of them: their number grows quickly with every input you add. Choose combinations in which inputs share a calculation, a stored record or an output, and those whose failure would cost most. Techniques for combinations, such as pairwise testing, come later in the test design module.

References

  • ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023The foundation syllabus of software testing: test levels and types, test design techniques, test management and tools.
  • ISTQB GlossaryISTQBThe standard definitions of testing terms — test case, regression testing, severity, priority, boundary value analysis and the rest.
  • UAX #29: Unicode Text SegmentationUnicode ConsortiumHow text is divided into grapheme clusters, words and sentences — why a "character" count can differ from a code-point or byte count.
  • Time Zone DatabaseIANAThe tz database of the world's time zones and their historical offset and daylight-saving rules, updated several times a year.
Tools

Practise with Mutqan tools

Edge Case Generator

Generate edge cases for strings, numbers, dates, files, lists and concurrency from a field definition.

Test Design

Unicode Dataset Generator

Generate Unicode test strings across scripts (Arabic, Devanagari, CJK, Cyrillic), emoji, combining marks and normalisation forms.

Test Data

String Length Counter

Measure string length in characters, code points, UTF-8 bytes and UTF-16 units.

Formatting

Date Test Data Generator

Generate date datasets: random dates in a range, leap days, month ends, DST edges and multiple formats.

Test Data

Timezone Converter

Convert a date and time between timezones (Riyadh, Amman, Delhi, UTC, New York, London…).

Utilities

Character Counter

Count characters with and without spaces, lines, and check limits for tweets, SMS and meta descriptions.

Formatting

Go deeper

Your progress on this topic

Part of the QA Roadmap