noraphat.dev

ช่วงที่เริ่มต้นทำงานเป็น Quality Assurance Engineer ตอนแรกก็คิดว่างานมันไม่น่ามีอะไร ก็แค่ไปทำอะไรๆให้มัน Automated สิ แค่นั้นเอง ไม่เห็นจะยาก

หลังจากเรียนคอร์สนี้จบ แล้วมองย้อนกลับไปตอนนั้น เห็นความคิดตัวเองแล้วรู้สึกว่า “คิดตื้นดี” ทำไมคิดง่ายจัง

หลังเรียนจบ ก็ได้ Topics เพื่อเอาไป Discuss กับทีมเพื่อหาทางเพิ่มประสิทธิภาพที่ว่าจะทำอย่างไรให้งานที่ทำใน Sprint มันเร็วและดีขึ้น ในแต่ละ Process

เพราะตอนนี้รู้แล้ว ว่าเราควรจะมองส่วนไหนเป็นสำคัญ

Good Job!

ขอเกริ่นก่อนสักนิดว่า ตัวผมเองได้มีโอกาสมาทำงานในตำแหน่ง Quality Assurance Engineer ซึ่งในวันที่เริ่มเขียน Blog นี้ก็น่าจะเป็นเวลาที่ทำงานในตำแหน่งนี้ได้เกือบ 2 ปี (1 ปี 9 เดือน) ในองค์กรที่ผมทำงานอยู่มีการนำเอาแนวทางของ Agile เข้ามาร่วมทำงานไปด้วยในทุกกระบวนการเลย ซึ่งถือว่าใหม่พอสมควรสำหรับคนที่ย้ายมาจากองค์กรที่เป็นแบบลำดับชั้นและทำงานในรูปแบบ Water Fall มาทำงานในรูปแบบกึ่งลำดับชั้น + แบนราบ และทำงานในรูปแบบ Agile ที่ต้องเริ่มเรียนรู้ใหม่ในหลายๆเรื่อง

การทำงานในบริษัทปัจจุบันกับตำแหน่งนี้ มีการสวมหมวกที่เปลี่ยนไป ทำให้มุมมองที่มีต่องานนั้นก็แตกต่างไปจากเดิม

ช่วงแรกที่เข้ามา ถือว่าใหม่ไปหมดทุกอย่าง ไม่ว่าจะเป็นตำแหน่งงานใหม่ Mind-set การทำงานแบบใหม่ จากเดิมที่ทำงานเป็นนักพัฒนา (Developer) ที่มุ่งเน้นการนำเอา Environtment ต่างๆที่องค์กรมี มารวมกับ Skills ที่เรามีอยู่ มาผนวกรวมกันสร้างเป็น Services หรือ Products เพื่อไปตอบโจทย์ให้กับลูกค้า ไม่ว่าจะทำไปเพื่อแก้ PainPoint ต่างๆ หรือสร้างบริการเพื่อหารายได้ให้กับองค์กร รวมไปถึงว่าจะทำอย่างไรให้ Code , Environtment , DB ทำงานได้ไว ตอบสนองได้เร็ว ในบางที่อาจรวมไปถึงการเขียน Code ให้มีมาตรฐาน สามารถอ่านได้ง่าย ดูแลรักษาได้ง่าย รวมถึงสามารถ Test ได้ง่าย ซึ่งกับที่ทำงานเดิมของผมนั้น ผมเรียกตัวเองว่าเขียน Code ได้ไม่ดี หรือถือว่าไร้มาตรฐานได้เลย (^____^”)

