“Test อย่างไรให้ครอบคลุม?” ถ้าสำหรับผมละก็เป็นคำถามสุดฮิตแทบจะว่าได้ ไม่ว่า Project Plan จะทำออกมาสวยหรูขนาดไหน แต่ระหว่างการพัฒนา Software ไปเรื่อยๆ ก็จะมี Revise กันอย่างน้อยก็ 3 รอบ เกิดอะไรขึ้นหลังจากนั้นบ้าง
“วัน Launch Project ขยับไม่ได้จริงๆ”
“Scope กับ Requirement มันเพิ่ม เลยต้องขยับ Plan ของ Development Team ออก”
“ทีม Test ลดวันลงหน่อยได้ไหม ช่วยๆ กันนะ”
โอวววว…แม่เจ้า…พูดกันเหมือนยังกับขายของเลย แต่สุดท้ายถ้า Project Owner หรือ Project sponsor ฟันธงลงมาแล้วว่าห้ามขยับวัน Launch Project เท่าที่ประสบพบเจอมา หวยจะมาออกที่ขั้นตอนของ Software Testing Phase
หัวอกของ Tester, Test Lead หรือแม้แต่ Test Manager จะทำไงได้ เมื่อเบื้องบนฟันธงลงมาแล้วแบบนั้น?
“เป้าหมายมีไว้เพื่อท้าทาย ใช่มีไว้เพื่อต่อรอง”
“อย่าหาเหตุผลมาอ้างว่าจะทำไม่ได้ แต่หาเหตุผล และหนทางดูว่าจะทำไงให้สำเร็จสู่เป้าหมาย”
เป็นคำพูดของครูคนหนึ่งของผม ก็ลอยเข้ามาทันที
ดังนั้นมาพิจารณากันดูว่า ในเวลาที่จำกัด เหล่า Tester, Test Lead และ Test Manager ทั้งหลาย เราจะทำไงดีเพื่อให้จะสามารถ Test ให้ครอบคลุมมากที่สุดเท่าที่จะเป็นไปได้
ต้องยอมรับจริงๆ ว่าเป็นเรื่องยากมากที่จะสามารถทำการ Test ได้ครอบคลุม ทุกๆ Features / Functions/ Requirement / Logic ในเวลาที่มีจำกัด ถึงแม้จะเติม Tester ลงไปก็ตาม เราเองต้องกลับมานั่งพิจารณา และระดมสมองกันแล้วว่าจะจัดลำดับ หรือเลือกหยิบอะไรขึ้นมา Test ก่อน และหลังบ้าง ซึ่งก็ต้องอาศัยเรื่องของความรู้ความสามารถที่มี (Skill), สามัญสำนึก (Common Sense) และประสบการณ์ (Experience) มาประกอบการตัดสินใจ ประกอบกับหลักการพิจารณาดังนี้
- Function อะไรบ้างที่มีความสำคัญที่สุดใน Project
- Function อะไรบ้างที่ Users จะใช้งานบ่อย
- Function อะไรบ้างที่มีผลกระทบกับ Users มากที่สุด
- Function อะไรบ้างที่เกี่ยวกับเงินๆ ทองๆ ที่สัมพันธ์กับ Users
- Functions หรือ Features ใดบ้าง ที่สามารถส่งมาทำการ Test ได้ก่อนในช่วงพัฒนา Software
- Coding ส่วนใดบ้างของ Software ที่มีความซับซ้อนมาก และมีวี่แววว่าจะมี Error แน่แน่
- Functions หรือ Features ใดบ้างที่ถูกพัฒนาออกมาแบบร้อนๆ ด่วนๆ อันนี้มี Error แน่แน่
- ส่วนใดบ้างของ Project นี้ ที่มีความคลายคลึงหรือสัมพันธ์กับปัญหาของ Project ก่อนหน้านี้
- Requirement หรือ Solution Design ส่วนใดบ้างที่คลุมเครือ ไม่ชัดเจนบ้าง
- Functions หรือ Features ใดบ้างในมุมของ Developer คิดว่ามันมีความเสี่ยงที่จะมี Error หรือทำงานผิดพลาด
- ปัญหาใดบ้างที่จะโดน User บ่น ตำหนิ ติ แน่แน่
- ปัญหาใดบ้างที่รับไม่ได้ หรือจะสร้างผลกระทบมากมายหลังจากเอาขึ้น Production
- ออกแบบการ Test หรือ Test แบบใดบ้าง ที่จะสามารถครอบคลุม Functions ได้มากที่สุด
หวังว่าเหล่า Tester, Test Lead และ Test Manager น่าจะพอจะนำไปใช้ประโยชน์ ในงานได้ ไม่มากก็น้อยครับ หรือมีอะไรจะเพิ่มเตืมเข้ามา ก็ใส่ในส่วนของความคิดเห็นได้เช่นกัน
February 2nd, 2008 at 1:06 pm
ที่บอกมาทั้งหมดนี้ สรุปว่า ต้องเทสหมดเลยอ่ะ แล้วจะจัด priority งัยดีน้ออออ
February 2nd, 2008 at 5:56 pm
share ของที่ทำงานนะครับ
เคยคุยกันไว้ว่า
เรา estimate เอาไว้ว่า test กัน 10 วัน
แล้วถูก task ก่อนหน้า delay มา เช่น ส่ง program มาให้ test ช้า
จนล้ำเขตแดน 10 วันของเรา
ถ้าเราตอบว่า เหลืออีก 5 วัน ทำได้ แบบง่ายเกินไปไม่มีเงื่อนไข
งานต่อไป PM หรือ user จะเพ่งเล็ง และบอกว่า
ครั้งก่อนขอไว้ 10 วันแต่ 5 วันก็ทำได้นี่นา
งานนี้ 5 วันละกันนะ project ฉันจะได้รีบขึ้น
ถ้าเกิดการรุกล้ำเขตแดนแบบนี้ จะให้ project board ตัดสินใจ
โดย จะ raise เป็น issue ของ project
แจ้ง risk ของ project ให้ทาง project board ทราบ
แล้วก็ให้ option ให้ project board เลือกว่า
1. ขอยืนยัน 10 วันเหมือนเดิม นั่นหมายถึง PM ต้อง revise plan
2. 5 วันได้ แต่ขอเพิ่ม resource (หากเวลายังพอเหลือให้ทำได้)
3. 5 วัน resource ไม่เพิ่ม ทำ 24 ชั่วโมง ยังไงก็ไม่พอ …
ช่วยกัน list test scenario ให้ user หรือเราจะเลือกให้ user ดูอีกทีก็ได้ว่า
จะ test อันไหนก่อนหลัง ในเวลาอันจำกัด เอาเท่าที่เวลาอำนวย
พอ project board เลือกว่าจะเอา option ไหนก็ทำตามนั้นครับ
February 8th, 2008 at 7:56 pm
โอ้ววว….ได้ยินคำพูดนี้แล้วมึนตึบ….
ทำงานเป็น tester แรกๆ ถ้าได้ยินคำนี้…หัวสมองก็จี๊ดด…โดยทันที…เอาอะไรคิดกันเนี่ยะ…รู้อยู่ล่ะ ว่ามันเป็นไปไม่ได้ๆๆๆ
แต่แล้วก็กลับมาก้มหน้าก้มตาทำงานให้เสร็จให้ทันเวลา..จนไม่ได้เห็นเดือนเห็นตะวัน…..เหมือนเช่นเคย…
จะมีข้อแม้…ก็เพียงแค่… “ขอคนมาช่วย support แล้วกัน ถ้ามีปัญหา งานจะได้เสร็จเร็วๆ” (โอ้ววฉานน….ตอนนั้นทำได้ดีที่สุดเท่านี้)
จากความกดดันมากมาย…ทำให้เหล่า tester มีชีวิตอย่างไม่เป็นสุข…
แต่จากเหตุการณ์พวกนี้เอง..มันก็ทำให้สิ่งดีๆ ใหม่ๆ เกิดขึ้นมากมาย…(ด้วยความช่วยเหลือของอัศวินม้าขาว…ผู้ที่เข้าใจว่า process คืออะไร)
ต่อไปนี้…Tester จะไม่เป็นเพียงผู้รับทำตามคำสั่งเท่านั้น …. เราจะเป็น lead ใน area ของเรา ทำหน้าที่ test lead ตาม role ได้อย่างเต็มที่
โอ้ววว(อีกครั้ง)..ความเป็น profressional เริ่มเข้ามาใกล้ล่ะ……อิอิ
จากการฝึกฝนด้านการเจรจาต่อรองกับ PMO,PM , User ,BA, developer และการ Manage test อยู่ระยะหนึ่ง ก็เริ่มรู้สึกว่ารอยหยักในสมองเริ่มมีมากขึ้น..
งานของเรา..ก็สำคัญใช่เล่นนะเนี่ยะ….การทำงานแข่งกับเวลา..และได้งานที่มีคุณภาพด้วยถือว่าเป็นเรื่องที่ท้าทายดีเหมือนกัน
เกริ่นซะยาว..(ด้วยความโดน) จะเข้าเรื่องล่ะนะ..
สรุป..
เราก็แก้ปัญหาคล้ายๆ พวกท่านที่ว่ามาเลย…(ไม่ได้ช่วยทำอะไรให้ดีขึ้นเล้ยย…555)
แต่เรายังยืนยัน..ว่าเราจำเป็นต้อง test ให้ได้ตาม scope ที่ design ไว้ตั้งแต่แรก ด้วยเวลาที่เท่าเดิมในครั้งแรกที่ estimate ไว้
แต่ถ้าเรื่องเวลาเป็นปัญหา…และเรื่อง quality เป็นปัญหาด้วยป่าว…แน่นอนทุกคนก็ต้องพูดเป็นเสียงเดียวกัน…”สำคัญแน่นอน”
แต่ถ้าเราต้องทำงานในสภาวะแบบนี้บ่อยๆ…สภาวะที่เวลา..ดูเหมืนอจะนำเรื่องคุณภาพ…ก็แอบมีคำถามในใจเหมือนกัน..แล้วงานเราจะมีคุณภาพได้อย่างไร
เราคงต้องวิเคราะห์และนำเสนออะไรในแง่ความเป็นจริง…คงหยวนเพื่อใครไม่ได้…แต่เราจะทำให้ดีที่สุด…ในหน้าที่ของเรา…
งาน QC เป็นอะไรที่ตรงๆ อยู่แล้ว…..ก็ว่ากันไปตามเนื้อผ้า….
February 8th, 2008 at 10:19 pm
ถูกต้องครับ
หัวหน้าย้ำเสมอว่า “Quality cannot be compromised”
February 8th, 2008 at 10:58 pm
มาแว้ววว Wipaday คู่ยาก ท่าทางอยากระบายนะเนี่ย ปรึกษากับท่านประธานเวบละ เด๋วจะเปิดหัวข้อให้เฉพาะเลย
ดีใจด้วยนะตอนนี้รอยหยักพัฒนาแล้วววว :surrender:
สงสัย บทความนี้โดนใจเอามากก จนเขียนผิดๆถูกๆไปเลยนะเนี่ย ว่า แต่ profressional มันแปลว่าไรอ่ะ
:disbelief: :disbelief: :threaten:
February 9th, 2008 at 1:04 pm
ซะงั้น…leeyongson… :love:
February 13th, 2008 at 6:02 pm
อย่าประมาทเมื่อพบงานง่าย อย่าท้อใจเมื่อพบงานยาก :#1:
ทำ test แล้ว project on production ได้อย่างมั่นใจ ข้อผิดพลาดน้อยที่สุด
เราคน IT ด้วยกัน เห็นใจกันครับ
:cries: :cries: :cries: ทำไมต้องมาทำกับทีมเทสแบบนี้ด้วยอ๊ะ :slap:
March 13th, 2008 at 5:54 pm
ทำใจ เป็นคำตอบ สุดท้าย :#1:
May 3rd, 2008 at 4:07 pm
หนูสู้ถึงที่สูดดดดดดดดดดดด เพื่อกินแมลง