QA & Support

หลังจากทดลองเปลี่ยน Process ต่างๆของทีม Dev ไปตัวละครที่แทบไม่ได้กล่าวถึงเลยคือฝ่าย Support และ QA ที่ไม่ค่อยพูดถึงเพราะยังนึกไม่ออกว่าหน้าที่จริงๆของสองฝ่ายหนี้คืออะไรบ้าง ควรจะรู้อะไรแค่ไหน แต่วันนี้ถกเถียงเรื่อง Process อีกครั้งก็เริ่มคิดจะเปลี่ยนอะไรบ้างอย่างอีกครั้งและเริ่มนึกถึงสองฝ่ายนี้มากขึ้น

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

  1. งานที่เกิดจาก Requirement และ Bug จาก QA งานส่วนนี้แหละที่มีปัญหา เพราะว่าคนที่บอกว่าเสร็จไม่ใช่ Dev แต่เป็น QA เพราะงั้นการจะบอกว่า Milestone จบโดยการยึด Bug/Feature จาก Task กลุ่มนี้จะทำให้ Milestone ที่กำหนดตามเวลา ปิดได้ตามกำหนดแทบจะเป็นไปไม่ได้เลย หาก Dev process ปัจจุบันยังไม่สามารถ Guarantee ได้ว่า Task เหล่านั้นทำงานได้ถูกต้องจริง (เรื่องนี้เขียนได้อีกเรื่อง) เพราะฉะนั้น Milestone สำหรับงานกลุ่มนี้เลยควรปิดเมื่อ Feature/Bug ที่กำหนดไว้ปิดหมดแล้ว
  2. งานส่วนที่สองคืองานที่ถูกกระจายออกมาจาก Task กลุ่มแรก ทำให้งานกลุ่มนี้อาจจมีมากกว่า หรือน้อยกว่าก็ได้ และเป็นงานที่ Dev ต้องทำจริงๆ ซึ่งจะมีรายละเอียดมากกว่า Task กลุ่มแรก และขั้นตอนน้อยกว่าด้วย Task กลุ่มนี้จะเป็นกลุ่มที่บอกว่าปิดตาม Milestone ที่กำหนดด้วยเวลา และถ้า Milestone ปิดแล้วจะไม่มีการเพิ่มอีก ถ้ามี Task มาใหม่ต้องถูกเพิ่มใน Milestone ถัดไปซึ่งคน Lead project ต้องเอามาจาก Task ที่ QA/Support list มาและกระจายให้ Dev แต่ละคนอีกที

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

เรื่องที่สองคือหน้าที่ของ QA/Support ปัญหาของ Dev team ปัจจุบันที่ทำงานอยู่ด้วยเชื่อว่า QA ทำให้ Software มีคุณภาพที่ดีขึ้นแต่ความเชื่อนี้เริ่มรู้สึกว่าไม่จริงเพราะจากประสบการณ์ที่ผ่านมาจะบอกว่าแย่ลงก็น่าจะได้ สาเหตุที่บอกว่าแย่ลงเพราะบั๊กที่เกิดขึ้นมันไม่ได้น้อยลงเลย แถมบั๊กเก่าๆ ที่หายไปมันกลับมาหลอกหลอนอีก เพราะงั้นปัญหามันไม่ได้เกิดจากว่า Dev team ไม่มีการตรวจสอบคุณภาพจาก QA แต่เป็นเพราะ Dev team ไม่มีการตรวจสอบคุณภาพของสิ่งที่เปลี่ยนไปต่างหากว่ามันกระทบกับเรื่องเดิมๆ หรือป่าว ปัญหาเรื่องนี้มันไม่ได้แก้โดยการให้คนภายนอกเข้ามาตรวจสอบแต่ต้องเกิดจาก Dev เองนั่นแหละเขียน Test คลุมส่วนที่ตัวเองทำว่าทำงานถูกต้องตามที่ได้ Requirement มาและเมื่อมี Change ในอนาคต สิ่งที่ตนเองทำไปก็ยังคงทำงานถูกต้องอยู่ ซึ่งปัจจุบัน Test เหล่านี้มันแทบไม่มีเลย (ประชุมวันนี้โกรธมากที่ทุกคนยังคงสน QA Process อยู่แต่ไม่พูดเรื่อง Test พวกนี้เลย) ถ้าไม่ทำให้ Test พวกนี้เกิด เพิ่ม QA ให้ QA Test ถี่ขึ้นก็ไร้ประโยชน์เพราะมี Change/Requirement ใหม่อนาคตก็ไม่สามารถบอกได้อยู่ดีว่า สิ่งที่เคยทำผ่านมายังทำงานถูกต้อง คำถามคือในเมื่อ Dev test พวกนี้ไปแล้ว แล้วหน้าที่ของ QA คืออะไรหละ

