อะไรบ้างที่ต้องทำเมื่อเราเป็น Software Tester ใน Agile Team — ประเมินระดับการทดสอบว่าเรา รอ หรือ คล่องตัว

รูปจาก http://gomairu.blogspot.com/2017/08/blog-post_78.html

ความเดิมจากตอนที่แล้ว

อะไรบ้างที่ต้องทำเมื่อเราเป็น Software Tester ใน Agile Team — รู้ตัวก่อนว่าที่ทำอยู่มันคือ mini-waterfall

ตอนต่อมา เราก็จะต้องรู้ว่า ณ ตอนนี้เรามีอะไรบ้างที่จะต้องทำเพื่อสร้างการเดินทางจาก ณ ปัจจุบัน ที่เป็น mini-waterfall ที่ ทดสอบอยู่ตอนท้าย ของ Iteration หรือ Sprint อยู่ มาสู่การทดสอบแบบที่เรียกว่า Agile Testing หรือ การทดสอบแบบคล่องตัว

หนึ่งในวิธีการที่ผมได้ไปเจอมา และดีงามมากกับการนำมาใช้มาเป็นระยะเวลาเกือบปีแล้ว คือ

Assessment — How agile is your testing?

แบบประเมิน How agile is your testing? นั้นเป็นของ Karan Greaves แห่ง Growing Agile (http://www.growingagile.co.nz/)

ดังนั้นเตรียมปากกา และกระดาษมาให้พร้อม เพื่อตอบคำถาม 10 ข้อว่าแต่ละข้อ

• ถ้าตอบว่า ใช่ ก็ให้ 1 คะแนน
• ถ้าตอบว่า ไม่ใช่ ก็ให้ 0 คะแนน

เพื่อให้รู้ตัวเราก่อนว่าเราอยู่ ณ จุดไหนใน 4 ระดับ ของ How agile is your testing? และในแต่ละคำถามผมจะอธิบายขยายความเพิ่ม เพื่อเป็นข้อมูลประกอบการตอบ

คำถามที่ 1 The whole team is clear on what should be tested for each user story and feature before any coding starts.

The Whole Team ผมขออ้างอิงไปที่ Extreme Programming และ Kent Beck ได้เขียนอธิบายไว้ในบทที่ 10 ของหนังสือ Extreme Programming Explained: Embrace Change, 2nd Edition (The XP Series) 2nd Edition

รูปจากบทที่ 10 The Whole XP Team

Kent Beck ได้ระบุไว่ว่า

The XP Whole Team = Testers + Interaction Designers + Architects + Project Managers + Product Managers + Executives + Technical Writers + Users + Programmers + Human Resources

และ

“…user story…” นั้นประกอบไปด้วย

Requirements = ( Functional Requirements + Test Scenarios + Test Data (Production หรือ Production-Like)) + ( Non-Functional Requirements + Test Scenarios + Test Data (Production หรือ Production-Like))

สมการ Requirements ผมนำอ้างอิงมาจาก

• http://www.extremeprogramming.org/rules/userstories.html
• http://microservices.io/microservices/news/2018/02/20/no-such-thing-as-a-microservice.html

“…should be tested…” หมายถึง การทดสอบซอฟต์แวร์ที่ประกอบไปด้วย Functional Testing และ Non-Functional Testing ต้องระบุให้ชัด ออกมาพร้อม Test Cases + Test Data และ Test Scenarios + Test Data ตั้งแต่ตอนจัดเตรียมรายละเอียด เช่น Scrum — Product Backlog Refinement

และ

“…before any coding start.” หมายถึง ก่อนที่จะลงมือจรดปลายนิ้วลงไปเขียน Test Code และ Production Code และ Test Code ต้องถูกเขียนขึ้นมาก่อนในระดับของ Acceptance Testing และ API Testing ตั้งแต่ตอนจัดเตรียมรายละเอียด เช่น Scrum — Product Backlog Refinement

ดังนั้น สำหรับคำถามข้อที่ 1 ใครตอบว่า

• ใช่ เราทำแบบนั้น ก็ + 1 คะแนน
• ไม่ใช่ เราไม่ได่ทำแบบนั้น ก็ +0 คะแนน

คำถามที่ 2 Before you discuss the solution, you make sure you understand the who and why behind any requirement.

ก่อนจะกระโจนไป วิเคราะห์ ออกแบบ และร่างภาพว่าจะต้องเขียน Production Code ออกมานั้น เรามีการระบุกันอย่างชัดเจนว่า เพื่อให้ทุกคนเห็นภาพตรงกันว่า

ใคร บ้างที่เกี่ยวข้องกับ Business Process เงื่อนไขต่างๆ และ Business Operation ของแต่ละความต้องการ พร้อม เหตุผลประกอบ ที่จับต้องได้

ซึ่งต้องเกิดขึ้นตั้งแต่ตอนจัดเตรียมรายละเอียด เช่น Scrum — Product Backlog Refinement

ดังนั้น สำหรับคำถามข้อที่ 2 ใครตอบว่า

• ใช่ เราทำแบบนั้น ก็ + 1 คะแนน
• ไม่ใช่ เราไม่ได่ทำแบบนั้น ก็ +0 คะแนน

คำถามที่ 3 You ask and answer the question “How will we test that?” when discussing a user story.

เรามาการตั้งคำถาม หรือ สร้างบัตรคำถามว่า

“How will we test that”?

หรือ

เราจะทดสอบอะไร และอย่างไร?

โดยไม่ใช่การตอบคำถามโดย Quality Assurance (in the name) หรือ Software Tester เท่านั้น ต้องเป็นทุๆ คนที่จะต้องช่วยกันตอบคำถามว่า ทั้ง Functional Testing และ Non-Functional Testing

พร้อมทั้งบันทึกออกมาเป็นเอกสารบน Flipchart หรือ กระดาน หรือ Microsoft Excel หรือ Google Spreadsheet

ดังนั้น สำหรับคำถามข้อที่ 3 ใครตอบว่า

• ใช่ เราทำแบบนั้น ก็ + 1 คะแนน
• ไม่ใช่ เราไม่ได่ทำแบบนั้น ก็ +0 คะแนน

คำถามที่ 4 Everyone on the team knows how to run the automated tests and read the results.

จาก

The XP Whole Team = Testers + Interaction Designers + Architects + Project Managers + Product Managers + Technical Writers + Users + Programmers + Executives + Human Resources

ดังนั้น ผมขอกำหนดเป็นสมการ

Everyone = Testers + Interaction Designers + Architects + Project Managers + Product Managers + Technical Writers + Users + Programmers

รู้ว่า

1. Automation Test Scripts ในทุกระดับของ Functional Test และ Non-Functional Test นั้น ต้องสร้าง เตรียมการให้พร้อม เพื่อ Run ซ้ำๆ กี่ครั้งต่อวันก็ได้แบบไม่มีข้อจำกัดเรื่องจำนวนครั้ง
2. Automation Test Scripts ในทุกระดับของ Functional Test และ Non-Functional Test นั้น ต้องสร้าง เตรียมการ และ Run ซ้ำๆ กี่ครั้งต่อวันก็ได้แบบไม่มีข้อจำกัดเรื่องจำนวนครั้ง ในทุกๆ Environments และได้ผลการทดสอบเหมือนเดิม กี่ครั้งต่แวันตั้งแต่ เครื่อง Programmer ไปในทุกๆ Environments จนถึง User Acceptance Testing Environment, Pre-Production/Staging Environment รวมทั้ง Production Environment
3. รู้ว่าอ่านรายงานอย่างไร และที่ใด

ดังนั้น สำหรับคำถามข้อที่ 4 ทั้ง ข้อที่ 1 ข้อ 2 และข้อที่ 3ใครตอบว่า

• ใช่ ใช่ และ ใช่ เราทำแบบนั้น ก็ + 1 คะแนน
• ไม่ใช่ ในข้อใด ข้อหนึ่ง เราไม่ได่ทำแบบนั้น ก็ +0 คะแนน

คำถามที่ 5 You discuss what you will automate at which level so that you don’t duplicate tests between the unit, integration, component, API and UI levels.

มีการคุยเพื่อให้เห็นภาพตรงกันว่าจะ

1. ต้องทดสอบอะไรบ้างทั้ง Functional Test และ Non-Functional Test เพื่อไม่ให้เกิดการทับซ้อน และซ้ำซ้อนกัน
2. ทั้งหมดต้องเป็น Automation Testing ที่สร้าง Code Test ขึ้นมาก่อนที่จะเริ่มลงมือพัฒนา Production Code

ดังนั้น สำหรับคำถามข้อที่ 5 ทั้งข้อที่ 1 และข้อที่ 2 ใครตอบว่า

• ใช่ และ ใช่ เราทำแบบนั้น ก็ + 1 คะแนน
• ไม่ใช่ ในข้อใด ข้อหนึ่ง เราไม่ได่ทำแบบนั้น ก็ +0 คะแนน

คำถามที่ 6 Your automation test scripts are version controlled and labelled along with the source code since tests are part of the working software.

Test Automation Scripts ในทุกๆ ชนิด และระดับของการทดสอบทั้ง Functional Test และ Non-Functional Test

1. จัดเก็บไว้ใน Source Code Management Tool ไม่ใช่ในเครื่องของคนที่สร้าง เช่น ใน เครื่องของ Quality Assurance (in the name) หรือ Software Tester
2. จัดเก็บไว้ใน Source Code Management Tool ใน Repository เดียวกันกับ Production Code ของ Service/Product

ดังนั้น สำหรับคำถามข้อที่ 6 ทั้งข้อที่ 1 และข้อที่ 2 ใครตอบว่า

• ใช่ เราทำแบบนั้น ก็ + 1 คะแนน
• ไม่ใช่ ในข้อใด ข้อหนึ่ง เราไม่ได่ทำแบบนั้น ก็ +0 คะแนน

คำถามที่ 7 You don’t have a bug database because you fix bugs as soon as you find them, instead of logging them.

ยามใดที่ตรวจพบ Bug หรือ Defect

1. เราไม่บันทึกเก็บ Bug หรือ Defect
2. เราวิเคราะห์ เพื่อหาต้นสาย ปลายเหตุ ของ Bug หรือ Defect
3. เราออกแบบ Test Cases + Test Data (Production หรือ Production-Like) และ/หรือ Test Scenarios + Test Data (Production หรือ Production-Like) หากไม่มี เลยทำให้เกิด Bug หรือ Defect
4. เราสร้าง Test Cases หรือ Test Scenarios ให้เป็น Automation
5. เรา Run Test Cases และ/หรือ Test Scenarios ที่เป็น Automation แล้ว ก็จะได้ผลลัพธ์ของการ Run ว่า ไม่ผ่าน
6. เราปรับแก้ไข Production Code เพื่อให้ Test Cases และ/หรือ Test Scenarios ที่เป็น Automation นั้นผ่าน
7. เรา Run ชุดการทดสอบ Unit Test Cases ทั้งหมดให้ผ่าน 100% และ Run ชุดการทดสอบระดับอื่นๆ ให้ผ่านทั้งหมด เพื่อให้มั่นใจว่าไม่เกิดผลกระทบใดๆ จากการปรับแก้ไข Production Code

เรา ในที่นี้ คือ Everybody

ดังนั้น สำหรับคำถามข้อที่ 7 ใครตอบว่า

• ใช่ ทั้ง 7 ข้อ เราทำแบบนั้น ก็ + 1 คะแนน
• ไม่ใช่ ในข้อใด ข้อหนึ่ง เราไม่ได่ทำแบบนั้น ก็ +0 คะแนน

คำถามที่ 8 When your continuous integration server fails, it is addressed and returned to a working state within an hour.

ยามใดที่ขั้นตอนของ Continous Integration ที่ประกอบไปด้วย Automation Build และ Automation Test เกิดไม่ผ่านในขั้นตอนใดขั้นตอนหนึ่ง

เราหยุดแล้วก็มาหาสาเหตุ และลงมือแก้ไข เพื่อให้กลับมาสู่ขั้นตอนของ Automation Build และ Automation Test ให้ผ่านทั้งหมด ภายในระยะเวลาไม่เกิน 1 ชั่วโมง

ดังนั้น สำหรับคำถามข้อที่ 8ใครตอบว่า

• ใช่ เราทำแบบนั้น ก็ + 1 คะแนน
• ไม่ใช่ เราไม่ได่ทำแบบนั้น ก็ +0 คะแนน

คำถามที่ 9 When observing your standup meeting an outsider would not be able to tell who is a developer and who is a tester.

ยามใดที่มีผู้มาเยี่ยม มีผู้มาดู มีผู้มาสังเกตการณ์ Extreme Programming — Standup Meeting หรือ Scrum — Daily Scrum ผู้คนเหล่านั้นต้องไม่สามารถระบุ ได้ว่าใครเป็น Programmer/Development หรือใครเป็น Tester

ดังนั้น สำหรับคำถามข้อที่ 9ใครตอบว่า

• ใช่ เขาระบุไม่ได้ ก็ + 1 คะแนน
• ไม่ใช่ เขาระบุได้ ก็ +0 คะแนน

คำถามที่ 10 Your team has a way to measure quality, which you use to identify if your testing process is working for you.

สมาชิกทุกคนในทีม กำหนดวิธีการวัดระดับของคุณภาพของงาน และนำข้อมูลจากการจับวัดเก็บค่ามาใช้ในการพัฒนาการทดสอบให้ดีขึ้นเรื่อยๆ

ดังนั้น สำหรับคำถามข้อที่ 10 ใครตอบว่า

• ใช่ เราทำแบบนั้น ก็ + 1 คะแนน
• ไม่ใช่ เราไม่ได่ทำแบบนั้น ก็ +0 คะแนน

รวมคะแนน แล้วดูว่าเราอยู่ตรงไหน

0 คะแนน

เป็นข่าวดีมาก ที่เราสามารถจะพัฒนาให้การทดสอบของเราให้ดีขึ้นได้ โดยเลือกมาหนึ่งข้อ แล้วนำไปกำหนดเพื่อวิเคราะห์หาต้นสายปลายเหตุ กำหนดเป้าหมาย และลงมือดำเนินการ เพื่อเปลี่ยนคำตอบจาก ไม่ใช่ ไปสู่ ใช่

1 ถึง 4 คะแนน

เรามากันถูกทางแล้วตามแนวทางปฏิบัติของการทดสอบซอฟต์แวร์ในรูปแบบของการพัฒนา ทดสอบ และส่งมอบซอฟต์แวร์แบบ Agile Software Development แล้วนำไปกำหนดเพื่อวิเคราะห์หาต้นสายปลายเหตุ กำหนดเป้าหมาย และลงมือดำเนินการ เพื่อเปลี่ยนคำตอบจาก ไม่ใช่ ไปสู่ ใช่ โดยไม่ไปเพิ่มปัญหาให้กับทีม และเกิดความล้า

5 ถึง 8 คะแนน

เราต้องออกมาเผยแพร่ แบ่งปัน ส่งมอบองค์ความรู้ และประสบกาณ์ให้กับคนอื่นๆ หรือทีมอื่นๆ และถ้าจะเพิ่มเติมและเปลี่ยนจาก ไม่ใช่ ไปสู่ ใช่

9 ถึง 10 คะแนน

เรามันระดับ Rock Star เราต้องออกไปเผยแพร่สิ่งที่เราทำออกไปให้คนอื่นๆ ปรับปรุงกระบวนการ และขั้นตอนของการทดสอบซอฟต์แวร์

คะแนนได้ออกมาเท่าไรก็จดไว้ และนำไปใช้เพื่อในการวางแผนในการปรับเปลี่ยน เพื่อพัฒนาการทดสอบซอฟต์แวร์ของทีมให้ดีขึ้นด้วยกันทั้งทีม

ในตอนต่อไปของ

อะไรบ้างที่ต้องทำเมื่อเราเป็น Software Tester ใน Agile Team

เราจะมาคุยต่อว่า Quality Assurance (in the name) หรือ Software Tester จะต้องทำอะไรบ้าง เพื่อปรับ และเปลี่ยนตัวเองก่อน จะไปนำพาคนอื่นว่าการทดสอบในรูปแบบของการพัฒนา ทดสอบ และส่งมอบซอฟต์แวร์ในรูปแบบของ Agile Software Development ด้วย Extreme Programming เพื่อให้เห็นว่า

ที่

1. การทดสอบนั้น ไม่ว่าจะในรูปแบบของการพัฒนา ทดสอบ และส่งมอบซอฟต์แวร์ทั้งแบบ Waterfall Model หรือจะ Agile Software Developent นั้น ต้องเป็นการป้องกันการเกิด Defects
2. ทุกๆ คนที่เกี่ยวข้องกับการพัฒนา ทดสอบ และส่งมอบซอฟต์แวร์ โดยเฉพาะอย่างยิ่ง Agile Software Development ไม่ว่าจะเป็นวิธีการ (Methodology) หรือกรอบการทำงาน (Framework) แบบใด ทั้งผู้คนจากฝั่งธุรกิจ และฝั่งพัฒนา จะต้องร่วมกันป้องกัน Defects

แล้ว ต้องป้องกัน ลด ละ เลิกการตรวจจับ นั้นต้องทำอย่างไรนั้น

ข้อมูลอ้างอิง และแหล่งที่ควรจะศึกษาเพิ่มเติม

1. Assessment — How agile is your testing? โดย Karan Greaves http://www.growingagile.co.za/2015/10/assessment-how-agile-is-your-testing/
2. User Story จาก http://www.extremeprogramming.org/rules/userstories.html
3. No such thing as a microservice จาก http://microservices.io/microservices/news/2018/02/20/no-such-thing-as-a-microservice.html

ไม่ว่าแง่มุมไหนที่ได้จาก WeLoveBug จะเหมือนหรือแตกต่างกันอย่างไร สำคัญที่สุดคือการนำไปปรับใช้ และส่งต่อประสบการณ์นั้นจากเราสู่เพื่อนพ้องน้องพี่รุ่นต่อไป เพราะ การแบ่งปันก็คือความใส่ใจ

วันอังคารที่ 17 กันยายน พ.ศ.2562
ราษฎร์บูรณะ กรุงเทพมหานคร ประเทศไทย