<BugDay-MiniEvent #03> นุ่นอยากรู้ว่า ต้อง “การบริหารจัดการ Bugs/Defects ใน Sprint อย่างไร? และแบบไม่เป็น Sprint ด้วย และหลาย ๆ Use Cases” #LearningWithSCK

เริ่มจาก ที่มาที่ไปของคำถาม ที่เป็นที่มาของ Session นี้

พี่นุ่นขอ สวมหมวกเดิม ก่อนเข้า SCK คือ Product Manager (ชื่อตำแหน่ง) พอผลิต Software ออกมาเสร็จแล้ว จะต้องมีช่วงส่งมอบงานให้ลูกค้าไปลองเล่น ก็จะได้ Defect Lists กลับมาจากลูกค้าเป็นของขวัญ ก็เลยเป็นคำถามว่า ต้องจัดการอย่างไรดี เพราะที่เคยทำมา ก็เป็น Waterfall และ mini-Waterfall ในรอบการทำงาน เลยอยากได้คำแนะนำ และ Use Cases ว่าพี่หนุ่ม บริหารจัดการอย่างไร

Defect เป็นคำที่ใช้น้อย ส่วนใหญ่เราจะเจอคำว่า Bug และอาจจะเจอ Error และอีกคำคือ Failure และก็อาจจะเจอ Issue แบบน้อยๆ หน่อย

ซึ่งถ้าใครเคยสอบหรือเคยผ่าน ISTQB (International Software Testing Qualifications Board) จะมีความหมาย คำนิยามที่ต่างกัน

ถ้าในบริบทตอนนี้ คำว่า Defect นี้ อาจจะมาจาก

• QA หรือ Software Tester หรือ UAT User ที่ทดสอบแล้ว Actual Result ไม่เท่ากันกับ Expected Result
• UAT User อาจจะพบว่า Actual Result ไม่เท่ากันกับ Expected Result (ประสบการณ์ที่เขาทำมา)

มาคุยกันที่ QA หรือ Software Tester หรือ UAT User ที่ทดสอบแล้ว Actual Result ไม่เท่ากันกับ Expected Result ก่อน

• Expected Result จะถูกเขียนใน Test Cases หรือ Test Scenarios (ขึ้นอยู่กับแต่ละบริษัทว่าจะเรียกอะไร)
• ซึ่ง Expected Result อาจจะมีปัญหาเยอะหรือน้อยสำหรับบางที่
• แจ้งก่อนว่า พี่หนุ่มไม่ใช่ไบเบิล แต่เป็นการแชร์ประสบการณ์

Expected Result ต้องระบุออกมาเป็นค่า หรือ Value ได้

• ตัวเลข
• สถานะ ยกตัวอย่างเช่น ecommerce สถานะแรก เป็น รอชำระเงิน
• ข้อความแจ้งใดๆ ไม่ว่าจะภาษาใดก็ตาม

Expected Result ที่ไม่ควรจะใช้

(เมื่อก่อน ประมาณสิบปีบวกๆ พี่หนุ่มก็เคยเขียนแบบนี้)

• ระบบทำงานถูกต้อง
• คำนวณเงินได้ถูกต้อง
• แสดงผลถูกต้อง
• ทำงานได้ปกติ

เพราะ มันตีความยาก เพราะมันไม่รู้ว่าอะไรถูกผิด อะไรตรงไม่ตรง เป็น Bug/Defect ไหม พอเราเปิดเป็น Bug ไป จะเกิดเหตุการณ์ มันไม่ Bug/Defect แล้วก็เถียงกันอีก

เอามาจากหนังสือเตรียมสอบ แต่พี่หนุ่มไม่ได้สอบ

สิ่งที่ต้องมีคือ

1. Tested Condition(s)
2. Expected Result(s)
3. Input
4. อาจจะมี Preconditions ก่อนหลัง

สิ่งเหล่านี้มันต้องถูกเขียนก่อนเริ่มดำเนินการทดสอบ

