จากหนังสือ The Clean Coder นั้น
มีเรื่องที่น่าสนใจสำหรับ Professional developer มากมาย
หนึ่งในนั้นคือ “Professional developer test their code”
การทดสอบ code ที่เขียนเป็นสิ่งที่ดี
แต่มันไม่ได้ง่ายแบบที่พูดนะสิ
ดังนั้นต้องเขียนแบบไหน เท่าไร ถึงจะดี
ก่อนอื่นต้องเริ่มด้วย Test Strategy ที่ดี
มาเริ่มเรียนรู้กัน
หัวข้อแรกคือ QA (Quality Assurance)
ในหนังสือบอกไว้ว่า
QA should find nothing
QA is part of the team
QA as specifier
QA as characterizer
QA should find nothing
หมายความว่า ถ้ายังแยกทีม Dev และ QA/Tester ออกจากกัน
ผลที่ตามมาคือ ความน่ากลัวและสิ้นเปลืองอย่างมาก
เหมือนเกมส์แมวจับหนู ซึ่งเป็นขั้นตอนการค้นหา
แต่สิ่งที่ควรเกิดขึ้นคือ QA/Tester ควรถามและบอกว่า
มีอะไรบ้างที่จะเกิดขึ้น จะทดสอบอย่างไร ขั้นตอนเป็นอย่างไร
ก่อนที่จะเริ่มต้นพัฒนา นี่คือสิ่งที่ควรต้องเกิดขึ้น
เพื่อป้องกันปัญหานั่นเอง ทำให้เกิด QA should find nothing
QA is part of the team
หมายความว่าทีม Dev และ QA/Tester ต้องทำงานร่วมกัน ไปด้วยกัน ผิดด้วยกัน
เพื่อช่วยกันทำให้มั่นใจว่า ระบบมีคุณภาพ
ซึ่งหน้าที่ของ QA ในทีมนั้นควรทำตัวเป็น specifier และ characterizer ?
QA as specifier
การที่ต้องทำงานร่วมกับฝ่าย business
เพื่อสร้าง automated acceptance test
มันก็คือ specification และ requirement ที่แท้จริงของระบบนั่นเอง
เป็นการแปลงข้อมูลจาก requirement จากฝั่ง business มาเป็นข้อมูลฝั่งพัฒนา
เพื่อทำให้เข้าใจความต้องการและการทำงานของระบบแบบชัดเจน
ไม่ต้องเสียเวลามานั่งตีความ
ซึ่งในการทำงานจริง ๆ นั้น
ฝั่ง business จะเขียน test caseเฉพาะ happy path
ส่วนฝั่ง QA จะเพิ่มเติมส่วนที่ขาดหายไปทั้ง unhappy path, edge case เป็นต้น
QA as characterizer
จะใช้แนวปฏิบัติจาก Exploratory Testing
สำหรับดูพฤติกรรมการทำงานจริง ๆ ของระบบว่าทำงานอย่างไร
จากนั้นทำการสรุปผลไปยังทีมพัฒนาและทีม business
QA นั้นไม่ได้มีหน้าที่ในการแปลหรืออธิบาย requirement
แต่ต้องทำการระบุให้ได้ว่า ระบบจริง ๆ มันทำงานและมีพฤติกรรมอย่างไร
เรื่องที่ 2 คือ The Test Automation Pyramid
เป็นเรื่องที่คนที่มีความเกี่ยวข้องในการพัฒนา software น่าจะเข้าใจเป็นอย่างดี
แม้จะนำไปใช้หรือไม่ใช้ก็ตาม
โดยในหนังสือจะเน้นมาก ๆ คือ
- Professional developer ต้องให้ความสำคัญกับ TDD สำหรับการสร้าง unit test
- Professional development team ต้องใช้ acceptance test สำหรับระบบการทำงานของระบบ
- Professional development team ต้องใช้ Continuous Integration สำหรับการทำ regression
แต่ Unit test และ Acceptance test มันเป็นเพียงการทดสอบส่วนหนึ่งเท่านั้นเอง
เป้าหมายหลักของเราคือ QA should find nothing
ดังนั้นจึงต้องมีการทดสอบอื่น ๆ อีกมากมาย
ซึ่งทำการสรุปไว้ใน The Test Automation Pyramid นั่นเอง
แสดงดังรูป
การทดสอบทั้งหมดนี้
เพื่อช่วยทำให้แน่ใจว่า ระบบงานสามารถตอบรับการทำงานจากผู้ใช้งานได้
และอย่างถูกต้องตามที่คาดหวัง
รวมทั้งทำให้เข้าใจการทำงานและพฤติกรรมต่าง ๆ ของระบบ
สุดท้ายการทดสอบต่าง ๆ
ควรต้องทำงานอยู่อย่างเสมอ
ควรทำงานได้อย่างรวดเร็ว เพื่อให้ได้รับ feedback ที่รวดเร็ว
เพื่อทำให้แน่ใจว่าระบบงานพร้อมอยู่ตลอดเวลา
วันนี้ QA should find nothing แล้วหรือยัง ?
ขอให้สนุกกับการ coding ครับ
