จาก blog ก่อนหน้า เมื่อมีสายดำก็ต้องมีสายขาว เมื่อมี Black box testing แล้ว ก็คงจะต้องมี White box Testing สินะ (ตามๆเค้าไป)

White box Testing แท้จริงแล้วเป็นเทคนิคสำหรับฝั่ง Developer ค่ะ แต่จะมีอีกเทคนิคนึงที่ QA ใช้กัน นั่นก็คือ Grey box Testing (บร๊ะ! มาได้ไงฟร๊ะ) มันเป็นการฟีเจอร์ริ่งกันระหว่าง White box Testing กับ Black box Testing นั่นเอง เดี๋ยวจะเล่าให้ฟังใน blog ถัดไปละกันนะ

Grey Box Testing

QA หลายคนคงจะงงว่าแล้วตรูจะรู้ White box Testing ไปเพื่ออะไรฟร๊ะครัช คำตอบคือ รู้ไว้เถอะ จะได้คุยกับ Developer รู้เรื่อง!! งั้นท่าน QA ทั้งหลายจงตาม P’Ploy มา เดี๋ยวจะเล่าให้ฟัง…

 

คืออะไร?

White box testing ก็คือกล่องสีขาวๆ ที่เรามองเห็นว่ามีอะไรอยู่ข้างในบ้าง ซึ่งก็คือ code ที่ developer เขียนนั่นเอง(แต่ถ้ามันจำไม่ได้ว่าเขียนอะไรมา ก็ตัวใครตัวมันนะจ๊ะ) โดยจะออกแบบ Test case ให้ครอบคลุมทั้ง เงื่อนไข และ input ต่างๆ ค่ะ แต่เห็นอย่างนี้มันไม่ได้มีวิธีการเดียวนะ มันมีให้เลือกเอามาใช้ตั้งหลายวิธีแหน่ะตัวเธอ !!!!

 

4 วิธีดี๊ดี ใช้ได้เลย ไม่เคยบิดพริ้ววววว

วิธีดี๊ดีที่ 1. Statement coverage

วิธีนี้เราจะเทสเฉพาะเคสที่เป็น true และ 1 เทสเคส ต่อ 1 condition …งงดิ งั้นดูตัวอย่าง

Statement Coverage Picture

จากตัวอย่างข้อนี้ Test case ที่ได้ ก็คือ

Statement Test case Example

 

วิธีดี๊ดีที่ 2. Decision coverage

วิธีนี้เราจะเทสให้ครอบคลุมกับทุกๆทางเลือก ทั้งเคสที่เป็น true และ false ซึ่งจะการันตีได้ว่าหากเราเขียน Test case ครอบคลุม 100% ของ decision coverage ได้ จะถือได้ว่าเราได้ครอบคลุม Statement coverage ด้วยนะ สุดยอดปะล่ะ ดูตัวอย่าง

Test case ที่ได้ ก็คือ

Decision Coverage Test case Example

 

วิธีดี๊ดีที่ 3. Condition coverage

วิธีนี้ซับซ้อนขึ้นมาอีกหน่อย เราจะเทสให้ครอบคลุมกับทุกๆเงื่อนไข ทั้งเคสที่เป็น true และ false

จากตัวอย่างเดิม เราสามารถแยกเทสเคสได้ดังนี้

Test case ที่ได้ ก็คือ

 

วิธีดี๊ดีที่ 4. Decision and condition coverage

วิธีนี้เป็นวิธีที่ละเอียดและครอบคลุมที่สุด เราจะเทสให้ครอบคลุมกับทุกๆทางเลือกและทุกๆเงื่อนไข ทั้งเคสที่เป็น true และ false เลย นั่นก็คือการเอา Decision coverage รวมร่างกับ Condition coverage นั่นเอง

Test case ที่ได้

Desicion&Condition Coverage Testcase example

เมื่อรู้อย่างนี้แล้ว เราสามารถนำหลักการเหล่านี้ไปประยุกต์ใช้ หรือหากในทีม Developer เองยังไม่มีหลักในการออกแบบ Test case QA เองก็สามารถช่วยไกค์แนวทางนี้ให้กับ developer ได้ค่ะ เพื่อคุณภาพของโปรแกรมที่ดีขึ้นต่อๆไปค่ะ

สุดท้ายนี้ ถ้าชอบกด Like ถ้าใช่กด Share กันได้เลยจ้าและอย่าลืมติดตาม Blog ต่อไปกับ QA Hive 🙂

References: