Software Tester คุณคือ จุดอ่อนด้อยง่อยเปลี้ยเสียขาข้างขวา!!!

you-are-weakest-link

ทำไมผมถึงจั๋วหัวว่า Software Tester คุณคือ จุดอ่อน!!! แอบแรงและอาจจะมีเหล่าเพื่อนพ้องน้องพี่ที่ดำเนินชีวิตด้วยการเป็น Software Tester อยู่ที่อ่านแล้วรู้สึกว่า ไม่ ไม่ ไม่ ฉันไม่ใช่แบบที่แกพูด ฉันไม่ใช่จุดอ่อน นะ ซึ่งผมก็ยังคงยืนยันว่า ใช่…คุณคือจุดออ่อน(ด้อย) เพราะ

คนที่มาทำงานเป็น Software Tester ไม่ได้หลงใหลคลั่งไคล้อะไรเรื่อง คุณภาพ

ย้อนหลังกับไปราวๆ ปี พ.ศ. 2548 ผมได้เข้าไปทำงานในบริษัทผู้ให้บริการ Web Portal นามว่า Sanook! โดยดำรงตำแหน่งเป็น Tester คนแรกและคนเดียว ณ เวลานั้นของที่นั่น ถามว่าทำไมถึงไปสมัครเพื่อเข้ารับตำแหน่ง Tester ณ เวลานั้น คำตอบ คือ งานอะไรก็ได้ที่เกี่ยวกับไอทีเพราะเรียนมา

จากวันเป็นเดือน จากเดือนเป็นปี จากปี พ.ศ. 2548 เป็นปีพ.ศ. 2558 สิริรวม สิบปี พอดิบพอดี ผู้คนที่เข้ามารับตำแหน่งและดำรงตำแหน่งเป็น Software Tester ไม่ว่าจะเป็นระดับแบบไหน ก็มิใช่คนที่มีความหลงใหลคลั่งไคล้ เรื่อง คุณภาพของการพัฒนาซอฟต์แวร์และการทดสอบซอฟต์แวร์ แต่อย่างใด ถ้าไม่เชื่อลองถามตัวเองดูว่า ทำไมถึงมาสมัครเพื่อรับตำแหน่งเป็น Software Tester? หรือถ้าคุณไม่ใช่ Software Tester ลองใช้คำถามเดียวกันไปถามเพื่อนพ้องที่ดำรงตำแหน่งหรือกำลังจะไปสมัครเพื่อรับตำแหน่ง Software Tester แล้วลองฟังคำตอบดูว่ามีใครตอบว่า ชอบ หลงใหล ฉันเกิดมาเพื่อดำรงตำแหน่งนี้ บ้าง

ณ จุดนี้ ก็ต้องยอมรับความจริงว่าเพื่อนพ้องน้องพี่ที่เข้ามาทำงานในส่วนของ Softeware Tester นั้นส่วนใหญ่เป็นผู้ที่อยากจะทำงานในสายงานของไอที ซึ่งจะแตกต่างจากตำแหน่งอื่นๆ เช่น Programmer หรือ Developer หรือ System Analyst หรือ Database Administrator หรือ อื่นๆ ที่หลายต่อหลายคนอยากจะเข้ามาดำรงตำแหน่งหลังจากจบการศึกษาแล้ว

การทำงานแบบเดิมก็ อ่อนด้อย อยู่แล้ว

traditional

ในรูปแบบของการพัฒนาซอฟต์แวร์แบบดั้งเดิม หรือ หลายต่อหลายคน เรียกขานว่า Waterfall (จริงๆ ที่เราใช้อยู่นั้นไม่ใช่ Waterfall มันเป็นแค่คูน้ำนะจ๊ะ) นั้นผมขอเรียกกระบวนท่านี้ว่า Plan-Driven Approach นะจ๊ะ โดยเราหรือคนอื่น (ส่วนมากจะเป็นคนอื่น) ทำการวางแผนการทำงานให้แบบละเอียดๆ ในลักษณะของ Gantt Chart เช่น โครงการพัฒนาซอฟต์แวร์ยาวสองปี เราก็วางแผนล่วงหน้าไปเลยแบบสองปีและขั้นตอนของการทดสอบ (Testing Phase) ก็ถูกวางไว้ตอนปลายๆ ก่อนที่จะถูกส่งมอบให้กับลูกค้าเพื่อดำเนินการทดสอบและตรวจรับ (UAT, User Acceptance Testing) แล้วก็พยายามมากๆ ให้แผนดำเนินการไปตามที่ได้วางแผนไว้เพื่อให้เกิดความผิดพลาดในการดำเนินการเพื่อให้เป็นไปตามแผนงานที่วางไว้น้อยที่สุด

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

เมื่อกลับมามองและสนใจเฉพาะผู้ดำรงตำแหน่ง Softare Tester นั้นแล้ว การทำงานแบบเดิมนั้น เราเองอ่อนด้อยมาก มากและมาก เพราะว่า

  • เอกสารอะไรต่อมิอะไรที่เขาได้กัน เราจะได้ฉบับแรกและฉบับเดียว
  • ข่าวสารอะไรที่เกิดขึ้น เราจะไม่ได้รับรู้อะไรมากนัก
  • แผนงานของการทดสอบถูกเขียนชะตาชีวิตโดยใครสักคนให้เราเดินตามนั้น
  • นั่งเขียน Test Cases ไปเรื่อยๆ ตามเวลาที่กำหนด
  • เป็นตัวอะไรสักอย่างที่เหล่า Programmer หรือ Developer ไม่อยากจะสนทนาด้วย (หากไม่น่ารักเข้าตามันเหล่านั้น)
  • นั่งทดสอบแบบถึกๆ ใช้แรงงานไป (Manual Testing)
  • มีเครื่องทุนแรงมาให้แต่ก็ใช้ได้ไม่เต็มที่ (Automate Testing)
  • ไม่ว่าจะทดสอบดีแค่ไหนสุดท้ายเมื่อเกิดปัญหาขึ้นในมือลูกค้าจะโดนถามก่อนเสมอว่า “ทดสอบมายังไงทำไมถึงมี Bug?!?!?”
  • ใครต่อใครได้ถูกส่งไปร่ำไปเรียนอะไรต่อมิอะไรใหม่ๆ เราเองนั่งอยู่ที่เดิม ทดสอบและนั่งไล่ตี Bug งก งก งก ไปวันวัน

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

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

ลุกแล้วลากเก้าอี้ไปหาที่นั่งใหม่เสียแต่วันนี้

change-traditional

หากยังคงต้องดำเนินชีวติอยู่ในวงจรของ Plan-Drivem Approach นั้น ผมขอแบ่งปันประสบการณ์ของตัวเองที่เคยใช้มาตลอดระยะเวลาที่ทำงานในสายของควบคุมคุณภาพและทดสอบซอฟต์แวร์โดยเริ่มต้นเข้าไปมีส่วนร่วม ณ จุดเหล่านี้

  • ขั้นตอนของการเก็บรวบรวมความต้องการและสะกัดความต้องการเชิงธุรกิจออกมาเป็น ความต้องการของซอฟต์แวร์ (Software Requirement Specification) โดยเข้าไปช่วยคิดและออกแบบ Test Cases ระดับของ Acceptance Testing พร้อมข้อมูลในการทดสอบ ที่ตกลงกับลูกค้า เพื่อช่วยลดความเสี่ยงที่จะก่อให้เกิด Bug ขึ้นมาจากความเข้าใจผิดทั้งลูกค้า ทีมพัฒนา และตัวเราเอง รวมทั้งให้ได้ข้อตกลงในการทำงานและตรวจรับร่วมกัน
  • ขั้นตอนของการวางแผนโครงการเข้าไปร่วมให้ข้อมูลว่าในการทดสอบเราต้องทำอะไรบ้าง มีความเสี่ยงอะไรที่เห็นบ้างในมุมมองเรื่องคุณภาพ
  • ขั้นตอนของการวิเคราพห์ความต้องการของซอฟต์แวร์เพื่อนำไปสู่การออกแบบการพัฒนาซอฟต์แวร์ เข้าไปช่วยในการออกแบบ Test Cases ทั้งส่วนของ Functional และ Non-Functional เพื่อให้เห็นว่าหน้าตาของ Test Cases ในแต่ละระดับที่ถูกนำมาต่อยอดจาก Acceptance Testing พร้อมทั้งหน้าตาของข้อมูลและมองหาว่าจะสามารถนำ Automate Testing เข้าไปปรับใช้ได้อย่างไรให้ได้มากที่สุดในทั้งๆ ระดับชั้นของการทดสอบ ตั้งแต่ Accpetance Testing ลงมาที่ System Testing ลงมาที่ Integration Testing และ Unit Testing ในส่วนของ Functional และยาวไปถึงส่วนของ Non-Functional ซึ่งมันต้องใช้เครื่องทุนแรงในการทดสอบ Automate Testing เข้ามาอยู่แล้ว

หากเราเก๋าพอ เราจะช่วยคุมกำเนิด Bug ทั้งที่จะเกิดจาก ลูกค้าเอย เหล่า Analyst ทั้งหลายเอย เหล่า Programmer หรือ Developer เอย และตัวเราเองด้วย เพราะทุกคนได้เห็นภาพเดียวกัน ทุกคนได้ร่วมตรวจสอบ

ตัวอย่างของการนำสิ่งที่ผมพล่ามไว้ไปใช้งานจริงๆ ซึ่งได้ออกแบบกระบวนท่านี้ไว้ปี พ.ศ. 2553 เมื่อครั้งเป็น หัวหน้าวินมอไซต์ อยู่ที่บริษัทให้บริการ eCommerce Platform แห่งหนึ่ง

example-of-test-process-1

example-of-test-process-2

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

หากเจอคำถามว่า ทำแบบที่พล่ามมานี่แล้วมันต้องจ่ายเงินเพิ่มขึ้นซิก็ให้คนที่ถามไปเสพ ฆ่า Bug หนึ่งตัวต้องใช้เงินเท่าไร? 

สำหรับตัวผมเอง มันคุ้มค่าที่จะลงทุนที่จะเริ่มทำงานในการควบคุมคุณภาพและทดสอบซอฟต์แวร์เชิงรุก เพื่อคุมกำเนิด Bug ที่จะเกิดขึ้น และเหล่า Software Tester ทั้งหลาย ถามตัวเอง ณ วันนี้เลยจะยังคงเป็น จุดอ่อนด้อยง่อยเปลี้ยเสียขา ต่อไปเรื่อยๆ หรือไม่ หรือจะลุกขึ้นมาดูเริ่มทำอะไรใหม่ๆ เพื่อปรับปรุงตัวเองให้เก๋าขึ้น ทำงานเชิงรุกได้ อย่ารอให้ใครมาสั่งให้เป็นหรือทำ

วันนี้มาพล่ามให้เห็นว่า Software Tester แม่งเป็นเป็น จุดอ่อนด้อยง่อยเปลี้ยเสียขาข้างขวา ในการทำงานแบบ Plan-Driven Development เป็นเช่นไร พรุ่งนี้จะมาพล่ามต่ออีกว่าแล้วถ้า Software Tester ที่อ่อนด้อยง่อยเปลี้ยเสียขาข้างขวาไปแล้วเหลือแต่ขาข้างซ้ายต้องเข้าไปอยู่ในการพัฒนาซอฟต์แวร์ที่กำลังมาแรงแซงทางโค้งแล้วก็จพหลุดโค้งลงเหวที่เรียกขานว่า แอจไจล์ (Agile) และจะยิ่งเป็น จุดอ่อนด้อยง่อยเปลี้ยเสียขาข้างซ้าย ไปอีกข้าง

วันพฤหัสบดีที่ 6 พฤศจิกายน พ.ศ. 2558 12:18น.
จตุจักร  กรุงเทพมหานคร

Leave a Reply

Your email address will not be published. Required fields are marked *