บทความ

How to be QA in Squad at Bitkub Exchange

การทำงานเป็น Quality Assurance หรือ QA ที่ Bitkub Exchange ว่าเราต้องทำอะไรบ้าง โดยบทความนี้จะครอบคลุมการทำงานของระดับ Jr. และ Sr.

อยากแรกเลย ต้องบอกก่อนว่าที่ Biktub Exchange เราทำงานในรูปแบบของ Agile กันอยู่แล้ว แต่สิ่งที่เราเพิ่มเติมเข้ามา คือ สิ่งที่เรียกว่า Test First Process ซึ่งจะมี Ceremony ดังนี้

PI Planning

Validation

Sprint Grooming

Sprint Planning

Daily Scrum

Sprint Demo

Retrospective

จาก Ceremony ที่กล่าวมา แล้วมันเกี่ยวข้องกับหน้าที่หรือการเป็น QA ยังไงละ งั้นเรามาดูกันเลย

Validation เป็น session ที่เราจะได้พบกับ Product Owner ที่เขาจะมาเล่า Requirement ของ Feature ที่ผ่านการทำ PI Planning มาแล้ว เขาก็จะเล่ารายละเอียดเกี่ยวกับ Feature เล่า Flow การทำงาน รวมถึงเล่าภาพในส่วนของ UI ว่ามีหน้าตาและรายละเอียดเป็นอย่างไรบ้าง เพื่อให้ทีมเข้าใจภาพร่วมกัน

หน้าที่ของ QA ใน session นี้ คือ

รับฟัง Requirement และเข้าใจ Requirement ว่าสิ่งที่เขาต้องการคืออะไร

ลองคิด Test Scenario คร่าวๆ จากที่ Product Owner เล่ามา ว่าจะเกิด Test Scenario แบบไหนได้บ้าง แล้วยังมี Requirement ส่วนไหนบ้างที่มันยังไม่ชัดเจน หรือสมบูรณ์ เพื่อจะได้พูดคุยและทำความเข้าใจกับ Product Owner และทีม เพื่อที่จะทำให้ Requirement ของ Feature นั้นๆ ชัดเจนและสมบูรณ์

หลังจากจบ session นี้ ถ้า Requirement ต่างๆ ชัดเจนครบถ้วนแล้ว เราสามารถเริ่มเขียน Test Scenario ได้เลยนะ

Sprint Grooming จะแบ่งออกเป็น 2 Part

Part I เป็น session ที่เราจะได้พบกับ Product Owner ที่เขาจะมาเล่ารายละเอียดของ User Story ของแต่ละ Feature ที่คาดหวังให้ Tech Team นำไปพัฒนาต่อ ถ้าในกรณีที่เรามีคำถามหรือข้อสงสัยเพิ่มเติมก็สามารถพูดคุยได้เลยนะ

Part II เป็น session ที่ Tech Team จะทำการพูดคุย ทำความเข้าใจใน User Story ร่วมกันอีกรอบ เพื่อแตก Sub-task งานต่างๆ ในแต่ละ User Story ว่าจะมี Sub-task อะไรบ้าง และ Sub-task นั้น ทีม Front-End, Backend, Mobile หรือ QA ใครจะเป็นคนรับผิดชอบ Task

หน้าที่ของ QA ใน session นี้ คือ

รับฟัง Requirement และเข้าใจ Requirement หรือ Criteria ของแต่ละ User Story ว่าสิ่งที่เขาต้องการคืออะไร

พูดคุยและทำความเข้าใจร่วมกันใน Criteria ของแต่ละ User Story

พูดคุยและแตก Sub-task ในแต่ละ User Story ว่าต้องทำอะไรบ้างใน Story นั้นๆ

หลังจากที่แตก Sub-task แล้ว ก็จะ Poke point เพื่อประเมินระยะเวลาในการทำงานของแต่ละ Sub-task ในการ Poke point เราก็จะมีการแสดงความคิดเห็นระหว่างกันด้วยนะในการ Poke point ว่าทำไมเราถึงให้ Point แบบนี้ สำหรับ Sub-task นี้

Sprint Planning เป็น session ที่เราจะได้พบกับ Product Owner ที่เขาจะมาชี้แจง Priority งานที่เขาจะเลือกเข้าใน Sprint เพื่อให้ทำ Development นำ Feature ไปพัฒนา หลังจากที่เราได้ Poke point ไปแล้ว ว่าแต่ละ User Story เราจะใช้เวลาทำทั้งหมดเท่าไร

หน้าที่ของ QA ใน session นี้ คือ

รับทราบถึง Feature หรือ User Story ที่จะต้องทำใน Sprint

หลังจากทราบ Feature หรือ User Story แล้ว ภายในทีม QA เราจะก็มาเลือก Feature หรือ User Story ที่เราอยากจะรับผิดชอบกัน

Daily Scrum เป็น session ที่เราจะได้มา Catch Up กับทีม โดยใน session นี้เราจะพูดคุยเกี่ยวกับ

เมื่อวานนี้เราได้ทำอะไรไปบ้าง แล้ว Progress งานเป็นยังไง

วันนี้เราจะทำอะไรต่อ

จากเมื่อวานเรามีติด Block อะไรบ้าง ที่ทำให้เราไม่สามารถทำงานได้สำเร็จ หรือมีติด block อะไรบ้างที่เรายังไม่สามารถเราทำงานในส่วนของเราได้

Sprint Demo & Review เป็น session ที่

เราจะมา demo ตัว feature ที่เราได้พัฒนาไป โดยแต่ละ Feature เราก็จะมีแบ่งหน้าที่กันระหว่างทีม Dev กับ QA ว่าใครจะรับผิดชอบ Demo ของ Feature ไหน

