หลังจากห่างหายจากการเขียนบทความไปนาน วันนี้เลยขอหยิบยกเอาเรื่องใกล้ตัวที่ต้องทำกันเป็นประจำมาเล่าให้ฟังนะครับ

เริ่มแรกต้องย้อนกลับไปสมัยยังเอ๊าะๆ เริ่มทำงานใหม่ๆเมื่อซักหกเจ็ดปีที่แล้ว จำได้ดีเลยว่าเริ่มทำเทสโปรเจคแรกเนี่ย ทาง Project Manager ก็จะบอกให้เรามา Estimate ว่าโปรเจคนี้จะใช้เวลาทำเทสเท่าไหร่

เอาหล่ะสิ ทำยังไงดีหล่ะทีนี้ ตอนนั้นสิ่งที่มีอยู่ในมืออยู่อย่างเดียวคือ requirement list ซึ่งก็เพิ่งเคยเห็นมันมาแค่สองวัน ยังไม่ได้ทำความเข้าใจและเรียนรู้กับมันซะด้วยว่าrequirementแต่ละตัวมันมีอะไรบ้าง พอถึงเวลาประชุมสรุป estimation ตัวเลขที่ออกไปจากปากตอนนั้นคือ 2 อาทิตย์ครับ ซึ่งตัวเลขนี้ได้ออกมาจากการนั่งเทียนครับ นั่งเทียนล้วนๆ คำว่านั่งเทียนในที่นี้คือการนั่งหลับตา ปล่อยสมองให้ว่างเปล่าแล้วตัวเลขหรือข้อมูลอันนึงจะโผล่แว๊ปเข้ามาในสมองของเราทันที หลังจากนั้นก็ลืมตาแล้วเอาตัวเลขนั้นหล่ะมาใช้ (คำว่านั่งเทียนนี้สามารถใช้กับ tester ที่ต้องออกแบบเทสเคสโดยที่ไม่รู้อิโหน่อิเหน่ไม่มีเทคนิคด้วยนะครับ หึๆๆ) ทีนี้เรามาลองสรุปข้อผิดพลาดที่เกิดขึ้นจากคำว่า 2 อาทิตย์ที่พูดไปเมื่อเจ็ดปีที่แล้วกันดีกว่าว่าความผิดพลาดหลักๆที่เกิดขึ้นจากการนั่งเทียนนั้นมีอะไรบ้าง

1. เวลา 2 อาทิตย์ที่บอกไปนั้น เราจินตนาการในใจว่าเราจะมีเวลาทำงาน 10 วันถ้วน (ไม่นับเสาร์อาทิตย์) แต่ในความเป็นจริงแล้ว ช่วง phase test นั้นมีวันหยุด 1 วัน และมีงานประชุมประจำปีของบริษัทอีกครึ่งวัน ดังนั้นเวลา 10 วันที่คิดไว้จึงเหลือแค่ 8 วันครึ่ง โดยปริยาย

2. เวลา 2 อาทิตย์ที่เราคิดถึงนั้น มันรวมแค่เวลาที่เราใช้รันเทสรอบแรกหนึ่งรอบ ไม่รวมช่วงเวลา bug analysis, fix bug, re-run test, summary test report อะไรเหล่านี้เลย แต่ PM คิดเหมารวมไปว่า system test phase  ทั้งหมดใช้เวลาทั้งหมด 2 อาทิตย์ เดชะบุญที่ช่วงเวลาที่ใช้ในการเขียน test case และ set up test environment นั้นสามารถทำขนานไปกับตอนที่ developer เขียน code ได้ไม่อย่างนั้นชีวิตจะยิ่งอับเฉาไปมากกว่านี้

3. ขณะ design test case ทำให้รู้ว่าเวลาที่ขอไป 2 อาทิตย์นั้น ถ้าจะรันเทสให้ได้ดีๆ และครบถ้วนทุก requirement นั้น ไม่มีทางเป็นไปได้เลย สิ่งที่เกิดขึ้นคือจำเป็นต้องออกแบบเทสให้น้อยกว่าที่อยากทำ และถึงจะออกแบบน้อยแล้วก็ยังต้องขอเพิ่มเวลาเป็น 3 อาทิตย์อยู่ดี