แล้วเอาไปเทียบ ตอนที่เกิด Phase ที่เรียกว่า ดำเนินการทดสอบ

หมายเหตุ เป็น Slide เก่ามาก เลยยังใช้คำว่า Cases อยู่

• Tested Condition(s) ตรงนี้ ถ้าเทียบกับที่ Dev ทำงานก็คือ functions/features
• พอใส่ Input เข้าไปใน functions/features พอได้ผลออกมา (Actual Results) มันก็จะตีได้สองแบบคือ
• PASS ถ้า Actual = Expected Results
• FAIL ถ้า Actual != Expected Results

(ช่วงร่วมสนุก กดตัวเลข พบว่า QA ที่เข้าร่วม Session วันนี้ส่วนมาก เป็นคนย้ำคิดย้ำทำ)

ถ้าเขียนว่า “ระบบทำงานถูกต้อง” จะบอกได้ยังไง?

สุดท้ายก็ต้องเอา Data ที่ไปนั่งคิดคำนวณมาลองกรอกอยู่ดี ซึ่งถ้าเทียบกันแล้ว ตัวเลขมันไม่เท่าจริงๆ ก็ค่อยเปิดเป็น Bugs/Defects

การจัดการ Bugs/Defects

สำหรับ Waterfall Model (หรือ Sequence Phase)

• การออกแบบ เกิดช่วง Analysis & Design — Coding
• การทดสอบ เกิดช่วง Testing ถ้ามันไม่ตรง ไม่ใช่ ก็จะเขียนรายงาน Bug/Defect ตรงช่วงนี้ ซึ่งแต่ละที่ ก็จะมี Defect Life Cycle อาจจะอยู่ในรูปแบบ Web, App, Excel หรืออะไรก็แล้วแต่

ยกตัวอย่างที่พี่หนุ่มเคยทำไว้เมื่อนานมาแล้ว (และไม่ให้เอาไปเป็นเยี่ยงอย่าง)

และ ต้องมีคำนิยาม ของแต่ละ Stage ว่าหมายถึงอะไร เช่น

สิ่งสำคัญคือ Bug/Defect ที่เราเขียน ไม่ว่าจะเขียนบรรยาย พรรณนาอะไร จะมีสองคำที่จะต้องถูกใช้คือ

Severity = ระดับความรุนแรงของผลกระทบ ของ Bug/Defect ตัวนั้น “กระทบฝั่งธุรกิจ”

• Critical
• Medium
• High
• Low

มีอีกคำศัพท์หนึ่ง คือ Deferred ยอมรับความเสี่ยงที่จะไปแก้บน Production

Priority = ลำดับความสำคัญของ Bug/Defect ตัวนั้น

• High = แก้เลยทันที
• Medium = ยังรอได้ แต่ต้องแก้นะ
• Low = ยังไม่ต้องแก้ มีเวลาค่อยทำ

กลับมาที่การทำงานแบบ Waterfall

• Dev ก็พัฒนา A → F ไป แล้วก็ส่งมาหา Tester ทั้งก้อนตู้มๆ แล้วก็ระดม Test ทีเดียว ส่งผลให้เจอจำนวน Bugs/Defects ปริมาณมาก

พี่หนุ่มขิง ว่าในโครงการที่ตัวเองเคยทำสมัยเป็น Tester เมื่อหลายสิบปีก่อน เขียนและรายงานไป 350 ตัว ที่เป็น Critical-High-Medium

ซึ่งได้ผู้ร่วมสนุกที่ขิงชนะพี่หนุ่มไปเรียบร้อย แพ้ตั้งแต่ 400+ ไปจนถึง 3k ตัว ก็คือ พี่หนุ่มขิงต่อไม่ได้แล้ว 555+

