เปลี่ยน Test Report จาก “กระดาษ” มาเป็น “กระดาน”

Ci-Jenkins

สวัสดีเพื่อนพ้องน้องพี่เช้าวันศุกร์ที่ 26 กุมภาพันธ์ พ.ศ.2559 เช้าวันนี้มานำส่งสิ่งที่ได้ไปร่ำเรียนมาจากชั้นเรียน The Whole Team Approach to Agile Testing ของป้า Janet Gregory ณ ประเทศสิงคโปร์ ในเรื่องของ Make Test Report Visible

รายงานผลการทดสอบ (Test Report) เป็นสิ่งที่จะต้องถูกนำส่งออกมาหลังจบกระบวนการทดสอบไม่ว่าจะการทดสอบในระดับใด (Test Level) เช่น Unit Testing เอย Integration Testing เอย System Testing เอย Performance Testing เอย เป็นต้น ซึ่งเอาเข้าจริงๆ มีคนอ่านมันอยู่ไม่กี่คนหรอกรายงานฉบับนี้  ดังนั้นถ้าจะยังต้องคงมีอยู่ มาเปลี่ยนรายการการทดสอบจาก กระดาษ มาเป็น กระดาน กันดีกว่า


การดูแลคุณภาพและการทดสอบซอฟต์แวร์นั้นควรจะอยู่ในความรับผิดชอบร่วมกันของทุกๆ คนที่เกี่ยวข้อง มิใช่เพียงแค่ Software Tester เพียงผู้เดียว หรือเฉพาะทีม Test เท่านั้น ในตำรับตำราของ Software Engineering ไม่ว่าจะเล่มไหนก็เขียนไว้มิต่างกัน

พอมาสู่ยุครุ่งเรืองของคำว่า แอจไจล์ (Agile) นั้นในส่วนของการควบคุมคุณภาพและการทดสอบก็ต้องเปลี่ยนไปด้วยเช่นกัน เพราะการพัฒนาซอฟต์แวร์แบบแอจไจล์ เน้นการทำงานเป็นรอบสั้นๆ (Sprint หากใช้ SCRUM หรือ Iteration หากใช้ XP หรือ Agile Practices/Methodology อื่นๆ หรือ Cadence ) ที่มีระยะเวลาของแต่ละรอบเท่าๆ กัน แต่ไม่ควรจะยาวเกิน 20 วันทำการ ส่วนตัวผมนิยมใช้ 10 วันทำการ เมื่อรอบการทำงานสั้นลงแต่ยังต้องคงไว้ในกระบวนการพัฒนาซอฟต์แวร์ (SDLC) ดังนั้น Software Tester หากยังคงทำงานเหมือนเดิม มิทันกินแน่ๆ และจะตามมาด้วยปัญหาไม่สามารถเสร็จงานในการทดสอบได้ในแต่ละรอบ และเมื่อจบหนึ่งรอบการทำงานก็ต้องสรุป Test Report ออกมาด้วยนะ ลองนึกภาพดูว่า

  1. รอบการทำงาน 10 วันทำการ
  2. จำนวนรอบการทำงานของ Release นั้น เท่ากับ 12 รอบการทำงาน
  3. จบการทดสอบของรอบการทำงานที่ 1 Software Tester ทดสอบไป 50 Test Cases สรุปผลลง Test Report ฉบับที่ 1
  4. จบการทดสอบของรอบการทำงานที่ 2 Software Tester ทดสอบของใหม่ 50 Test Cases และต้องทดสอบของเดิมที่เคยทดสอบผ่านมาแล้วอีก 50 Test Cases และทั้ง 100 Test Cases ต้องผ่าน และสรุปผลลง Test Report ฉบับที่ 2

ถ้าทุกๆ รอบการทำงานมีจำนวน Test Case ที่ต้องทดสอบ เท่ากับ 50 Test Cases เราก็จะสนุกสนานกับการทำ Regression Testing และออก Test Report ทั้งสิ้น 12 ฉบับ

อาจจะมีคนคิดว่าออกทีเดียวฉบับเดียวตอนครบทั้ง 12 รอบการทำงานก็ได้นี่ครับ ก็ได้นะ แต่คำถามคือ “ใครสนใจที่จะนั่งอ่านบ้าง?”

เอาจริงๆ นึกภาพตามนะครับ “หนังสือหนังหายังไม่ค่อยจะอ่าน แล้วรายงานแบบนี้จะอ่านกันหรือไร?”

