“Get To Know The Writer” “มาทำความรู้จักกับผู้เขียนกันเถอะ”

ได้ฤกษ์งามยามดีเสียทีนะคะ สำหรับการเข้ามาเจิม คอลัมน์ UAT: User Acceptance Test หลังจากที่ซุ่ม(โป่ง) มาหลายอาทิตย์แล้ว แต่ก็ถือว่าโชคยังเข้าข้างอยู่บ้าง ที่ยังไม่โดนประธานของเว็บ ตัดหางปล่อยวัดไปเสียก่อน อันเนื่องจากไม่ยอมแบ่งปันเรื่องราว ดีๆ ให้ชาว Tester แห่งสยาม เสียที

ก่อนที่จะประเดิม เรื่องแรกให้กับ We Love Bug ก็จะถือ โอกาสนี้ เปิดตัว คอลัมน์ UAT เป็นทางการ แล้วก็ อยากจะเชิญชวน พี่ ๆ น้องๆ ชาว Tester แห่งประเทศสยาม เข้ามาร่วมจอยกับเราด้วย ไม่ว่าจะเป็นการแชร์ประสบการณ์จากการทำงาน หรือมาร่วม แบ่งปัน เพิ่มพูน ความรู้ และวิธีการ ในการทำ Test ไม่ว่าจะเป็น Test ประเภทไหนก็ตาม ผ่าน We Love Bug แห่งนี้ค่ะ

เนื่องจากผู้เขียนเองก็ทำงานในวงการไอทีสาย Software Development มาประมาณเกือบ ๆ สิบปี เริ่มงานตั้งแต่ Junior Programmer, Analyst programmer, Software Architect, Senior software engineer etc… ซึ่งส่วนใหญ่ ก็ล้วนเป็นองค์กรประเภท software industry อย่าเพิ่งแปลกใจว่า ทำไมต้องกล่าวถึงสายงานเหล่านั้น ก็เพราะว่า ต้องเกี่ยวข้องและคุ้นเคยกับการ Test ทั้งสิ้น ไม่ว่าจะเป็น Unit Test, System Test, Integration Test, Performance Test … แล้วเมื่อมองย้อนไปในอดีตประมาณสัก 5- 6 ปี ในงานเทสที่ผู้เขียนเคยผ่านมานั้น ก็ต้องยอมรับกันตรงๆ ว่าความเข้มข้น หรือจริงจังในการทำเทสในสายงานยังมีไม่มากพอ หรือพูดอีกอย่างคือ ให้ความสำคัญน้อยกว่า การที่จะ code program หรือ design ระบบให้เสร็จทันกับ timeline ซึ่งโดยสถิติส่วนตัวแล้ว เป็นไปได้น้อยมากที่จะเทสได้ครบทุก case ที่วางไว้หรือทำได้ดีที่สุดก็คือเลือกเทสได้บางเคสเท่านั้น แล้วผลก็คือ เมื่อต้องไปส่งมอบระบบแล้วต้องไปทำ UAT ร่วมกับลูกค้า ก็มักจะพบเจอกับ ดีเฟคที่คาดไม่ถึงเสมอๆ ไม่ว่าจะเป็น บั๊คที่ไม่ควรจะให้ลูกค้าเจอ (unwanted defect) หรือควรจะหาเจอตั้งแต่ในกระบวนการพัฒนาแล้ว และอีกประเภทคือ ระบบไม่สามารถรองรับการทำงานในปัจจุบันของลูกค้าได้อย่าง 100% ซึ่งปัญหานี้ โดยส่วนตัวมองว่า เป็นดีเฟคที่มีโอกาสที่จะเจอได้ในทุกๆ ระบบ หรือทุกบริษัทผู้ผลิตซอฟแวร์ตามสั่ง ซึ่งอาจจะเกิดจากกระบวนการ requirement ซึ่งเป็นต้นทางของการพัฒนาไม่สมบูรณ์ หรือปัญหาจากการ design ที่ไม่สอดคล้องกับความต้องการของลูกค้า ทั้งนี้ทั้งนั้นส่วนหนึ่ง ก็ขึ้นอยู่กับว่าลูกค้าจะสามารถยอมรับระบบนั้นได้ในเงื่อนไขอะไรบ้างเช่น ใช้งานขนานกับระบบเดิมตามช่วงเวลาที่กำหนด เพื่อเก็บดีเฟค เป็นต้น เพราะจะให้ไม่มีดีเฟคเลยนั้น คงเป็นไปได้ยากส์ (no defect free)