แต่พอเราได้เข้ามาจับงาน QA ของงานปัจจุบันนี้ ความคิดในตอนแรกก็คิดว่า “คงไม่มีอะไรหรอกมั้ง เดี๋ยวเขียน Code ไป Automated Test ให้มันจบๆงานไปแค่นั้นเองจะมีอะไรมาก” พอเอาเข้าจริง มันไม่ง่ายแบบที่คิดเลย เพราะมีหลากหลายเรื่องที่เราควรจะต้องศึกษาในจุดเริ่มต้น ไม่ว่าจะเป็น Mindset ของ QA , การป้องกัน Issue ที่อาจเกิดในตัว Product , การทำงานร่วมกับทีมเพื่อสร้าง Best Practice ที่จะทำให้งานและการเทสเป็นไปอย่างมีประสิทธิภาพอย่างการทดสอบแบบ Shift Left (Test from the early stages) , การแจ้ง Progress ของงาน , การ Monitor งาน , การเพิ่มคุณภาพของงาน ที่จะทำให้ทั้งทีมของเราผลิต ผลิตภัณฑ์ที่มีคุณภาพมากยิ่งขึ้น ?!!

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

จึงเป็นที่มาให้ได้มาเขียน Blog นี้….

พอรู้ว่าขาด ผมเริ่มไปศึกษาหาความรู้เพิ่มเติม ไม่ว่าจะเป็น การไป Take Course ของ Linkedin Learning เพื่อกลบสิ่งที่ขาดต่างๆเหล่านั้น และทำให้เรามีความมั่นใจกับความรู้ของมาตรฐานการทำงาน เพื่อให้การทำงานกับทีมนั้น ทำได้ดียิ่งกว่าเดิม

รวมถึงการอ่านหนังสืออย่าง “Agile Tesing.. Apractical Guide for Testers and Agile Teams” ของ Lisa Crispin , Janet Greggory ที่อ่านแล้วรู้สึกว้าวจนทำให้มาเขียนสิ่งดีๆในหนังสือเล่มนี้แบ่งปันให้ผู้อื่นได้อ่านกัน

ผมขอยกตัวอย่างของ 10 หลักการสำหรับ Agile Testers ที่คิดว่าเป็นประโยชน์ ให้กับใครก็ตาม ที่ยังคงทำงานเป็น QA แต่ยังไม่รู้ในเรื่องเหล่านี้ หรือคนที่อยากจะเป็น QA ที่ดี เพื่อให้ได้รู้กันว่า 10 หลักการที่ดีนั้นประกอบไปด้วยอะไรบ้าง อย่างน้อยที่สุดหลังจากอ่าน Blog นี้ไปแล้ว คุณน่าจะมี Mindset ของการ Test ที่ดีติดตัวไป ไม่มากก็น้อย

1.ให้ผลตอบรับอย่างต่อเนื่อง (Provide Continuous Feedback): ความสำเร็จในงานขึ้นอยู่กับการให้และรับ Feedback ที่ทำเป็นประจำ เพื่อให้ทีมมีทิศทางที่ชัดเจนและปรับปรุงอย่างต่อเนื่อง ตัวอย่างเช่น เมื่อทีมเจอกับปัญหาไม่ว่าจะเป็น ส่งงานผ่าน QA ไปแต่ User บอกว่าหน้าจอไม่ตรงกับที่ออกแบบไปนะ แบบนี้เราควรจะแก้ปัญหาอย่างไร วิธีที่ดีที่สุดคือการให้ Feedback อย่างตรงไปตรงมา รวมถึงวิธีการแก้ปัญหาที่เราควรทำ ปัญหาที่มันเกิดแล้ว หากมีการจัดการกับมันเป็นอย่างดี เชื่อว่าปัญหาเดิมเดียวกันนี้ จะไม่เกิดอีกในครั้งถัดไป

2.นำเสนอคุณค่าต่อลูกค้า (Deliver Value to the Customer): ทุกกิจกรรมที่ทำควรมีจุดมุ่งหมายในการสร้างคุณค่า (Value) ที่ดีที่สุดให้กับลูกค้า ทั้งนี้ต้องฟังและเข้าใจความต้องการของลูกค้า หน้าที่ของ Tester ในจุดนี้คือการมองที่ภาพรวมของ Product ในแต่ละ Sprint ถึงสิ่งที่มันควรจะทำได้ (Critical path) หรือ งานเฉพาะที่จำเป็นและมีความสำคัญบางส่วน (Thin slice) ในเส้นของงานต่างๆ ว่าจะต้องทำงานได้เป็นอย่างดี และหากมีเวลา เราจึงวกกลับมาทำ Features ที่เหลือก็ยังได้ (แม้ในความเป็นจริง เวลาในแต่ละ Sprint จะไม่เคยจะเหลือเลย Hahaha)

