1. Can be Lazy
ปัจจัยสำคัญที่สุดอย่างหนึ่งสำหรับกระบวนการของการพัฒนาซอฟต์แวร์ หรือ กระบวนการพัฒนาอื่น ๆ ก็ตาม คงหนีไม่พ้นเรื่อง เวลา เพราะฉะนั้น อย่างแรกสุด คือ เลิก สวมบท พระ ร(ล)อ กันเสียที หลายต่อครั้ง ที่เคยได้รับคำตอบว่า “ไม่สามารถทดสอบระบบได้ เนื่องจาก Environment ไม่พร้อม” “ยังได้รับข้อมูล หรือ เอกสาร ไม่ครบถ้วน”

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

2. Can become expert easily
หลายต่อหลายครั้ง ที่มักได้ยินว่า “Tester งานนี้น่าสนใจแฮะ” จากนั้นก็ตามติดมาด้วย “คงไม่มีอะไรใช่มั้ย แค่ คลิก ๆๆๆๆๆๆ” นั่นไง ได้ยินข้อความประมาณนี้ ตั้งแต่ที่งานด้านการทดสอบระบบยังไม่ค่อยมีใครให้ความสำคัญเท่าไหร่ จนมาถึงบัดนี้ (ความสำคัญมากขึ้นมาหน่อย) ก็ยังคงได้ยินไม่เว้นวัน ซึ่งยังมี กลุ่มคนกันเอง (เหล่า Tester นี่ล่ะ) ที่ยังเข้าใจผิดว่าหน้าที่หลัก คือ การคลิกมักมีคนชอบตั้งคำถามถามว่า “ใคร ๆ ก็เป็น Tester ได้ ว่ามั้ย”

3. Can blame anyone
เคยได้มีโอกาสสัมภาษณ์ผู้ร่วมอุดมการณ์มาบ้าง หลายต่อหลายคนบอกว่า เหตุที่มาทำงานเป็น Tester ก็เพราะจะได้จับผิดชาวบ้าน บางครั้งก็ได้ยินมาบ้างว่า “ไม่อยากส่งงานให้ Test อ่ะ เพราะ Tester ชอบจับผิด”

อยากให้ทุกคน ลองกลับมาคิดดูใหม่  Tester ก็สามารถทำผิดพลาดได้เช่นกัน  ในกระบวนการของการพัฒนา  เราจึงต้องมีจุดยึดในจุดเดียวกัน และ พัฒนาระบบให้ตรงตามสิ่งที่เรากำหนดไว้ร่วมกัน คือ Requirement Spec  ซึ่งบริษัทส่วนใหญ่นั้น มักจะมี Technical Spec / Solution Spec สำหรับทีมพัฒนาระบบ  และ Test Spec สำหรับทีมทดสอบระบบ  ซึ่งทุก ๆ ทีม ก็จะกำหนด Spec ให้ตรงตาม Requirement Spec อยู่แล้ว  แต่ควรจะเพิ่มอีกส่วนนึงก็คือ  ลองหยิบ  Technical Spec / Solution Spec มาเทียบกับ Test Spec บ้างสิค่ะ ว่ามันไปในทิศทางเดียวกันหรือเปล่า เพราะปัญหาคลาสสิคสุด ๆ คือ การตีความ

4. Love parrots
ก่อนอื่น คุณรู้ความหมายของคำว่า “รู้” และ “เข้าใจ” มากแค่ไหนกันค่ะเคยมีประเด็นถกเถียงกับผู้ร่วมอุดมการณ์มาหลายครั้ง ว่า หากเราเป็น Web Tester แล้ว เราจะผันตัวเองไปเป็น Game Tester, Mobile Tester, ฯลฯ ได้หรือไม่ สำหรับคำตอบก็คือ เป็นไปได้ 100% ค่ะ งั้นคุณลองมาสำรวจตัวเองดูว่า คุณ ”รู้” หรือ “เข้าใจ” ในงานของ Tester มาน้อยแค่ไหน เพราะการทดสอบระบบไม่ใช่เป็นเพียงการท่องจำเพื่อไปทำต่อ แต่คุณต้องมีพื้นฐานของความเข้าใจ เพื่อนำไปต่อยอดในการทดสอบระบบแต่ละแบบ หากคุณเข้าใจอย่างแท้จริง ก็ไม่ยากเลยหากคุณจะนำความรู้ความเข้าใจนั้น ไปประยุกต์ใช้ต่อไป (หรือว่า คุณจะเป็นนกแก้วสีสวยก็ตามใจคุณ)

5. Do not need to learn
อีกส่วนที่สำคัญสำหรับ Tester ก็คือ การศึกษาเทคโนโลยีใหม่ ๆ ซึ่งบางคนก็บอกว่า ไม่ใช่หน้าที่ของ Tester ทั้งนี้อาจจะไม่ใช่ หน้าที่หลัก แต่การศึกษาเทคโนโลยีนั้น เป็นส่วนหนึ่งที่ทำให้ Tester สามารถนำความรู้เหล่านั้นมาปรับปรุงกระบวนการทดสอบ หรือ Test inventory ต่าง ๆ ให้ทันสมัย และสอดคล้องกับการทำงานของระบบมากที่สุดเช่นกัน

6. Without adding real value
แล้วหลังจากที่มี Tester แล้ว คุณทำอะไรให้กับทีมงานของคุณได้บ้าง หลายต่อหลายท่านอาจเข้าใจผิดไปว่า

– KPI ของ Tester ก็คือ จำนวน Defects / Errors / Bugs ที่คุณพบ ที่จะต้องมากที่สุด
– KPI ของ Programmer ก็คงไม่พ้น กับ จำนวน Defects / Errors / Bugs ที่คุณสร้าง ซึ่งจะต้องน้อยที่สุด

ถ้าเกิดประเด็นอย่างข้างต้น ทีมงานของคุณคงต้องปั่นป่วนมาก ๆ ค่ะ เพราะว่า มองกันคนละมุมอย่างสิ้นเชิง  แท้จริงแล้ว KPI ของ Tester ใช่ว่าจะขึ้นอยู่กับ จำนวน Defects ที่คุณพบเสมอไป  ซึ่ง Tester แต่ละคน ก็คงจะต้องเจอ Defects เดิม ๆ ซ้ำ ๆ มากันคนละหลายสิบรอบ  เรามาลองหาวิธีลด Defects พวกนั้น ออกไปจากทีมงานของคุณกันดีกว่ามั้ยค่ะ  อาจจะเริ่มต้นจาก Test Checklist ง่าย ๆ เพื่อเป็นแนวทางให้ทีมพัฒนาลองทดสอบในเบื้องต้นก่อน  อาจจะช่วยลด Defects บ้าง แถมไม่ต้องเสียเวลามานั่งเขียน Defects กันด้วย อย่างนี้ ก็ Happy กันทุกฝ่าย แต่ทั้งนี้ทั้งนั้น Test Checklist ดังกล่าว ก็ควรให้ทุกฝ่ายได้ร่วมลงความเห็นกันด้วยนะค่ะ จะเป็นการดีที่สุดค่ะ

ที่มา: www.welovebug.com