The Bug Life Cycle ขั้นตอนการจัดการ Bug แบบ QA Engineer มืออาชีพ

ตอนนี้ QA bootcamp เนื้อหาเข้มข้นขึ้นเรื่อยๆ แอดเรียนมาถึง sprint 02 เรื่อง test design and documentation

เห็นภาพการทำงาน QA เยอะขึ้นมากๆ ใกล้จะได้เขียน code แล้ว 555+ ใน sprint หน้าๆจะมี JS framework สำหรับเขียน test และก็ SQL ไว้ test database รอเรียนเลย

A Bug Life Cycle

อ้างอิงจาก Google คำว่า Life Cycle คือขั้นตอนแสดงการเปลี่ยนแปลงของสิ่งมีชีวิต “organism” ตั้งแต่เกิดจนตาย

The series of changes in the life of an organism including reproduction.

Google

จริงๆเราสามารถมอง software เป็นเหมือนสิ่งมีชีวิตได้เช่นกัน เกิดมาจาก requirements ที่ต้องการแก้ปัญหาบางอย่าง ค่อยๆเติบโต เพิ่มฟีเจอร์ใหม่ขึ้นเรื่อยๆในแต่ละ sprint

แอดเคยคุยกับภวินท์ Technical Lead ที่ Jitta (ex-ODDS) ว่า software มันจะต้องทำไปถึงเมื่อไหร่ sprint ไหนถึงจะจบ

The Bug Life Cycle คือ cycle ที่แทรกอยู่ในการพัฒนาซอฟต์แวร์ เป็น subset ที่ QA engineer รับผิดชอบ ตั้งแต่ตรวจเจอ bug บันทึก รายงาน ทดสอบ และแก้ไข

มีอยู่สองคำที่ QA engineer ต้องเข้าใจคือ severity และ priority แอดมีเกริ่นไว้คร่าวๆใน newsletter Bug Report ฉบับก่อนหน้านี้

• Severity คือความรุนแรงของ bug ที่เราเจอ (its impact on other functions)
• Priority คือความเร่งด่วนที่ bug นั้นควรได้รับการแก้ไข (when it will be fixed)

บางอย่างสำคัญและด่วน ต้องทำก่อน บางอย่างสำคัญแต่ยังไม่ด่วน ไว้ว่ากัน sprint หน้า

Test Three Times

ทิปในการตรวจ bug คือต้อง test อย่างน้อยสามรอบเพื่อยืนยันว่าสิ่งที่เราเจอคือ bug จริงๆ

“QA engineers execute the test script at least three times with different data in different environments to ensure that there’s a real bug.”

เพราะหลายครั้ง bug ไม่ใช่ bug แต่มันคือ feature ยั๊งงง มุกนี้อีกแล้ว 555+

พอ QA engineer ยืนยันแล้วว่าสิ่งนั้นคือ bug เราจะสร้าง report (ใน Jira หรือ Notion) และเข้าสู่ Bug Life Cycle ต่อไป

Life Cycle Diagram

Highlight ของ sprint นี้คือการเห็นภาพ Bug Life Cycle ตั้งแต่ต้นจนจบ

TripleTen ทำพวก graphics ได้สวยงามมากๆ เรียบหรู ดูมีสไตล์ แอดชอบมากเลย 555+ คิดว่าจะลองทำ diagram แบบนี้มากขึ้นในบทความที่แอดเขียนปีนี้

ความหมายของแต่ละ status ใน diagram

• New – QA engineer ตรวจเจอ bug และสร้าง report
• Assigned – ทีม business คอนเฟิร์ม bug ตัวนั้น และส่งต่อให้ developer
• Open – developer ที่ได้รับมอบหมายงาน เริ่ม fix bug
• Fixed – developer แก้ไข bug เสร็จแล้ว ส่งกลับให้ QA engineer
• Deferred – ทีมย้าย bug นั้นไปแก้ใน sprint ต่อไป ตามระดับ severity และ priority
• Rejected – bug นั้นถูกปฏิเสธ เพราะอาจจะไม่ใช่ bug จริงๆ (invalid) หรือมีคนรายงาน bug นั้นมาแล้ว (duplicated bug)
• Re-Test – QA engineer ทดสอบ bug อีกรอบว่า bug ได้รับแก้แก้ไขแล้ว
• Closed – bug นั้นได้รับการแก้ไขเรียบร้อย ปิดงานสวยๆ