3.ส่งเสริมการทำงานแบบติดต่อช่วยเหลือกัน (Enable Face-to-Face Communication): ไม่มีทีมไหนที่ทำงานได้ดีโดยปราศจากการสื่อสารในทีมที่ดี การสื่อสารสามารถช่วยเพิ่มความเข้าใจและประสิทธิภาพในการทำงานร่วมกัน ยิ่งทีมมีการสื่อสารภายในทีมที่ดีและมีบรรยากาศที่ดี จะช่วยให้การทำงานในทีม มีประสิทธิภาพมากยิ่งขึ้น

4.มีความกล้า (Have Courage): อ่านหัวข้อนี้แล้วชอบมาก โดยเฉพาะคนไทยที่มีคำว่า “เกรงใจ” อยู่ในพจนานุกรม ความกล้าในที่นี้อาจจะเป็นความกล้าที่เราไปขอความช่วยเหลือจากทีม Dev แล้วทีม Dev ก็กำลัง Pair งานกันตลอดทั้งวัน และ Issues ที่เราเจอก็ไม่สามารถรอได้ คำว่าเกรงใจ จะทำให้วันใน Sprint ของเราหายไป 1 วัน การเข้าไปคุยเพื่อขอความช่วยเหลือจะช่วยเรื่องนี้ได้ หรือการชี้ให้เห็นข้อผิดพลาดในระหว่างการ Deskcheck ร่วมกันกับ Dev และเราตีงานกลับไปเพราะว่าเราเจอ Bug นั้น ก็เป็นสิ่งที่ต้องใช้ความกล้า แต่เชื่อเลยว่าหากเราทำสิ่งเหล่านี้ได้ดีแล้ว และทีมมีบรรยากาศในทีมที่ดี จนทีมเข้าใจว่าเราก็เป็น QA ประเภทแบบนี้ เมื่อนั้นงานจะง่ายขึ้น การกล้าทำในสิ่งที่ถูกในงาน จะช่วยให้งานที่เราทำนั้นดีขึ้นตามมา

5.ทำให้มันเรียบง่าย (Keep It Simple): ปฏิบัติตามหลัก KISS (Keep It Simple, Stupid!) โดยมุ่งทำให้ทุกสิ่งที่ทำมีความเรียบง่ายและไม่ซับซ้อน ยกตัวอย่างเช่นทีมทำการประเมิน Score ใน Card งาน ได้คะแนนมาถึง 13 Points! ซึ่งจะดีกว่ามั้ยหากเราทำการย่อย Card ที่มีคะแนนสูงเหล่านั้นให้แตกออกเป็น Card 3-4 ใบแทน เพื่อทำให้การเทสนั้นง่ายขึ้นหรือการใช้เทคโนโลยีที่เหมาะสมมาช่วยในการเทส เพื่อให้เราทำเวลาได้ดีขึ้น ดีกว่าหมดเวลาไปกับการทำ Manual Test นานๆ แถมยังรองรับการ Regression Test ใน Releash ถัดไปได้อีกด้วย (ว่าแต่การใช้ Tools มันเรียบง่ายกว่า Manual Test จริงรึ ? !)

6.การปรับปรุงอย่างต่อเนื่อง (Practice Continuous Improvement): การมองหาวิธีการทำงานให้ดีขึ้นเป็นส่วนหนึ่งของ Mindset ใน Team Agile ที่ดีที่สะท้อนถึงการเรียนรู้และปรับปรุงจากประสบการณ์ในทุกๆ งานที่ทำ, นำไปสู่การพัฒนาต่อเนื่อง ไม่ว่าจะเป็นการเข้าสัมมานา การศึกษาหาความรู้การเทสจาก Online Courses ต่างๆ การอ่านหนังสืออย่าง “Agile Tesing” เล่มนี้ หรืออาจเป็นการนำเอาส่ิงที่ควรปรับปรุงจาก Restrospective มาปรับปรุงในแต่ละ Sprint ก็ถือว่าเป็นเรื่องที่ควรทำอย่างต่อเนื่องเช่นเดียวกัน

