10 หลักปฏิบัติของ Agile Tester ที่ไม่ใช้ Agile ก็นำไปทำได้ ตอน เน้นช่วยส่งมอบซอฟต์แวร์ที่ทำงานได้จริงก่อนเสมอ

Delivery-Value-To-Customer

ข้อปฏิบัติที่ 2 ของ Agile Testing คือ Deliver Value to Customer ผมขอแปลเป็นภาษาไทยว่า เน้นช่วยส่งมอบซอฟต์แวร์ที่ทำงานได้จริงก่อนเสมอ ซึ่งต้องมาคุยต่อกันกับคำว่า ซอฟต์แวร์ที่ทำงานได้จริง ว่ามันคืออะไร? แล้ว Tester นั้นมีส่วนช่วยเหลือได้อย่างไรบ้าง?

ผมเชื่อว่าหลายๆ คนที่อ่านอยู่ตอนนี้

ถ้าเป็น Programmer หรือ Developer หรือ Team Leader หรือ System Analyst น่าจะเคยมีประสบการณ์ที่ต้องนั่งอยู่ในห้องประชุมที่มี Tester กำลังอธิบาย Bug หรือ Defect ที่ นาน นาน นาน และนานทีถึงจะเกิดขึ้นในระบบ แต่เราต้องมานั่งเสียเวลาเพื่อพุดคุยว่าสาเหตุคืออะไร? แล้วจะแก้ไขยังไง?

ถ้าเป็น Tester เราก็จะเป็นพวกที่จะมีความสามารถที่จะคิดหากรณีที่แปลกๆ ที่เจอ Bug หรือ Defect ที่ นาน นาน นาน และนานทีถึงจะเกิดขึ้นในระบบ แล้วก็ไม่ยอมให้ผ่านไปได้ง่ายๆ

ซึ่งหลายต่อหลายครั้ง ไม่สามารถส่งมอบซอฟต์แวร์ให้กับลูกค้าได้เพราะ Bug หรือ Defect ที่ นาน นาน นาน และนานทีถึงจะเกิดขึ้น

เรียงลำดับความสำคัญของความต้องการ

การพัฒนาซอฟต์แวร์แบบ Agile นั้น เกือบทุกรูปแบบหรือกระบวนการ ความต้องการ (Requirement) จะต้องถูกเรียงลำดับความสำคัญ โดยคนหนึ่งคนซึ่งส่วนใหญ่จะเรียกขานว่า Product Owner หรือ Product Champion ซึ่งในแต่ละรอบการทำงานทีมพัฒนาจะต้องพูดคุย ช่วยเหลือ และตกลงหาข้อสรุปในการตรวจรอบแต่ละความต้องการ (Requirement) นั้นๆ กับทาง Product Owner หรือ Product Champion

ทีมพัฒนาจะต้องพิจารณาว่าสามารถรับความต้องการ (Requirement) เข้ามาได้มากน้อยเพียงใดในแต่ละรอบการทำงาน (Iteration) และยืนยันกับไปที่ Product Owner หรือ Product Champion ทีมพัฒนาเริ่มดำเนินการตามกระบวนการพัฒนาซอฟต์แวร์หลังจากที่ Product Owner หรือ Product Champion ตกลง

ตัวอย่าง (Example)

ความต้องการ (Requirement) เพื่อให้หล่อขึ้นผมแนะนำให้ใช้เทคนิคชื่อว่า Specification by Example

Specification-By-Example

โดยสรุปเป็นลำดับง่ายๆ ได้ดังนี้

  • คิด วิเคราะห์ และสรุปตัวอย่างข้อมูลในแต่ละกรณีของความต้องการออกมา โดยจะสรูปออกมาในรูปแบบของตาราง
  • ตัวอย่าง (Example) จะถูกแปลงร่างไปเป็น กรณีการทดสอบ (Test Case)

จัดกลุ่มและเรียงลำดับความสำคัญของกรณีการทดสอบ (Test Case)

กรณีการทดสอบที่ถูกออกแบบต่อมาจากตารางที่ได้มาจากตเทคนิค Specification by Examples สามารถจัดกลุ่มกรณีการทดสอบออกได้เป็น 2 กลุ่มคือ

  • Test to Pass หรือบ้างก็เรียกขานว่า Happy Path ทดสอบและตรวจสอบว่าถูกต้องตรงตามเงื่อนไขความต้องการ
  • Test to Fail หรือบ้างก็เรียกขานว่า Sad Path หรือ Negative ทดสอบและตรวจสอบกรณีแปลก

