Agile ทำให้งาน QA น้อยลง?

อันนี้เป็นคำถามที่น่าคิดและเหมือนจะเป็น paradox อันหนึ่ง คือ ถ้า Agile ไม่ทำให้งาน QA น้อยลง QA ย่อมจะเป็นคนกลุ่มแรกที่จะต่อต้านการนำ Agile มาใช้อย่างแน่นอนที่สุด (ก็ทำให้ชีวิต ชั้นลำบากนี่นา) แต่ถ้ามันทำให้ชีวิต QA ดีขึ้น ก็คงจะเป็นเรื่องที่ดี แต่ถ้าคิดๆ ต่อไป อ้าว ก็ Agile ให้ release บ่อยขึ้นและทุกๆ sprint ต้องได้ product ที่พร้อมสำหรับการ deploy เสมอ อย่างนี้จะทำให้งาน QA น้อยลงได้ยังไง คิดดูแล้วมีแต่จะเพิ่มขึ้นนี่นา

คำถามนี้ที่จริง จะว่าง่ายก็ง่าย จะว่ายากก็ยาก เอาเป็นว่าตอบสั้นๆ แล้วกันว่า ถ้าเอา Agile ไปใส่ในทีม QA ที่เคยทำงานแบบ water fall มาก่อนนั้นจะทำให้ ชีวิต ถึงขั้นสิ้นหวัง(miserable) ทันที เพราะมันจะทำให้แทนที่จะทำ regression ทึ release ที่ประมาณ 4-6 เดือนครั้ง เป็นต้องทำมัน ทุก 2-4 สัปดาห์ ซึ่งมันจะเป็นเรื่องที่ insane มาก ถ้าผลออกมาในรูปนี้แล้วล่ะก็ จะเกิดงานค้าง ที่คอยให้ QA ทำเป็นปริมาณมหาศาล และ QA ต้องเร่งทำงานเป็นบ้าเป็นหลัง สุดท้าย Quality ก็จะตก พบ bug ใน production มาก (base on true story)และสุดท้าย ก็จะต้องเลิกใช้ Agile ในที่สุด

แต่หยุดก่อน นี่ไม่ใช่เรื่องที่จะเกิดขึ้นจริง ถ้าคุณใช้ Agile ถูกวิธี Agile ไม่ใช่ยาสารพัดนึกที่จะกินก็ได้จะทาก็ได้ การนำ Agile มาใช้หมายถึงการ เปลี่ยนความคิด และชีวิตแบบถึงขีดสุด (extreme) ลองคิดดูสิ Project manager ต้อง สละอำนาจควบคุมให้กับทีม โปรแกรมเมอร์ต้องทำงานกันสองคน(pair programming) ต้องเขียน test ก่อน code (TDD) ต้องร่วมทำแผน (planning poker) เพราะฉะนั้น ชีวิต QA ก็ต้องเปลี่ยนไปเหมือนกัน สิ่งที่ QA จะต้องมีให้ได้ในโลก Agile คือ

1. Automated testing เนื่องเพราะ Agile นั้น release บ่อย ทำให้ถ้าเรามานั่งทำ regression test เองเราจะตายอย่างแน่นอน
2. Risk based testing เพราะซอฟแวร์สมัยใหม่นั้นมีความซับซ้อนสูง การ test แบบครบทุกกรณีเริ่มที่จะเป็นไปไม่ได้และมีค่าใช้จ่ายมาก จึงต้องมีการนำ ค่าความเสี่ยงมาใช้ประกอบในการวางแผน test อย่างพอเพียงในเวลาที่ำจำกัด แต่ได้คุณภาพตามต้องการ
3. Become trusted advisers QA จะต้องเปลี่ยนจาก tester (คนทดสอบ) ไปเป็น ที่ปรึกษาด้านคุณภาพแก่ project sponsors เพราะฉะนั้นผลของ QA จะไม่ใช่ ผ่าน/ไม่ผ่านอีกต่อไป แต่จะเปลี่ยนไปเป็นค่าความมั่นใจในการ release product นั่นเอง (ตัวอย่าง ค่าคุณภาพตอนนี้อยู่ที่ 80% เป็นต้น)
4. Early involvement สมัยก่อน QA พอจบ construction phase ก็ค่อยเอา Requirements มากางแล้ว test ตามนั้น จะต้องเปลี่ยนไป เป็น เข้าไปรู้ เห็น แนะนำ วางแผนการ test ตั้งแต่ ต้น เพราะ requirement มันไม่มีแล้วกลายเป็น story ซึ่งถ้าเขียนไม่ดี มันก็ test ไม่ได้ คนที่จะบอกได้จริงๆ ก็มีแต่ QA คนเดียว ถ้าปล่อยให้ Dev ทำไปแล้วค่อยมา test ทีหลังก็จะพบว่า story มันไม่ testable เอาซะเลย

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

Links:
http://www.agile66.com/blogs/forum/?mingleforumaction=viewtopic&t=4.0

Advertisements

ใส่ความเห็น

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / เปลี่ยนแปลง )

Twitter picture

You are commenting using your Twitter account. Log Out / เปลี่ยนแปลง )

Facebook photo

You are commenting using your Facebook account. Log Out / เปลี่ยนแปลง )

Google+ photo

You are commenting using your Google+ account. Log Out / เปลี่ยนแปลง )

Connecting to %s