ที่มาที่ไปของ BugDay รอบนี้ คือ นุ่นที่เป็นสมาชิกของ SCK ได้เกิดคำถามเกี่ยวกับบริหารจัดการ Bugs/Defects ใน Sprint ควรทำงานยังไง
ในบริบทที่นุ่นได้ถามมา Defect คือ ผลลัพธ์ จากการทดสอบโดย QA/Software Tester ที่ทดสอบแล้วพบว่า Actual Result ไม่เท่ากับ Expected Result
หรือ
Defect ได้มาจาก UAT หรือ User ที่ทดสอบแล้ว พบว่า Actual ไม่เท่ากันกับ Expected Result ประสบการณ์ที่เขาทำมา
Expected Result
ถ้าถามว่า Expected Result มาจากไหน ก็ตอบได้เลยว่า มาจากที่ QA Tester เป็นคนเขียนระบุไว้ใน Test Cases หรือ Test Scenarios ซึ่งจะต้องระบุออกมาเป็น ค่า หรือ Value ให้ได้ เช่น
- ตัวเลข
- สถานะ: รอชำระเงิน หรือ ค่าอะไรที่บอกว่า รอชำระเงิน
- ข้อความที่แจ้ง
ส่วนที่ไม่ควรใช้เป็น Expected Result เช่น
- ระบบทำงานถูกต้อง
- คำนวนได้ถูกต้อง
- แสดงผลถูกต้อง
- ทำงานได้ปกติ
เพราะมันจะทำให้เราตีความยากหรือตีความไม่ได้ว่า ที่ถูกเป็นยังไง ที่ผิดเป็นยังไง มันทำงานถูกต้องหรือไม่ถูกต้อง เราไม่สามารถบอกได้
มาดูกระบวนการทดสอบกันก่อนเลย
จากภาพจะเห็นว่า มีองค์ประกอบอยู่ 4 ตัว คือ
- เริ่มต้นเราจะทดสอบเงื่อนไขไหน
- จะต้องมี Expected Result
- จะต้องมี Input เพื่อเอาเข้าไปทำ Action อะไรสักอย่าง
- สิ่งที่ต้องทำก่อนการทดสอบ และ สิ่งที่ต้องทำทำหลังจากทดสอบ (ถ้ามี)
โดยตอน Execute มันก็จะวิ่งจาก นำ Input ที่เตรียมไว้เข้าไป > เพื่อทำ Action (การทำงาน) อะไรบางอย่าง > จากนั้นนำ Input ที่ได้มา เอาเข้าไปทดสอบ บนเงื่อนไขที่เราต้องการทดสอบ (Test Condition(s)) > เปรียบเทียบผลลัพธ์ที่ออกมากับ Expected Result
ลองคิดดูว่า ถ้าหากเราระบุผลการทดสอบเป็นแบบที่ไม่ควรใส่ เช่น ระบบทำงานถูกต้อง ก็จะเจอกับสถาณการณ์ ประมาณนี้
ถ้าหากทำแล้ว ได้ผลลัพธ์ Pass เราก็มันก็จะไม่มีปัญหาอะไร แต่ถ้าหากระบบทำงานผิดพลาด เราก็จะต้องมาหาว่า Actual Result หรือ Expected Result ที่ผิดกันแน่
และเมื่อรู้แล้วว่า มันเกิด Bug/Defect เราก็จะเอามา log เป็น bug/defect ตีกลับเข้าไป
วิธีการ Log Bug/Defect
ถ้าหาก Tester เจอบั๊คในขั้นตอนการทดสอบแล้ว ก็จะไปเขียนรายงาน Bug/Defect ตามกระบวนการ Defect life Cycle ซึ่งตรงนี้ขึ้นอยู่กับแต่ละที ซึ่งอาจจะแตกต่างกันออกไป เช่น
ส่วนวิธีการเขียน Bug/Defect จะถูกเขียนไปตามสไตล์ของแต่คนว่าจะเขียนอะไรยังไง แต่จะต้องมีการเขียนอยู่ 2 ตัวนี้ ประกอบอยู่ด้วยเสมอ คือ
Severity คือ ระดับความรุนแรงของผลกระทบของ Bug/Defect ตัวนั้น โดยเราจะมองในฝั่งของธุรกิจ เช่น
- Critical
- High
- Medium
- Low
Priority คือ ลำดับความสำคัญของ bug/defect ตัวนั้น เช่น
- High == แก้เลยทันที
- Medium == ยังรอได้ แต่ต้องแก้นะ
- Low == ยังไม่ต้องแก้ ว่างแล้วค่อยมาแก้
Waterfall
สำหรับ waterfall ที่เน้นทำทั้งหมดให้เสร็จทีเดียว เวลาที่ Developer เขียนโค๊ด เมื่อเขียนเสร็จทั้งหมดแล้ว ก็จะส่งทั้งหมดมาให้ Tester ทดสอบ เราก็จะได้ bug/defect ในจำนวนทีเยอะมากๆ
แล้วก็ตี bug/defect เหล่านั้น กลับไปให้ developer กลับไปแก้บั๊คเหล่านั้น ซึ่งในกรอบระยะเวลาในการทดสอบมักจะแฝง Fix Defects เข้าไปใน phase ทดสอบเข้าไปด้วย
ซึ่งเวลาที่มีจะน้อยกว่าเวลาพัฒนา เลยต้องใช้ Severity และ Priority เข้ามาช่วยในการบริหารจัดการเวลา และการจัดการคิว เพื่อให้รู้ว่าควรเอาอะไรมาแก้ก่อนหรือหลัง เพื่อให้สามารถทำงานได้ทันตามเวลา
ทั้งหมดนี้ก็จะอยู่ใน defect life cycle
ทีนี้ก่อนที่เราจะแก้ bug/defect เราจจะต้องวิเคราะห์ หรือ วินิจฉัย เพื่อตั้งสมมติฐาน เพื่อหาสาเหตุของ bug/defect ก่อน
จากนั้นเข้าไปสู่กระบวนการวิเคราะห์และออกแบบ เพื่อแก้ไข เสร็จแล้วจึงดำเนินการทดสอบว่า สมมุติฐานนั้นถูกต้องหรือไม่ (bug/defects ถูกแก้ไข ให้เป็นไปตาม expected result)
เพราะฉนั้นถ้าหากว่า เรา เขียนว่า Expected Result ว่า "ระบบทำงานถูกต้อง" เราก็จะไม่สามารถบอกได้ว่ามันถูกหรือผิดอย่างไร
อีกอย่าง คือ ต้องชัวร์ว่า เราเข้าใจ Business และ Conditions นั้นจริงๆ ถ้าเราไม่เข้าใจ Business Domain ไม่เข้าใจสูตร ไม่เข้าใจ Logic เราจะเป็นต้นเหตุในการสร้าง Bugs
ขั้นตอนทั้งหมดที่กล่าวมาหน้าตาก็จะเป็นประมาณนี้
จากภาพ หากเราต้องวิเคราะห์หรือวินิจฉัย เพื่อหาสาเหตุก่อนที่จะเอา bug/defect ก่อนเข้าคิว เราสามารถมาใส่ Priority หลังจาก วิเคราะห์และออกแบบ เพื่อแก้ไขก็ได้ ยังไม่จำเป็นต้องใส่ตั้งแต่แรก
ในขั้นตอนของการวิเคราะห์และออกแบบ การแก้ไข หลังจากที่แก้ไขเสร็จแล้ว จะต้องนำเอาข้อมูลทั้งหมดแต่ละ defect มาวิเคราะห์ เพื่อหา หรือกำหนด หรือปรับปรุง เพื่อไม่ให้เกิดปัญหา หรือสาเหตุนั้น ขึ้นมาอีก ซ้ำๆ ซากๆ ซึ่งสิ่งนี้เป็นกระบวนการ Process Improvement ที่อยู่เรื่องของ Defect Management เพื่อให้ได้สิ่งที่เรียกว่า Real World Actionable + Time box + Measurement
Iterations / Sprint
ในการทำงานเป็นรอบ หรือ sprint หรือ iteration นั้น เราจะเอาเรื่องของการบริหารจัดการ bugs/defects จาก Extreme Programming จาก course Holistic Testing เราสามารถบริหารจัดการได้ดังนี้
ถ้าหากเป็นข้อผิดพลาด เจอปุ๊ปให้แก้โดยทันที
เพื่อลดเลี่ยงวิธีการ log defects เพราะมันเสียเวลา
วิธีการนี้จะต่างจาก waterfall ที่ต้องรอทดสอบตอนทั้ง เลยทำให้ต้องมีการ log bugs/defects เพื่อจัดเรียงลำดับความสำคัญ และจัดคิวเพื่อแก้ไข เพราะส่วนใหญ่แล้วเราไม่สามารถทดสอบได้ทั้งหมด
แต่ในการทำงานเป็นรอบนั้นต่างกัน ถ้ารอไปทดสอบตอนท้าย sprint จะแก้ไม่ทันแน่นอน
เพื่อป้องกันการเกิด Bugs/defects เราจะต้องทำ Test-First คิดก่อนว่าจะทดสอบอะไร
เพื่อหาการเกิด Bugs ให้เร็วขึ้นที่สุด หากเจอก็ให้แก้เลย ซึ่งหมายความว่า เราจะต้องหามันตั้งแต่ช่วงที่เขียนโปรแกรมเลย ซึ่งมันจะนำไปสู่การทำ Automation Testing เช่น Unit Testing, Integration Testing, APIs Testing เป็นต้น
วิธีการแก้ Bug
เราสามารถแบ่งกลุ่มของการแก้ bugs ได้ออกเป็น 3 กลุ่มตามภาพนี้
Fix now: อะไรที่แก้ได้เลย ใช้เวลาไม่เยอะ ให้แก้ทันที เช่น text ผิด แก้สี เป็นต้น
Estimate, Prioritize and fix later if it's...: ถ้าหากส่วนที่ต้องแก้มีความซับซ้อน หรือให้ effort เยอะ หรือ เป็น Legacy code ที่จำเป็นต้องไปขุดคุ้ยหรือวิเคราะห์ก่อน ให้ QA Tester ไปคุยกับ Product Owner เป็นคนตัดสินใจว่าจะแก้เลยมั้ย หรือไว้แก้ทีหลัง
Never fix: ไม่ต้องแก้หาก ระบบนั้นกำลังจะถูกเขียนใหม่ หรือระบบนี้จะไม่ใช้แล้ว (ก็ทำเป็นลืมๆ มันไป ไม่ต้องแก้มัน)
นอกจากนี้ ใน daily scrum หาก QA Tester พบว่ามี defect เกิดขึ้นระหว่าง sprint เยอะเกินไป สามารถแจ้งทุกคนในทีม เพื่อหาเวลามาคุยกันเพื่อหาสาเหตุว่าทำไมมันถึงเกิดเยอะ เพราะมีความเสี่ยงที่ sprint นั้น มีโอกาศที่ทำให้ Quality ของงานลดลง