Verification and Validation (V&V) สองคำนี้เพื่อนพ้องน้องพี่หลายๆ คน คงจะคุ้นเคย และก็เกี่ยวข้อง โดยเฉพาะอย่างยิ่ง Software Tester ทั้งหลาย เชื่อได้ว่าหลายๆ คนก็ยังคง งง งง กับเจ้าสองคำนี้อยู่ว่ามันคืออะไร วันนี้ผมก็เลยหยิบยกมาเป็นเรื่องที่จะเขียนลงใน welovebug ครับ

ผมว่าหลายๆ คนคงจะเคยใช้ Verification and Validation ไปค้นใน Search Engine หาว่า ความหมายของเจ้าสองคำนี้คืดอะไร? หรือหลายๆ คนโดนสั่งให้ไปทำ Verification and Validation ของ Software ที่จะพัฒนาขึ้นมา หรือไม่ก็ตรวจรับ Software ทั้งๆ ที่คนสั่ง ก็ไม่รู้เหมือนกันว่า Verification and Validation คืออะไร (แอบนินทา)

บมความนี้ผมเขียนขึ้นมาจากสิ่งที่ได้อ่านมาจาก ตำรา, เอกสารอบรม, บทความบน internet และจากประสบการณ์ทำงานส่วนตัวในงานด้าน Software Testing เผื่อว่าจะเป็นประโยชน์ไม่มากก็น้อยกับเพื่อนพ้องน้องพี่ทั้งหลายครับ

Verification: Have we built the software RIGHT?

เพื่อน V ตัวแรกของเรา Verification เป็น กระบวนการตรวจสอบ และควบคุม ให้ Software ถูกออกแบบ และพัฒนาอย่างถูกต้อง ตรงตาม Requirements Specification ของ Users

Have we built the software RIGHT?

Verification จะถูกเริ่มดำเนินการตั้งแต่ขั้นตอนแรกของการเริ่มพัฒนา Software และดำเนินต่อไปจน Software ถูกพัฒนาจนเสร็จสิ้น อธิบายง่ายคือ

• ตรวจสอบความถูกต้อง, ครบถ้วน และชัดเจนของ Requirements ของ User ในขั้นตอนการเก็บ Requirements จาก Users
• ตรวจสอบความถูกต้อง และครบถ้วน ของการออกแบบ Software ตรงตาม Requirements ของ User
• ตรวจสอบความถูกต้อง และควบคุม การพัฒนา Software ดำเนินการตรงกับเอกสารที่ได้จากการออกแบบ Software

ในการดำเนินการกระบวนการ Verification นั้นจะต้องอาศัยความร่วมไม้ร่วมมือจากทุกๆ คน และทุกๆ ทีมงาน ที่เกี่ยวข้องกับการพัฒนา Software ที่จะเข้ามาช่วยกัน วิธีการที่สามารถนำมาใช้ได้ในกระบวนการ Verification คือ Inspection, Walkthrough และ Peer Review

Inspection / Walkthrought

ทุกๆ ทีมที่เกี่ยวข้องกับการพัฒนาจะได้รับเอกสารต่างๆ ที่เกี่ยวข้องกับการพัฒนา Software และมอบหมายให้ตัวแทนของแต่ละทีมทำการอ่าน, ทำความเข้าใจ, เตรียมคำถาม หรือข้อสงสัยต่างๆ รวมทั้ง จุดที่จะทำให้เกิด Defects/Bugs ขึ้นได้

Project Manager หรือ Lead เรียกประชุมตัวแทนของแต่ละทีม โดยตัวแทนของแต่ละทีมนำเสนอ คำถาม, ข้อสงสัยต่างๆ และจุดที่จะทำให้เกิด Defects/Bugs ในที่ประชุม เพื่อหาคำตอบ หรือนำกลับไปถาม Users เพิ่มเติมเพื่อให้ได้คำตอบ และให้เกิดความเข้าใจที่ตรงกันกับทุกๆ ทีมงานที่ร่วมในการพัฒนา Software

ควรทำ Inspection / Walkthrought เมื่อ

• เมื่อเสร็จสิ้นการเก็บ Requirements จาก Users (สำคัญมาก)
• เมื่อเสร็จสิ้นการวิเคราะห์และออกแบบ Software (สำคัญมาก)

ที่ผมเน้นว่า สำคัญมาก ก็เพราะว่าหากไม่ทำในสองส่วนนี้ ไม่ว่าจะเหตุผลใดๆ เช่น เสียเวลา, มีเวลาน้อยในการพัฒนา หรือ ของเคยทำๆ อยู่แล้ว คุ้นมือ เป็นต้น ลองคิดเล่นๆ ดูว่าจะเกิดอะไรขึ้น หากแต่ละทีมอ่านเอกสาร Requirements ของ Users แล้วเข้าใจผิดไปคนละทาง หรือตีความหมายของ Requirements ไปคนละทิศละทาง แล้วก็ลงมือทำงานกันไป มาเจอเอาก็ตอนที่ Testing ว่าผิด เผลอๆ แก้ใหม่ทั้งหมด อันนี้ สนุกสนาน เลยครับ

Peer Review

การทำ Peer Review เป็นอีกวิธีการหนึ่งในการทำ Verification ได้ แต่ละคนในทีมงานพัฒนา Software ให้เพื่อนในทีมงานเดียวกัน หรือต่างทีมงาน ช่วย Review งานของตัวเอง เช่น

