Size นั้นสำคัญไฉน .. QA ควรทำอะไรเมื่ออยู่ใน Size ทีมเล็ก
ก่อนจะเริ่มอ่านบทความต่อไปนี้ ขอออกตัวก่อนเลยว่าสิ่งที่ท่านผู้อ่านจะได้อ่านเป็นเพียงมุมมองการคิด วิเคราะห์ แยะแยะ ส่วนตัวของข้าพเจ้า หาได้อิงจากตำราใด ๆ ไม่ หากมีเหตุผลอันใดที่คิดว่าไม่สมเหตุสมควร จะเป็นความกรุณาถ้าสามารถ Inbox มาเพื่อแนะนำ หรือดิสสะคัสกันได้ จะขอบพระคุณยิ่งครับ เมื่อเข้าใจตรงกันแล้ว ลุยกันเลย !!
เรื่องของเรื่องคือได้มีโอกาสสัมภาษณ์งาน บวกกับพูดคุยกับเพื่อนที่ทำงาน QA ในบริษัทขนาดต่าง ๆ พบว่าหน้าที่ หลาย ๆ อย่างที่บริษัทต้องการและ QA ควรทำแตกต่างกันค่อนข้างมาก ตั้งแต่วิธีคิด เอกสารที่จัดทำ ขั้นตอนดำเนินการทดสอบ การ Log issue หรือการประสานงาน
ขอพูดถึงการสัมภาษณ์ บริษัทที่ได้มีโอกาสสัมภาษณ์มาหลาย ๆ บริษัทเป็นบริษัทขนาดเล็กที่ไม่มี QA เลย ก็คือไปประเดิมเป็น QA คนแรกในบริษัท หรือเป็นทีมขนาดเล็กที่มี QA อยู่แค่คนเดียว โดยคิดอัตราส่วนออกมาจะคิดเป็น QA หนึ่งคนต่อ Dev หกคนเลยทีเดียว
คำถามที่ชวนสะกิดใจให้เอ๊ะ ที่ทุกทีมขนาดเล็กมักถามคือเรื่องของการ Log issue ว่าเคยมีประสบการณ์การ Log issue เมื่อเจอ Bug อย่างไรบ้าง ได้จัดทำเป็นเอกสาร หรือเดินไปบอก Dev เลย ด้วยความที่เราเคยผ่านงานแบบเดินไปบอก Dev เลย ไม่ได้จัดทำเอกสารเป็นทางการเพื่อเก็บผล คำถามที่จะตามมาติด ๆ เลยคือ แล้วถ้ามี Bug หลายตัวจะทำยังไง จะไม่หลุดเหรอ ?
เราก็ตอบไปว่าถ้ามี Bug หลายตัวจะจดเก็บไว้เป็นส่วนตัว ไม่ได้จัดทำเป็นเอกสารทางการที่ส่งต่อให้ Dev ดูแต่อย่างใด
แล้วมันดีจริงไหมนะ !?
เป็นคำถามที่นึกตลอดเมื่อผ่านการสัมภาษณ์เสร็จ พยายามรีเสิร์ชก็ไม่เห็นมีใครเขียนไว้ ( หรือหาไม่เจอเองก็ไม่รู้ 555 ) จะมีก็เพียงแต่ความหมาย Template หรือวิธี Log issue ให้ดี .. เมื่อเจอเหตุการณ์แบบนี้เรามักจะเริ่มต้นคำถามว่า “ทำไม” แล้วไล่หาเหตุผลไปเรื่อย ๆ มาเริ่มกันด้วยคำถามแรก ..
ทำไมเราต้องทำ Bug report ?
ก่อนจะไปถึงประเด็นทำไมเราต้องทำ Bug report มาเริ่มจากที่ว่า Bug report คืออะไร ?
คำตอบคือ Bug report จัดทำเพื่อเก็บผล รายละเอียดที่เจอว่าไม่ตรงกับสิ่งที่คาดหวังไว้ในตัว Test case อย่างไร
โอเค เราได้คำตอบแล้ว แล้วทำเพื่ออะไรล่ะ เพื่อสื่อสารกับ Dev ให้ทราบถึงปัญหาร่วมกัน
โอเค งั้นหน้าที่ของ Bug report คือการสื่อสารกับ Dev ให้เข้าใจตรงกับกันว่าเกิดเหตุการณ์อะไรขึ้น ด้วยขั้นตอนอย่างไร
แล้วในทีมเล็กที่ข้อได้เปรียบคือการพูดคุยสื่อสารกันมันง่าย การจัดทำ Bug report ยังจำเป็นต้องทำอยู่ไหมนะ ?
เป็นสิ .. เพื่อให้เป็น ”ระบบ” จัดเก็บไว้เพื่อมาดูย้อนหลังยังไงล่ะ ( คำตอบที่แว่วมา )
งั้นถามต่ออีกสักนิด แล้ว “ระบบ” ที่ว่านี้เรากำลังยึดตามหลักอะไรอยู่ล่ะ .. เชื่อว่าองค์กรส่วนใหญ่ที่พัฒนา Software ยึดตามหลักการทำงานแบบ Agile และเมื่ออ้างอิงจากแก่นของ Agile จริง ๆ จะเห็นได้ว่าให้ความสำคัญกับการมีปฏิสัมพันธ์กันมากกว่าการทำตามขั้นตอน และเอกสารที่ครบถ้วน
นั่นคือการเดินไปบอก Dev เวลาเจอ Bug หากยึดตามหลัก Agile จริง ๆ ก็ถูกต้องเลยนี่นา ไม่มีเหตุจำเป็นต้องทำเอกสารตัวนี้ขึ้นมาก็ได้
แต่ความรู้สึกที่เป็น “ระบบ” ที่รู้สึกกันคงถูกถ่ายทอดมาจากทีมใหญ่ ๆ เวลาต้องติดต่อ ประสานงานกันไม่ได้ง่ายเหมือนทีมเล็ก จึงจำเป็นต้องทำตัวเอกสาร Bug report ขึ้นมาเพื่อลดขั้นตอนการนัดประชุมกันมากกว่า
แล้ว QA ในทีมขนาดเล็กควรทำอะไร ?
หากยึดตามหลักนี้ จะมีเอกสารอะไรที่ไม่ต้องทำอีกไหม ? เรื่องนี้คงให้คำตอบแบบเฉพาะเจาะจงได้ยาก เพราะแต่ละทีมก็มี Flow การทำงานที่แตกต่างกัน แต่สามารถยึดแนวปฏิบัติได้ ดังนี้
ตัดเอกสารที่ไม่จำเป็นทิ้ง
อย่างที่ยกตัวอย่าง Bug report ลองตั้งคำถามเสมอว่าเอกสารทุกชิ้นที่ทำขึ้นมามีจุดประสงค์อะไร หากไม่มีมันจะทำให้การทำงานของเราสะดุด หรือประสิทธิภาพลดลงไหม หากคำตอบคือไม่ก็ตัดเอกสารพวกนั้นออกไปก่อน อย่าเอาเวลาไปเสียกับตรงนั้น
อย่าทุ่มเวลาไปกับการหาระบบที่ดีเลิศ
ข้อได้เปรียบของทีมที่เล็กคือติดต่อ สื่อสารกันง่าย เมื่อเกิดเรื่องอะไรสามารถปรึกษากันได้รวดเร็ว อย่าเพิ่งพยายามหาระบบ หรือ Tool อะไรมาครอบเพื่อลดข้อได้เปรียบในจุดนี้ลง โฟกัสกับการ Deliver งานออกมาในระบบที่พอใช้งานได้ก็พอ
ตัดประชุมที่ไม่จำเป็นออก
เรื่องนี้ต้องคงต้องคุยกับทั้งทีม ว่าประชุมที่มีอยู่ มีจุดประสงค์อะไร ได้ประโยชน์อย่างไร จากการประชุมนั้น ๆ ทีมขนาดเล็กคงยังไม่ต้องมีประชุม 1 on 1 หรือ feedback ประจำสัปดาห์ก็ได้ เพราะอย่างไรก็สื่อสารกันแทบตลอดเวลาเรียกได้ว่าเป็นช่วงเวลาแห่งการสาดไอเดียใหม่ ๆ แทบทุกวันอยู่แล้ว
สรุป
ประเด็นของบทความนี้คือ เข้าใจบริบท QA ขนาดเล็ก ควรเลือกทำในสิ่งที่จำเป็นต้องทำ จัดลำดับความสำคัญ โดยผ่านการวิเคราะห์ ไม่จำเป็นต้องทำตาม “ระบบ” หากสิ่งที่ทำอยู่มีประสิทธิภาพมากกว่า แต่ไม่ได้บอกว่าไม่ต้องสนใจพัฒนา Flow การทำงานให้มีประสิทธิภาพยิ่งขึ้นนะ เพราะเมื่อทีมค่อย ๆ ขยายขึ้นปัญหาก็จะค่อย ๆ มีมากขึ้น เพราะงั้นก็มองหาทางพัฒนาอยู่ตลอดจะดีที่สุดแหละเนอะ
