Category: Tech Learning Journey

มีความตั้งใจอยากลงเรียนที่ Coursera เพราะว่าเป็น Platform Online Learning ที่ดังและมีชื่อเสียง แถมหากเรียนที่นี่จบ ยังได้รับ Certificate เพื่อเอาไปประกอบการสมัครงาน หรือนำไปใช้ติดสไลด์ประกอบการบรรยาย ว่าเราเป็นผู้ที่ผ่านการลงเรียนในเรื่องนั้นมาแล้วจริงๆได้อีก

จากความตั้งใจเดิม คือจะเก็บเงินเพื่อไป Take Course รายปีของที่นี่ ราคาตกอยู่ที่ประมาณ 1 หมื่นกว่าบาท หากหารเป็นเดือน ก็จะตกเดือนละพันนิดๆ แต่พอคิดๆดู ก็ยังไม่กล้าที่จะเสี่ยงเอาเงินหมื่นไปลง แล้วไม่รู้เราจะเรียนไหวมั้ย เพราะเป็นภาษาอังกฤษล้วน (แต่ตอนนี้มีบรรยายภาษาไทยแล้ว) และก็ยังไม่รู้อีกว่าจะมีรูปแบบการสอนจะเหมือนหรือแตกต่างจาก Udemy , Linkedin Learning อย่างไร

แล้วจู่ๆ ก็ไปเจอ Post จาก Future Trends ว่าทาง Coursera จัดโปร จ่าย 1 เหรียญ เรียนไม่อั้น ตลอดระยะเวลา 1 เดือน หลังอ่านเจอแล้วก็กดสมัคร แล้วจ่ายเงินไปเลยทันที ไม่ต้องคิดอะไรอีกใดๆ กะว่าหากเข้าไปเรียนแล้ว จะเก็บเอา Certificated มาประดับ Profile ซัก 3-4 ใบ เรียนมันไปให้คุ้มเลย 5555

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

1.ทุกบทเรียน มีเทส

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

สำหรับคนที่มีคำถาม ว่าหากระหว่างที่เราทำเทส แล้วเราทำผิดหล่ะ ตรงนี้จะทำยังไง

ต้องตอบไปเลย ว่าเว็บนี้ให้ผิดได้ไม่อั้น อยู่ที่ว่าคุณทำคะแนนได้ถึงขึ้นต่ำที่เขาต้องการไว้หรือไม่ เช่น
-บางหัวข้อ ต้องการให้คุณทำคะแนนได้ถึง 80%
-บางหัวข้อ ต้องการให้คุณทำคะแนนได้ถึง 100%
-บางหัวข้อ ต้องการให้คุณทำคะแนนได้ถึง 100% รวมถึง หากคุณตอบผิดไม่ถึงเป้า คุณจะต้องรอเป็นเวลา 1 ชั่วโมงก่อนจะเข้าไปสอบใหม่ได้อีกครั้งหนึ่ง !!!

ในมุมมองคนเรียน แล้วเห็นระบบการทำงานอะไรที่ไม่เหมือนกับที่เราเคยเรียนมา ก็รู้สึกว้าวกับตรงนี้เหมือนกันนะ หรือหากเราอยากทำ Platform เกี่ยวกับ Corse Online ขึ้นมา เอาความรู้ตรงนี้ไปปรับใช้ ก็ถือว่าเป็นความคิดที่ดีเช่นกัน

2.ในแต่ละ Week มี Assignment

นอกจากจะมีเทสที่เราทำไปในแต่ละบทเรียนแล้ว ตัว Platform ยังมอบหมายงานให้เราทำด้วย
อย่างหัวข้อที่เรียนมาจะเป็นหัวข้อ Introduction to Software Testing ก็จะมีมอบหมายงานเกี่ยวกับการเขียน Test Case ด้วยภาษา Java ให้ครอบคลุมกับโจทย์ที่เขาให้มา โดยมี Code ตัวอย่างมาให้เราดู หน้าที่ของเรามีแค่ แก้ไข Code ให้มันทำงานให้ถูกและดี อย่างที่ควรจะเป็น โดยมีวิธีการติดตั้งเครื่องมือที่จำเป็นต้องใช้ในแต่ละ OS , Version ของ Java ที่ต้องการ หลังจากนั้นก็ส่ง Code ไปให้ Platform นี้ตรวจ

โดยหน้าจอการสั่งงานก็จะประมาณภาพด้านล่างนี้

หากทำงานที่สั่งให้เสร็จแล้ว ก็ไปที่ Tabs My Submissions เพื่อส่งงานและรอดูผลกันได้เลย

ความเจ๋งของ Platform นี้อีกหนึ่งอย่างนั่นคือ เมื่อผู้เรียนส่ง ​Code ไปให้กับทางระบบ หลังจากนั้นอีกเพียงไม่กี่นาที ตัวระบบก็แจ้งกลับ ว่า Code ที่เราส่งไป ได้คะแนนเท่าไหร่ หากมีสิ่งอะไรที่ขาดหรือผิดพลาดไป ก็จะแจ้งกลับมาตามภาพด้านล่างเลย

ตรงนี้หากคิดอยากทำ Platform เกี่ยวกับ Corse Online ก็ต้องคิดเพิ่มแล้วหล่ะ ว่าจะใช้ Features อะไร เพื่อนำมาใช้ตรวจสอบ Code ที่นักเรียนส่งเข้ามาได้ (ChatGPT API , CoPilot API ?)

3.ให้แต่ละผู้เรียน ทำการให้คะแนนผู้เรียนคนอื่นๆด้วยตัวเอง

ต่อจากหัวข้อที่เรียน มันมีงานนึงจะต้องเขียน Test Plan ขึ้นมา ในโจทย์ก็จะมีไฟล์ตัวอย่างมาให้ 3 Files ดังนี้