หน้าที่ของ QA คือการตรวจสอบความถูกต้องของ Requirement ว่า Dev ลืมทำอะไรไปหรือป่าวเช่น Validation ไม่ครอบคลุม หรือไม่ครบตาม Requirement แต่ไม่ใช่งานที่ต้องมาคอยตรวจว่า Feature ทั้งหมดของระบบนั้นทำงานถูกต้องหรือป่าว ซึ่งถ้าเป็นระบบใหญ่แล้วไม่สามารถทดสอบได้ครอบคลุมเลยโดยคน การทดสอบทั้งสองอย่างนั้งต้องตกลงกับ Dev, Designer, คนให้ Requirement ทุกคนในทีม ตั้งแต่ต้นว่างานแต่ละอย่างทำอะไรได้บ้าง ไม่ได้บ้าง ขั้นตอนการทำงานเป็นอย่างไร ละเอียดในระดับหนึ่งจากนั้น QA ก็สร้างเป็นงานต่างๆ ไว้ว่าจะทดสอบอะไรบ้างที่ระบบจะต้องทำได้ ให้ครอบคลุมมากสุดพร้อมกับคนที่จะแจกจ่ายงานไปให้ Dev เพราะงั้น สิ่งที่จะหลุดมาที่ QA เลยไม่ควรจะมีว่า Task นั้นทำงานได้ไม่ตรงกับที่กำหนดมา

มาถึงหน้าที่ของ Support ฝ่ายนี้เป็นฝ่ายนึงที่งานหนักสุดและเป็นหน้าด่านให้ Dev/QA งานของฝ่ายนี้จะเกิดเมื่อมีเหตุการณ์สองอย่างคือ

  1. User ใช้งานระบบแบบไม่ถูกต้อง ซึ่งอันนี้คือหน้าที่หลักของ Support ที่จะคอยช่วยเหลือให้ User ใช้งานอย่างถูกต้อง หรือถ้าเจอ User งี่เง่าก็ต้องหาวิธีสั่งสอนกันไป
  2. User เจอบั๊กของระบบ อันนี้ Support ต้องมาอัดกับ Dev เต็มๆอาจจะหา Work around เลี่ยงให้ User ใช้ไปก่อนแต่ยังไงก็คงต้องมาบอกให้ฝั่ง Dev แก้ซึ่ง Dev ก็ต้องหาทางแก้ให้ได้โดยกะเวลาที่แน่นอนให้ฝ่าย Support ด้วยเพื่อหาเหตุผลและตอบ User ได้ ข้อนี้ที่เห็นในปัจจุบันคือ Dev ไม่สามารถบอกได้ว่าบั๊กเกิดจากอะไร QA ก็ไม่เจอเพราะเป็น Feature เก่าแก่ที่อาจจะเคยทำงานได้แต่พังไปเพราะ Change ที่พึ่งทำไปไม่นานซึ่งเรื่องพวกนี้ไม่ใช่ความผิดของ Support เลยแต่ Support ต้องคอยเป็นหน้าด่านให้ Dev และ Dev ก็ไม่ค่อยอยากจะแก้งานในกลุ่มนี้เสียด้วยเพราะคนที่รู้ก็แทบจะไม่เหลือแล้ว ทางแก้เรื่องนี้มีอย่างเดียวคือต้องหาทางใส่ Test ทุกระดับให้ได้ ไม่งั้น Support ตาย

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

