🖼️ See the drawing + lab 🏠 Course home 🌿 Branch on GitHub ✏️ View source

🖼️ आकृती आणि labThe drawing + lab पूर्ण पानावर उघडा ↗Open full page ↗

🎯 धडा 03 — Test design: योग्य प्रश्न 34.5 वरचा bug शोधतात

📍 तुम्ही इथे आहात: 12 पैकी धडा 03 · मागे: lesson-02-unit-tests · पुढे: lesson-04-fixtures

📦 या ब्रँचमध्ये काय आहे

धडे 01–02, आणि प्रश्न कसे निवडायचे: equivalence classes (उत्तराच्या प्रत्येक प्रकारासाठी एक प्रश्न), boundary values (नेमके कडांवरचे प्रश्न, जिथे bugs राहतात) आणि decision tables (नियमांच्या प्रत्येक जोडीसाठी एक प्रश्न). यांच्या मदतीने कतरिनाला grade_v1 चा 34.5 वरचा bug सापडतो — आणि आणखी दोन. exam/demo.py मधले design().

🧒 5 वर्षांच्या मुलाला समजावल्यासारखे

कतरिना प्रत्येक शक्य score बद्दल विचारू शकत नाही. म्हणून ती गटांमध्ये विचार करते. 🗂️

45 ते 59 मधल्या सगळ्या scores ना C मिळतो. 50 किंवा 52 बद्दल विचारले तरी तिला तेच कळते. म्हणून सुरुवातीला प्रत्येक गटातून एक प्रश्न पुरेसा: एक F, एक D, एक C, एक B, एक A — आणि दोन विचित्र scores, −0.1 आणि 100.1, जे नाकारले गेलेच पाहिजेत.

सात प्रश्न. सातही pass. Bug अजूनही तिथेच आहे.

मग ती विचार करते: "चुका कुठे होतात? गटांमधल्या कडांवर." 🚧 म्हणून ती 34.4, 34.5, 34.6 आणि 35 बद्दल विचारते. आणि तसेच 45, 60 आणि 75 वर.

34.5 वर code म्हणतो F. नियम म्हणतो D. पकडला. 🎯 आणि 44.5 आणि 74.5 वरसुद्धा.

शेवटी, report card: "average pass असेल आणि attendance किमान 75% असेल तर promoted — किंवा medical note असेल तर". तीन हो/नाही प्रश्नांच्या 8 जोड्या होतात. कतरिना सगळ्या 8 चा एक तक्ता काढते, म्हणजे कोणतीही जोडी विसरली जात नाही.

🗺️ आकृती

flowchart LR
    subgraph eq["🗂️ equivalence classes: 7 questions, 0 bugs"]
      e["-0.1 refused · 17 F · 40 D · 52 C · 67 B · 88 A · 100.1 refused"]
    end
    subgraph bv["🚧 boundary values: 16 questions, 3 bugs"]
      b["34.4 F · 34.5 v1 F, rule D ← BUG · 35 D<br/>44.5 ← BUG · 59.5 ok by luck · 74.5 ← BUG"]
    end
    subgraph dt["📋 decision table: 3 conditions, 8 rules"]
      d["average passes? · attendance at least 75%? · medical note?"]
    end
    eq --> bv --> dt

🗺️ काढलेली आवृत्ती + एक lab: https://school-edh.pages.dev/testing/lesson-diagrams.html#l03

❓ काय

Equivalence partitioning (equivalence classes) — inputs ना अशा गटांत विभागा ज्यांना code ने सारखेच वागवायला हवे, आणि प्रत्येक गटातून एक किंमत test करा. grade साठी: 0 खाली, F, D, C, B, A, 100 वर — सात classes.
Boundary value analysis — bugs classes च्या कडांवर गोळा होतात: >= विरुद्ध >, off-by-one, rounding. कड स्वतः आणि दोन्ही बाजूंचे तिचे सर्वात जवळचे शेजारी test करा. Round केलेल्या score वरच्या नियमासाठी, शेजारी म्हणजे प्रत्येक बाजूला round होणाऱ्या किमती: 34.4 आणि 34.5.
Decision table — अटींची प्रत्येक जोडी (इथे 2 × 2 × 2 = 8) आणि प्रत्येकीचा अपेक्षित निकाल यांची यादी करा. कोणीच न सांगितलेल्या जोड्या त्यातून उघड होतात.
Exhaustive testing — प्रत्येक input वापरून पाहणे. सहसा अशक्य (floats, strings), पण input space लहान असेल तेव्हा ही सर्वात भक्कम test असते: demo 0 ते 100 मधले सगळे 201 half-mark scores तपासतो.
Parametrized test — एकच test body, (input, expected) ओळींचा एक तक्ता. प्रत्येक ओळ वेगळी report होते.
Round-half-to-even — Python च्या round() चा नियम: बरोबरी झाल्यास सम शेजाऱ्याकडे. म्हणूनच 34.5 → 34 (इथे चूक) पण 59.5 → 60 (योगायोगाने बरोबर).