• Review เอกสารที่ได้จากการวิเคราะห์ และออกแบบ Software
• Review Code ในระหว่างการดำเนินการพัฒนา Software
• Review Test Cases ที่จะถูกใช้ในการ Testing

เพื่อช่วยให้เกิดความถูกต้อง และควบคุมเรื่องของคุณภาพ เกิดขึ้นในทุกๆ ขั้นตอนของการพัฒนา Software และเป็นวิธีการที่ง่าย และสามารถกระจายลงไปดำเนินการได้ภายในทีมงานแต่ละทีมงานได้

Validation: Have we built the RIGHT software?

เพื่อน V อีกตัวของเรา Validation เป็น กระบวนการตรวจสอบ Software ถูกพัฒนาตรงตาม Requirements ที่ Users ต้องการ

Have we built the RIGHT software?

Validation จะถูกเริ่มต้นหลังจากเสร็จสิ้นขั้นตอนของ Verification และเริ่มดำเนินการ Coding โดยทีม Development ซึ่ง Validation สามารถดำเนินการไปได้ในแต่ละขั้นตอนของการพัฒนา Software และ/หรือ เมื่อทีม Development เสร็จสิ้นการพัฒนา Software พร้อมส่ง Software ให้ทีม Test ดำเนินการต่อไปตาม Test Plan ที่กำหนดไว้

อธิบายกันแบบง่ายๆ ว่า Validation จะต้อง

• ตรวจสอบว่า Software ทำงานถูกต้อง ตรงตาม Requirements ของ Users

Software Tester จะเกี่ยวข้องกับการทำ Validation โดยตรง ดังนั้น การวางแผนการ Test (Test Plan), การออกแบบการ Test (Test Design), การเขียน Test Cases และการทำสอบ (Test Execution) ที่เกิดขึ้นในแต่ละการ Test ที่เกิดขึ้น เป็นการช่วยตรวจสอบ และควบคุมคุณภาพของ Software ให้ทำงานถูกต้องตรงตาม Requirements ของ Users

Testing Type หลักๆ ที่เกี่ยวข้องกับ Validation

Unit Testing, Developer/Programmer ดำเนินการทำ Unit Testing ในแต่ละ Module/Function ว่าทำงานเป็นไปตาม Logic ที่ถูกออกแบบมาจาก Requirements ของ Users และจัดการแก้ไข Defects/Bugs ที่เกิดขึ้นในระดับของ Module/Function เรียกขั้นตอนนี้ว่า Code Validation

Integration Testing, Developer/Programmer ดำเนินการทำ Integration Testing ในการทำงานร่วมกันของ Modules/Functions ต่างๆ ให้เป็นไปอย่างถูกต้อง ตรงตาม Logic ที่ได้ถูกออกแบบ และจัดการแก้ไข Defects/Bugs ที่เกิดในระดับของการทำงานร่วมกันระหว่าง Modules/Functions เรียกขั้นตอนนี้ว่า Integration Validation

System Testing, Tester ดำเนินการทำ System Testing เพื่อทดสอบ และตรวจสอบ ว่า Software ทำงานถูกต้อง และเป็นไปตาม Requirements ต่างๆ ของ Users และแจ้งกลับไปยังทีม Development เมื่อพบ Defects/Bugs เพื่อให้ดำเนินการแก้ไข ก่อนที่จะส่งมอบ Software ให้กับ User ดำเนินการทำ UAT ต่อไป เรียกขั้นตอนี้ว่า System Validation

Verification and Validation

ถ้าเพื่อนพ้องน้องพี่ยังคงจำ Software Quality Triangle ได้… หลายๆ คนคง สงสัย ว่า Software Quality Triangle คืออะไร? ตามไปอ่านจาก มอง Software Product Quality ผ่าน สามเหลี่ยมด้านเท่า ได้ครับ กลับเข้าเรื่องต่อ เราสามารถจับ Software Quality Triangle กับ Verification and Validation เข้าหากันได้ ดังภาพนี้

จาก Goal ของ Software Quality Triangle นั้น เราจะต้องทำการลด Gap ของแต่ละมุมลงในอัตราส่วนที่เท่าๆ กัน เพื่อให้ได้รูปสามเหลี่ยมด้านเท่าที่เล็กที่สุด นั่นก็หมายถึง เราสามารถพัฒนา Software ได้ออกมาตรงตาม Requirements ของ Users และเป็นไปตาม Requirement Specification ที่ถูกวิเคราะห์ และออกแบบ ดังนั้น

• Requirement Define เข้ามาช่วยในการลด Gap ระหว่าง Users Requirements และ Requirements Specification
• Verification เข้ามาช่วยในการลด Gap ระหว่าง Requirements Specification และ Software
• Validation เข้ามาช่วยในการลด Gap ระหว่าง Software และ User Requirements

Verification and Validation (V&V) เป็นกระบวนการในการตรวจสอบว่า Software ถูกพัฒนาออกมาตรงกับ Requirements และ Specifications หรือไม่? โดยเกี่ยวข้องโดยตรงกับทุกๆ คนที่อยู่ในทีมพัฒนา Software มิใช่เพียงแค่ Software Tester แต่เพียงผู้เดียว เพราะ คุณภาพจะต้องเกิดขึ้นในทุกๆ ขั้นตอนของการพัฒนา Software (ยังคง ตอกและย้ำ ในเรื่องนี้ไปเรื่อย )

Quality in Every Phase, Not Afterthought