10 หลักปฏิบัติของ Agile Tester ที่ไม่ใช้ Agile ก็นำไปทำได้ ตอน ให้ข้อมูลผลลัพธ์ต่างๆ อย่างสม่ำเสมอ

provide-continuous-feedback

ภาคต่อของ 10 หลักปฏิบัติของ Agile Tester ที่ไม่ใช้ Agile ก็นำไปทำได้ วันนี้ขอพูดถึงหลักข้อที่ 1 คือ Provice Continuous Feedback ซึ่งขอแปลเป็นภาษาไทยว่า ให้ข้อมูลอย่างสม่ำเสมอ ละกันนะครับโดนจะขอแจกแจงออกมาเป็นลำดับว่า Tester จะต้องเปลี่ยนตัวเองจากทำงานเชิงรับ มาทำงานเชิงรุก และเปลี่ยนจากทำหน้าที่คุ้ยเขี่ยหาแมลงประเภทต่างๆ ที่อยู่ในซอฟต์แวร์มาคุมกำเนิดแมลงที่จะเกิด โดยขอเล่าลำดับตามภาพนะจ๊ะ

เป็นผู้นำทางจิตวิญญาณในการกลั่นกรองเติมเต็มความต้องการของลูกค้าให้ครบถ้วน

การพัฒนาซอฟต์แวร์แบบ Agile เน้นเรื่องของการทำงานร่วมกันของทีมเป็นรอบสั้นๆ โดยส่วนใหญ่จะใช้รอบการทำงานประมาณ 5 วันหรือ 10 วัน และจะต้องส่งมอบฟังก์ชั่นหรือฟีเจอร์ซึ่งทำงานได้จริงให้กับลูกค้า ดังนั้นเรื่องที่มีความสำคัญมากคือความครบถ้วนสมบูรณ์ของความต้องการ (Requirement) แต่ละข้อที่ลูกค้าจะส่งมอบมาให้ทีมพัฒนานำไปแปลงจากตัวอักษร+รูปภาพ+Flow การทำงาน เป็นต้น ไปเป็นซอฟต์แวร์ หนึ่งเรื่องที่ต้องให้ความสำคัญอย่างมากๆ เลยคือ จากสถิติ Bug หรือ Defect ที่เกิดขึ้นหากทำการวิเคราะห์แหล่งกำเนิด จากประสบการณ์ของผมเองและงานวิจัยต่างๆ เกิน 50% มาจากความต้องการ (Requirement) ซึ่งเพื่อป้องการและคุมกำเนิดการเกิด Bug หรือ Defect นั้น Tester จะต้องลุกขึ้นมาทำงานเชิงรุกมากขึ้นโดยเข้าไปช่วยลูกค้าดูว่าความต้องการ (Requirement) ที่จะนำส่งมาให้กับทีมนั้นครบถ้วนตามที่ได้ตกลงกันไว้กับทีมหรือไม่ และมีเรื่องใด ประเด็นใด และเงื่อนไขใด ที่ดูน่าจะเป็นจุดกำเนิดของ Bug หรือ Defect ได้ก็ต้องให้ความคิดความเห็นหรือแสดงให้เห็นเสียตั้งแต่แรกเพื่อป้องกัน

เทคนิคหนึ่งที่ Tester สามารถนำเข้ามาช่วยได้ในการทำให้ความต้องการชัดเจนขึ้นคือ การสร้างตัวอย่างหรือกลุ่มตัวอย่างของข้อมูลหรือกรณีที่จะเกิดขึ้น โดยขอทิ้งชื่อเทคนิคนนี้ว่า Specification by Examples และไว้จะกลับมาอธิบายเรื่องนี้อย่างละเอียดอีกครั้งนะจ๊ะ

ในความต้องการหนึ่งๆ จะต้องมีตัวอย่างข้อมูลของแต่ละกรณีขึ้นมาโดน Tester และลุกค้าทำงานร่วมกันเพื่อให้ได้ตัวอย่างเหล่านี้ออกมา โดยหากลุกค้าไม่เข้าใจเรื่องนี้ Tester จะต้องเป็นผู้อธิบายและทำให้ดูเป็นตัวอย่างว่าวิธีการคิดมองและเลือกตัวอย่างข้อมูลทำได้อย่างไรบ้าง