4. ถึงแม้จะขอเพิ่มเวลาในตอนหลังเพิ่มมาหนึ่งอาทิตย์แบบเกรงใจแล้วก็ตาม ใน 3 อาทิตย์นั้นต้องอยู่รันงานจนดึกทุกคืน และวันเสาร์อาทิตย์ยังต้องเข้ามาทำงานอีกต่างหาก (ดีที่ตอนจบใหม่ยังฟิตและคะนอง จึงไม่ได้รู้สึกลำบากเท่าที่ควรจะรู้สึก)

5. สุดท้าย Project delay ไปเดือนกว่าเนื่องจากเวลาที่เราขอเพิ่มหนึ่งอาทิตย์ และนอกจากนี้โปรเจคยัง delay จากเวลาที่ใช้ในการ fix bug + re-run test ที่ไม่ได้ estimate ไว้ในตอนแรก

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

ตอนนี้ Practice ที่ทีมทำในการทำ estimation ในโปรเจคแต่ละครั้งเป็นดังนี้ครับ

1. เมื่อได้ Requirement list มา ให้แบ่ง requirement ให้ tester แต่ละคนไปศึกษาคร่าวๆ รวมทั้งให้คิดถึง Test technique ที่จะใช้ในการออกแบบเทสเคส สำหรับ Requirement นั้นๆด้วย ที่ต้องคิดเรื่อง Test technique เพราะว่า Test technique แต่ละประเภทจะมีวัตถุประสงค์และลักษณะจำนวน test case ที่ต่างกัน ยกตัวอย่างเช่น ถ้า requirement นั้นๆเหมาะกับ equivalence partition technique โดยธรรมชาติของเทคนิคนี้จะมีจำนวนเทสเคสที่น้อย แต่ถ้าหากเลือกที่จะใช้ Cause-effect graphing/ Decision table technique แล้วหล่ะก็ จำนวนเทสเคสจะออกมาเยอะครับ

2. เมื่อแต่ละคนได้ศึกษา requirement คร่าวๆ และเลือก test technique แล้วให้แต่ละคน estimate สิ่งต่างๆดังต่อไปนี้

1) Number of test cases

2) เวลาที่คิดว่าจะใช้ในการสร้าง test condition (คือการ design test case โดยใช้ test technique หน่ะครับ)

3) เวลาที่ใช้ในการแปลง test condition นั้นไปเป็น test script (มี step ในการรันเทสและ expect result โดยละเอียด)

4) เวลาที่ใช้ในการสร้าง test tool (ทั้ง functional test tool และ automate test tool)

5) เวลาที่ใช้ในการจัดการ test environment (ลงเครื่อง ,วางระบบเนตเวิร์ค, etc)

6) เวลาที่ใช้ในการ run test

โดย Item ที่ 1, 2, 3, 4 & 6 จะคิดแยกของแต่ละ requirement ออกมาเลยนะครับ เดี๋ยวจะเล่าประโยชน์ของการคิดแยกให้ฟังทีหลังครับ ส่วนหน่วยของการ estimate ให้ทำออกมาเป็น หน่วยชั่วโมงครับ

3. Test leader กับ Dev leader จะช่วยกัน estimate เวลาที่จะใช้ในการ Fix bug และ Re-run test เน้นว่าต้องคิดร่วมกันนะครับ เนื่องจาก test team ไม่สามารถ estimate เวลาที่ใช้ในการ fix bug ได้เองแน่ๆ ส่วนเวลาที่ใช้ในการ Re-run test เนี่ย อาจจะต้องดูจากสถิติของโปรเจคก่อนหน้าว่าใช้ประมาณเท่าไหร่ แต่ถ้าของทีมผม โดยส่วนใหญ่ การรันเทสรอบสอง จะใช้เวลาลดลงมาครึ่งนึงของการ run test รอบแรก และรอบถัดๆมาก็จะใช้เวลาลดลงไปเรื่อยๆ เนื่องจากจำนวนเทสเคสที่ใช้รันโดยปกติแล้วจะลดลงในแต่ละรอบ ส่วนจำนวนรอบที่น่าจะมีการรันเทส ก็คงต้องดูจากสถิติและความน่าเชื่อถือจากทีม Dev นั่นแหล่ะครับ