🤔 का

कारण शक्य inputs ची संख्या प्रचंड आहे आणि तुम्हाला परवडणाऱ्या tests ची संख्या लहान. Test design म्हणजे चुकीचे उत्तर पकडण्याची सर्वाधिक शक्यता असलेले थोडे प्रश्न निवडणे. सात class प्रश्नांची किंमत सात boundary प्रश्नांइतकीच आहे, पण bug फक्त boundary प्रश्नांनाच सापडला.

🔧 कसे (या repo मध्ये)

exam/demo.py मधले design() सात class किमती grade मधून चालवते, मग दहा boundary किमती grade_v1 आणि grade दोन्हींमधून चालवून प्रत्येक फरक खुणावते, मग 0 ते 100 मधले सगळे 201 half marks. Decision table exam/grades.py मधले report_card() average (70 किंवा 30), attendance (90% किंवा 60%) आणि medical note (हो किंवा नाही) यांच्या 8 पैकी प्रत्येक जोडीसाठी बोलवते.

🧪 करून पाहा

python3 exam/demo.py design
python3 - <<'EOF'
from exam.grades import grade, grade_v1
classes = {"invalid low": -0.1, "F": 17, "D": 40, "C": 52, "B": 67, "A": 88, "invalid high": 100.1}
for name, s in classes.items():
    try: print(f"{name:<12} {s:>5} → v1 {grade_v1(s)} · fixed {grade(s)}")
    except ValueError: print(f"{name:<12} {s:>5} → refused")
edges = []
for cut in (35, 45, 60, 75):
    edges += [cut - 0.6, cut - 0.5, cut - 0.4, cut]
found = [s for s in edges if grade_v1(s) != grade(s)]
print(f"{len(edges)} boundary questions, v1 wrong at {[round(s, 1) for s in found]}")
print("the classes alone found:", [n for n, s in classes.items() if s >= 0 and s <= 100 and grade_v1(s) != grade(s)])
EOF

✅ तपासा — तुम्हाला काय दिसायला हवे

design छापते (काही भाग):

    34.4: v1 F · fixed F
    34.5: v1 F · fixed D   ← BUG
      35: v1 D · fixed D
    44.5: v1 D · fixed C   ← BUG
    59.5: v1 B · fixed B
    74.5: v1 B · fixed A   ← BUG
   every half-mark 0–100 (201 scores): v1 is wrong at [34.5, 44.5, 74.5] — round() sends halves to the EVEN number
   average 70 · attendance 60% · note yes → promoted
   average 30 · attendance 90% · note yes → held back

तुमचा snippet छापतो:

invalid low   -0.1 → refused
F               17 → v1 F · fixed F
D               40 → v1 D · fixed D
C               52 → v1 C · fixed C
B               67 → v1 B · fixed B
A               88 → v1 A · fixed A
invalid high 100.1 → refused
16 boundary questions, v1 wrong at [34.5, 44.5, 74.5]
the classes alone found: []

🏁 तुम्ही आत्ताच काय सिद्ध केले

सात नीट निवडलेल्या class प्रश्नांना काहीच सापडले नाही; सोळा boundary प्रश्नांना तिन्ही चुकीचे scores सापडले. Classes तरीही उपयोगी आहेत — प्रत्येक grade पर्यंत पोहोचता येते आणि विचित्र scores नाकारले जातात हे त्या सिद्ध करतात — पण bugs कडांवर होते. Decision table असा नियम दाखवते जो वाचणाऱ्याच्या नजरेतून सुटू शकतो: medical note कमी attendance ला वाचवते, पण fail होणाऱ्या average ला कधीच नाही (average 30 · note yes → held back).

⚠️ नेहमीच्या चुका

प्रत्येक class चा मधला भाग test करणे आणि कड कधीच नाही
कड फक्त एकाच बाजूने test करणे (35 पण 34.5 नाही)
अवैध classes विसरणे: negative, खूप मोठे, रिकामे, चुकीचा type
नियमाच्या प्रत्येक ओळीसाठी एक test ऐवजी code मधल्या प्रत्येक if साठी एक test — code मध्ये एखादी ओळच नसू शकते
code मधल्या boundaries test मध्ये copy करणे, म्हणजे चुकीची boundary स्वतःशीच तपासली जाते

🏭 प्रत्यक्ष वापरात

खऱ्या project वर — boundary तक्ता एकाच parametrized pytest test मध्ये; प्रत्येक ओळ स्वतःच्या line वर report होते:

