[The Clean Coder] เรื่องของ Test Strategy

จากหนังสือ 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 ครับ