Test Design Techniques#

Requirement บอกว่า capacity ของ workshop อยู่ระหว่าง 1–500 ทีมเขียน test ค่า 20 แล้วจบ ทั้งที่ defects มักเกิด ตรง 0, 1, 500, 501 หรือเมื่อ rule หลายข้อชนกัน Test design techniques เปลี่ยน requirement/risk/model ให้เป็น test conditions อย่างเป็นระบบก่อนเลือกว่าจะ automate ที่ layer ใด

Technique ไม่ใช่ Test Level#

Technique คือวิธีเลือก conditions/data เช่น boundary analysis ส่วน test level/seam คือจุดที่ execute เช่น pure function, service API หรือ browser UI Boundary เดียวกันอาจตรวจระดับ unit เพื่อ feedback เร็ว และมี browser case หนึ่งเพื่อยืนยัน form/API mapping โดยไม่จำเป็นต้องทำทุกค่าในทุก layer

ISTQB แบ่ง techniques กว้าง ๆ เป็น:

• Black-box — derive จาก specification/behavior โดยไม่อาศัย internal structure
• White-box — derive จาก code/architecture/control/data flow
• Experience-based — ใช้ความรู้ defect, domain และการเรียนรู้ระหว่างสำรวจ
• Collaboration-based — ตัวอย่างและ acceptance criteria ที่ทีมสร้างร่วมกับ stakeholder

แต่ละชนิดค้นหาช่องว่างต่างกันและใช้ร่วมกันได้

Equivalence Partitioning#

แบ่ง input/output domain เป็น partitions ที่คาดว่าระบบปฏิบัติเหมือนกัน แล้วเลือก representative จากทุก valid/invalid partition สำหรับ capacity 1–500:

อย่ารวม missing, wrong type และ out-of-range เป็น invalid ก้อนเดียวหากระบบมี validation paths/error contracts ต่างกัน Partition มาจาก test basis และ risk ไม่ใช่เดาจาก implementation เท่านั้น

Boundary Value Analysis#

Defects มักอยู่จุดเปลี่ยน behavior จึงเลือกค่าที่ boundary และเพื่อนบ้าน:

Minimum boundary: 0, 1, 2
Maximum boundary: 499, 500, 501

ถ้า contract เป็น [1, 500] ค่า 1/500 อยู่ใน ส่วน 0/501 อยู่นอก Two-value BVA อาจใช้ boundary value 2 ด้าน Three-value BVA เพิ่ม neighboring value อีก 1 ค่า โดยเลือกด้านที่จำเป็นตาม risk และ test level

สำหรับ datetime boundary ต้องระบุ instant/timezone/precision:

cutoff = 2030-06-15T08:00:00.000Z
07:59:59.999Z → allow
08:00:00.000Z → contract ต้องบอก allow หรือ reject
08:00:00.001Z → reject

ถ้า requirement ไม่บอก equality นั่นคือ ambiguity ที่ static testing ควรแก้ก่อน automate

Decision Table Testing#

ใช้เมื่อผลขึ้นกับ conditions หลายข้อ ตารางบังคับให้เห็น combinations และ precedence สำหรับ Reserve:

— หมายถึง condition ไม่กระทบผลภายใต้ rule นั้น ตารางนี้เผยคำถาม precedence เช่น unauthenticated request ต่อ closed workshop ควรตอบ authentication ก่อนหรือเปิดเผย status ได้หรือไม่ Product/security owner ต้องเลือก contract

Decision table ช่วยลด combinations ด้วยการรวม don't-care แต่ต้องระวัง rule ที่หายและ impossible combination Trace แต่ละ automated test กลับไป rule ID ได้

State Transition Testing#

Behavior ที่ขึ้นกับ current state ต้องตรวจ valid/invalid transitions ไม่ใช่แค่ endpoint แยก:

System map

สร้าง transition table:

ครอบ states อย่างเดียวไม่เท่ากับ transition coverage และ transition pairs/sequences อาจเปิด defect ที่ single transition ไม่เห็น เช่น close → reopen → reserve State model ต้องระบุ side effects/invariants ไม่ใช่แค่ status field

Scenario และ Acceptance Examples#

Concrete examples ช่วย business/technology สร้าง shared understanding:

Given workshop A is open with one seat remaining
And learner B has no reservation
When learner B reserves workshop A
Then one confirmed reservation exists for learner B
And seats remaining becomes zero
And a second request with the same request id returns the same reservation

Example นี้ให้ oracle หลายชั้น: visible outcome, persisted effect และ idempotent behavior แต่ยังต้องเติม negative, boundary, concurrency และ quality risks อย่าให้ Given/When/Then กลายเป็น prose ที่ไม่มี owner หรือ executable contract