งง สิ ว่า คำว่าตัวอย่างข้อมูลนั้นคืออะไร จริงๆ แล้วสำหรับผมมันคือ Test Data ของแต่ละ Test Case นั้นแหละครับ ไม่ต้องมองไปไหนไกลๆ แต่ Tester เพียงแค่นำมาแสดงในรูปแบบของตารางตามภาพที่เขียนหมายเลข 2 กำกับไว้

แปลงตัวอย่างข้อมูลของแต่ละเงื่อนไขให้เป็น Automate Testing ให้ได้มากที่สุดเท่าที่จะเป็นไปได้

เมื่อเราได้ตารางที่บรรจุไปด้วยตัวอย่างของข้อมูลซึ่งสอดคล้องกับเงื่อนไขต่างๆ ของความต้องการ (Requirement) แล้วนั้น ปัญหาที่จะเกิดขึ้นต่อไปคือความช้าของการให้ผลการทดสอบของ Tester เอง เพราะยังคงต้องใช้แรงงานของตัวเองในการทดสอบแบบ Manual Testing ถ้าซอฟต์แวร์มันเล็กๆ มีฟังก์ชั่นหรือฟีเจอร์การทำงานแค่หนึ่งหรือสองก็ไม่เท่าไร แต่จริงๆ แล้วนั้นซอฟต์แวร์หนึ่งตัวมันมีอะไรเยอะแยะมากมายหลายสิ่งอย่างและยิ่ง Tester ยังคงใช้กระบวนท่า Manual Testing อยู่ พูดง่ายๆ คือ ทำงานแบบถึกๆ ความช้าตรงนี้จะมีผลอย่างมากกับเรื่องของผลของการทดสอบที่จะส่งมอบให้กับทุกๆ คนที่เกี่ยวข้อง ยกตัวอย่างเช่น ความต้องการเปลี่ยน เชิงเทคนิคเปลี่ยนตัวแปรในตัวโค้ดของซอฟต์แวร์เพียงแค่หนึ่งตัว ส่งต่อมาให้ Tester ช่วยทดสอบดูว่ากระทบกับส่วนไหนของการทำงานของซอฟต์แวร์ทั้งหมด ซึ่ง Tester น่าจะต้องใช้เวลาไม่ต่ำกว่าสามชั่วโมงในการทดสอบเพื่อบอกกลับไปว่ามีผลกระทบหรือไม่กระทบ ซึ่ง ซึ่ง ซึ่ง ไม่ทันกินหรอก แถมยังจะเกิดความผิดพลาดจากความเป็นมนุษย์ของเราเองได้ เพราะมันทำเรื่องเดิมๆ ซ้ำๆ มันจะเบื่อ ดังนั้นอะไรที่ต้องทดสอบซ้ำๆ เดิมๆ บ่อยๆ เราโยกย้ายจาก Manual Testing ไปเป็น Automate Testing ให้ได้มากที่สุดในทุกๆ ระดับของการทดสอบ (Test Level) เพื่อเรื่องสำคัญที่สุดคือ ผลการทดสอบที่รู้ผลได้เร็วที่สุด

ดังนั้น Tester จะต้อง คิด วิเคราะห์ พิจาราณา และลงมือในการนำ Automate Testing เข้ามาช่วยในการทำ Re-Test และ Regression Testing ให้ได้มากที่สุดเพื่อสามารถ ทดสอบซ้ำๆ ได้บ่อยๆ และรู้ผลได้รวมเร็วว่าผ่านหรือไม่ผ่าน

ให้ข้อมูลสรุปภาพรวมและรายละเอียดสำคัญๆ กับทุกๆ คนที่เกี่ยวข้องตลอดเวลา