-ตัวธุรกิจที่เรากำลังจะเขียน Test Plan ว่ามีรูปแบบการทำงานอย่างไร
-ตัวอย่าง Test Plan ที่เอาไว้ดูเป็นตัวอย่าง
-Test Plan Template

หัวข้อนี้เหมือนจะไม่มีอะไรมาก คือให้อ่านให้มาก แล้วก็เขียนแผนออกมา แค่นั้น ไม่ต้องกังวลเรื่องผิดหรือถูก แต่ที่กังวลมากที่สุด คงจะเป็นเรื่องภาษาอังกฤษนี่แหล่ะ ที่เราจะเขียนยังไงดีว้า เขาจะให้คะแนนเรามั้ยนะ (^____^”)
ซึ่งเอาจริงๆ ก็ถือว่าติดอยู่ตรงหัวข้อนี้นานพอสมควร จนเกือบถอดใจไปเลย

แต่พอผ่านมาได้ กลั้นใน จากนั้นก็ Upload File Test Plan ของเราขึ้นไปให้เพื่อนๆตรวจกัน

จังหวะการตรวจที่กังวลไว้ตั้งแต่แรก ว่าเราจะโดนตรวจอย่างไร ก็คลายกังวลเมื่อเราส่งงานไป

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

วิธีการตรวจก็ไม่ยากมาก ทางระบบ เขาจะเตรียมวิธีการตรวจมาให้เราช่วยตรวจสอบ หน้าที่ของเรา มีแค่ตรวจสอบว่าใน Test Plan ที่ส่งกันเข้ามา มีหรือไม่มีสิ่งไหน

หรือในความคิดของเรา เราคิดว่าส่วนไหนใน Test Plan นี้คือจุดแข็งของเขา ก็สามารถเขียนลงไปเพื่อบอกผู้เรียนคนอื่นๆได้

ต้องบอกว่าตรงจุดนี้แอบว้าวกับ QA Engineer จากอินเดียหลายคนมากๆ ที่ทำ Test Plan ออกมาได้สวยมาก
มีใส่ Metric UI ตารางต่างๆเข้ามา พอเห็นแล้วก็ได้แต่ชื่นชม

4.มี MiNi Project ให้ทำก่อนจบ

หลังจากเรียนมาจนครบทุกหัวข้อ มาที่หัวข้อสุดท้ายของเรื่องนี้จะเป็นหัวข้อเกี่ยวกับการเขียน Code Test Script ให้ครอบคลุม เหมือนกับหัวข้อแรก แต่ในที่นี้มี Tools มาให้ใช้ร่วม รวมทั้งหมด 3 ตัว โดยเราต้องเขียน Script ทั้งหมด 3 Script และส่งให้ Platform นี้ตรวจ

ส่วนตัว คิดว่าส่วนนี้คือส่วนที่ทำยากที่สุด บางคนที่เรียนพร้อมๆกัน ส่งมากกว่า 20 ครั้งถึงจะผ่านหัวข้อนี้เลยก็มี !!!!

หลังผ่านการเรียนมา 3 สัปดาห์ และความคาดหวังว่าจะเอา Certificate จากเว็บนี้ไปเยอะๆ ด้วยทุน 1 เหรียญ กลับพบว่า มันก็ไม่ง่ายแบบเปิดฟังให้จบแล้วจะได้ Cert เลยน้า (^____^”)

ยิ่งพอเรียนคอร์สนี้แล้วกลับทำให้เราหันมาทบทวนเลย ว่าเรายังจำเป็นจะต้องเรียนเพื่อหวัง Cert จริงดิ 5555

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

=============================================================================

และในที่สุดก็ได้รับ E-Mail แจ้งเตือน ว่ายินดีด้วย คุณได้ผ่านหลักสูตร !!

https://coursera.org/share/64f50ffcefa0f6a78799b9df28bcad3e

ภูมิใจไม่รู้จะภูมิใจยังไง ที่ได้ Cer ใบนี้จาก Coursera มาได้

เพราะตอนเรียนนั่งเรียนจริงๆจังๆ นั่งแก้ Code , เขียน Test Plan เป็นเรียงความภาษาอังกฤษ

ถึงขนาดเริ่มท้อใจ ว่าเราจะเรียนไปต่อทำไมน้า เสียเงินลงเรียนไปแค่ 1 เหรียญ ปล่อยๆไปเถอะ

แต่สุดท้ายก็คว้า Cert มาได้

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

หรือลงเรียนคอร์สแล้วเรียนไม่จบ (เพราะมันยากตรง Assignment + Mini Project)

ตอนนั้นจะเป็นยังไงนะ คงจะต้องมานั่งบ่น คิดเสียดายเงิน เป็นแน่แท้

555

ต่อไปคงต้องทบทวนตัวเองอีกที ว่านี่เราจะเรียนเอา Cer แบบแค่เรียนๆไปนั่งเรียนทั่วๆไปก็พอขอให้ได้ความรู้

หรือเรามาเอา Cer แบบกิจลักษณะ ที่ต้องทำการบ้าน ส่ง Project ทำ MiniProject แบบนี้อีกทีดี

แต่ที่รู้แน่ๆตอนนี้ พักก่อน (^_____^)

“The beautiful thing about learning is that no one can take it away from you.”

— B.B. King

ช่วงที่เริ่มต้นทำงานเป็น 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 ก็ไม่รู้ว่าทีมที่รับผิดชอบจะทำได้สำเร็จเมื่อไหร่ แต่เชื่อเลยว่าหากยังทำต่อไป คิดว่าต้องสำเร็จได้แน่นอน

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