Quality Assurance (QA) ที่ Muze เราทำอะไรบ้าง ..?
| และจะเกิดปัญหาอะไรขึ้นบ้างถ้าที่ Muze ไม่มี QA..
“พี่เฟิร์น” นภวรรณ ฉาบกังวาล (Muze Senior Quality Assurance) ซึ่งเป็น QA
‘คนแรก’ ของ Muze อีกทั้งยังเป็นอดีต Developer ที่ผ่านประสบการณ์ Code เอง Test เองที่ Muze อีกด้วย
วันนี้จะมาแชร์ประสบการณ์การ Testing กว่า 8 ปี… Process การทำงานร่วมกับ Developer.. และเรื่องอื่น ๆ ที่หลายคนอยากรู้เกี่ยวกับตำแหน่งนี้
แนะนำตัวกันหน่อย
ชื่อเฟิร์นค่ะ อายุ 30 ปี ปัจจุบันเป็น Senior Quality Assurance (QA) อยู่ที่ Muze มาตั้งแต่เรียนจบเลย จนถึงตอนนี้ก็ประมาณ 8 ปีได้ ซึ่งก่อนนี้เคยทำในตำแหน่ง Developer เคย Coding เอง โดยได้ทำทั้ง Website และ Mobile มาก่อน ซึ่งตอนนั้นเราก็ทั้ง Dev และ Test งานด้วยตัวเองไปด้วยเลย รู้สึกชอบทำงานในส่วน Test มากกว่า เพราะตอนนั้นที่ Muze ยังไม่มี QA พอทำมาเรื่อย ๆ เลยเป็นจุดที่ทำให้เราเริ่มมาเป็น QA เต็มตัวแทน
ทำไมถึงเลือกมาเป็น QA เต็มตัว ?
พอได้ทำแล้วรู้สึกสนุกกว่าการ Dev แล้วก็การเป็น QA การได้ Test ระบบด้วยรูปแบบต่าง ๆ มันมีความท้าทายว่าเราจะส่งงานออกไปยังไง แบบมีคุณภาพและเกิดข้อผิดพลาดน้อยที่สุด ไปถึงมือลูกค้า แบบที่มี Bug และผลกระทบกับลูกค้าน้อยที่สุด เพราะเราอยากจะส่งมอบงานที่มีคุณภาพไปให้ถึงมือลูกค้า
อีกอย่างหนึ่งคือมาจากพื้นฐานนิสัยช่างสังเกต ขี้สงสัยความอยากรู้อยากเห็น กับความชอบจับผิดนิด ๆ ที่มีอยู่ในตัวเองด้วย ทำให้เวลาที่เราไป Test หรือพยายามมองหาจุดบกพร่องต่าง ๆ บน Product เป็นเรื่องสนุก เลยทำให้เรามาเป็น QA จนถึงตอนนี้เลย จากตอนนั้นถึงตอนนี้ก็น่าจะประมาณ 5 ปีแล้ว
ตอน Coding กับตอนที่เป็น QA มีความแตกต่างกันไหม ?
| ในเรื่องของความรู้สึกหรือมุมมองในการทำงาน..
แตกต่างกันอยู่แล้ว อย่าง Developer จะต้องรู้ลึกในงานที่เค้าทำ พวก Technology Stack, Programming Language ส่วน QA อาจจะไม่ต้องรู้ละเอียดลึกซึ้ง เท่า Dev รู้ให้เพียงพอต่อความต้องการ ลึก แต่ควรจะต้องรู้ทุกเรื่อง เพื่อที่ให้เราสามารถทำงานออกมาได้
หมายความว่า เราไม่จำเป็นต้องรู้เรื่องภาษาโปรแกรมเมอร์ที่ใช้ในโปรเจกต์ เราไม่ต้องเขียนเป็น
แต่เราต้องรู้ว่ามันทำงานยังไง มีลำดับการทำงานแบบไหน Flow Diagram เป็นยังไง การทำงานจะมีข้อจำกัดอะไรบ้างเอาไว้ใช้เพื่ออะไร หรือภาษานั้น ๆ มีข้อจำกัดอะไรบ้าง แล้วอะไรที่สามารถทำให้เกิดผลกระทบกับงาน รวมไปถึงเข้าใจใน Scope ของงาน และ Requirement ของลูกค้า
| อย่างนี้ความรู้เรื่อง Coding จำเป็นไหมสำหรับตำแหน่ง QA ?
ถ้าถามว่าจำเป็นไหม โดยทั่วไปอาจจะไม่ได้จำเป็น แต่การมีความรู้เรื่อง Coding จะทำให้เราเรียนรู้ได้เร็ว เช่น ในเรื่องของการทำ Automate Test ซึ่งการทำ Automate ปกติจะต้องมี Tools ต่าง ๆ มารองรับ ซึ่งแฝงไปด้วยการ Coding อยู่แล้ว ในส่วนนี้ถ้ามีความรู้การ Coding ก็จะเรียนรู้ได้เร็วขึ้น แต่ถ้าเป็น Manual Test เราก็ไม่ต้อง Coding อะไรเลย
ซึ่งตรงนี้ที่ Muze เราจะใช้ทั้ง 2 แบบ ขึ้นอยู่กับว่าในแต่ละโปรเจกต์เราจะทำการเลือกว่าจะใช้ Manual Test หรือ Automate Test เข้ามาทำ ขึ้นอยู่กับว่าวิธีการหรือรูปแบบไหนที่เหมาะสมกับระยะเวลาและข้อจำกัดที่เรามี
ลองแชร์ Process การทำงานของ QA ที่ Muze
ที่นี่เราทำงานเป็น Sprint QA เข้าประชุมพร้อมกับทีมเลย ตั้งแต่ Grooming, Planning เพื่อรับรู้ Requirement ในระหว่างนั้น QA ต้องเริ่มคิดและตั้งคำถามหรือเสนอความคิดเห็น มีการคุยกันและหาข้อสรุปสำหรับเรื่องต่างๆ เพื่อให้ทุกคนมีความเข้าใจที่ตรงกัน หลังจากทีมเริ่มแพลนงานใน Sprint เรียบร้อยแล้ว QA มีหน้าที่เขียน Test Case Scenario สำหรับงานใน Sprint นั้น ๆ รวมถึงทีม Developer ที่เริ่มทำการ Coding พอถึงช่วงกลางหรือจบสปรินท์ Developer จะส่งงานมาให้เรา Test เราก็จะ Test ตาม Case Scenario ที่เราสร้างขึ้นมา
พอถึงตอนนี้เราก็มีหน้าที่ Report งานว่า Pass หรือ Fail หรือมี Issues อื่น ๆ อะไรบ้าง ซึ่งเราก็ต้อง Investigate เบื้องต้นและวิเคราะห์ในส่วนนี้ออกไปให้กับทีมเพื่อทำการแก้ไข
พอจบงานใน Sprint เราก็ต้องเข้าร่วม Demo งานในส่วนนี้ให้กับลูกค้า รอรับ Feedback ต่าง หรือในส่วนที่ลูกค้าอยากปรับหรือเพิ่มเติมส่วนไหน ก็จะนำกลับมาเป็นงานเพื่อเข้าใน Sprint ถัดไป ให้เห็นว่างานที่เราจะส่งมอบให้เป็นยังไง
ทักษะอะไรบ้างที่ QA จำเป็นต้องมี ?
1. อย่างแรกคือเรื่อง “ความแม่นยำ” ซึ่งสำคัญในการ Test งานมาก การที่เรามีความแม่นยำ ทำให้เราไม่พลาดในจุดเล็กจุดน้อย ที่อาจก่อให้เกิดผลกระทบต่างๆ ทำให้สามารถวิเคราะห์ Requirement ได้
2. “การฟังและการสื่อสาร” ฟังให้มาก เข้าใจในสิ่งที่คู่สนทนาเรากำลังสื่อสาร ที่เป็นทั้ง Requirement รูปแบบกระบวนการทำงาน ที่ขาดไม่ได้คือการสื่อสาร เพราะ QA ต้องทำงานร่วมกับ Developer เป็นหลัก ทีนี่เวลาเราเจอบัค เราจะต้องสื่อสารให้เข้าใจตรงกัน และไม่ทำให้เค้ารู้สึกว่าโดนจับผิด คือเราต้องคุยกับเค้าให้รู้เรื่อง รวมถึงบางครั้งที่อาจจะต้องคุยกับลูกค้าเองด้วย
3. “Prioritize” เมื่อเราเจอ Issues ที่มากกว่าหนึ่งขึ้นไป เราจะต้อง Investigate เบื้องต้นและตัดสินใจได้ว่าบัคอันไหนจำเป็นต้องแก้ก่อน-แก้หลัง ซึ่ง QA มีหน้าที่ต้องจัดการพวกนี้ได้ในเรื่องจัดลำดับความเร่งด่วนและความสำคัญของ Issues ที่เจอ
4. สุดท้ายคือการเข้าใจ Workflow ของ Software ที่เราจะทำ และรู้พื้นฐานการทดสอบ Software ต่าง ๆ เช่นเรื่องของ Mobile testing, Security testing รวมไปถึงการออกแบบ Test case scenario
คิดว่าจะเกิดปัญหาอะไรขึ้นถ้าทีมไม่มี QA ?
ปัญหาที่อาจจะเกิด คือผลกระทบในขณะที่เรา Go Live ไปแล้ว เนื่องจากเวลาที่ Developers หรือแม้แต่เราทำงานหนึ่งขึ้นมา เราอาจจะไม่เห็นข้อบกพร่องที่เกิดขึ้น เรามักจะเห็นแค่สิ่งที่เราทำออกมา
‘เหมือนเรามองแก้วที่มีหู มองข้างเดียวแล้วอีกข้างมองไม่เห็น’
การที่มี QA เข้ามาช่วย ก็เหมือนมีคนเข้ามาช่วยตรวจสอบ ตรวจทานสิ่งที่ Developer ทำออกมาเพื่อให้งานที่ออกมามีคุณภาพสูงสุด
สุดท้ายอยากให้ลองชวน คนที่สนใจในตำแหน่ง Quality Assurance Software Tester (QA) มาร่วมทีม เติบโตไปพร้อมกับ Muze
ใครที่สนใจ มองหางานในตำแหน่ง QA อยากให้ลองมาที่ Muze เพราะ..
ที่นี่มีความท้าทายใหม่ ๆ เนื่องจากเรามีโปรเจกต์ใหม่เข้ามาเรื่อย ๆ แล้วแต่ละโปรเจกต์ก็จะถูกพัฒนาด้วยเทคโนโลยีที่แตกต่างกัน อย่างเช่นถูก Coding มาด้วยภาษาที่แตกต่างกัน เพราะฉะนั้นเราจะไม่ได้ทำงานซ้ำ ๆ เหมือนเดิม เราได้เจอลูกค้าหลากหลาย รูปแบบ Business ที่หลากหลายและมีความต้องการที่ไม่เหมือนกัน ความ
ความ Challenge คือ เราจะต้องทำยังไงให้ส่งงานได้ตรงกับสิ่งที่ลูกค้าเค้าต้องการและมีคุณภาพ Bug น้อย อีกอย่างหนึ่งคือเราจะต้องทำงานยังไงเพื่อลดเวลาให้น้อยลงในแต่ละโปรเจกต์ด้วย อีกอย่างคือที่ Muze ทำงานเป็นทีมจริง ๆ เราร่วมงานและร่วมแชร์ไอเดียในทุก Process ของการทำงาน
“ทีมของ muze เหมือนเพื่อนร่วมทำ Project จบตอนมหาวิทยาลัย แต่ละคนทำคนละส่วน รู้หน้าที่ ช่วยเหลือกัน ช่วยกันแก้ปัญหา หาทางออก”