ข้อมูลสถานะของการทดสอบเป็นเรื่องที่สำคัญมาก โดยปกติที่ทำๆ กันมาโดยอาจจะรู้ที่มาหรือไม่รู้ที่มาบ้าง เน้นย้ำว่าจากประสบกาณ์ของตัวผมเอง รายงานความคืบหน้าต่างๆ ของ Tester แบบเดิมๆ จะมีอยู่ 2 ช่องทางคือ ออกจากปากเมื่อถาม และออกมาเป็นรูปแบบเอกสารสรุปที่เรียกว่า รายงานผลการทดสอบ (Test Report) ซึ่งถ้าไม่ถามก็ไม่ค่อยบอก และถ้าไม่เปิดอ่านรายงานผลการทดสอบ (Test Report) ก็จะไม่รู้ สุดท้ายไม่ว่าจะเป็น ลูกค้า ผู้จัดการในส่วนต่างๆ หรือคนที่เกี่ยวข้องก็เลือกที่จะเอยปากถาม Tester ว่าตกลงผลการทดสอบเป็นอย่างไร มากกว่าที่จะมานั่งอ่านสรุปจากรายงานการทดสอบ

การพูดเรื่องเดิมซ้ำๆ มันน่าเบื่อมากๆ สำหรับผมในหมวกของ Tester ดังนั้นเราก็ควรนำเทคนิคของ Visualization (ยังหาคำแปลไทยแบบสวยๆ ไม่ได้) มาใช้ ซึ่งหาก Tester นำพา Automate Testing มาใหทีมได้รู้จัก และใช้งานไปพร้อมๆ กันนั้น สิ่งที่ได้มาคือเรื่องของรายงานที่ได้จากการทดสอบซ้ำๆ ในแต่ละรอบ

ในเมื่อเครื่องไม้เครื่องมือที่เรานำมาใช้ในการทำ Automate Testing มีให้แล้ว ก็นำมันขึ้นจอทีวี LED หรือ Projector ใหญ่ๆ ให้ทุกคนที่เกี่ยวข้องทั้งทางตรงและทางอ้อมของการพัฒนาซอฟต์แวร์นั้นๆ ได้เห็นสถานะของการทดสอบไปเลยซึ่ง Automate Testing ส่วนใหญ่จะมีส่วนของรายงานและสรุปเป็น Dashboard ให้อยู่แล้ว Tester ก็เพีนงแค่หาวิธีให้มันนำขึ้นจอใหญ่ๆ ได้เท่านั้น

สรุป

การพัฒนาซอฟต์แวร์แบบ Agile เรื่องหนึ่งที่สำคัญคือ ผลการตอบสนองอย่างต่อเนื่อง (Feedback) เพื่อรู้ถ้าผ่านก็ไปต่อ ถ้าผิดก็หยุดแก้ไขให้ถูกต้อง มองกลับมาที่การพัฒนาซอฟต์แวร์แบบดั้งเดิม เน้นว่าดั้งเดิมไม่ใช่ Waterfall (ไว้จะกลับมาอธิบายอีกทีว่าจริงๆ แล้ว Waterfall จากคนที่คิดเนี่ยเขาบอกไว้อย่างไร) ซึ่งส่วนใหญ่ Tester จะทำงานเชิงรับมากกว่า ถามมาก็ตอบไป หรือรอให้เสร็จทั้งหมดแล้วตอบไป หรือแม้จะมี Tester บางกลุ่มที่ให้ผลกลับไปทันทีที่ผิดพลาดแต่ก็ยังต้องใช้พลังและแรงงานเยอะอยู่

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

การให้ข้อมูลรายงานต่างๆ อย่างต่อเนื่องได้โดยผ่านทางรูปแบบของ Visualization นั้นเป็นหนึ่งในหมัดเด็ดที่จะทำให้ Tester หล่อขึ้น 200%

ปัญหาจะอยู่ตรงที่เหล่า Tester ทั้งหลาย จะก้าวออกจาก Comfort Zone ในวงเล็บ Killing Zone ออกมาสู่โลกของการเรียนรู้เพิ่มเติมในสายอาชีพของตัวเองหรือไม่ ลองถามตัวเองดู

ตอนต่อไปผมจะพาให้เห็นเรื่องของ เน้นการส่งมอบของที่มันสำคัญแลัมีคุณค่าจริงๆ กับลูกค้าเป็นหลัก (Deliver Value to Customer) นะจ๊ะ ราตรีสวัสดิ์

วันอังคารที่ 5 พฤษภาคม พ.ศ. 2558 เวลา 23:39น.
หลักสี่ กรุงเทพมหานคร

One clap, two clap, three clap, forty?

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