และประสบการณ์ต่อจากนั้นของผู้เขียนในช่วงประมาณหกปีหลังนี้ก็เริ่มเข้าใกล้ คำว่า Software Quality มากขึ้น เมื่อมีโอกาสได้เป็นส่วนหนึ่งในการทำงานในส่วนการวางระบบกระบวนการพัฒนาระบบอย่างมีแบบแผนหรือตอนนั้นก็คือ CMM (ปัจจุบัน CMMI) ซึ่งก็ยังต้องทำงานด้าน develop ไปด้วย(พูดง่ายๆ งานเพิ่มขึ้น) ซึ่งตรงนี้ล่ะได้มีโอกาส เรียนรู้ และได้เขียนโพรเซสการทำงานอย่างมีขั้นตอนในเฟสที่ตัวเองรับผิดชอบ รวมถึงการได้เข้าใจและให้ความสำคัญของการ Test เพราะเราได้มีการก่อตั้ง Unit ของการ Test ขื้นมาอีกด้วย และด้วยนโยบายจากเบื้องบนในเรื่องการให้ความสำคัญใน quality ของ ซอฟต์แวร์ ในทุกเฟสของการ develop เราในฐานะ SA ตอนนั้น ก็ต้องควบคุมคุณภาพในระบบที่ตัวเองรับผิดชอบ ไม่ว่าจะ ออกแบบเทสเคสเอง หรือลงมือเทสเพื่อตรวจสอบผลการ unit test ของ PG เองก่อนที่จะส่งออกไปยัง Test Team ก็ทำให้ SA หลายๆ คน alert กันพอสมควรเพราะเท่ากับงานเพิ่มนะเนี่ย(คิดตอนนั้น) แต่ก็สนุกและได้เพิ่มมุมมอง เพราะจากการได้ลองเทส หรือ รีวิว code ของคนอื่นนั้น ก็ทำให้เห็นสไตล์การเขียน โปรแกรมหรือการจัดวางรูปแบบ กระบวนการคิดของแต่ละคนต่างๆกัน อีกอย่างนะคะ ถึงแม้ว่าจะมีการรีวิวกันแล้ว ส่งออกไปให้ Test Team ยังอุตส่าห์ หาบั๊คเจออีก (งานยิ่งเร่งๆ อยู่ ต้องมา ประกอบระบบใหม่อีกละ) ก็มีบ้างที่ SA กับ Test Lead จะไม่ค่อยจะลงรอยกัน (เฉพาะเวลางานนะ)

แต่ ณ วันนี้ ผู้เขียนได้มานั่งอยู่ในมุมอีกมุมหนึ่งของสายงาน คือ IT Test Management ในฐานะ Test Lead ซึ่งโฟกัสการทำเทสใน ส่วน UAT and E2E ใน industry Telco มาได้ เกือบๆจะ สามปีละ เพื่อนๆ พี่ๆ ที่รู้จัก ก็มีถามไถ่ในตอนแรกๆ ว่าเราตัดสินใจดีแล้วหรือ จะเหมาะกับเราเหรอเพราะอาจจะคิดว่าผู้เขียนน่าจะเหมาะที่จะทำสายเดิม คำถามและความห่วงใยมากมายตามมาระยะนึง แต่ก็เข้าใจทุกๆคนที่เป็นห่วงค่ะ แต่จะขอบอกว่าถึงแม้จะหนัก แต่รู้สึกว่าเนี่ยล่ะใช่เลยที่อยากทำ เพราะได้เรียนรู้ระบบใหญ่ๆ ใหม่ๆ หลากหลาย (เพราะว่าทีมนี้รับเทสทั่วราชอาณาจักร 555) บางระบบก็เชื่อมโยงกันซับซ้อน(ซ่อนเงื่อน ไม่ให้เพื่อนรู้) ท้าทายในการทำเทส และท้าทายกับโรคกระเพาะเหลือเกิน และนอกจากจะมี In-house develop แล้ว ก็ยังต้องทำงานกับ supplier มากมายที่ต้องการใบผ่านด่านจากทีมเรา(จะจ่ายเงินหรือไม่ก็ทีมนี้ก็เป็นส่วนหนึ่งล่ะ) ว่าแล้วก็ต้องย้อนกลับไปสมัยเป็น supplier เอง ก็มียากบ้างง่ายบ้าง ในการ ทำ UAT ยิ่งบริษัทไหนไม่มี IT Team เคี่ยวๆ ล่ะก็ สบายไปเลย ได้ sign-off มาง่ายดาย (อิอิ) แต่ตอนนี้มาอยู่ในมุมนี้ ได้มีส่วนในการ ตรวจรับระบบที่มีคุณภาพให้กับบริษัท รู้สึกปลื้มใจจริงๆ ว่าแล้วก็ไม่รอช้า พยายามหาทางงัดกลยุทธิ์ เท่าที่ตัวเองมี หรือจากประสบการณ์ มาใช้ทำงานโดยด่วนเลย ไม่ว่าจะเป็นการ วางแผนการเทส การออกแบบเทสเคส การบริหารจัดการทีม กับ user ที่เชิญมาร่วมกันทำ UAT แล้วไหนจะ มีเรือ่ง test process improvement อีก สนุกนะคะขอบอก

ก็ได้รู้จักกับผู้เขียนไปแล้วนะคะ หวังว่าจะมีผู้สนใจและคอยติดตามผลงานของผู้เขียนและทีมงานท่านอื่นๆกันต่อไป และหวังเป็นอย่างยิ่งว่าเราจะสามารถสร้างสังคมแห่งการเรียนรู้ Software Testing ในประเทศไทย เพื่อยกระดับ คุณภาพของบุคลากรในสายงานนี้ให้ทัดเทียมกับนานาประเทศ

เตรียมตัวพบกับสาระและประสบการณ์ที่น่าสนใจเกี่ยวกับ UAT เร็วๆ นี้ ในหัวข้อ

“มาทำความรู้จัก กับ User Acceptance Testing กันเถอะ“

Coming next, we are going to take a closer look at “What is User Acceptance Testing”

“A journey of a thousand miles begins with a single step” Let’s take the first step

LeeFong..