เสร็จแน่เจ้า Bug .. พลังแห่ง Black-Box Testing Techniques จะลงทัณฑ์แกเอง !!
“เอ้า !? แบบนี้ก็ใส่ข้อมูลอะไรเข้าไป Test ก็ได้เหรอวะ แล้วแบบนี้จะรู้ได้ไงอ่ะ ว่ามันครอบคลุมแล้วจริง ๆ”
เป็นประโยคที่เราพูดกับตัวเอง ตอนนั่งงมทำการบ้าน Test Case ของคอร์สออนไลน์ Tester ที่ซื้อมา เพราะมันชวนสะกิดใจว่าถ้าเราใส่ข้อมูลที่ Test ไปมั่ว ๆ แบบไม่มีหลักการอะไร เราจะรู้ได้ยังไงว่าข้อมูลที่เราใส่ไปจะครอบคลุมกับ Case ที่เรากำลัง Test อยู่
หลังงงงวยอยู่หน้าจอสักแป๊บก็พิมพ์ตะล๊อกต๊อกแต๊กหาข้อมูลว่ามันจะมีวิธีไหนกันน้า ที่จะทำให้เรารู้ว่าข้อมูลที่เราจะใส่เพื่อ Test มันครอบคลุมเพียงพอจริง ๆ .. พิมพ์ตะล๊อกต๊อกแต๊กอยู่ไม่นานเราก็ได้เจอกับสิ่งที่เรียกว่า Black-Box Testing Techniques
เรียกได้ว่าเปิดโลกในตอนนั้นมากทีเดียวเชียว จนตัดสินใจเด็ดขาดว่า ฉันจะต้องเป็น Tester ให้ได้เล๊ยย .. บล็อกนี้จึงเป็นเหมือนสรุปส่วนตัวเอาไว้เตือนตัวเองว่าได้อ่าน ได้ศึกษาอะไรมาบ้างนั้นเองง
ถ้าพร้อมแล้วจะช้าอยู่ไยเลื่อนไปอ่านให้ไวกันเลย โดยก่อนจะเข้าเรื่องเทคนิค อยากพูดถึงเบสิกก่อนว่า Black-Box Testing ที่ว่าเนี้ย คืออะไร สำคัญยังไง แล้วทำไมเราต้องรู้ ไป !! เริ่ม !!
Black-Box testing คืออะไร ?
Black-Box Testing คือ การ Test ที่เราจะไม่สนใจขั้นตอนการทำงานภายในของระบบ คือจะไม่ไปยุ่งกับ source code เลย สนใจเพียงแต่ เมื่อเราใส่ Input เข้าไป Output ที่ได้ออกมาจะต้องตรงกับสิ่งที่เราคาดหวังไว้เพียงเท่านั้น จบ !! เคลียร์ !!
แต่ด้วยการ Test ที่ไม่สนว่าเราจะใส่ Input อะไรเข้าไปก็ได้แบบนี้ จึงเกิดปัญหาขึ้นมาว่า .. แล้วเราจะรู้ได้อย่างไรว่า Input ที่เราใส่ไปนั้นจะครอบคลุม ไม่หลุด Bug ร้ายแรงแบบที่เราคาดไม่ถึงออกไป
ตรงนี้เองที่เราต้องเอา Black-Box Testing Techniques เข้ามาช่วยไกด์ ให้เรามั่นใจว่าข้อมูลที่เราใช้ Test มีประสิทธิภาพมากพอ ไม่เยอะจนเกินจำเป็นและไม่น้อยเกินไปจนไม่ครอบคลุม
Black-Box Testing Techniques มีอะไรบ้าง ?
เมื่อรู้แล้วว่า Black-Box Testing คืออะไร รู้แล้วว่ามีเทคนิคที่ให้ใช้ได้ เป็นประโยชน์นะ .. แต่เพื่อน ๆ หลายคนก็อาจยังสงสัย ที่บอกมีประโยชน์ มันมีประโยชน์ยังไงบ้างอ่ะ ไม่เห็นเก็ทเลย เลยอยากจะอธิบายเพิ่มเติมให้เห็นภาพอีกสักนี๊ด ก่อนลงลึกว่าแต่ละเทคนิคคืออะไร
โดยสมมติว่าเรามี Text Box ที่รับค่าตัวเลขจำนวนเต็มได้ตั้งแต่ 100–599 โดยมี Requirement ให้เช็คตัวเลขที่รับมานั้นตรงกับ HTTP status codes กรณี Successful responses หรือไม่ ? ( 200–299 อิงจาก MDN )
แต่ ๆๆๆ .. ก่อน Test อยากให้ลองมโนว่าหาก Bug นี้หลุดไป เราจะโดนปรับ 10 ล้านบาท !!
เอาล่ะดิ .. เป็นเรื่องแล้วไง ถ้า Bug นี้หลุดไปมีหวังเป็นหนี้หัวโตแน่นอน ถ้าหากเราไม่รู้เทคนิคการ Test เมื่อไม่อยากเสี่ยงให้มี Bug หลุดแม้แต่ตัวเดียว เราคงจำเป็นต้องไล่ Test ไปทีละตัวตั้งแต่ 200,201,202, … , 299 เป็นแน่
ซึ่งว่ากันตามตรงวิธีอึด ถึก ทนแบบนี้ก็ไม่ได้ผิดอะไร มันก็สามารถ Test เพื่อหาคำตอบได้ แต่ลองคิดดูว่าหากมี Test แบบนี้สักร้อยตัว เราไม่ต้องมานั่งไล่พิมพ์ Test กันทีละตัวแบบนี้จนตาแตกเลยเหรอ
แต่เชื่อไหมว่าหากเราใช้เทคนิคต่าง ๆ ต่อไปนี้เราสามารถ Test Requirement นี้ได้ด้วยข้อมูลไม่กี่ตัว ซึ่งจะช่วยลดเวลา อีกทั้งทำให้เรามั่นใจได้ด้วยว่าข้อมูลที่นำมาใช ้ครอบคลุมเพียงพอ โดยไม่ต้องมาคอยไล่ Test ทีละตัวอีกต่อไป เจ๋งป่ะล้าา !!
โดยเจ้า Black-Box Testing ที่จะมาช่วยเรา แบ่งเป็น 4 เทคนิคหลัก ๆ ดังนี้
- Equivalent Partition
- Boundary Value Analysis
- State Transition
- Decision Table
จะรอช้าอยู่ทำไมไปทำความรู้จักกับเทคนี้แรกกันเลยกับ ..
1. Equivalent Partition
เทคนิคนี้อธิบายแบบง่าย ๆ คือ การแบ่งส่วน แล้วหยิบมาใช้ แค่นั้นเอง .. เมื่อดูตาม Requirement ด้านบน ได้กำหนดไว้ว่าต้องการเช็คค่า Input โดยอยากรู้ว่าค่าที่ได้มาเนี้ย มีค่าอยู่ระหว่าง 200–299 ใช่หรือไม่
ดังนั้นค่า Positive Value ของเราก็จะเป็นค่า 200–299 โดยค่าอื่น ๆ ที่สามารถใส่เข้ามาได้ที่ไม่ได้อยู่ระหว่าง 200–299 ก็จะกลายเป็น Negative Value ทั้งหมด เมื่อนำมาทำเป็นตารางให้เห็นภาพก็จะได้ ดังนี้
จะเห็นได้ว่าเมื่อเรานำมาทำเป็นตาราง เราสามารถแบ่งค่าออกได้ 3 ช่วง ( partitions ) ซึ่ง Concept ของเทคนิคนี้คือ ค่าในช่วงใด ๆ สามารถเป็นตัวแทนของทั้งช่วงนั้นได้ ให้เลือกค่าใด ๆ ในช่วงนั้น มาอย่างละหนึ่งดีกว่าการ Test ทุกค่าในช่วงนั้น ๆ
เมื่อดูตามตาราง จะสรุปง่าย ๆ ได้ใจความว่า ..
ช่วงที่หนึ่งมีค่า 100–199 ให้เลือกมาสักค่า แล้วเอาไป Test ซะ
ช่วงที่สองมีค่า 200–299 ให้เลือกมาสักค่า แล้วเอาไป Test ซะะ
ช่วงที่สามมีค่า 300–599 ให้เลือกมาสักค่า แล้วเอาไป Test ซร้าา
แต่ถึงเราจะ Test ด้วยการแบ่งค่าออกเป็นช่วง ๆ แล้ว เราก็คงยังไม่สามารถวางใจได้ 100% ว่าข้อมูลที่ใช้นั้นครอบคลุมเพียงพอแล้ว จึงต้องมีเทคนิคที่สองที่จะมาช่วยย้ำความมั่นใจว่าการ Test ครั้งนี้จะหนักแน่น และรัดกุมมากพอกับ Boundary Value Analysis ..
2. Boundary Value Analysis
สืบเนื่องมาจากเทคนิคแรก .. เมื่อเราแบ่งค่าข้อมูลออกเป็นช่วง และหยิบค่าจากแต่ละช่วงมา Test ได้แล้ว จริงอยู่ว่ามันเพียงพอต่อการ Test แต่ถ้าจะให้รัดกุมยิ่งขึ้นนอกเหนือจากค่าในช่วง เราจะต้องเพิ่มการ Test ค่า “ระหว่างช่วง” เข้าไปด้วย
จากตารางเมื่อเราแบ่งช่วงข้อมูล 100–599 ออกเป็น 3 ช่วง ค่าระหว่างช่วงที่เราควรนำไป Test จะเป็น 199, 200, 299 และ 300 โดยเมื่อนำไป Test ผลที่ได้ควรออกมาเป็น ..
199 เมื่อนำไป Test ผลที่ได้ออกมาควรเป็น Fail
200 เมื่อนำไป Test ผลที่ได้ออกมาควรเป็น Pass
299 เมื่อนำไป Test ผลที่ได้ออกมาควรเป็น Pass
300 เมื่อนำไป Test ผลที่ได้ออกมาควรเป็น Fail
จะเห็นได้ว่าทั้งสองเทคนิคนี้มีความเกี่ยวเนื่องกัน หากอยากใช้เทคนิคที่สองนี้ก็จำเป็นจะต้องเข้าใจการแบ่งช่วงข้อมูลก่อน เพื่อจะได้สามารถกำหนดค่าระหว่างช่วงได้ถูกต้อง หลายเว็บฯ จึงมักนิยมเขียนรวมกันเป็น Equivalent Partition & Boundary Value Analysis ไปเลย
3. State Transition
State Transition เป็นเทคนิคที่ช่วยให้เรามองเห็น flow ของระบบ รวมถึง action ต่าง ๆ ที่สามารถเกิดขึ้นใน flow นั้นได้ ผ่านเส้น Transition อ่านแล้วอาจจะยังไม่เห็นภาพและดูงง ๆ
การจะอธิบายเทคนิคนี้ให้ง่ายที่สุด คงหนีไม่พ้นการทำงานของเครื่อง ATM ที่มีการทำงานที่เปลี่ยนไปในแต่ละ State ให้ลองนึกภาพเมื่อเราไปใช้งานตู้ ATM
สิ่งแรกที่เราต้องทำคือการเสียบบัตร และใส่รหัสเพื่อเข้าสู่ระบบ โดยหากใส่รหัสถูกก็สามารถเข้าไปในระบบได้เลย แต่หากใส่รหัสไม่ถูกสามครั้งติด เจ้าเครื่อง ATM ก็จะเขมือบบัตรของเราไปเป็นอาหารว่าง โดยในระหว่างนั้นจะมี State ที่เครื่องทำงาน ดังนี้
เมื่อดูตาม Diagram จะเห็นได้ว่าเราสามารถเข้าใจ flow ได้ง่ายขึ้นผ่านเส้น Transition ที่เป็น action ของ user โดยเราสามารถเขียนออกมาเป็น Scenario ได้ 4 ข้อ ดังนี้
- Positive Case — ใส่รหัสผ่านถูกต้องในครั้งแรก สามารถเข้าสู่ระบบได้เลย
- Positive Case — ใส่รหัสผ่านผิดในครั้งแรก แต่ใส่ถูกในครั้งที่สอง จึงเข้าสู่ระบบได้
- Positive Case — ใส่รหัสผ่านผิดในครั้งแรก และครั้งที่สอง แต่ใส่ถูกในครั้งที่สาม จึงเข้าสู่ระบบได้
- Negative Case— ใส่รหัสผ่านผิดหมด จึงถูก ATM เขมือบบัตร
ด้วยการทำงานของระบบที่ถึงจะใส่ค่า Input เดิม แต่หาก State เปลี่ยน ค่า Output ที่ได้อาจไม่เหมือนเดิมทุกครั้ง หากเราไม่เอาเทคนิคนี้มาไกด์ คงยากที่จะเขียน Test ให้ครอบคลุมได้ล่ะนะ
4. Decision Table
ในเทคนิคที่หนึ่งและสองเราได้เข้าใจแล้วว่าหากต้องการ Test Input ในรูปแบบ เงื่อนไขเดียวทำยังไง แต่ถ้าเป็นข้อมูลที่มีหลายเงื่อนไข เราคงไม่สามารถแบ่งค่า หรือหาค่าระหว่างช่วงอย่างเดียวได้ เราจำเป็นต้องใช้เทคนิคนี้ช่วยในการ Test
โดยเทคนิคนี้จะนำเอาเงื่อนไขต่าง ๆ มาจัดทำเป็นตาราง เพื่อให้เข้าใจง่าย เช่น มี Text Box ที่รับค่าการเปลี่ยนรหัสผ่านใหม่โดยมีเงื่อนไข ดังนี้
- ต้องมีความยาวตัวอักษร 8–15 ตัวอักษร
- ต้องเป็นตัวอักษรภาษาอังกฤษเท่านั้น
- ต้องไม่ซ้ำกับรหัสผ่านเก่า
รหัสผ่านใหม่จะต้องครบทั้ง 3 เงื่อนไขนี้เท่านั้น จึงจะทำการ Submit ต่อไปได้ ไม่เช่นนั้นระบบจะแจ้งเตือน Error Message ตามเคสต่าง ๆ ขึ้นมาหลังจากกดปุ่ม Submit
ด้วยเงื่อนไขที่มีมากกว่าหนึ่ง ในตัว Text Box ตัวเดียว อาจทำให้เรามึน ๆ งง ๆ ได้ว่าเราควรจะ Test ด้วยข้อมูลไหน ก่อน-หลังดี อย่าเพิ่งตกใจไป ให้ลองตีตารางง่าย ๆ ด้วยการแบ่งเคสออกเป็นกรณีที่ถูก-ผิด ตามตาราง ดังนี้
จะเห็นได้ว่าเมื่อจัดทำออกมาเป็นตาราง ลำดับขั้นตอนการ Test จะเข้าใจง่าย มองเห็นภาพรวมมากขึ้น ว่ามีกี่เคสที่เราจำเป็นต้องจัดการ ทำให้ลดการหลุดไปได้มาก โดยจากตารางเมื่อให้สีเขียวแทนค่า TRUE และให้สีแดงแทนค่า FALSE จะเห็นได้ชัดเจนเลยว่ามี 7 กรณีที่จะทำให้ระบบของเราขึ้น Error Message และมีเพียงกรณีเดียวที่เราสามารถเปลี่ยน Password ได้สำเร็จ
ซึ่งจำนวนกรณีของการ Test แบบหลายเงื่อนไข จะเท่ากับ 2 ยกกำลัง n โดย n จะแทนค่าของเงื่อนไขที่มี ในกรณีนี้คือ 2 ยกกำลัง 3 ก็จะได้ 8 Test Case เลยทีเดียว ถึงจะค่อนข้างเยอะก็ยังดีกว่าปล่อยให้ Bug หลุดไปแหละเนอะ
สรุป
Black-Box Testing Techniques เป็นเทคนิคการ Test ที่โนสนโนแคร์ว่าการทำงานภายในระบบจะทำงานอย่างไร ขอเพียงแค่ป้อน Input เข้าไปแล้ว Output ออกมาตรงตามที่ต้องการก็พอ
ถามว่าจำเป็นไหม .. เราคิดว่าจำเป็นมากกกก ที่ต้องรู้ไว้
เพราะเมื่อไป Test ระบบจริง ความซับซ้อนที่ต้องเจอเรียกได้ว่าอลังการล้านแปดจัด ๆ ทำให้ Test Case ที่ต้องเขียนเยอะตาม ซึ่งถ้าเราไม่รู้เทคนิคพวกนี้ติดตัวไว้อาจเกิดเคสหลุด หรือ Test มากเกินความจำเป็นได้ แต่หากเรารู้และนำไปประยุกต์ใช้เราก็สามารถมั่นใจได้ใน ‘ระดับนึง’
ว่า Test Case ที่เราเขียนไปเนี้ย รัดกุมมากพอตามหลักการแล้วนะ แต่หากเจอ Bug ที่นอกเหนือจากหลักการจริง ๆ ก็คงต้องว่ากันไปตามหน้างานอีกทีด้วย ว่าจะมีวิธีการจัดการยังไง
และในที่สุดดด ก็จบจนได้ .. กับการเขียน ๆ ลบ ๆ โดยหวังให้เนื้อหา และภาษาที่ใช้อ่านแล้วเข้าใจง่ายที่สุด หากเพื่อน ๆ เห็นว่าบล็อกนี้เป็นประโยชน์แม้แต่เศษเสี้ยวก็ช่วยกด Clap👏 มาเป็นกำลังใจสักนี๊ด จะขอบคุณมากครับผ้ม ( กดดิ กด กดเซ่ ก๊ดดดดดดดดด !! )
