ระหว่างนั่งรอเครื่องบินเข้ากรุงเทพ
อ่านบทความเรื่อง The Current and Future State of Testing: a Conversation with Lisa Crispin
พูดคุยเรื่อง สถานะปัจจุบันของการทดสอบ software ว่าเป็นอย่างไร ?
ยิ่งปัจจุบันมีการพัฒนาระบบงานเป็นรอบสั้น ๆ ด้วยแล้ว
การทดสอบจะเป็นอย่างไร ?
ยังคงทำงานในรูปแบบเดิม คือรอให้พัฒนาเสร็จทั้งหมดก่อน
แล้วจึงทำการทดสอบเพื่อหาข้อผิดพลาดอยู่ไหม ?
การทำสอบควรเป็น manual หรือ automation ?
มาดูกันเลย

การทดสอบระบบงานในโลกที่การพัฒนาระบบงานเป็นแบบรอบสั้น ๆ ( Iteration and Incremental )

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

  • Organization
  • People
  • Process
  • Tool
  • Communication และ Collaboration

ปัญหาอย่างหนึ่งของการนำการทำงานแบบเป็นรอบสั้น ๆ มาใช้งานคืออะไร ?

ปัญหาใหญ่คือ คนที่นำไปใช้งานไม่เข้าใจดีพอ !!
เพราะว่าส่วนใหญ่จะเริ่มต้นด้วย
เราจะเปลี่ยนการทำงานเป็นรอบสั้น ๆ รอบบละประมาณ 2 สัปดาห์
ในทุก ๆ วันเข้าจะทำการ standup meeting
แล้วเราจะไปได้เร็วขึ้นเอง !!!

แต่สิ่งที่ต้องทำและเข้าใจจริง ๆ คือ
เราต้องทำการเรียนรู้ทักษะใหม่ ๆ เพียบ
ทุกคนในทีมต้องมีความรับผิดชอบในเรื่องของคุณภาพและการทดสอบ
เพื่อสร้างระบบงานที่มีคุณภาพ
ต้องสร้าง infrastructure สำหรับการทดสอบขึ้นมา
การทดสอบนั้นมีทั้งแบบ manual และ automation
สิ่งที่ทำมานั้น เพื่อช่วยเพิ่มความมั่นใจต่อระบบงานที่จะส่งมอบ
สิ่งที่ส่งมอบนั้นจะเป็นชิ้นเล็ก ๆ ที่ใช้งานได้ และส่งมอบอย่างต่อเนื่อง

แต่ถ้าฝ่าย management ไม่เข้าใจและไม่สนับสนุนเรื่องเหล่านี้
สนใจแต่ time, cost และต้องเสร็จเท่านั้น
ก็จะทำให้ทีมไม่สนใจในเรื่องของคุณภาพ !!
สนใจแต่สร้าง feature ให้เสร็จ ๆ ไป
สุดท้ายผลที่ออกมาคือ 
ทำไมยังมี bug เยอะอีกนะ
ทำไมยังทำไม่ทันเหมือนเดิม
แสดงว่า การทำงานแบบรอบสั้น ๆ ไม่ work สิ
เลิกทำดีกว่า กลับไปทำเหมือนเดิมซะ !!

บ่อยครั้งพบว่าฝ่าย management จะบอกว่า
เราต้องการระบบที่มีคุณภาพ แต่ไม่เข้าใจจริง ๆ ว่า
คำว่าคุณภาพนั้นคืออะไร เป็นอย่างไร
ที่สำคัญต้องลงทุนอะไร เท่าไร ถึงจะได้สิ่งที่มีคุณภาพ
สุดท้ายก็จบด้วย
การโยนทิ้งทุกอย่าง เพื่อให้ได้ระบบงานที่ต้องการ
หลังจากนั้นคือ ความยากลำบากที่ต้องอยู่กับระบบไปยาว ๆ คือการดูแลรักษา !!

ดังนั้น การสนใจและใส่ใจในคุณภาพนั้น 
มันคือการวางแผลและลงทุนในระยะยาว
อย่ามองอะไรเพียงสั้น ๆ มิเช่นนั้นชีวิตเราก็จะสั้นเช่นกัน

ฝั่งนักพัฒนาก็เช่นกัน
ควรต้องมีความรู้ความสามารถในด้านการทดสอบด้วยเช่นกัน
น่าจะกลายเป็นความสามารถพื้นฐานไปแล้วด้วย

มีอีกกลุ่มคำถามที่น่าสนใจคือ

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