• พอเรารายงานผลเสร็จ Bugs/Defects ทุกตัว ต้องถูกนำไปดำเนินการแก้ไข ซึ่งหลักๆ คนแก้ก็คือ Developer/Programmer (สมมติว่าต้องถูกส่งไปแก้จริงๆ ไม่ใช่เราทดสอบผิดเอง) ภายในระยะเวลา “ที่เหลือน้อย”
• เพราะมันจะมี Phase ที่เรียกว่า UAT รออยู่
• มันมีเวลากำหนด งานต้องเคลียร์บั๊กให้ได้มากที่สุด เพราะเมื่อส่ง UAT แล้ว User จะได้ไม่เจอ (หรือเจอน้อยสุด)
• ซึ่งมันมีจะมีเวลา Fix Defect แฝงอยู่ ซึ่งก็น้อยอยู่ดี เมื่อเทียบกับเวลาที่ Coding มาตั้งนาน เช่น Code 6 เดือน แล้วมีเวลา Fix Defect แค่ 0.5–1 เดือน
• ด้วยกรอบเวลาที่น้อย ก็ส่งผลให้ แก้ได้ไม่ครบ เลยเกิด Severity, Priority ขึ้นมา เพื่อใช้ในการจัดการบริหารคิว ในการแก้ไข → Retest (→ Regression Tests)

ประเด็นก็คือ ปัจจุบัน (ในแต่ละที่) ใครเป็นคนกำหนด Severity, Priority ? ตอนเปิดบั๊กครั้งแรกในชีวิต (ให้ย้อนอดีตกลับไป) จะคิดว่า ต้องเปิดระดับอะไรนะ? แล้วก็จะโดนตีกลับว่า Set แบบนี้ไม่ได้

มันจะมี Matrix การให้ Scoring อยู่ (ลองไป Search หาดูได้)

สรุปก็คือ มันเอามาจัดคิว จะได้รู้ว่า อะไรแก้ก่อน แก้หลัง

• ก่อนจะส่งไปหา Programmer แก้ มันต้องผ่านกระบวนการวิเคราะห์ วินิจฉัย เพื่อตั้งสมมติฐาน ว่าตรงไหน น่าจะเป็นสาเหตุที่ทำให้เกิด Bug/Defect นั้น

1. ใช้คนที่มีชั่วโมงบินสูง เป็นคนวิเคราะห์ และสมมติฐาน
2. Dev Lead, QA/Tester Lead, QA/Tester Manager ผู้เชี่ยวชาญเฉพาะเรื่อง
3. และมีประสบการณ์ Business Domain นั้นๆ

• แล้วค่อยเข้าสู่กระบวนการวิเคราะห์และออกแบบการแก้ไข (ส่วนที่ Programmer จะทำ)
• บริหาร จัดการคิว เพื่อทำการแก้ไข
• แล้วเข้าสู่ ดำเนินการทดสอบ ว่าสมมติฐานนั้น ถูกต้องหรือไม่ == Bugs/Defects ถูกแก้ไขให้เป็นไปตาม Expected Results

ข้อควรระวัง

1. ถ้า Expected Result เขียน คำว่า ถูกต้อง บอกไม่ได้ ว่าถูกหรือผิดเป็นอย่างไร
2. ตัวเลข ก็ต้องชัวร์ว่า เราเข้าใจ Business และ Conditions นั้นจริงๆ ถ้าเราไม่เข้าใจ Business Domain ไม่เข้าใจสูตร ไม่เข้าใจ Logic เราจะเป็นต้นเหตุในการสร้าง Bugs

Bugs/Defect ที่เกิดขึ้น ที่เราเจอ

ถ้าเราลองวาดภาพให้เห็นจะพบว่าส่วนมากเจอที่ด้านบนของภาพ แต่สิ่งที่ Programmer ต้องแก้ คือด้านล่างของภาพ

• Function
• Service, APIs, Component

ที่เราต้องวิเคราะห์ ต้นสาย ปลายเหตุก่อน เพราะอาจจะเกิดกรณีแบบนี้ได้

