Risk-Based Testing
What To Do When You Have Very Short Testing Time
The Way It Is
เคยมีน้องๆ QA Engineer มาเล่าเชิงบ่นให้ฟังว่า
“เอาอีกแล้วพี่ ส่งงานมาให้เทสช้ากว่าที่ตกลงกัน แล้วก็มาบังคับว่าต้องทำให้เสร็จตาม Deadline”
“ผมหละเบื่อจริงๆ เทสได้แค่ไหนก็แค่นั้นแล้วกันนะ”
ก็ถูกของน้องเค้าที่ว่าได้แค่ไหนแค่นั้น … แต่ในเวลาอันจำกัดเราสามารถเลือกทำงานแบบฉลาดได้นะ
The Way It Should Be
เป็นความจริงที่ขมขื่นสำหรับคนที่เป็น QA Engineer หรือ Tester ที่ต้องรับผิดชอบทดสอบซอฟท์แวร์เพื่อตรวจสอบคุณภาพและมักจะได้เวลาทำงานน้อยเหลือเกินเมื่อเปรียบเทียบกับงาน Development แต่ The Show Must Go On … เราจะทำยังไงกับเรื่องแบบนี้
ก่อนอื่นเราควรต้องเข้าใจความจริงในเรื่อง Testing สักสองสามข้อ
- ถ้าเรามั่นใจ 100% ว่าซอฟท์แวร์ของเราทำงานได้ถูกต้องเป๊ะๆ การทำ Testing ก็ไม่จำเป็น (No Risk No Test)
- เราต้องพยายามการันตีคุณภาพที่ดีที่สุดในเวลาที่สั้นที่สุด (หรือตามเวลาที่กำหนดไว้)
- ดังนั้นเราควรจะมองหา Bug ที่สำคัญและรุนแรงให้เจอเร็วที่สุด
เมื่อเป็นแบบนี้แล้วเราต้องมองหากลยุทธ์ที่จะช่วยให้เราการันตีคุณภาพที่ดีที่สุดให้ได้ (แทนที่จะเอาแต่บ่นว่า เวลาเทสไม่พอๆ) ลองพิจารณา Risk-Based Testing ดูครับ
Risk-Based Testing คือการวางแผนการทดสอบซอฟท์แวร์หรือโปรดักส์โดยดูจากความเสี่ยงหรือ Product Risk เป็นสำคัญ ถ้าส่วนไหนมีความเสี่ยงสูงเราก็จะให้เวลากับมันเยอะหน่อย เราจะรู้ได้อย่างไรว่า Product Risk มีมากหรือน้อย?
1. ระบุ Modules หรือ Features
เราต้องรู้ก่อนว่าระบบที่เรากำลังจะเทส (System Under Test หรือ SUT) นั้นมี Modules หรือ Features อะไรบ้าง เช่น
- Module = Login / New Feature = Connect with Facebook
- Module = Shopping Cart / New Feature = Share Shopping Cart with Friends
- Module = Check Out / New Feature = Peer Review Items before Payment
- Module = Payment / New Feature = Borrow Money from Friends
2. ระบุปัจจัยความเสี่ยง (Risk Factors)
จากนั้นก็มาดูปัจจัยที่มาของความเสี่ยงกัน เช่น
- ลักษณะของ Project ว่าเป็น New Development หรือ Enhancement
- ความสำคัญของ Features นั้น เช่น เกี่ยวกับการเงิน หรือเป็นแค่ User Profile
- ความซับซ้อนของ Architecture/Implementation เช่น ต้องติดต่อกับระบบภายนอกหลายระบบ, มี System Flow หรือ Sequence ที่สลับไปสลับมา
- ความซับซ้อนของ Data เช่น ต้องมีการทำ Data Migration
- ความคาดหวังด้าน Performance เช่น ต้องจัดการ Transaction จำนวนมากในเวลาอันสั้น
- ข้อมูลในอดีตบอกเราว่า Modules หรือ Features ไหนมีบั๊กเยอะตลอดเวลา
- ระดับคุณภาพของงานที่ได้รับมา โดยทั่วไปจะดูว่า Developer ทำ Unit หรือ Integration Test มามากแค่ไหนแล้ว
- ประสบการณ์และความสามารถของ Developer
- เทคโนโลยีที่เลือกใช้เก่าหรือใหม่ เก่ามากก็ไม่ดี ใหม่มากก็ไม่ดี
- อื่นๆ …
3. สร้าง Product Risk Graph
ความเสี่ยงมีคุณสมบัติอยู่สองอย่างคือ (1) โอกาสที่ความเสี่ยงนี้จะเกิดเป็นความจริง (Probability) และ (2) ระดับของผลกระทบจากปัญหาที่เกิดขึ้นจากความเสี่ยงนี้ (Impact) ในขั้นตอนนี้เราจะประเมินความเสี่ยงของ Modules หรือ Features จากปัจจัยต่างๆที่เราวิเคราะห์ไว้แล้วก็เขียนเป็น Graph แบบนี้ขึ้นมา
4. กำหนด Testing Techniques
จากคำแนะนำของ Erik van Veenendaal เราจะกำหนด Testing Technique ให้เหมาะสมกับความเสี่ยงของแต่ละ Module และ Feature ตามรูป ถ้าความเสี่ยงมากก็จะใช้ Testing Technique ที่ลงละเอียดมากตามไปด้วย
ลองประยุกต์ใช้กันดูครับ … ถ้าทำได้ผมจะรู้สึกว่ามัน Professional มากๆเลย ฮ่าๆ
ผมเขียนบทความนี้เพราะอยากเปลี่ยนแปลงสิ่งที่เป็นอยู่ในอุตสาหกรรมการผลิตซอฟท์แวร์ให้ดีขึ้นตามความเชื่อและประสบการณ์ของผม ถ้าเพื่อนๆเชื่อในแนวทางเดียวกัน เรามาช่วยกันคนละไม้คนละมือทำให้สังคมของเราดีขึ้นครับ จะแชร์บทความนี้ผ่าน Social Network หรือจะแบ่งปันเรื่องราวนี้ให้คนที่นั่งข้างๆฟังบ้างก็ได้
The Future Has Arrived — It’s Just Not Evenly Distributed Yet, William Gibson
อนาคตอยู่ตรงนี้แล้ว เรามีหน้าที่ต้องถ่ายทอดมันออกไปให้คนอื่นได้สัมผัสสิ่งดีๆร่วมกันครับ