import pytest
from exam.grades import grade

@pytest.mark.parametrize("score, expected", [
    (34.4, "F"), (34.5, "D"), (35, "D"),
    (44.4, "D"), (44.5, "C"), (45, "C"),
    (59.4, "C"), (59.5, "B"), (60, "B"),
    (74.4, "B"), (74.5, "A"), (75, "A"),
])
def test_grade_boundaries(score, expected):
    assert grade(score) == expected

unittest मध्ये हीच कल्पना subTest वापरते, म्हणजे एक failing ओळ बाकीच्यांना लपवत नाही:

def test_boundaries(self):
    for score, expected in [(34.5, "D"), (44.5, "C"), (74.5, "A")]:
        with self.subTest(score=score):
            self.assertEqual(grade(score), expected)

ही तंत्रे ISTQB tester syllabus मध्ये standard आहेत (equivalence partitioning, boundary value analysis, decision table testing, state transition testing) आणि कोणत्याही भाषेत लागू होतात.

🏭 Production मध्ये हे का महत्त्वाचे: ज्या नियमात एखादा आकडा आहे — pass mark, price threshold, rate limit, date cut-off — त्या प्रत्येकासाठी आधी boundary तक्ता लिहा. Users नी report केलेले बहुतेक "अशक्य" bugs नेमके एखाद्या कडेवर बसलेले असतात.

⏭️ पुढे

चांगल्या प्रश्नांना चांगल्या उत्तरपत्रिका लागतात: test data. प्रत्येक test मध्ये त्या हाताने बनवणे हळू आणि नाजूक आहे. Builders, setup आणि teardown, आणि एकमेकांवर अवलंबून नसलेले tests.

git checkout lesson-04-fixtures

🎯 Lesson 03 — Test design: the right questions find the bug at 34.5

📍 You are here: Lesson 03 of 12 · Previous: lesson-02-unit-tests · Next: lesson-04-fixtures

📦 What's in this branch

Lessons 01–02, plus how to choose questions: equivalence classes (one question per kind of answer), boundary values (questions right at the edges, where bugs live) and decision tables (one question per combination of rules). With them, Katrina finds grade_v1's bug at 34.5 — and two more. design() in exam/demo.py.

🧒 Explain like I'm 5

Katrina cannot ask about every possible score. So she thinks in groups. 🗂️

All scores from 45 to 59 get a C. Asking about 50 or 52 tells her the same thing. So one question per group is enough to start: one F, one D, one C, one B, one A — and two silly scores, −0.1 and 100.1, which must be refused.

Seven questions. All seven pass. The bug is still there.

Then she thinks: "Where do mistakes happen? At the edges between groups." 🚧 So she asks about 34.4, 34.5, 34.6 and 35. And the same at 45, 60 and 75.

At 34.5, the code says F. The rule says D. Caught. 🎯 And at 44.5 and 74.5 too.

Last, the report card: "promoted if the average passes and attendance is at least 75% — or there is a medical note". Three yes/no questions make 8 combinations. Katrina draws a table with all 8, so no combination is forgotten.

🗺️ Diagram

flowchart LR
    subgraph eq["🗂️ equivalence classes: 7 questions, 0 bugs"]
      e["-0.1 refused · 17 F · 40 D · 52 C · 67 B · 88 A · 100.1 refused"]
    end
    subgraph bv["🚧 boundary values: 16 questions, 3 bugs"]
      b["34.4 F · 34.5 v1 F, rule D ← BUG · 35 D<br/>44.5 ← BUG · 59.5 ok by luck · 74.5 ← BUG"]
    end
    subgraph dt["📋 decision table: 3 conditions, 8 rules"]
      d["average passes? · attendance at least 75%? · medical note?"]
    end
    eq --> bv --> dt

🗺️ Drawn version + a lab: https://school-edh.pages.dev/testing/lesson-diagrams.html#l03

❓ What

Equivalence partitioning (equivalence classes) — split the inputs into groups the code should treat the same, and test one value from each. For grade: below 0, F, D, C, B, A, above 100 — seven classes.
Boundary value analysis — bugs cluster at the edges of classes: >= vs >, off-by-one, rounding. Test the edge itself and its nearest neighbours on both sides. For a rule on a rounded score, the neighbours are the values that round to each side: 34.4 and 34.5.
Decision table — list every combination of conditions (here 2 × 2 × 2 = 8) and the expected outcome of each. It exposes combinations nobody specified.
Exhaustive testing — trying every input. Usually impossible (floats, strings), but when the input space is small it is the strongest test there is: the demo checks all 201 half-mark scores from 0 to 100.
Parametrized test — one test body, a table of (input, expected) rows. Each row is reported separately.
Round-half-to-even — Python's round() rule: a tie goes to the even neighbour. That is why 34.5 → 34 (wrong here) but 59.5 → 60 (right by luck).