คือถ้าแก้แม่ได้ ลูกๆ ก็จะหายไปด้วย เพราะมันเป็น Function เดียวกัน (หรืออาจจะเกี่ยวเนื่องกันในระดับที่ใหญ่ขึ้น)

หรืออีกแบบคือ ไม่เกี่ยวข้องกัน เป็นอิสระต่อกันโดยสิ้นเชิง

หรือที่ผิด แล้วชีวิตก็เปลี่ยนเช่นกัน เช่น

1. Test Data
2. Test Environment ไม่ว่าจะ Env ไหนๆ ก็ตาม
3. Configuration เช่น Software, Hardware, Equipment ต่างๆ (เช่น อุปกรณ์ทาง Network)
4. เกิดจาก QA/Tester เองนี่แหละ

เพราะฉะนั้นแนะนำเลย หาสาเหตุ ให้เจอก่อน จะไปลงมือแก้ไข

เมื่อแก้ไขใดๆ เสร็จแล้ว

หน้าที่ของ Lead และ Manager ทั้ง Dev และ QA

• ต้องนำสิ่งนี้ทั้งหมดมาผ่านกระบวนการวิเคราะห์ เพื่อ หา หรือ กำหนด หรือ ปรับปรุง ให้ไม่เกิดปัญหา หรือ สาเหตุนั้น ซ้ำๆ ซากๆ
• ถ้าใครไป Search พวก Defect Management จะเท่ากันกับ Process Improvement
• ผลที่ออกมา จากการทำสิ่งนี้ จะกลายเป็น Real World Actionable Item(s) + Time-box + Measurement

(ใจจริงตัวเอง อยากให้เสริม RACI เข้าไปเลย แต่พี่หนุ่มบอกให้ใจร่มๆ)

Mini-Waterfall

• ทำงานเป็นรอบๆ แต่ก็ทดสอบช่วงท้ายอยู่ดี
• หรือไม่ก็ทดสอบไม่เสร็จใน Sprint นั้นหรอก ข้าม Sprint กันไปเลย

เอาตามตรง เราไม่ได้ทำงานเป็น Sprint เรายังทำงานเป็น Waterfall เหมือนเดิม แถม UAT ยังอยู่ช่วงท้ายอีกต่างหาก

แล้ว Scrum มันมีหน้าตาเป็นอย่างไร?

• สีชมพู คือมีใน Scrum (Guide)
• สีเหลือง คือสำนัก SCK เสริมเข้าไป

Software version ล่าสุด ต้องพร้อมขายหรือพร้อมให้บริการ (เล่นได้จริง เชื่อมต่อจริง) ติดตั้งบน Env: UAT, Pre-Prod, Prod (คำตอบจากผู้เข้าร่วมเรียน)

แนะนำต้องคุยกันแต่แรก ในบริบทของการทดสอบ เรายอมรับผลการทดสอบอยู่ที่เท่าไหร่ เช่น

ซึ่งในเอกสาร Scrum Guide ไม่ได้พูดถึงเรื่องการทดสอบมากนัก ส่วนคำว่า Bugs/Defects Management รวมถึง Software Design ไม่มีในเอกสาร

ประโยคย้ำซ้ำๆ “Scrum เดี่ยวๆ ใช้ทำ Software ไม่ได้”

เมื่อไหร่ที่เอา Scrum ไปใช้ แล้วทดสอบแบบ Waterfall มันก็จะเป็น mini-Waterfall อยู่ดี

ถ้าทำงานเป็นรอบๆ เจอ Bugs เมื่อไหร่ ต้องแก้เลย ซึ่งไม่มีใน Scrum แต่มีใน Extreme Programming (XP)

เขียนโดย คุณ Janet และ คุณ Lisa ผู้มากประสบการณ์การทดสอบมากกว่าพวกเราตรงนี้