4. ให้ team member ทุกคน list แปลนวันลา วันหยุด วันที่มีเทรนนิ่ง ของตัวเองออกมาให้หมด รวมถึง test leader เช็ควันหยุดประจำปีของบริษัท และ event ต่างๆที่อาจเกิดขึ้นในช่วงระยะเวลาโปรเจคไว้ให้หมดด้วย เช่น party ประจำปี การประชุมประจำเดือน อะไรพวกนี้

5. Test leader ต้องคิดคำนวนว่า วันนึงจะให้ tester ทำงานกับโปรเจคนี้วันละกี่ชั่วโมง โดยปกติผมจะคิดให้น้องๆทำงานวันละ 6-7 ชั่วโมง ส่วน 1-2 ชั่วโมงที่เหลือจะเผื่อไว้ให้สำหรับ การเช็คเมล ประชุม และอื่นๆ ต่างๆนาๆ

6. Test leader, Dev leader และ Project manager ช่วยกันร่างวันที่เป็น schedule ตาม Calendar โดยดูจากจำนวนชั่วโมงของเนื้องานที่ estimate มาร่วมกับ จำนวน Tester ที่จัดสรรค์ให้ทำงานในโปรเจค รวมถึง วันลา วันหยุด และวันที่มีเทรนนิ่ง ที่แต่ละคนระบุไว้ โดยคิดจากจำนวนชั่วโมงทำงานต่อวันด้วย

7. สุดท้าย ให้ทุกคนใน project team ช่วยกัน review แปลนที่ร่างขึ้นมาก่อนที่จะ issue แปลนนั้นและนำมาใช้ในการ Track Project นะครับ

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

สำหรับบางคนที่ยังไม่รู้นะครับ แค่เรื่องของการ estimate เองก็มี Technique มากมายหลายวิธีแล้วเช่น Historical Data, PERT, Finger in the air, etc…

เสริมเรื่องการ estimate effort แยกเป็นแต่ละ requirement นะครับ ว่ามีประโยชน์อย่างไร คือโดยปกติแล้วเวลาลากแปลนออกมาจากที่เรา estimate effortไว้เนี่ย PM มักจะบอกเสมอว่าออกมานานเกินไปลูกค้าต้องการเร็วกว่านี้ ทำให้โปรเจคเสร็จเร็วกว่านี้ได้มั๊ย ถ้าเป็นผม ผมจะกางข้อมูลของการ estimate ให้ดูเลยครับว่าแต่ละrequirementใช้เวลาในการเขียนเทสเคสเท่าไหร่ เขียน test tool เท่าไหร่ รันเทสเท่าไหร่ effortรวมทั้งหมดเป็นเท่าไหร่ ทีนี้ถ้าอยากให้เร็วขึ้น อยากเลือกเอา requirement ไหนออกก็เอาเลย พูดง่ายๆคือให้เลือก shopping เอาได้เลยครับ เพราะบาง requirement ใช้เวลา implement และ test นานมากทั้งๆที่เป็น requirement ที่ไม่จำเป็นสำหรับลูกค้าเลย ทีนี้พอเห็นข้อมูลแยกออกมาให้อย่างนี้ก้อทำให้ Project Manager เลือก Requirement เข้าหรือออกจากโปรเจคได้ง่ายหน่อยครับ และเรายังไม่ต้องบีบเวลาในการทำงานของตัวเองด้วย

ต้องขออภัยสำหรับความยาวของบทความด้วยนะครับ พอเขียนแล้วมันก็ไหลไปเรื่อยเลยมีเรื่องเสริมมาเยอะ ขออภัยในภาษาเขียนที่ปะปนกันทั้งภาษาไทยและภาษาอังกฤษด้วยนะครับ