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 อีกครั้ง เพื่อตรวจสอบความถูกต้องของระบบ
สกุลเงิน | ราคาล่าสุด (THB) | ซื้อขาย/ วัน |
---|