บ่อยครั้งพบว่า Automated test นั้นมีทั้ง test case ที่มีและไม่มีคุณค่า ?

แบบนี้เราจะจัดการมันอย่างไรดี ?
เพราะว่า การทดสอบนั้นเป็นหนึ่งขึ้นตอนในระบบ CI/CD นะ
ถ้า test case อะไรที่ไม่มีคุณค่า ก็ไม่น่าจะอยู่นะ
เพราะว่าเสียทั้งเวลาและค่าใช้จ่ายในการสร้างและดูแลมัน !!

การที่จะสร้างและดูแล Automated test นั้น
ทางที่ดีกว่าคือ ให้ทางนักพัฒนาทำงานร่วมกับ Tester
เพื่อสร้างชุดการทดสอบเหล่านั้นขึ้นมา
ทั้งแบบ manual และ automation เลย
โดยที่นักพัฒนาจะสร้างขึ้นมา
และ Tester จะช่วยออกแบบ test case และ test data ว่าเป็นอย่างไร
ซึ่งการทำงานร่วมกันแบบนี้ 
จะทำให้เราได้ชุดการทดสอบที่ดีและทำให้มั่นใจกว่ามาก
เหมือนการเดินไปข้างหน้าทีละก้าวอย่างมั่นคง

ปัญหาที่ตามมาคือ จำนวน test case มาก ๆ การทดสอบยิ่งไม่น่าเชื่อถือ พังบ่อย และ ช้า !!

เราจะแก้ไขและรับมืออย่างไรดี ?

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

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

การจะทำให้ test case มันมีความน่าเชื่อถือ
จำเป็นต้องพูดคุย และ ทำงานร่วมกับผู้เชี่ยวชาญด้านอื่น ๆ ด้วย
เช่น infrastructure และ database administrator เป็นต้น
ทำให้เรื่องของ communication และ collaboration
เป็นความสามารถพื้นฐานที่ทุก ๆ คนต้องมี

มีคำถามเรื่องอัตราส่วนระหว่างจำนวนของนักพัฒนากับ Tester ว่าเป็นอย่างไร ?

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

ยกตัวอย่างที่เจอมาคือ
ทีมนั้นจะ focus ไปที่คุณภาพเสมอ
การเขียน test case แบบอัตโนมัติเป็นเรื่องปกติของทีมพัฒนา
ดังนั้นอัตราส่วนของ Tester ต่อ Developer เป็น 2-3 คนต่อ 30 คน
หรือบางครั้งอาจจะไม่ต้องการ Tester เลยก็ได้

มีคำถามเกี่ยวกับ AI และ Machine Learning มาช่วยในการทดสอบระบบงาน ?

เป็นสิ่งที่ดีเลย ช่วยลดเวลาในด้านต่าง ๆ ลงไปเยอะ
ยกตัวอย่างเช่น Mabl platform
แต่สิ่งที่เราต้องเข้าใจก่อนคือ
พวก Machine Learning ในแบบที่เราสอน
ต้องใช้ข้อมูลเข้าไปสอนเพื่อเรียนรู้
ดังนั้นเรื่องของข้อมูลจึงสำคัญและระมัดระวัง
ถ้าข้อมูลผิด ผลที่ออกมาก็จะผิดได้ง่าย ๆ เช่นกัน
ดังนั้นต้องการคนที่มีความรู้ความเข้าใจอย่างมากเข้ามาช่วยกัน
แต่เป็นแนวทางที่น่าสนใจมาก ๆ
ต้องเรียนรู้และศึกษากันต่อไป

คำถามสุดท้าย มีคำแนะนำสำหรับ Tester มือใหม่อะไรบ้าง ?

สิ่งที่สำคัญมาก ๆ คือ ต้องรู้และเข้าใจว่า สิ่งที่คุณกำลังค้นหาคืออะไร ?
Bug ? มีปัญหาเรื่องการพูดคุย ? 
ทาง business ไม่สามารถอธิบายให้ทีมเข้าใจใช่หรือไม่ ?
ทางทีมพัฒนาเข้าใจผิดจากที่ฝั่ง business ต้องการหรือไม่ ?

พบว่า 20% ของปัญหามาจากการ coding
และ 80% ของปัญหามาจากการพูดคุยติดต่อสื่อสาร

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

จะสังเกตุว่า เรื่อง soft skill สำคัญมาก ๆ
และก็อย่าลืมและฝึกฝน technical/testing skill ด้วยเสมอ

สรุปหนังสือและ link ต่าง ๆ ที่น่าสนใจ