มีช่วง Q&A เพื่อถาม ตอบ เกี่ยวกับ Feature ที่เราได้ทำการ Demo ไป สำหรับคนที่มีข้อสงสัย

มี Review ตัว User Story ทั้งหมดที่รับเข้า Sprint ว่ามี User Story ไหนบ้างที่ทำเสร็จแล้ว หรือมี User Story ไหนบ้างที่ยังทำไม่เสร็จ และที่ยังทำไม่เสร็จ มีติดปัญหาเรื่องอะไรบ้าง

Retrospective เป็น session ที่เราจะเปิดอกพูดคุยกันว่าใน 1 Sprint ที่เราทำงานร่วมกันมาเนี้ย เราพบเจอเรื่องอะไรมาบ้าง ทั้งที่ดีและไม่ดี หรือเรื่องที่เราควรเริ่มทำและเรื่องที่เราไม่ควรจะทำ เพื่อให้การทำงานร่วมกันเป็นไปอย่างราบรื่น สวยงาม ซึ่งที่เราพูดคุยกัน เราก็จะช่วยกันคิดหาทางออกหรือวิธีแก้ไขปัญหานั้นๆ หรือรักษาสิ่งที่ดีอยู่แล้วให้มันดำเนินต่อไป

จากที่เล่ามาทั้งหมด ยังมีอีก 1 session คือ PI Planning ที่ยังไม่ได้เล่า ซึ่งต้องบอกเลยว่า session นี้ เป็น session ในส่วนของผู้ที่มีตำแหน่ง Team Lead ขึ้นไป จะเป็นคนจัดการในส่วนนี้ครับ ดังนั้นแล้วเรามาดูกันต่อว่าในระหว่าง Sprint นั้น QA อย่างพวกเรานั้นทำอะไรกันบ้าง

เขียน Test Scenario ตาม Requirement ของ User Story โดยจะเขียนแบ่งเป็น 2 Part คือ

1. Input validation ส่วนนี้เป็นส่วนของ Dev เพื่อสามารถนำไปเขียน Unit test

2. Business Rule ส่วนนี้เป็นส่วนของ Functional ของ Requirement เพื่อให้เข้าใจภาพการทำงานของ Feature

หลังจากที่เราทำ Test Scenario เสร็จแล้ว เราก็นำ Test Scenario ไป Review ร่วมกันภายในทีมทั้ง Product Owner และ Tech Team เพื่อให้เข้าใจและมองภาพของ Business Requirement ในแต่ละ User Story ไปในทิศทางเดียวกัน

หลังจาก Test Scenario เรียบร้อยแล้ว เราก็จะนำ Test Scenario มาเขียนเป็น Test Case

ในบาง User Story เราก็จะมีการเตรียม Custom element “data-testid” ให้กับ Dev เพื่อให้ Dev นำไปใส่ให้บนหน้าเว็บ เพื่อเตรียมความพร้อมสำหรับการทำ UI Automated Test Script

ในบาง User Story เราก็จะมีการทำ Automated Test Script ทั้งในส่วนของ UI Layer และ API Layer เพื่อลดการทำงานแบบ Manual Test แต่เราก็ยังมี Manual Test อยู่นะ เพราะว่าบาง Test Case ไม่เหมาะที่จะ Automated หรือว่าบาง User Story ก็ไม่เหมาะที่จะทำ Automated และอีกอย่าง Manual Test ก็ยังช่วยส่งเสริมให้การทดสอบระบบของเรานั้นสมบูรณ์มากยิ่งขึ้นด้วยนะ

เตรียม Test Data และทดสอบ Feature ตาม Test Case ที่เราได้เตรียมไว้ และเก็บผลในแต่ละ Test Case ซึ่งตรงนี้เราจะใช้ Testrail ในการจัดเก็บ Test Case และ Test Result

ในกรณีที่เราเจอ Bug เราก็จะ Log Bug ทิ้งไว้ และก็แจ้งให้ Dev รับทราบ

มี Tracking Progress งานตาม User Story หรือ Bug กับทาง Dev

Generate Summary Report ของแต่ละ Feature ที่เราได้ทำการทดสอบเรียบร้อยแล้ว แจ้งให้กับทีมได้รับทราบ เพื่อจะได้นำไปเข้าสู่กระบวนการ Deployment

ในส่วนของการ Deployment Feature เราจะทำการ Deploy ในสัปดาห์ถัดไปหลังจากเราปิด Sprint ไปแล้ว ซึ่งในส่วนนี้เราก็จะมีการจัดประชุม Rollout Plan ร่วมกัน ทั้งทีม Product Owner และ Tech Team เพื่อพูดคุยรายละเอียด Feature ต่างๆ ที่เราจำทำการ Deploy ขึ้น Production และกรอกรายละเอียดต่างๆ ของการ Deployment ลงในเอกสารที่เรียกว่า Rollout Plan สำหรับ QA แล้ว ตัว Rollout Plan เราจะใส่พวกรายละเอียดของ Sanity Test Step ว่าเราจะมี Sanity Test ใน Feature ไหนบ้าง และในแต่ละ Feature เราต้อง Sanity Test บน Platform อะไรบ้าง เช่น Web หรือ Mobile-iOS เป็นต้น

ในช่วงของการ Deployment เราจะทำการ Sanity Test ก่อนการขึ้น Production เพื่อตรวจสอบตัว Feature ที่ทาง Dev Deploy ไป สามารถทำงานได้อย่างถูกต้องหรือไม่ก่อนที่จะนำไป Deploy จริงบน Production และหลังจากที่ Dev ทำการ Deploy Feature บน Production แล้ว เราก็จะทำการ Sanity Test บน Production อีกครั้ง เพื่อตรวจสอบความถูกต้องของระบบ