ดังนั้น เปลี่ยนจากรายงานการทดสอบแบบ “กระดาษ” มาเป็น “กระดาน” กันดีกว่า

Ci-Jenkins

 

  1. สร้างความรู้และความเข้าใจใหม่เลยว่า การควบคุมและการทดสอบซอฟต์แวร์คืออะไร? ส่วนตัวผมถือเป็นหน้าที่ความรับผิดชอบของ Software Tester ที่ต้องเป็นผู้รู้และเข้าใจ และถ่ายทอดเรื่องเหล่านี้ให้กับคนอื่นๆ ในทีมทำงาน
  2. ทุกๆ คนที่เกี่ยวข้องการการเขียน Code รวมทั้ง Software Tester ต้องทำงานร่วมกัน แบพจัดเก็บทั้ง Source Code และ Test Cases (Automate) ไว้บน Source Code Management เช่น Git หรือ SVN เป็นต้น
  3. วิเคราะห์ความต้องการ (Requirements) วิเคราะห์ระบบ และออกแบบการทดสอบ (Test Design) ทั้ง Functional และ Non-Functional ก่อนเสมอที่จะลงมือออกแบบระบบ และพัฒนา เพื่อทำให้เกิด Automate Testing ได้มากที่สุด
  4. Software Tester ไปศึกษา และฝึกฝนการทำ Automate Testing ในระดับของ Acceptance Testing แนะนำให้ไปเสพที่ www.somkiat.cc
  5. Programmer / Developer ไปศึกษาและฝึกฝนว่าการทำ Automate Testing ในระดับของ Unit Testing และ Integration Testing ทำอย่างไร โดยจำง่ายๆ คุณใช้ ภาษาอะไรเขียน Code ก็ใช้ภาษานั้นเขียน Unit Testing และ Integration Testing แนะนำให้ไปเสพที่ www.somkiat.cc
  6. เมื่อเกิดมี Automate Testing ขึ้นแล้วนั้นให้นำแนวปฏิบัติเรื่องของ Continuous Integration (CI) เข้ามาใช้งาน พร้อมมองหาเครื่องมือ (Tools) สำหรับ CI เข้ามาใช้ ก็แนะนำให้ไปเสพที่ www.somkiat.cc
  7. ทุกๆ Automate Testing ที่นำมาใช้จะออกรายการสรุปผลการทดสอบเสมอว่ามีจำนวน Test Cases เท่าไร ทดสอบผ่านและไม่ผ่านเท่าไร และเมื่อนำ CI เข้ามาใช้แล้วนั้นรายงานสรุปผลการทดสอบเหล่านั้นสามารถที่จะนำไปแสดงผลบน CI ได้เป็นหน้า Dashboard (กระดาน) ใหญ่ๆ พร้อมกับบางตัวยังมีเสียงกรี๊ดร้องเวลาที่พบว่ามี Test Cases ที่ไม่ผ่านการทดสอบ ก็แนะนำให้ไปเสพต่อที่ www.somkiat.cc
  8. หาซื้อจอ LED ใหญ่ๆ จะขนาดไหนก็แล้วแต่งบ หรือนำ Projector มาต่อกับเครื่องคอมพิวเตอร์เพื่อเปิดหน้า Dashboard ของ CI ให้ผู้คนได้เห็นว่าผลการทดสอบเป็นเช่นไรบ้างในทุกๆ ครั้งที่มีการเปลี่ยนแปลงเกิดขึ้นใน Source Code ไม่ว่าจะมาจากการเปลี่ยนแปลงความต้องการ (Requirements) และ/หรือ เปลี่ยนการออกแบบการพัฒนา (Design) เป็นต้น
  9. สร้างข้อตกลงร่วมกันทุกๆ ครั้งที่มีการเปลี่ยนแปลงใดๆ ใน Source Code เกิดขึ้นจะต้องทดสอบการในทุกๆ ระดับที่มี Automate Testing ให้ครบแล้วต้องผ่านทั้งหมด หากมี Test Case ที่ทดสอบไม่ผ่านเกิดขึ้นจะต้องช่วยการดูและแก้ไข Test Case ที่ทดสอบไม่ผ่านให้ผ่านก่อนที่จะพัฒนาต่อไป

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

วันศุกร์ที่ 26 กุมภาพันธ์ พ.ศ. 2559 เวลา 15:14น.
สุขุมวิท กรุงเทพมหานคร

Leave a Reply

Your email address will not be published. Required fields are marked *