• Cards ในบริบทนี้แปลว่า กระดาษ บอร์ดจริงๆ เพราะสมัยนั้นยังไม่มี Electronics Tools
• ถ้าการทำงานเป็นรอบกันจริงๆ ต้อง ทดสอบและแก้ให้เสร็จในรอบการทำงาน ไม่เข้าคิว เจอปุ๊บ แก้ปั๊บ ถ้าปล่อยทิ้งไว้นานๆ โค้ดโตขึ้นเรื่อยๆ มันก็จะแก้ยากขึ้นเรื่อยๆ

• Sprint มีสิบวัน ถ้า Dev ส่งมาให้ทดสอบ มาให้ Log Defect วันที่ 7–8–9 ชีวิตมันจะนรกกว่า Waterfall ไหม? ถามใจเธอดู
• ถ้าจะทำงานแบบนี้ จำต้องมุ่งเน้นที่ “การป้องกัน” คิดก่อนว่าจะทำอะไร ก่อนเขียนโค้ด Test-First Development ซึ่งเป็นที่มาของ TDD, ATDD, BDD, Specification by Examples

• Test-First สิ่งที่จะได้มาคือ Automation Tests ในระดับ End to End business Process Test ผ่านทาง APIs หรือ Services Layer และ ระดับ Unit Test (ไม่แนะนำให้ทำที่ระดับ UI)
• Forget คือ Regression Tests ทุกครั้งที่มีการแก้ไข Production Code
• ถ้าเราเจอแล้วแก้เลย ก็ไม่จำเป็นต้องมี Severity, Priority แล้ว

แต่อย่าลืม! กระบวนการหาสาเหตุว่า Bug/Defect มีสาเหตุเกิดจากอะไร ให้ได้ Real World Actionable Item(s) + Time-box + Measurement เสมอ

— ถ้าใน Scrum ก็คือ Sprint Retrospective

และอีกพิธีกรรมที่สามารถ “แจ้ง” เรื่องนี้ได้คือ Daily Scrum

เช่น ปริมาณ Defect เยอะขึ้นเรื่อยๆ แล้วเรามองเห็น ก็ให้แจ้งขึ้นมา

ถ้ามันมีปัญหาต้องคุย ก็นัดเวลาแยกออกมา เพื่อคุยปัญหาเหล่านี้กับคนที่เกี่ยวข้อง

พี่หนุ่มย้ำว่าไม่ได้ขายคอร์ส Holistic Testing: Strategies for Agile Teams แต่ทางนี้จะขายให้แล้วกัน ถ้าใครสนใจทักมาถามที่เพจ https://www.facebook.com/siamchamnankit ได้เลยค่ะ

ซึ่งไม่รู้ว่าพี่หนุ่มจะเปิดอีกทีเมื่อไหร่ เพราะฉะนั้นอ่านบทความที่เคยไปเขียนมาได้ที่นี่ไปพลางๆ ก่อน

• Holistic Testing: Strategies for Agile Teams Day 1
• Holistic Testing: Strategies for Agile Teams Day 2
• Holistic Testing: Strategies for Agile Teams Day 3

พี่นุ่นปิดท้ายสวยๆ ว่า “มันคือทั้งทีม รับผิดชอบร่วม ร่วมด้วยช่วยกัน ไม่ใช่ชี้หน้ากัน โทษกัน มันเกิดขึ้นแล้ว ก็มาหาสาเหตุร่วมกัน”

พี่หนุ่มกล่าวว่า “ไม่ใช่ที่ทุกคนทำอยู่ตอนนี้ผิด และที่พี่หนุ่มทำตอนนี้ก็อาจจะไม่ถูก พรุ่งนี้อาจจะเจออะไรใหม่ที่มาปรับอีก เพื่อให้พ้นทุกข์”

อยากชวนทุกคนมาแชร์ใน MiniEvent แบบนี้ ทักผ่านเพจ ทักผ่านพี่หนุ่ม หรือทักผ่านพริ้วมาก็ได้นะค้า

สำหรับวันนี้ ลาไปทิ้งตัวแล้วค่ะ แชทบอทปวดหลัง 55555