7.ตอบสนองต่อการเปลี่ยนแปลง (Respond to Change): อยากบอกว่าข้อนี้ที่ประสบกับการทำงาน คือข้อที่ยากสุด ตัวอย่างเช่นเมื่อมีงานเข้ามาแล้วเมื่อต้น Sprint และเราได้ Test Card นั้นผ่านไปแล้ว แต่อยู่ๆ Dev ไปทำ Features มาเพิ่มและกระทบกับ Card เดิมที่เราได้ทำไปแล้ว ทำให้เราต้องกลับมา Test ใหม่ หนำซ้ำกลับมี Bug ?! ความสามารถปรับตัวและรับมือกับการเปลี่ยนแปลงที่เกิดขึ้นเหล่านี้ได้อย่างรวดเร็วและมีประสิทธิภาพถือว่าเป็นหลักการที่ดีที่ควรมีของ Agile Tester คำถามถัดมา และหากทีมเจอปัญหาแบบนี้เราต้องทำอย่างไร หากทีมไหนที่ทำ Automated Test ไปแล้วคงไม่น่ามีปัญหามากเท่าไหร่ เพราะทุกๆ Features ที่ขึ้นไป เราสามารถสั่ง Automated Test ให้รันซ้ำได้ แต่หากทีมไหนทำงานแบบ Manual Test กันหล่ะก็ งานนั้นคงยิ้มรับและบอกว่าเราพร้อมเทสให้ใหม่นะ

8.การจัดการตนเอง (Self-Organize): ทีมควรมีความสามารถในการจัดการและตัดสินใจด้วยตัวเองโดยไม่ต้องพึ่งพาการจัดการที่เป็นรูปแบบลงตัว รวมไปถึงความรับผิดชอบในงานของตนเองและงานของทีม ที่ต้องมองว่าเราต้องช่วยกันเพื่อให้ทีมบรรลุเป้าหมาย

9.เน้นที่คน (Focus on People): การทำงานแบบ Agile Team มุ่งเน้นที่คนทำงาน สมาชิกภายในทีมควรรู้สึกปลอดภัยไม่ต้องรู้สึกกังวลจากการถูกตำหนิหรือกลัวไปว่าจะตกงานหากทำงานได้ไม่ดี การเคารพซึ่งกันและกัน การมีปฏิสัมพันธ์กับคนที่ทำงานด้วย สิ่งต่างๆเหล่านี้มีความสำคัญที่ช่วยให้การส่งมอบผลงานมีคุณภาพมากยิ่งขึ้น

10.สนุก (Enjoy): การทำงานที่เป็นมิตรและสนุกระหว่างผู้มีส่วนเกี่ยวข้องในตำแหน่งต่างๆ สามารถช่วยให้การทำงานนั้นดียิ่งขึ้น ไม่ว่าจะเป็น Dev – QA , BA – DEV , BA -QA , QA – BA – USER , QA – BA -DEV , QA – USER , PO – QA ยิ่งทีมมีการประสานงานที่ดีต่อกัน สิ่งเหล่านี้ยิ่งช่วยให้ทีมมีประสิทธิภาพมากยิ่งขึ้น ส่งผลให้ส่งมอบผลงาน เป็นไปอย่างดียิ่งขึ้น

หลังอ่านหัวข้อนี้จบ เหมือนคนที่รู้แล้วว่าเราควรจะทำอย่างไรต่อไปกับทีมดี รวมถึงรู้ไปอีกว่า เราจะวางตัวในฐานะ QA ที่ดีได้อย่างไร

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

ตอนนี้ตั้งเป้าหมายไว้ว่า อยากให้ทีมที่ทำอยู่ เป็น Automated Test 80% Manual Test 20% จากภาพของ Test Piramid + CICD ก็ไม่รู้ว่าทีมที่รับผิดชอบจะทำได้สำเร็จเมื่อไหร่ แต่เชื่อเลยว่าหากยังทำต่อไป คิดว่าต้องสำเร็จได้แน่นอน

ขอบคุณที่อ่านจนจบ