สิ่งที่ Tester จะต้องสนใจเป็นอันดับแรกคือ Test to Pass หรือ Happy Path ในระดับของเงื่อนไขของความต้องการ หรือว่ากันง่ายๆ ก็ทดสอบ System Testing นั่นเองนะจ๊ะ จัดการทดสอบให้เรียบร้อยและครบถ้วนก่อน

  • ถ้าสามารถแปลง Test Case เหล่านั้นให้เป็น Automate Testing ได้ไปพร้อมๆ กันกับที่นักพัฒนาไม่ว่าจะเป็น Programmer หรือ Developer กำลังพัฒนาอยู่จะหล่อมาก
  • ถ้าไม่สามารถแปลงเป็น Automate Testing ได้ตั้งแต่แรก ก็ให้ดำเนินการทดสอบแบบ Manual Testing ไปก่อนเมื่อเรียบร้อยก็จัดการแปลงให้เป็น Automate Testing ให้ได้มากที่สุดเท่าที่จะเป็นไปได้

เมื่อกรณีการทดสอบแบบ Test to Pass หรือ Happy Path ถูกทดสอบครบและผ่าน เราก็สามารถที่จะส่งไปให้กับทาง Product Owner หรือ Product Champion หรือ ลูกค้า หรือ ผู้ใช้งาน นำไปทดสอบในระดับของ UAT หรือนำไปใช้งานจริงๆ ได้เลยทันที

ส่วนกรณีการทดสอบแบบ Negative นั้นก็ต้องเรียงลำดับความสำคัญเช่นกันและค่อยๆ เพิ่ม Test Case เข้าไปเรื่อยๆ เท่าที่จำเป็น และหาทางที่จะแปลงให้เป็น Automate Testing ให้ได้มากที่สุดเช่นเดียวกับ Test to Pass หรือ Happy Path

แบ่งความต้องการให้เล็กลงจาก Test Case

อันนี้เพิ่มเติมให้นะครับ หลายๆ ครั้งที่ทีมพัฒนาซอฟต์แวร์ด้วยหลักการแบบ Agile จะเจอปัญหาเรื่องของการรับความต้องการ (Requirement) เข้ามาไม่ว่าจะอยู่ในรูปแบบของ Use Case, User Story, Story, Product Backlog Items หรืออะไรก็ตามที่ Product Owner หรือ Product Champion กับทีมพัฒนาตกลงกันนั้น ไม่สามารถส่งมอบได้ครบทุกเงื่อนไขของการทำงานในรอบการทำงานนั้นๆ

เราสามารถที่จะนำ ตัวอย่าง (Example) หรือ Test Cases ที่เกิดจากตัวอย่าง มาแบ่งความต้องการนั้นๆ ออกให้เล็กลงได้ แต่เน้นย้ำว่า ตัวอย่าง (Example) หรือ Test Cases ที่เกิดขึ้นจากตัวอย่างเป็นระดับของ System Testing นะจ๊ะ

สำหรับรายละเอียดวิธีการพร้อมตัวอย่าง ขอยกไว้ไปเขียนต่อหลังจากจบ Series 10 หลักปฏิบัติของ Agile Tester ที่ไม่ใช้ Agile ก็นำไปทำได้ นะจ๊ะ

สรุป

Tester นั้นจะต้องให้ความสำคัญกับเรื่องของการคิดวิเคราะห์และสรุปตัวอย่าง (Example) ของแต่ละเงื่อนไขของความต้องการออกมา และแปลงให้เป็น Test Case ให้ได้ทั้งแบบ Test to Pass และ Test to Fail

เมื่อพูดถึง Test Case สำหรับผมจะใช้สมการนี้เสมอ

Test Case = Business Rule + Test Data

ซึ่งเทคนิค Specification by Example นั้น จะได้มาทั้ง Business Rule และ Test Data

กรณีการทดสอบบกลุ่ม Test to Pass นั้นจะต้องถูกนำมาทดสอบก่อนเสมอ แล้วจึงค่อยๆ เพิ่มกลุ่ม Test to Fail หรือ Negative เข้าไป

และแปลงให้เป็น Automate Testing ให้ได้มากที่สุดเท่าที่จะเป็นไปได้ เพื่อความสะดวก รวดเร็ว และถูกต้องสำหรับการทำ Regression Testing นะจ๊ะ

วันพฤหัสบดีที่ 7 พฤษภาคม พ.ศ. 2558 เวลา 19:28น.
หลักสี่ กรุงเทพมหานคร
One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.