White-box Coverage#

Statement coverage บอก statements ที่ execute Branch coverage สนใจ outcomes ของ decisions เช่น true/false มีประโยชน์กับ internal logic และหา unexecuted paths แต่ coverage สูงไม่รับประกัน oracle ถูกหรือ requirements ครบ:

if (!registrationOpen) return 'CLOSED'
if (hasReservation) return 'EXISTING'
return seatsRemaining > 0 ? 'CONFIRMED' : 'WAITLISTED'

Black-box decision table อาจ derive cases โดยไม่เห็น code ส่วน branch coverage บอกว่าทุก branch ใน implementation ถูก execute การใช้ทั้งคู่ช่วยพบทั้ง missing requirement rule และ untested implementation path

Error Guessing และ Defect Taxonomy#

Experience-based testing ใช้ incident/history/domain knowledge เช่น:

• double click และ retry หลัง response หาย
• browser back/refresh ระหว่าง submit
• Unicode, whitespace, duplicate title และ very long text
• timezone/DST และ clock skew
• stale page หลัง organizer ปิด workshop
• two learners แข่ง last seat

เก็บ error guesses เป็น defect taxonomy พร้อม source เช่น incident ID, production metric หรือ prior bug ไม่ใช่ checklist ไร้ที่มา แล้วทบทวนเมื่อ architecture เปลี่ยน

Exploratory Testing#

Exploratory testing ออกแบบ, execute และประเมิน tests พร้อมกับเรียนรู้ระบบ ไม่ใช่ “คลิกสุ่ม” ใช้ time-boxed charter:

Mission: สำรวจการจองเมื่อสถานะเปลี่ยนระหว่างที่ผู้ใช้เปิดหน้า
Focus: stale data, duplicate action, messaging, recovery
Data: workshop capacity 1; learner accounts A/B; throttled network
Duration: 45 minutes
Oracles: reservation invariant, approved status model, user-visible consistency
Record: notes, timeline, screenshots, candidate regression tests, questions
Debrief: product + developer + tester

Scripted regression ป้องกัน behavior ที่รู้แล้ว Exploratory session ค้นหา questions/risks ใหม่ ทั้ง 2เสริมกัน เมื่อพบ stable high-value behavior ให้ย้ายเป็น automated regression ที่ seam คุ้มค่า

Pairwise และ Combinatorial Thinking#

Browser × role × locale × theme × workshop state × network condition สร้าง combinations จำนวนมาก Pairwise tools ช่วยเลือกชุดที่ครอบ interaction ระหว่างทุกคู่ของ factor values แต่ไม่รับประกัน multi-way defect หรือ business-critical combination ต้องเพิ่ม mandated scenarios ตาม risk เสมอ และห้ามใช้ pairwise กับ sequential state/race โดยไม่สร้าง model

จาก Technique ไป Test Portfolio#

Condition: capacity boundaries
Technique: equivalence partitioning + BVA
Fast seam: domain/service validation tests ครบทุกค่า
API seam: exact status/error schema สำหรับ min/max invalid
Browser seam: one valid + one visible validation case
Residual risk: database integer/constraint mapping มี integration test แยก

เทคนิคเลือก “อะไร” Test strategy เลือก “ที่ไหน/เมื่อไร/ลึกเท่าไร” และ automation design เลือก “ทำซ้ำอย่างไร” บท Risk-Based Automation Strategy จะเชื่อม 3 คำถามนี้เข้ากับ test portfolio

Lab: ออกแบบ Cancellation Tests#

ใช้ cancellation policy สมมติแล้วส่งมอบ:

1. equivalence partitions ของ role, time และ reservation state
2. boundary values รอบ cutoff พร้อม timezone/precision
3. decision table ที่ระบุ precedence ของ auth, ownership, state และ cutoff
4. state/transition table รวม invalid transitions
5. white-box coverage question หลังเห็น implementation
6. exploratory charter สำหรับ stale/multi-tab/network recovery
7. mapping ว่า cases ใดควรอยู่ small, service/API, browser หรือ manual exploration พร้อมเหตุผล

รายการตรวจสอบ#

• Technique แยกจาก test level/tool
• ทุก valid/invalid partition ที่มี behavior ต่างถูกแทน
• Boundary equality, timezone และ precision ระบุชัด
• Decision table มี precedence, don't-care และ impossible rules
• State tests ครอบ invalid transitions และ side effects
• Code coverage ไม่ถูกใช้แทน requirement/risk coverage
• Exploratory charter มี mission, oracles, record และ debrief

อ่านเพิ่มเติม#

• ISTQB CTFL 4.0.1 — Test Analysis and Design
• W3C ACT Rules Format — examples of test cases and expectations