อะไรบ้างที่ต้องทำเมื่อเราเป็น Software Tester ใน Agile Team — อารัมภบท
17 ปี 4 เดือน 18 วัน เป็นระยะเวลาจากวันอังคารที่ 13 กุมภาพันธ์ พ.ศ.2544 จนถึงวันนี้ วันเสาร์ที่ 30 มิถุนายน พ.ศ.2561 ที่ Agile Manifesto to Software Development ถูกประกาศออกมา และจากวันนั้นจนถึงวันนี้สิ่งที่เกิดขึ้นคือ Agile ระบาดไปเกือบทุกองค์กรที่มีแผนก IT รวมทั้งยังระบาดไปสู่ภาคส่วนอื่นที่ที่เป็น Non-IT อีกด้วยเช่นกัน ไม่ว่าจะเป็นต่างประเทศหรือแม้แต่ในประเทศไทยเองก็ตาม
หนึ่งปัญหาที่พบเจอจากการนำ Agile for Software Development มาปรับใช้ในองค์กรในส่วนงานของ IT ที่มีหน้าที่พัฒนาและส่งมอบซอฟต์แวร์นั้นคือ Software Tester มิรู้ว่าจะต้องทำตัวอย่างไรและต้องทำอะไร?
มันไม่เหมือนเดิม
เรื่องที่จะต้องหยุดแล้วกลับมาดูกันในรายละเอียดก่อนก็คือการพัฒนาและส่งมอบแบบ Agile for Software Development นั้นแตกต่างจากการพัฒนาและส่งมอบแบบที่ส่วนใหญ่เรียกว่า Waterfall
ที่ไม่เหมือนเดิมในบริบทของการทดสอบซอฟต์แวร์ (Testing) เพราะ
การทดสอบไม่เป็น Phase อีกต่อไป และการทดสอบต้องเป็นงาน (Task) ที่จะต้องทำให้ครบในทุกระดับของการทดสอบทั้ง Functional Testing และ Non-Functional Testing ต่อหนึ่ง Feature หรือ Function หรือ Use Case หรือ User Story
ดังนั้น
- Software Tester ไม่สามารถจะทำงานตามแบบเดิมได้
- Programmer / Developer ไม่สามารถจะทำงานตามแบบเดิมได้
- Business Analyst / System Analyst ไม่สามารถจะทำงานตามแบบเดิมได้
- User / Customer ไม่สามารถจะทำงานตามแบบเดิมได้
เริ่มต้นจาก
จากที่เกริ่นนำไว้แล้วว่าไม่เหมือนเดิม เรื่องที่จะต้องทำก่อนเลยคือ ศึกษา ก่อนว่า
Agile for Software Development คืออะไร?
ผมแนะนำให้อ่านเพื่อทำความรู้จักกับ Agile for Software Development ผ่านทาง หลักการจำนวนสิบสองข้อที่ จาก http://agilemanifesto.org/principles.html
เมื่ออ่านจบแล้วจะพบว่า ไม่มีการระบุถึงการทดสอบซอฟต์แวร์อย่างชัดเจนสักข้อ
ที่จะใกล้เคียงสุดก็เห็นจะเป็นข้อที่เก้า คือ
Continuous attention to technical excellence and good design enhances agility.
แต่ก็มิได้มีการพูดขยายความไว้เสียแต่อย่างใด ณ เว็บไซต์ AgileManifesto
ดังนั้น Agile for Software Development นั้นบอกเราเพียงแค่หลักการ (Principle) ว่าจะต้องเกิดอะไรขึ้นบ้างเท่านั้น แต่ไม่ได้บอกถึง การปฏิบัติ (Practice)
จาก หลักการ สู่ การปฏิบัติ
สิ่งที่เราจะต้องไปต่อกันกับ Agile for Software Development คือ การนำหลักการ (Principle) จำนวนสิบสองข้อที่ระบุไว้ ไปสู่ การปฏิบัติ (Practices) เพื่อนำไปปรับประยุกต์ใช้ ซึ่งการปฏิบัติต่างๆ ก็จะมีอยู่ในกรอบการทำงาน (Framework) หรือระเบียบวิธี (Methodology) ที่เกี่ยวข้องกับ Agile for Software Development
กรอบการทำงาน (Framework) ที่ได้รับความนิยม คือ Scrum
Scrum ถูกคิดและปรับปรุงพัฒนาให้ดีขึ้นโดยสองท่านคือ Dr.Jeff Sutherland และ Ken Schwaber โดยทั้งสองท่านร่วมกันเขียนเอกสารเพื่อแนะนำ Scrum ในนามว่า Scrum Guide โดยสามารถหาอ่านได้จากเว็บไซต์ที่ทั้งสองท่านดูแลอยู่คือ ScrumGuide.org (http://www.scrumguides.org/download.html)
อ้างอิงจากเอกสาร Scrum Guide ฉบับล่าสุด พฤศจิกายน 2560 ก็มิได้มีการบอกเล่าว่า Software Tester จะต้องทำอะไรบ้างแบบชัดเจนใน Scrum แต่ก็มิได้จะสิ้นหวังไปเสียแต่อย่างใดเพราะใน Scrum Guide มีการระบุไว้ถึงแม้จะไม่ตรงๆ ว่า Software Tester จะต้องทำอะไร แต่ก็มีกล่าวถึงเรื่องของคุณภาพของซอฟต์แวร์ไว้อยู่ตามที่ผม Highlight ไว้ตามรูป
ในระยะเวลาไม่เกินหนึ่งเดือน ทีมพัฒนาของ Scrum จะต้องสร้างสิ่งที่ Scrum เรียกว่า Potentially releasable product increment ออกมา โดยมีการระบุถึงคำว่า Done และ Usable โดยทีมพัฒนาของ Scrum จะต้องทำงานในกรอบเวลาที่คงที่ที่เรียกว่า Sprint ที่มีระยะเวลาตั้งแต่เริ่มจนจบเท่ากันตลอดทุกๆ Sprint
จากตรงที่ผมเขียนขยายความขึ้นมานั้น Usable ก็มีความเกี่ยวข้องโดยตรงกับเรื่องของการทดสอบอยู่ทั้ง Functional Testing และ Non-Functional Testing ที่จะต้องถูกทดสอบและแก้ไข Bugs หรือ Defects ที่พบแล้วเป็นที่เรียบร้อย ซึ่งเป็นหนึ่งองค์ประกอบหลักก่อนที่จะบอกว่า Feature หรือ Function หรือ Use Case หรือ User Story นั้น “เสร็จเรียบร้อย”
อีกหนึ่งจุดที่มีการระบุว่าใน Sprint จะต้องมีการทดสอบให้เรียบร้อยตรงที่บอกไว้ว่า
Sprints contain and consist of Sprint Planning, Daily Scrums, the development work, the Sprint Review and the Sprint Retrospective.
Development work สำหรับผมตีความจากประสบการณ์ คือ ขั้นตอนของการพัฒนาและส่งมอบที่ประกอบไปด้วย การวิเคราะห์ ออกแบบ พัฒนา ทดสอบ และจัดเตรียมเพื่อส่งมอบ ดังนั้นหากนำ Scrum มาใช้ในการพัฒนาและส่งมอบซอฟต์แวร์นั้นก็ต้องมีการทดสอบซอฟต์แวร์อยู่ใน Development work
อีกทั้งการทดสอบซอฟต์แวร์นั้นจะต้องไม่เป็น Phase จะต้องเป็นงานที่จะต้องทำให้เสร็จ โดยหากมี Software Tester อยู่เป็นสมาชิกของทีมพัฒนานั้น Software Tester ต้องเป็นหนึ่งในสมาชิกประจำของทีม ต้องอยู่ด้วยตลอด ต้องร่วมวิเคราะห์ ต้องร่วมวางแผน ต้องร่วมพัฒนา ต้องร่วมทดสอบ ต้องร่วมส่งมอบและต้องร่วมทำงานทุกอย่างให้เรียบร้อยเพื่อส่งมอบ Potentially releasable product increment โดยผมความจากประสบการณ์ในการทำงานที่เคยเป็น Software Tester และ Scrum Master มาตรงประโยคที่เขียนว่า
Sprints have consistent durations throughout a development effort.
และห้ามที่จะละเลยหรือตัดเรื่องของคุณภาพของซอฟต์แวร์ออกไปซึ่งการทดสอบเป็นหนึ่งในองค์ประกอบของคุณภาพซอฟต์แวร์จากประโยคที่ว่า
Quality goals do not decrease
คำว่า “Done” หรือ “เสร็จเรียบร้อย” ของ Scrum มีการระบุไว้อย่างชัดเจนว่าทุกๆ คนที่เป็นสมาชิกใน Scrum Team (ประกอบไปด้วย Product Owner, Development Team และ Scrum Master) ต้องมีความเข้าใจ เห็นภาพตรงกัน และแบ่งปันความรู้ความเข้าใจให้กับสมาชิกใน Scrum Team และผู้ที่เกี่ยวข้อง ว่าเมื่อจะเอยว่า Product Backlot item (PBI) ซึ่งจะเป็น Feather หรือ Function หรือ Use Case หรือ User Story นั้นๆ “Done” หรือ “เสร็จเรียบร้อย”
ดังนั้นหากอยู่ในบริบทของ
Software Testing = Functional Test + Non-Functional Test
นั้นเป็นหน้าที่ความรับผิดชอบโดยตรงของ Software Tester ที่จะต้อง
- ให้ความรู้ผ่านการสอน (Trainning)
- นำพาผ่านการลงมือเพื่อให้ได้รับประสบการณ์ตรง (Workshop)
กับสมาชิกทุกๆ คนที่เกี่ยวข้องกับการส่งมอบ Potentially releasable product increment
แต่ก็ต้องยอมรับกันตรงๆ ก่อนว่า Software Tester ในไทย ณ ตอนนี้จะมีความรู้และความเข้าใจจากประสบการณ์ที่ได้มาจากการลงมือทำเองมาแล้วให้ครบทั้ง Functional Test และ Non-Functional Test นั้นหาได้ยากมาก
แต่ผู้สร้าง Scrum ทั้งสองคนก็มิได้ไม่มีทางออกให้ในเรื่องนี้
Scrum Master คือผู้ที่จะเข้ามาช่วยในกรณีที่ Software Tester นั้นไม่สามารถ
ให้ความรู้ผ่านการสอน (Trainning)
นำพาผ่านการลงมือเพื่อให้ได้รับประสบการณ์ตรง (Workshop)
ทั้งในส่วนของ Functional Test และ Non-Functional Test กับสมาชิกทุกๆ คนที่เกี่ยวข้องกับการส่งมอบ Potentially releasable product increment
อันนี้ก็ยากอีกเช่นกันเพราะก็ต้องยอมรับกันตรงๆ ว่า ผู้คนที่ทั้งโดนอุปโลกน์จากใครสักคนให้เป็น Scrum Master หรือ อุปโลกน์ตนเองขึ้นมาเป็น Scrum Master ที่จะมีทั้งองค์ความรู้และประสบการณ์ตรงที่ผ่านจากการลงมือทำมาทั้ง Functional Test และ Non-Functional Test
และมากไปกว่านั้นเนื่องจาก Scrum จะมีการแบ่งรอบการทำงานออกเป็นรอบสั้นๆ ที่มีระยะเวลาเท่าๆ กันที่ไม่เกินหนึ่งเดือนที่เรียกว่า Sprint ดังนั้นการทดสอบซอฟต์แวร์และควบคุมคุณภาพซอฟต์แวร์จะต้องดำเนินการตลอดในทุกๆ วัน นั้นหมายความว่าจะต้องมีการทดสอบที่เรียกว่า Regression Testing ทั้ง Functional Test และ Non-Functional Test ในทุกๆ ครั้งที่มีการแก้ไข Source Code ตามการเปลี่ยนแปลงที่เกิดขึ้นจากฝ่ายธุรกิจที่ถูกส่งผ่านมาทาง Product backlog items ดังนั้น
Regression Testing จะต้องถูกดำเนินการทดสอบแบบอัตโนมัติ (Automation Testing) อย่างหลีกเลี่ยงไม่ได้
นั่นหมายความว่าทุกๆ คนที่เป็นสมาชิกในทีมพัฒนาของ Scrum จะต้องมีความรู้และลงมือทำให้เกิด Automation Testing ให้ได้มากที่สุดเท่าที่จะเป็นไปได้ เพราะเป็นส่วนหนึ่งของ Development work ที่ได้เขียนไว้ตามด้านบน
ทั้งหมดที่ผมพล่ามมาด้านบนที่เกี่ยวกับ Scrum นั้น ส่วนที่อ้างอิงหลักการแนวทางก็มาจากเอกสาร Scrum Guide และส่วนที่เกี่ยวกับ Software Testing นั้นก็มาจากประสบการณ์ของตนเอง ซึ่งผมแนะนำให้อ่านเอกสาร Scrum Guide ต่อเมื่อจบการเสพบทความที่ผมพล่ามไว้นี้ และจะได้เห็นว่า Scrum เองก็ไม่ได้บอกอะไรแบบชัดเจนเลยเกี่ยวกับเรื่องของการทดสอบซอฟต์แวร์
ดังนั้นไม่ต้องแปลกในที่ Software Tester ดเมื่อถูกเลือกให้เข้าไปอยู่เป็นส่วนหนึ่งของสมาชิกทั้งชั่วคราวหรือประจำของทีมพัฒนาของ Scrum นั้นจะไม่รู้ว่าจะต้องทำอะไร และเอะอะก็ให้ไปทำ Automation Testing แบบทำไปทำไมก็ไม่ค่อยรู้
ระเบียบวิธี (Methodology) ที่เหมือนจะรู้จักแต่ไม่รู้จัก คือ Extremem Programming (XP)
ผมอยู่กับ Scrum มาระยะหนึ่งเพราะอุปโลกน์ตนเองเป็น Scrum Master และตลอดระยะเวลาก็พบว่า Scrum มิเพียงพอ และก็ออกหาความรู้ใหม่จนมาได้พบกับหนึ่งระเบียบวิธี (Methodology) นามว่า Extremem Programming คิดโดย Programmer เพื่อ Programmer และผู้คิดก็เป็นหนึ่งในสิบเจ็ดคนที่ร่วมกันประกาศ Agile Manifesto for Software Development และ Principles Behind Agile for Software Development นามว่า Kent Beck (https://en.wikipedia.org/wiki/Kent_Beck)
ผมรู้จัก Extreme Programming ผ่านทางเว็บไซต์ชื่อ Extreme Programming: A gentle introduction (http://www.extremeprogramming.org) ซึ่งผู้เขียนบทความบนเว็บไซต์ชื่อ Don Wells โดยสามารถอ่านประวัติของเขาได้จาก http://www.extremeprogramming.org/donwells.html
จากข้อมูลจาก Extreme Programming: A gentle introduction ได้อธิบายเรื่องของ กฏกติกาของ Extreme Programming ไว้และหนึ่งในนั้นมีเรื่องของ The Rules of Extreme Programming (http://www.extremeprogramming.org/rules.html) ซึ่งมีการระบุถึงเรื่องของการทดสอบซอฟต์แวร์ไว้อย่างชัดเจนตาม Highlight ในรูป
รวมทั้งที่มีการระบุถึงการทดสอบยังมีอีกสองส่วนคือ
ส่วนที่หนึ่ง Project Level ตามรูปแนบที่ Highlight ไว้ ทุกๆ User Story จะต้องมี Test Scenarios พร้อม Test Data (Production) มาพร้อมกันเพื่อนำเข้ามาใช้ในการวางแผนโครงการ (Release Planning)
ส่วนที่สอง Collective Code Ownership Level ตามรูปแนบที่ Highlight ไว้ที่มีการทดสอบทั้ง Unit Testing ผ่านการสร้าง Unit Test ขึ้นมาก่อนเพื่อใช้ในการออกแบบพฤติกรรมและพัฒนา Function ใหม่ๆ ออกมา และจะต้องรวม Source Code โดยการทำ Continous Integation ซึ่งประกอบไปด้วยสองการทดสอบแบบอัตโนมัติคือ 100% Unit Tests Passed และ Acceptance Test Passed
ดังนั้นไม่ว่าคุณจะเป็น Programmer หรือ Developer หรือ Software Tester ที่อ่านมาจนถึงบรรทัดนี้ผมแนะนำให้ศึกษา Extreme Programming และลงมือฝึกเพื่อให้ได้รับประสบการณ์ ก่อนการนำมาใช้ในกระบวนการพัฒนาและส่งมอบซอฟต์แวร์ไม่ว่าจะเป็นแบบใดๆ ก็ตาม มิใช่ว่าเมื่อโดนสั่งว่าเราจะใช้ Agile for Software Development แล้วถึงจะนำการปฏิบัติ (Practices) ของ Extremem Programming เข้ามาใช้ผ่านทาง Keywords ยอดฮิตติด Top Ten มาหลายปีติดต่อกันคือ Test-Driven Development (TDD), Acceptance Test Driven Development (ATDD), Continous Integation, Continous Delivery และ Code Review ซึ่งส่วนใหญ่จะเน้นหนักไปทางเรื่องของเครื่องมือซะมากกว่าความเข้าใจถึงจุดประสงค์ของการปฏิบัติ (Practices) แต่ละตัว
จุดเริ่มต้นของการศึกษาหาความรู้เกี่ยวกับ Extreme Programming ผมขอแนะนำหนังสือชื่อ Extrmeme Programming Explained ตามภาพ และศึกษาเพิ่มเติมต่อไปรวมทั้งลงมือทำประกอบไปด้วยเช่นเดียวกัน
มาถึง ณ จุดนี้ความเข้าใจเรื่องของการปรับประยุกต์ใช้ Agile for Software Development ไปใช้ในองค์กรนั้นยังเน้นหนักไปทาง Scrum ซะเยอะ หลังๆ ก็มีเรื่องอื่นตามมาปะปนเข้าไปด้วยไม่ว่าจะเป็น DevOps, Microservices, Docker และอื่นๆ แต่ไม่ว่าจะอย่างไรเท่าที่พบเจอมานั้นการทดสอบยังคงถูกทำแค่ส่วนของ Functional Test เท่านั้นในแต่ละรอบการทำงานไม่ว่าจะเรียกขานว่า Sprint หรือ Iteration และยังคงเป็นแบบ Mini-Waterfall ในป้ายชื่อใหม่ว่า Agile หรือ Scrum และ Software Tester ก็ยังคง งง งง และโดนมอบหมายให้เป็นมือทำ Automation Testing ไปพร้อมๆ กับยังต้องทดสอบแบบ Manual Testing
เริ่มต้นไปด้วยกัน
บทความชุดนี้ที่ตั้งชื่อว่า “อะไรบ้างที่ต้องทำเมื่อเราเป็น Software Tester ใน Agile Team” ถูกเขียนขึ้นเพื่อส่งมอบทั้งความรู้และประสบการณ์จากการลงมือทำของผมและเพื่อนพ้องน้องพี่ที่ร่วมเดินทางบนเส้นทาง Agile for Software Development ให้กับทุกๆ คนที่เกี่ยวข้องกับการพัฒนาและส่งมอบซอฟต์แวร์ โดยจะเน้นหนักไปกับ Software Tester อยู่ในระดับหนึ่ง ผ่านทางการบันทึกไว้ในรูปแบบของบทความ Podcast และ VDO ผ่านทาง WeLoveBug
ไม่ว่าแง่มุมไหนที่ได้จาก WeLoveBug จะเหมือนหรือแตกต่างกันอย่างไร สำคัญที่สุดคือการนำไปปรับใช้ และส่งต่อประสบการณ์นั้นจากเราสู่เพื่อนพ้องน้องพี่รุ่นต่อไป เพราะ การแบ่งปันก็คือความใส่ใจ
วันอาทิตย์ที่ 1 กรกฎาคม พ.ศ.2561
กรุงเทพมหานคร ประเทศไทย