🤔 Why

Because the number of possible inputs is enormous and the number of tests you can afford is small. Test design is how you pick the few questions most likely to catch a wrong answer. Seven class questions cost the same as seven boundary questions, but only the boundary questions found the bug.

🔧 How (in this repo)

design() in exam/demo.py runs seven class values through grade, then ten boundary values through both grade_v1 and grade and marks each difference, then all 201 half marks from 0 to 100. The decision table calls report_card() from exam/grades.py for each of the 8 combinations of average (70 or 30), attendance (90% or 60%) and a medical note (yes or no).

🧪 Try it

python3 exam/demo.py design
python3 - <<'EOF'
from exam.grades import grade, grade_v1
classes = {"invalid low": -0.1, "F": 17, "D": 40, "C": 52, "B": 67, "A": 88, "invalid high": 100.1}
for name, s in classes.items():
    try: print(f"{name:<12} {s:>5} → v1 {grade_v1(s)} · fixed {grade(s)}")
    except ValueError: print(f"{name:<12} {s:>5} → refused")
edges = []
for cut in (35, 45, 60, 75):
    edges += [cut - 0.6, cut - 0.5, cut - 0.4, cut]
found = [s for s in edges if grade_v1(s) != grade(s)]
print(f"{len(edges)} boundary questions, v1 wrong at {[round(s, 1) for s in found]}")
print("the classes alone found:", [n for n, s in classes.items() if s >= 0 and s <= 100 and grade_v1(s) != grade(s)])
EOF

✅ Verify — what you should see

design prints (in part):

    34.4: v1 F · fixed F
    34.5: v1 F · fixed D   ← BUG
      35: v1 D · fixed D
    44.5: v1 D · fixed C   ← BUG
    59.5: v1 B · fixed B
    74.5: v1 B · fixed A   ← BUG
   every half-mark 0–100 (201 scores): v1 is wrong at [34.5, 44.5, 74.5] — round() sends halves to the EVEN number
   average 70 · attendance 60% · note yes → promoted
   average 30 · attendance 90% · note yes → held back

Your snippet prints:

invalid low   -0.1 → refused
F               17 → v1 F · fixed F
D               40 → v1 D · fixed D
C               52 → v1 C · fixed C
B               67 → v1 B · fixed B
A               88 → v1 A · fixed A
invalid high 100.1 → refused
16 boundary questions, v1 wrong at [34.5, 44.5, 74.5]
the classes alone found: []

🏁 What you just proved

Seven well-chosen class questions found nothing; sixteen boundary questions found all three wrong scores. The classes are still worth having — they prove each grade is reachable and that silly scores are refused — but the bugs were at the edges. The decision table shows a rule a reader might miss: a medical note rescues low attendance, never a failing average (average 30 · note yes → held back).

⚠️ Common mistakes

testing the middle of each class and never the edge
testing the edge on one side only (35 but not 34.5)
forgetting invalid classes: negative, too big, empty, wrong type
one test per if in the code instead of one test per row of the rule — the code may be missing a row
copying the boundaries from the code into the test, so a wrong boundary is checked against itself

🏭 In production

On a real project — the boundary table as one parametrized pytest test; each row is reported on its own line:

import pytest
from exam.grades import grade

@pytest.mark.parametrize("score, expected", [
    (34.4, "F"), (34.5, "D"), (35, "D"),
    (44.4, "D"), (44.5, "C"), (45, "C"),
    (59.4, "C"), (59.5, "B"), (60, "B"),
    (74.4, "B"), (74.5, "A"), (75, "A"),
])
def test_grade_boundaries(score, expected):
    assert grade(score) == expected

The same idea in unittest uses subTest, so one failing row does not hide the others:

def test_boundaries(self):
    for score, expected in [(34.5, "D"), (44.5, "C"), (74.5, "A")]:
        with self.subTest(score=score):
            self.assertEqual(grade(score), expected)

These techniques are standard in the ISTQB tester syllabus (equivalence partitioning, boundary value analysis, decision table testing, state transition testing) and apply in any language.

🏭 Why this matters in production: for every rule with a number in it — a pass mark, a price threshold, a rate limit, a date cut-off — write the boundary table first. Most "impossible" bugs reported by users sit exactly on an edge.

⏭️ Next

Good questions need good answer sheets: the test data. Building them by hand in every test is slow and fragile. Builders, setup and teardown, and tests that do not depend on each other.

git checkout lesson-04-fixtures

← Previousunit tests Next →fixtures

This page is the lesson's README from the lesson-03-test-design branch, shown here so the whole School stays on one site. Code files open on GitHub at the same branch.