อ่านจบ ง่ายจนงง แต่ที่เหลือยากหมดนะ หยอกๆ 555+

The Bug Life Cycle มีแค่นี้เลยจริงๆ เป็น professional workflow ที่ QA, business และ developer ทำงานร่วมกันในการแก้ไข bug

ตอนเรียนจบ sprint เค้ามี quiz ทดสอบความรู้สั้นๆ แอดชอบคำถามข้อนี้

เวลา QA engineer เขียน bug report ไม่ใช่หน้าที่ของเราที่เสนอวิธีแก้ bug ปล่อยเรื่องนี้เป็นหน้าที่ของ dev team (to decide how a bug should be fixed)

การเข้าใจ scope และ responsibility ของงานตัวเอง คือพื้นฐานของมืออาชีพ เฉียบ

Newsletter ฉบับต่อไป เราจะเข้าเนื้อหาของแทร่กันแล้ว เรื่อง Test Plan ที่ QA Engineer ต้องเขียนเพื่อ outline ทุกอย่างที่เราต้องทำใน software testing process

ไว้กำหนด scope, objectives, approach และ focus of testing ของโปรเจ็คนั้นๆ

Insights From Frontline

[Patch 11.03.2024] ตะกี้ส่งบทความให้น้องๆอ่าน น้องบุ๋มบิ๋ม QA Engineer – Thoughtworks ช่วยเสริมจากประสบการณ์จากการทำงานจริงเลย

“bug บางตัวแก้ง่าย แต่กระทบ functionality อื่นต่อด้วย เหมือนแก้ bug นี้ แล้วสร้าง bug ใหม่ อย่างน้อยตอนคุยกันจะทำให้เราเข้าใจผลกระทบ วิธีป้องกันด้วย”

〽️ น้อง บบ. แชร์เพิ่มเติมวิธีการทำงานของทีม QA ที่น้องทำงานอยู่

“ถ้า bug บางตัวที่เราเห็นชัดว่ามันคือ bug เพราะไม่ตรงตาม requirements หรือ Acceptance Criteria อันนี้ทีมจะใช้วิธีดึงกลับไปให้ dev เลย ไม่สร้าง ticket ค่ะ เพราะถือว่างานยังไม่เสร็จ ไม่ตรงตามข้อกำหนด”

อันนี้ insights ดีมาก ขอบคุณน้อง บบ. มากๆเลยนะครับ เย้

Our Newsletter is Growing

นี่แอดเขียน newsletter มาครบ 6 ฉบับแล้ว เวลาผ่านไปเร็วมากๆ ขอบคุณเพื่อนๆทุกคนที่ติดตาม The Weekend Engineer มากๆนะครับ

เนื้อหาบทความครอบคลุมเรื่อง

• งาน QA Engineer ต้องทำอะไรบ้าง
• การทำ Software Requirement Analysis
• การสร้าง Bug Report ใน Notion (ทำได้เหมือน Jira)

อ่าน newsletter archive ทั้งหมดของเราได้ที่ QA Engineering

ช่วงนี้แอดมีโอกาสได้เจอกับเพื่อนๆในสายงาน QA, Software มากขึ้นด้วย วันศุกร์ที่แล้วนัดคุยกับน้องแอน น้องบิ๋ม Thoughtworks มี อธบ จาก ODDS มาจอยกันด้วย

รออ่านบทสัมภาษณ์น้องแอน Lead Engineer – Thoughtworks ได้เลยครับทุกคน กดดันแล้วหนึ่ง ยั๊งงง 555+

🪲 เพื่อนๆที่สนใจบทความด้าน software/ dev ตอนนี้ภวินเขียน blog แชร์ความรู้ที่ phawin.net อ่านสนุกมาก ยั๊งงง 555+