About llun

Just a programmer

,

  • http://twitter.com/visibletrap TAP

    ส่วนแรกอ่านไม่ค่อยรู้เรื่องเลยครับ แต่ถ้าพี่ตั้งใจเขียนไว้อ่านเองก็ไม่เป็นไร :)

    เรื่อง QA คิดคล้ายพี่เห็นด้วยเรื่องเติม test ใน dev อยากเพิ่มเติมว่าส่วนตัวผมชอบใช้ประโยคว่า QA เอาไว้ “หา bug ท่าพิศดาร”

    เรื่อง Support ตามนั้นครับ แต่อยากเสริม “ต้องหาทางใส่ Test ทุกระดับให้ได้ ไม่งั้น Support ตาย” ว่าเขียน test ไม่ดีก็ตายได้เหมือนกัน คือ จริงๆแล้ว Selenium ที่ผมเอาเข้ามาผมก็พยายามแก้ปัญหานี้ แต่พอ approach ไม่ดี มันกลายเป็นภาระไป

    • http://llun.in.th/ llun

      ส่วนแรกมันเกี่ยวเนื่องกับ http://llun.in.th/2011/08/%E0%B8%A5%E0%B9%89%E0%B8%B2%E0%B8%87%E0%B9%84%E0%B8%9E%E0%B9%88/ อ่ะดัดแปลงไปเรื่อยๆ เป้าหมายคือ Milestone ที่แน่นอน และการกะเวลาความสามารถของ Dev ได้ยังไม่ได้เขียนคลุมทั้ง Process เลยน่าจะอ่านไม่รู้เรื่อง

      ส่วน Selenium แน่นอนว่าต้องทำแต่ว่ามันต้องทำเมื่อ UI มันนิ่งแล้วอ่ะ ไม่งั้นคนทำ Selenium ก็ตาย แต่เป้าหมายของการใส่ Selenium คือเพื่อให้ Automate ได้ทุกส่วนมากกว่า เพราะงั้นอาจจะไม่ใช่ Selenium ก็ได้สุดท้ายแต่เป็นตัวอื่นที่ Automate UI ได้

    • http://twitter.com/visibletrap TAP

      “ที่พยายามแก้ปัญหานี้” คือ ปัญหาจาก regression bug ของ support ข้อ 2 ที่พี่พูดถึงนะครับ ไม่ได้หมายถึง ui automate

      ที่ผมเลือกใช้ selenium เพราะว่าผมยังไม่สามารถทำ unit test กับ code เก่าได้ หวังว่า selenium จะคลุมไว้ เผื่อวันหน้าจะผ่าตัดข้างในจะได้มีตัวเช็ค functional

      แต่ที่บอกว่า approach ผิด คือ test มันมี dependency เยอะ มันเลยทำให้รันยากเขียนยากไป สร้าง bad impression 

    • http://llun.in.th/ llun

      อืมเข้าใจหละ แต่กรณีแก้ปัญหา Support.2 นี่ยังนึกทางทดสอบแบบเร่งด่วนไม่ออกเหมือนกัน แต่ถ้าจะให้ดีมันต้องรู้ทุกส่วนแล้วแก้ถาวรอ่ะ ที่ผ่านมาจะบอกกันไม่ได้ว่าต้องแก้ยังไงใช้เวลาเท่าไหร่มากกว่า

    • http://twitter.com/visibletrap TAP

      คำว่า “รู้ทุกส่วน” ไม่น่าจะมีวันมาถึง