อะไรบ้างที่ต้องทำเมื่อเราเป็น Software Tester ใน Agile Team — รู้ตัวก่อนว่าที่ทำอยู่มันคือ mini-waterfall
ตอนที่สอง ของ อะไรบ้างที่ต้องทำเมื่อเราเป็น Software Tester ใน Agile Team ที่เขียนตอนที่หนึ่งไปเมื่อ วันอาทิตย์ที่ 1 กรกฎาคม พ.ศ.2561 (นานมาก) เพื่อทบทวนก็สามารถกลับไปอ่านทบทวนอีกครั้งได้ที่
อะไรบ้างที่ต้องทำเมื่อเราเป็น Software Tester ใน Agile Team — อารัมภบท
สำหรับตอนที่สองนี้ ผมใช้ชื่อตอนว่า หยุดให้กำเนิด mini-waterfall เพราะ ณ เทียบเท่าปัจจุบันนี้สิ่งที่ได้ประสบพบเจอมาผ่านทั้งการเข้าไปนำพา (Coaching) และส่งมอบองค์ความรู้ และประสบการณ์ (Training) นั้นเจออยู่เป็นประจำกับสิ่งเหล่านี้
- Quality Assurance (in the name) หรือ Software Tester โดนสั่งให้ไปเรียนรู้ และสร้าง Automation Test Scripts ผ่านเครื่องมือเหล่านี้ เช่น Robotframework และ/หรือ CyPress และ/หรือ Postman และ/หรือ Katalon และ/หรือ บลา บลา บลา
- Quality Assurance (in the name) หรือ Software Tester นั่งสร้าง Automation Test Scripts เสร็จแล้วก็บันทึก และจัดเก็บไว้ในเครื่องคอมพิวเตอร์ของตนเอง และ/หรือ Share Drive และ/หรือ Repository ของตนเอง บน Github และ/หรือ GitLab
- Quality Assurance (in the name) หรือ Software Tester ต้องทดสอบซอฟต์แวร์แบบ Manual Testing ก่อน เมื่อแก้ Bugs/Defects หมดแล้ว จึงไปสร้าง Automation Test Scripts
- Quality Assurance (in the name) หรือ Software Tester ต้องนั่งเตรียมข้อมูลในการทดสอบ (Test Data) ใหม่ทุกครั้งที่จะสั่ง Run Automation Test Scripts
- Quality Assurance (in the name) หรือ Software Tester ไม่สามารถควบคุมข้อมูลในการทดสอบ (Test Data) ได้เลย
- Quality Assurance (in the name) หรือ Software Tester บางคนเท่านั้นที่ถูกเลือกเข้ามาสังกัด ทีมใหม่ ที่ชื่อว่า Automation Test Team ที่จะเป็นปัญหา
เป็นต้น
แล้ว Quality Assurance (in the name) หรือ Software Tester ก็
เมื่อเหล่า Developer และ/หรือ Programmer เขียน Code เสร็จก็จะส่งมาให้ดำเนินการทดสอบไม่ว่าจะ Manual Testing หรือ Run Automation Testing Scripts
และ
เมื่อประสบพบเจอกับ Bugs/Defects ที่จะทำการเรียก Developer และ/หรือ Programmer มาดูแล้วให้ไปแก้ หรือไม่ก็เข้าไปบันทึกเป็นรายงาน Bug Report/Defect Report ลงในระบบ Defect Management
แล้ว
Developer/Programmer ก็กลับไปนั่งหาสาเหตุว่า Bugs/Defects นั้นเกิดจากอะไร จะแก้ไขอย่างไร และลงมือแก้ไข
ระหว่างนั้น
Quality Assurance (in the name) หรือ Software Tester ก็ไปหยิบ Story หรือ User Story อื่นๆ มานั่งทดสอบไม่ว่าจะ Manual Testing หรือ Run Automation Testing Scripts
กงกรรม กงเกวียน ก็จะวนวนไปเรื่อยๆ โดยสะกดจิตตนเองว่า เราเป็น Agile แล้ว เพราะเรามี Automation Test Scripts
ใจร่มๆ และวางถุงกาวลงก่อน
Agile Software Development ก็ไม่ได้บอกอะไรไว้เลย
การพัฒนา ทดสอบ และส่งมอบซอฟต์แวร์แบบ Agile Software Development นั้น ไม่มีการระบุอะไรเกี่ยวกับการทดสอบใดๆ ทั้งสิ้น เพราะใน Manifesto for Agile Software Development ก็ไม่มีระบุอะไร เกี่ยวกับเรื่องของการทดสอบซอฟต์แวร์
รวมทั้ง Principles behind the Agile Manifesto ก็ไม่ได้ระบุ หรือบอกอะไรไว้เกี่ยวกับเรื่องของการทดสอบซอฟต์แวร์
ดังนั้น
Software Tester ต้องมาทำความเข้าใจก่อนว่า Agile Software Development ที่เขาพูดๆ กันนั้น ไม่ได้บอกอะไรไว้เลยว่าจะต้องทำอะไร
ดังนั้น
ก่อนการนำ Agile Software Development มาปรับ ประยุกต์ใช้
รูปแบบการพัฒนา ทดสอบ และส่งมอบซอฟต์แวร์ของเราเราเป็นแบบ Sequence Phases เช่น Waterfall Model ที่
ความรับผิดชอบเรื่องการทดสอบ อาจจะรวมถึงคุณภาพของซอฟต์แวร์ จะอยู่บนบ่า คอ และไหล่ ของ Quality Assurance (in the name) หรือ Software Tester และจะมีนิดหน่อยที่แตะๆ โดนกับผู้คนทางฝั่งธุรกิจ (Business) รวมทั้งผู้คนที่อยู่ในส่วนของการวิเคราะห์ และออกแบบ (Analyst) และพัฒนา (Developer/Programmer)
เมื่อนำ Agile Software Development เข้ามาใช้
ณ ปัจจุบันที่หลายๆ ทีม หลายๆ องค์กร นำ Agile Software Development เข้าไปปรับใช้ผ่านกรอบการทำงาน Scrum Framework
ที่
ไม่มีบอกอะไรไว้เลยเกี่ยวกับการทดสอบซอฟต์แวร์ไม่ว่าจะระดับไหน
แต่ก็ไม่ผิดเพราะ Scrum Framework ออกตัวไว้แล้วว่า
และเมื่อไปดูในรายละเอียดอย่างใช้สติก็จะพบว่า ยังคงเป็น Sequence Phases แบบระยะเวลาสั้นๆ คือ สองสัปดาห์ และชัดเจนมากบน Sprint Backlog มีช่องของการทดสอบ (Testing) ยกตัวอย่างตามรูปที่ 1 และรูปที่ 2
ทั้งสองรูปตัวอย่างที่ยกมานั้น เท่าที่ได้รับฟัง และเห็นจากกิจกรรมในการสอน และการนำพา ก็ระบุออกมาชัดเจนจากสมาชิกของทีมพัฒนา (Development Team) ว่าเป็นแบบนั้น และ Quality Assurance (in the name) หรือ Software Tester ก็รอจนกว่า “Card” หรือ “Story” หรือ “User Story” จะเดินทางมาถึงตรงช่อง QA Test ถึงจะเริ่มดำเนินการทดสอบไม่ว่าจะเป็น Manual Testing หรือ Automation Test Scripts
รูปแบบของ mini-waterfall
ก่อนที่จะเริ่มเสพอะไรต่อไปที่เกี่ยวกับ mini-waterfall ผมขอยกประโยคที่ผมชอบจาก YouTube ช่อง มิติที่ 6 มาเพื่อลดเรื่องดราม่าลง
วิจารณญาณทำกับข้าวเสร็จหรือยัง ถ้าเสร็จแล้วจงเรียกให้มานั่งฟังไปพร้อมๆ กันว่าเรื่องราวเหล่านี้มันคืออะไรกันแน่
เพราะ อาการของ mini-waterfall ที่กำลังจะบอกเล่าต่อไปนี้ มาจาก
- จากประสบการณ์ตรงส่วนตัวสมัยยัง ละอ่อน อ่อนด้อยในการลงมือทำ หลงคำ หลงใบประกาศนียบัตร (Certificate) ทั้งหลาย หลงเชื่อ และหลงทาง จนหลายๆ โครงการพังคามือด้วย Scrum Framework มาแล้ว
- จากการสังเกตทั้งการสอนที่คนเรียนเขียนออกมาให้ดูว่าปัจจุบันขั้นตอนการพัฒนา และทดสอบเป็นแบบใดใน Scrum Framework
- การได้เข้าไปช่วยดูว่าที่เรานำทั้ง Agile และ Scrum เข้ามาใช้ร่วมทั้ง TDD (Test-Driven Development) และ Automation Testing Tools หลายตัว แต่ทำไมมันยังไม่ Agile เลย เพราะจบ Sprint ไม่มีอะไรเสร็จ
- ร่วมพิจารณา และให้คำแนะนำในการตรวจคัดกรอง Proposal ของเหล่าบริษัททั้งไทย และต่างประเทศทั้งที่ World Wide Wellknown และ ไม่ Wellknown นำเสนอรูปแบบการทำงานแบบ Agile มา
- ประสบการณ์ตรงของ Janet Gregory หนึ่งในผู้ร่วมเขียนหนังสือ Agile Testing และ More Agile Testing
โดยขอใช้ Slide การสอน Agile Testing for The Whole Team ของ Janet Gregory และ Lisa Crispin มายกเป็นตัวอย่างของ mini-waterfall ทั้งสองแบบ
mini-waterfall แบบที่ 1 ทดสอบตอนท้ายของรอบการทำงาน
ยกตัวอย่างเช่น
ระยะเวลา 1 รอบการทำงาน ที่เรียกว่า Sprint จาก Scrum Framework เท่ากับ 10 วันทำการ
วันที่ 1 ของ Sprint ใช้ไปกับ พิธีกรรม Sprint Planning ทั้ง Part I และ Part II จนให้คำมั่นสัญญากับ Product Owner และนำ Requirements เข้าไปแปะไว้ที่ Sprint Backlog ในช่อง To-Do
วันที่ 2 หลังจบพิธีกรรม Daily Scrum
เหล่า Developer/Programer ก็จะลาก ความต้องการลำดับที่ 1 และ ความต้องการลำดับที่ 2 เข้ามาที่ช่อง Doing หลายๆ อัน และเริ่มลงมือเขียน Production Code ซึ่งอาจจะมีการเขียน Test Code เช่น Unit Test Cases และ/หรือ Integration Test Cases และ/หรือ Component Test Cases และ/หรือ การทดสอบอื่นๆ
ในขณะเดียวกัน Quality Assurance (in the name) หรือ Software Tester ก็จะทำงานขนานไปด้วย โดยจะมีใบงาน หรือไม่มีใบงาน และอาจจะมีกระดานงานของตนเอง | To-Do | Doing | Done | เท่าที่ได้เห็น และได้ยินมา จะตั้งชื่อว่า QA Board หรือ Tester Board และก็จะเริ่มเขียน Test Scenarios ระดับของการทดสอบ User Acceptance Test และ/หรือ System Integration Test และ/หรือ API Test และ/หรือ End-to-End Test ทั้งในรูปแบบ Manual Testing ที่อยู่ใน Microsoft Excel หรือ Microsoft Word หรือ Automation Test Scripts เช่น Robotframework และ/หรือ CyPress และ/หรือ Postman รวมทั้งเขียนการตรวจสอบการ Validate Text Fields ต่างๆ ลงไปด้วยทั้งใน Manual Testing และ/หรือ Automation Test Scenarios สำหรับ ความต้องการลำดับที่ 1
วันที่ 3 หลังจบ Daily Scrum
วันที่ 4 หลังจบ Daily Scrum
Quality Assurance (in the name) หรือ Software Tester เขียน Test Scenarios สำหรับ ความต้องการลำดับที่ 1 เสร็จ แล้วก็เอาไปพักไว้ เพื่อรอทดสอบ และก็ลงมือเขียน Test Scenarios สำหรับ ความต้องการลำกดับที่ 2 ต่อ
วันที่ 5 หลังจบ Daily Scrum
เหล่า Developers/Programmers ไปลาก ความต้องการลำดับที่ 4 เข้ามาที่ Doing
ขณะที่ Quality Assurance (in the name) หรือ Software Tester เขียน Test Scenarios สำหรับ ความต้องการลำดับที่ 3 ต่อ
วันที่ 6
เหล่า Developers/Programmers ไปลาก ความต้องการลำดับที่ 2 จาก Doing ไปยัง QA Test
Quality Assurance (in the name) หรือ Software Tester ต้องวางมือจากการเขียน Test Scenarios สำหรับ ความต้องการลำดับที่ 3 แล้วมาทำการดำเนินการทดสอบไม่ว่าจะเป็น Manual Testing หรือ Automation Test Scripts
วันที่ 7
Quality Assurance (in the name) หรือ Software Tester พบ Bug/Defect ของ ความต้องการที่ 2 แล้วส่งกลับไปให้เหล่า Developer/Programmer ดำเนินการแก้ไข
เหล่า Developer/Programmer ก็ไปลาก ความต้องการลำดับที่ 3 เข้ามาที่ Doing เพราะเข้าสู่วันที่ 7 แล้ว ต้องรีบเขียน Production Code ให้เสร็จ เพื่อส่งไปให้ Quality Assurance (in the name) หรือ Software Tester ทดสอบ
Quality Assurance (in the name) หรือ Software Tester กลับมาเขียน Test Scenarios สำหรับ ความต้องการลำดับที่ 3 ต่อเพื่อ
และวันที่ 7 ทั้งหมดก็จะใช้เวลาหลังเลิกงาน เพื่อทำงานล่วงเวลาตอนค่ำ
วันที่ 8
เหล่า Developer/Programmer ก็ไปส่ง ความต้องการลำดับที่ 1 และ ความต้องการลำกับที่ 2 เข้ามาที่ QA Test
Quality Assurance (in the name) หรือ Software Tester วางมือจากการเขียน Test Scenarios สำหรับ ความต้องการลำดับที่ 4 แล้วมาลงมือทดสอบ ความต้องการลำดับที่ 1 ในขณะที่ ความต้องการลำดับที่ 4 นั้นมารอให้ทดสอบแล้ว
และวันที่ 8 ทั้งหมดก็จะใช้เวลาหลังเลิกงาน เพื่อทำงานล่วงเวลาตอนค่ำ ยาวไปจนถึงดึก โดยก็ยังให้กำลังใจกันอยู่ตลอด พร้อมถ่ายภาพแสดงถึงความทุ่มเทขึ้นบน Social Network เช่น Facebook
วันที่ 9
เหล่า Developer/Programmer นำส่ง ความต้องการลำดับที่ 2 ที่แก้ไข Bug แล้ว ความต้องการลำดับที่ 3 เข้าสู่ QA Test
Quality Assurance (in the name) หรือ Software Tester ก็เร่งเขียนการทดสอบสำหรับความต้องการลำดับที่ 4 ให้เสร็จ แล้วก็ไปดำเนินการทดสอบทั้ง 3 ความต้องการที่มารออยู่ในช่อง QA Test ขณะที่ ความต้องการลำดับที่ 1 นั้นผ่านการทดสอบจาก QA Test และส่งไปให้ User Test แล้วจึงลากไปไว้ที่ Done ที่ เสร็จ แค่ทดสอบผ่านเฉพาะส่วนของ Functional Test เท่านั้น ยังไม่ได้ทำการทดสอบในส่วนของ Non-Functional Test เลย ไม่ว่าจะเป็น Performance Test และ/หรือ Load Test และ/หรือ Security Test เป็นต้น
ตลอดวันที่ 9 บรรยากาศระหว่างเหล่า Developer/Programmer และ Quality Assurance (in the name) หรือ Software Tester และผู้ที่ต้องเข้ามาทดสอบในช่อง User Test นั้นจะมีความวุ่นวายพอสมควร เพราะเวลานั้นถูกนับถอยหลังไปเรื่อยๆ เพื่อเข้าสู่ พิธีกรรม ลำดับที่ 4 ของ Scrum Framework คือ Sprint Review ที่จะเกิดขึ้นในวันที่ 10
เวลายามบ่าย เดินทางสู่เวลายามค่ำ เวลายามค่ำเดินทางสู่ยามดึก กับบรรยากาศการทำงานที่วนไปวนมาระหว่าง ทดสอบ รายงานผล แก้ไข ทดสอบซ้ำว่าแก้ไขแล้ว ส่งให้ผู้ใช้ตรวจดูว่าสามารถย้ายไปที่ Done ได้หรือยัง
จนสุดท้ายก็ Done เฉพาะส่วนของ Functional Test เท่านั้น ยังไม่ได้ทำการทดสอบในส่วนของ Non-Functional Test เลย ไม่ว่าจะเป็น Performance Test และ/หรือ Load Test และ/หรือ Security Test เป็นต้น
จากตัวอย่างของ mini-waterfall แบบที่ 1 นั้นจะเห็นว่าเอาเข้าจริงๆ ก็ไม่ได้เสร็จแบบที่พร้อมที่จะสามารถนำขึ้นไปเปิดทดลองใช้บริการ หรือเปิดให้บริการได้บน Production Environment และก็เป็นการพัฒนา ทดสอบ เพื่อส่งมอบซอฟต์แวร์แบบ Sequence Phases เหมือนเดิม และที่เพิ่มเติมคือ เหนื่อยมากกว่าเดิม ตลอดระยะเวลาในแต่ละ Sprint
mini-waterfall แบบที่ 2 ไปทดสอบในรอบการทำงานถัดไป
สำหรับรูปแบบของ mini-waterfall แบบที่ 2 นั้น สรุปออกมาได้ดังนี้
- ระยะเวลาตั้งแต่วันที่ 2 ถึงวันที่ 9 ของ Sprint เหล่า Developer/Programmer ก็ลงมือพัฒนา Production Code โดยอาจจะมีการพัฒนา Test Code เช่น Unit Test Cases และ/หรือ Integration Test Cases และ/หรือ Component Test Cases และ/หรือ การทดสอบอื่นๆ
- Quality Assurance (in the name) หรือ Software Tester ก็จะทำงานขนานไปด้วย โดยจะมีใบงาน หรือไม่มีใบงาน และอาจจะมีกระดานงานของตนเอง | To-Do | Doing | Done | เท่าที่ได้เห็น และได้ยินมา จะตั้งชื่อว่า QA Board หรือ Tester Board และก็จะเริ่มเขียน Test Scenarios ระดับของการทดสอบ User Acceptance Test และ/หรือ System Integration Test และ/หรือ API Test และ/หรือ End-to-End Test ทั้งในรูปแบบ Manual Testing ที่อยู่ใน Microsoft Excel หรือ Microsoft Word หรือ Automation Test Scripts เช่น Robotframework และ/หรือ CyPress และ/หรือ Postman รวมทั้งเขียนการตรวจสอบการ Validate Text Fields ต่างๆ ลงไปด้วยทั้งใน Manual Testing และ/หรือ Automation Test Scenarios สำหรับ ทุกความต้องการของ Sprint 1
- Quality Assurance (in the name) หรือ Software Tester รวมทั้งผู้ใช้ที่เกี่ยวข้องกับการทดสอบ User Test จะไปลงมือทดสอบ ทุกความต้องการของ Sprint 1 ในช่วงเวลาของ Sprint 2
- ใน Sprint 2 เหล่า Developer/Programmer ก็ลงมือพัฒนา Production Code โดยอาจจะมีการพัฒนา Test Code เช่น Unit Test Cases และ/หรือ Integration Test Cases และ/หรือ Component Test Cases และ/หรือ การทดสอบอื่นๆ ของ ความต้องการทั้งหมดของ Sprint 2 ในขณะที่ต้องแก้ไข Bugs/Defects ของทุกความต้องการของ Sprint 1
และทุกคนไม่ว่าจะเป็น
- เหล่า Developer/Programmer
- Quality Assurance (in the name) หรือ Software Tester
- ผู้ใช้ที่เกี่ยวข้องกับการทดสอบ User Test
ก็ต้องร่วมกงกรรมกงเกวียนเป็นรอบๆ ไปจนช่วงสุดท้ายของระยะเวลาที่จะมีการตั้งชื่อ Sprint นั้นว่า Release Sprint ที่จะ แก้ แก้ แก้ ของทั้งหมดที่ตกค้างมาเรื่อยๆ จาก Sprint ต่างๆ
เช่นเดียวกัน mini-waterfall แบบที่ 2 ก็ไม่ต่างอะไรกับ Sequence Phases ปกติเลย
ดังนั้น
ในฐานะของผู้ที่สวมบทบาทสมมติเป็น Quality Assurance (in the name) หรือ Software Tester ต้องรู้ว่า ณ ตอนนี้ที่ทำงานกันอยู่นั้น และเข้าใจกันไปว่า Agile และใช้ Scrum กันอยู่ในทุกๆ วันนั้น เราเป็นแค่ mini-waterfall
เมื่อสติมาและถุงกาวถูกส่งไปไว้ที่อื่นแล้วนั้น ในฐานะของผู้ที่สวมบทบาทสมมติเป็น Quality Assurance (in the name) หรือ Software Tester ก็ต้องอธิบาย เพื่อให้ทุกๆ คนที่เกี่ยวข้องทราบว่า เราเป็นแค่ mini-waterfall
และจะต้องเปลี่ยนรูปแบบของการพัฒนา ทดสอบ และส่งมอบซอฟต์แวร์ให้เป็นแบบที่
ความรับผิดชอบเรื่องของการทดสอบ และคุณภาพของซอฟต์แวร์ร่วมกันทุกผู้ทุกคนที่เกี่ยวข้องกับการพัฒนา ทดสอบ และส่งมอบซอฟต์แวร์ ไม่ว่าจะเป็นในรูปแบบของ Sequence Phases หรือ Agile Software Development
ดังนั้น
ต้องป้องกัน ลด ละ เลิกการตรวจจับ
ผมขอยกคำพูดของ Mary Poppendieck ที่เขียนบันทึกไว้ในหนังสือที่ถ่ายทอดจากประสบการณ์ลงมาใน Implementing Lean Software Development ที่ว่า
The job of tests, and the people that develop and run tests, is to prevent defects, not to find them.
ผมถอดความออกมาว่า
- การทดสอบนั้น ไม่ว่าจะในรูปแบบของการพัฒนา ทดสอบ และส่งมอบซอฟต์แวร์ทั้งแบบ Waterfall Model หรือจะ Agile Software Developent นั้น ต้องเป็นการป้องกันการเกิด Defects
- ทุกๆ คนที่เกี่ยวข้องกับการพัฒนา ทดสอบ และส่งมอบซอฟต์แวร์ โดยเฉพาะอย่างยิ่ง Agile Software Development ไม่ว่าจะเป็นวิธีการ (Methodology) หรือกรอบการทำงาน (Framework) แบบใด ทั้งผู้คนจากฝั่งธุรกิจ และฝั่งพัฒนา จะต้องร่วมกันป้องกัน Defects
แล้ว ต้องป้องกัน ลด ละ เลิกการตรวจจับ นั้นต้องทำอย่างไรนั้น จะถูกบอกเล่า พร้อมตัวอย่างในตอนต่อไปของ
อะไรบ้างที่ต้องทำเมื่อเราเป็น Software Tester ใน Agile Team
ไม่ว่าแง่มุมไหนที่ได้จาก WeLoveBug จะเหมือนหรือแตกต่างกันอย่างไร สำคัญที่สุดคือการนำไปปรับใช้ และส่งต่อประสบการณ์นั้นจากเราสู่เพื่อนพ้องน้องพี่รุ่นต่อไป เพราะ การแบ่งปันก็คือความใส่ใจ
วันอังคารที่ 10 กันยายน พ.ศ.2562
หลักสี่ กรุงเทพมหานคร ประเทศไทย
