ทำอย่างไรถ้าเวลาสำหรับ Software Testing เหลือนิดเดียว
เพื่อนพ้องน้องพี่ทั้งหลายคงจะเจอกับประโยคสุดยอด Classics เหล่านี้
“วัน Launch Project ขยับไม่ได้จริงๆ”
“Scope กับ Requirement มันเพิ่ม เลยต้องขยับ Plan ของ Development Team ออก”
“ทีม Test ลดวันลงหน่อยได้ไหม ช่วยๆ กันนะ”
สิ่งที่ตามมาคือคำถาม “ถ้าเวลามีจำกัดจะ Test อย่างไงดีให้ครอบคลุม?”
2 กุมภาพันธ์ 2552
ผมได้เขียนบทความเรื่องนี้ไว้ “ถ้าเวลามีจำกัดจะ Test อย่างไงดีให้ครอบคลุม?” เพราะได้ไปประสบพบเจอจากเว็บไซต์เมืองนอกเมืองนามา บวกกับตอนนั้นได้ผ่านพ้นปัญหาเรื่องพวกนี้มา ก็เลยลองหยิบยก เอามาแบ่งปันให้เพื่อนพ้องน้องพี่ เผื่อว่าจะมีประดยชน์ไม่มากก็น้อยกับเพื่อนพ้องน้องพี่หลายๆ ท่านครับ ซึ่งพอจะสรุปได้ดังนี้
- 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 ได้มากที่สุด
9 มกราคม 2553
คุณ Kannique เพื่อนพ้องของเราชาว welovebug มาแสดงความคิดความเห็นไว้ ใน บทความ “ถ้าเวลามีจำกัดจะ Test อย่างไงดีให้ครอบคลุม?” ไว้ดัวนี้
ขอบคุณสำหรับบทความดีๆครับผมจากประสบการณ์ของผม ส่วนมากแล้วสถานการณ์ที่เกิดจะเป็นว่ามีเวลาจำกัดในการ Test แถม Scope เพิ่มด้วยอะฮะ แต่แนวทางที่ช่วยผ่อนหนักให้เป็นเบาก็มีบ้างนะครับ ตามหลักการ Time = Scope + Quality + Resources1. เพิ่ม Resource: มองซ้ายมองขวาไม่เห็นใคร ก็คว้าเอา Developer มาช่วยเราซะเลย … ช่วย Run Test พอนะ งานเขียน Test Spec กับการเตรียม Test Data ก็ยังเป็นของเราอยู่ครับ2. ลด Quality: ก็อาจจะต้องต่อรองของลด Quality ลงบ้างครับ แต่ทำอย่างมีหลักการนิดนึง อย่างแรกที่ผมจะพิจารณาก็คือการลดระดับการทำ Cross Platform Testing ลงไปครับ โดยเน้นไปที่ส่วนที่สำคัญจริงๆก่อน (อย่างที่คุณ Zyracuze บอกไว้ในบทความครับ)หลังจากที่ลองให้วิธีการนี้ในหลายๆงานที่ผ่านมา (คือมีปัญหาตลอดอะฮะ ฮ่าๆ) ก็ได้ผลเป็นที่น่าพอใจนะครับ งานมีคุณภาพใช้ได้และเสร็จทันเวลาครับ
คุณ Kannique มี Blog ส่วนตัวที่เขียนเกี่ยวกับ Project Management กับ Software Development Process และก็มีหลายๆ บทความที่เกี่ยวข้องกับเรื่องของ Software Testing และ Software Quality ผมก็เลยติดต่อไปเพื่อขอนำบทความของ คุณ Kannique มาเผยแพร่ต่อผ่านทาง welovebug ซึ่งก็ได้รับอนุญาติจากคุณ Kannique และต้องขอขอบคุณ ไว้ ณ ที่นี้ด้วยครับ
ทำอย่างไรถ้าเวลาสำหรับ Software Testing เหลือนิดเดียว
“ทำอย่างไรถ้าเวลาสำหรับ Software Testing เหลือนิดเดียว” เป็นบทความที่ว่าด้วยเรื่องของการบริจัดการเรื่องของการ Test เมื่อมีเวลาจำกัด จากประสบการณ์ของคุณ Kannique เขียนไว้ที่ Chapterpiece.com ผมก็เลขขออนุญาตินำมาเผยแพร่ต่อบน welovebug แบบสรุปๆ ดังนี้ครับ
เคยเจอปัญหาแบบนี้มั้ยครับ?
เช้าวันหนึ่ง ณ บริษัทซอฟท์แวร์เฮ้าส์
พี่ PM: น้อง QA พี่เพิ่งได้อีเมล์จากลูกค้ามาขอเพิ่ม requirement มาตัวนึง กับแก้ของเก่าตัวนึง
น้อง QA: หรอพี่ แล้วทางฝั่ง Dev เค้าว่าไงหละฮะ?
พี่ PM: ทางนั้นเค้าก็ไม่อยากทำหรอกนะเพราะ release date ก็ใกล้เข้ามาแล้ว แต่มันก็เลี่ยงยาก
น้อง QA: ถ้ามันเลี่ยงไม่ได้ ทางผมเองก็คงต้องเอางานมาดูแล้ว estimate effort ใหม่ก่อนฮะ
พี่ PM: คือ … จริงๆแล้ว ผู้ใหญ่เค้าก็กำชับมาว่าห้ามเลื่อนวัน release อยู่ดีอะน้อง
น้อง QA: อ่าว …
คุณ Kannique ได้นำเสนอวิธีแก้ไขหรือผ่อนหนักให้เป็นเบาอยู่ 3 วิธี จากประสบการณ์ของ คุณ Kannique ดังนี้
- เพิ่ม Resource ได้ทันใจ
- ลด Quality อย่างมีสไตล์
- เพิ่ม Time ด้วยการลด Time
เพื่อนพ้องน้องพี่หลายๆ คนคงจะแอบสงสับว่า 3 วิธีการที่ คุณ Kannique นำเสนอมานั้นมันเป็นอย่างไร ???
ผมไม่ขอนำ Copy และ Paste ลงบน welovebug ละกันนะครับ มันดูไม่แจ่มเท่าไร เลยขอให้เพื่อนพ้องน้องพี่ตามต่อไปที่
“ทำอย่างไรถ้าเวลาสำหรับ Software Testing เหลือนิดเดียว” โดย คุณ Kannique
ของเขาดีจริงๆ ครับ ผมขอ Confired 
ประสบการณ์จากเพื่อนพ้องน้องพี่ท่านอื่นๆ
นอกจากคุณ Kannique แล้วนั้น ก็ยังมีเพื่อนพ้องน้องพี่ท่านอื่นๆ ที่ร่วมแวดงความคิด ความเห็น และแบ่งปันประสบการณ์จากการทำงานเมื่อต้องเผชิญหน้ากับเรื่องของ เวลาในการทำ Test ที่เหลือนิดเดียวครับ
พี่ Mike แบ่งปันไว้เมื่อ 2 กุมภาพันธ์ 2552
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 ไหนก็ทำตามนั้นครับ
คุณ Wipaday แบ่งปันไว้เมื่อ 2 กุมภาพันธ์ 2552
อ้ววว….ได้ยินคำพูดนี้แล้วมึนตึบ….
ทำงานเป็น 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 เป็นอะไรที่ตรงๆ อยู่แล้ว…..ก็ว่ากันไปตามเนื้อผ้า….
แก้ปัญหานี้แบบไหนดี?
ผมว่ามิใช่เพียงแค่ ผม, คุณ Kannique, พี่ Mike และคุณ Wipaday เท่านั้นที่เจอปัญหา และวิธีการรับมือกับเรื่องของ Time ที่มีสั้นลง รวมทั้ง Resources ที่มีจำกัด
บทความของวันนี้ ผมเรียกว่า นำของเก่ามาปัดฝุ่นหากิน อีกรอบครับ และจะขอปิดท้ายไว้ด้วยคำถามว่า
“เพื่อนพ้องน้องพี่มีวิธีการแก้นับมือเมื่อเวลาสำหรับ Software Testing เหลือนิดเดียว อย่างไร?“
ร่วมแบ่งปัน ความคิด ความเห็น และประสบการณ์ผ่านทาง Comments ของบทความนี้ได้ครับ
Testing does not Finish, It’s just STOP!
โอ้ว…ได้อ่านแล้ว..จะนับไปประยุกต์ ขอรับ…
ประสบการณ์สุดยอดเลยครับ ขอบคุณมากครับสำหรับความรู้ และข้อคิดดีดี ผมเริ่มงานแรก คือ software test engineering คงต้องใช้ความรู้ของพี่ ๆ มาช่วยเยอะ ๆ ละครับ
ขออนุญาตประชาสัมพันธฺ์ข่าวค่ะ ITPC เปิดอบรม หลักสูตร “ISEB Software Testing Foundation” เพื่อเตรียมความพร้อมสู่การพิชิต ISEB Foundation Certificate ซึ่งเป็นมาตรฐานที่ได้รับการยอมรับในระดับสากลมากที่สุดในการบ่งชี้ วัดถึงความสามารถและความเข้าใจพื้น ฐานสำคัญทั้งหมดของ Software Testing โดยวิทยากรผู้เชี่ยวชาญด้าน Software Testing และกูรูชื่อดังจาก Welovebug K.Ekaluck 7-8 มี.ค.54 นี้ ณ ITPC IT Training Center ชั้น 19 อาคารสีลมคอมเพล็กซ์ สนใจสอบถามเพิ่มเติม โทร. 02-2313851-9 ต่อ 620-1 http://www.itpc.co.th
[...] [...]
“ทำอย่างไรถ้าเวลาสำหรับ Software Testing เหลือนิดเดียว”
คำถามคือว่าจริงๆ เราต้องการเวลาสำหรับ test อย่างเดียวเท่าไหร่? 10 วัน? 15 วัน?
10 วันที่คาดหวังไว้ จริงๆ เป็นเวลาสำหรับ test ทั้ง 10 วันจริงๆ หรือ?
หรือว่าเป็นการ test จริงๆ แค่ 3 วันที่เหลือคือการแก้บั๊กกันแน่?
คำถามจะย้อนกลับมาถามว่า แล้วทำไมถึงปล่อยให้ test เป็นเรื่องสุดท้าย ทำไม quality ไม่ถูก built-in เข้าไปตลอด process การพัฒนา
เราเริ่มต้น test ช้ากันเกินไปหรือเปล่า?
ผมพูดอย่างนี้ ไม่ได้หมายความว่าทุกคนต้องทำ TDD, BDD กันนะ
แต่เรื่อง quality ต่างๆ เป็น cross cutting concern ที่ลากผ่านระบบ + process อยู่แล้ว
ทำไมหลายที่กลับไม่ได้เลือกที่จะแทรกคุณภาพเข้าไปในทุกกระบวนการละ?
กลับเลือกจะส่งมอบกันชุดใหญ่ตอนท้าย แล้วแก้กันตอนท้าย ตอนที่การแก้ไขต้องแลกมาด้วยค่าเสียหายราคาแพงโดยไม่จำเป็น
ผมกำลังจะบอกว่า ตราบใดที่แก้ปัญหาที่ปลายเหต ตราบใดที่คุณสมบัติ stop-the-line ไม่ได้ถูกนำมาประยุกต์ใช้ในองค์กรณ์ ก็ยากที่จะ improve quality อย่างมีนัยสำคัญ
การ stop-the-line คือการหยุดสายพานการพัฒนาเมื่อเจอปัญหาร้ายแรงทันที และแก้ไขในทันที + ออกแบบป้องกันไม่ให้ปัญหาเดิมเกิดซ้ำขึ้นอีกเป็นครั้งที่สอง
เราจะต้องการวัน test สักกี่วันกันหากทุกอย่างผ่านการ QC ในขั้นตอนของตัวเอง แล้วมีการส่งมอบเป็นระยะอยู่แล้ว?
จง Fixed Resource, Fixed Deadline, Fixed Quality แล้วปรับ Scope เอา คือกุญแจสำคัญ
เลือกสิ่งที่จำเป็นที่สุด ถามลูกค้าให้ตัดสิ่งที่ยังไม่จำเป็นออกหากรู้ตัวว่าไม่ทันแล้ว แล้วทำสิ่งที่ต้องทำให้มีคุณภาพ
สุดท้าย product ที่ได้ นอกจากจะส่งมอบทันกำหนด พอเพียง มันยัง maintain ได้ง่ายกว่าด้วย
ผมไม่ได้ตอบคำถามนี้ตรงๆ ต้องขออภัยด้วย แต่เลือกจะถามกลับว่าทำไมวันที่เหลืออยู่ไม่พอ มันไม่พอเพราะมันมาพร้อมกันมากเกินไป หรือสายเกินไปหรือเปล่า ทำไมถึงเป็นเช่นนั้น เพื่อให้คิดไปที่ต้นตอของปัญหาว่า เราพลาดอะไรไปหรือเปล่า
เรื่องนี้ต้องอาศัยการร่วมมือกัน สื่อสาร และสอดรับกันหลายฝ่าย เป็นปัญหาเกี่ยวกับกระบวนการการพัฒนาที่ต้องถูกปรับปรุง ไม่ใช่เรื่องที่แผนกหนึ่งหรือคนเพียงส่วนหนึ่งสามารถแก้ไขได้ด้วยตัวเองฝ่ายเดียว แต่จะต้องร่วมมือกันเพื่อให้สอดคล้องไปด้วยกันถึงจะทำได้ครับ
ขอบคุณครับดีน สำหรับ มุมมองของ Developer ครับ
เชิญลงชื่อ พูดคุยเรื่อง “ทำอย่างไรถ้าเวลาสำหรับ Software Testing เหลือนิดเดียว” ได้ที่นี่ครับ http://bit.ly/c27Ucg
หนุ่มครับ หาเวลาสักครึ่งวัน share เรื่อง “ทำอย่างไรถ้าเวลาสำหรับ Software Testing เหลือนิดเดียว” เพราะจะได้ประสบการณ์จากหลาย ๆ ท่าน ซึ่งสามารถนำไปปรับใช้งานการทำงานได้จริง ๆ ค่ะ
จัดให้ครับพี่อิ๋ว ผมก็คิดเหมือนกันว่าน่าจะจัดครับ บ่ายๆ จะเปิดเรื่องแล้วให้แต่ละท่านมาลงชื่อว่าสนใจมาคุยกันเมื่อไร ที่ไหนครับ
ถ้าผมจะเป็นส่วนหนึ่งของการพูดคุยก็ยินดีครับ ผมจะได้เอาแนวคิดของเพื่อนๆคนอื่นไปใช้ด้วย
ผมอยู่แถวลาดพร้าวครับ ส่วนมากแล้วเสาร์บ่ายไม่ว่างครับ ถ้าเป็นวันอาทิตย์น่าจะได้ฮะ
สวัสดีครับคุณวีระยุทธ(ฺBee),
ขอบคุณมากสำหรับคำแนะนำครับ ผมคิดว่าเป็นวิธีการที่น่าจะใช้ได้จริงเลยหละฮะ แต่มีข้อสงสัยนิดนึงตรงที่ว่า
“หลังจาก Assign Risk Weight แล้วก็ให้เก็บมันเอาไว้อย่างนั้น ห้ามเปลี่ยนเด็ดขาด” เท่าที่ผมเข้าใจคือว่า Risk Factor ของงานจริงๆมันไม่ได้เป็นค่าตายตัวตลอดเวลาอะครับ เช่น ถ้าเรามองว่า หนึ่งใน Risk Factor ของ Feature นี้คือ Availability of Technology Expertise ถ้าเวลาผ่านไปทีมเรามีความรู้และประสบการณ์มากขึ้นใน Technology ที่ใช้ ค่า Risk Factor ตัวนี้ควรจะลดลงรึเปล่าครับ? เป็นไปได้หรือไม่ครับที่เราจะมีการ Review Risk Score ทุกครั้งที่จะจบโปรเจก หรือเริ่มโปรเจกใหม่ครับ?
ถ้านับ Project Management Areas ผมสนใจเรื่อง Risk Management มากที่สุดเลยครับ โปรเจกจบปริญญาโทก็เป็นงานที่เกี่ยวกับเรื่องนี้ ดีใจที่มีคนสนใจเรื่องเดียวกันครับ
ขอบคุณครับ
Risk Weight ที่ผมบอกเอาไว้ว่าให้เก็บเอาไว้อย่าเปลี่ยนเด็ดขาด ก็เพื่อให้สมาชิกของทีมทุกคน มีความเข้าใจในความสำคัญของแง่มุมต่างตรงกัน ทำงานด้วยมาตรฐานเดียวกัน ไม่ใช่ทำงาน 2 มาตรฐานแบบที่เค้าชอบใช้กัน (นอกเรื่องนิดนึงนะครับ)
แต่ผมเองก็แนบท้ายไปด้วยว่า ยกเว้นว่ามีความจำเป็นจริงๆครับ ซึ่งโดยส่วนใหญ่แล้ว Risk weight จะเปลี่ยนแปลงจากความต้องการของลูกค้าเป็นหลัก เช่นลูกค้าไม่ได้มองว่า feature นี้สำคัญกับธุรกิจเค้าแล้ว จะดื้อทำแบบเดิมไปก็ไม่เกิดประโยชน์จริงมั๊ยครับ แต่ตัวอย่างที่ คุณ Kannique ยกตัวอย่างมาก็เป็นตัวอย่างที่ดีมากๆครับ สะท้อนให้เห็นมุมอื่นของความเสี่ยงได้เป็นอย่างดี
ตัว Risk Factor และ Risk Weighting นี้ มันเป็นความเสี่ยงเฉพาะของแต่ละ project ครับ (ในที่นี้หมายถึง Software Testing Project แต่ Project ทั้วไปก็ใช้หลักการคล้ายๆกัน) เนื่องจาก แต่ละ Project จะมีลักษณะเฉพาะที่ไม่เหมือนกัน
ดังนั้นที่บอกว่า จะมีการ Review Risk Factor ทุกครั้งที่จบหรือเริ่ม Project นั้น ส่วนตัวผมคิดว่า คงจะเน้นไปที่ตอนเริ่มโปรเจคใหม่ซะมากว่าครับ ก็คือจะมีการเรียกประชุม Stakeholder เพื่อมาช่วยกันกำหนดความเสี่ยงต่่างๆและให้คะแนน (ถ้าผมเข้าใจถูก คือคุณน่าจะคิดว่า Risk Factor นี่ใช้แบบยาวๆกันไปเลย) เพราะฉนั้นยิ่งเราทำ Project ที่ความคล้ายกับ Project ก่อนๆมากเท่าไร ความเสี่ยงโดยรวมของ Project ก็จะลดลง Risk Mitigation ทำได้ง่ายขึ้น และโอกาสที่ Project จะประสบความสำเร็จก็มาขึ้นด้วยครับ แต่ก็อย่างที่รู้กันนะครับ Project จะสำเร็จได้ ต้องมี Project Management ที่ดีพอสมควร ทำให้เหตุการณ์ไม่คาดคิดต่างๆ นั้นถูกจัดการได้ตามความเหมาะสม
สำหรับ Risk Management ผมคิดว่าเป็นสิ่งที่เราควรนำมาประยุกต์ใช้เป็น standard ได้แล้วนะครับในประเทศไทย เพราะต่างประเทศนี่เค้าก็ทำกันมานานแล้ว แล้วก็ประสบความสำเร็จกันก็มาก เรื่องพวกนี้เราตามทางฝั่งโน้นกันไม่ค่อยทัน หรือถ้าตามก็ตามแบบไม่เข้าใจในหลักการที่เป็นรากฐาน การนำมาใช้ก็เป็นแค่การอ้างอิง ไม่ได้นำมาประยุกต์ให้เกิดประโยชน์สูงสุด ตามจุดประสงค์ที่ได้ตั้งเอาไว้ ถ้าเราเข้าใจถึงหลักคิดพื้นฐานจริงๆ ในบางจุดที่เป็นจุดที่ไม่เหมาะกับงานของเรา ก็ยังสามารถพัฒนาคิดค้น ต่อยอดให้ดีกว่าของเดิมด้วยซ้ำไป
ยาวหน่อยนะครับ
ขอบคุณครับ
ขอบคุณสำหรับคำตอบนะครับ ผมเข้าใจว่า
1. การทำ Risk Based Testing คือกำหนด Test Strategy ว่า Feature ไหนมีความเสี่ยง (Risk Score) สูงที่สุดก็จะถูก Test ก่อนและ Test มากที่สุด โดย Risk Score จะจากการหา Risk Factor และ Risk Weighting ที่เกี่ยวข้องกับลูกค้าโดยตรง ซึ่ง Risk Score ที่ได้นี้จะไม่เปลี่ยนแปลงนอกจากเป็นความต้องการของลูกค้าเอง
2. การทำ Risk Identification and Analysis สำหรับ Project ที่เปิดใหม่ก็จะเริ่มทำในช่วง Project Planning โดยที่พิจารณา Risk Factor ในมุมที่กว้างกว่า เช่น Factor ต่างๆที่เกี่ยวกับ Mission and Goals, Organization Management, Customer/User, Project Parameters เป็นต้น ซึ่งค่า Risk Score นั้นสามารถเปลี่ยนแปลงได้ เช่น Risk Factor ที่เป็น Availability of Technology Expertise ถ้าเวลาผ่านไปทีมเรามีความรู้และประสบการณ์มากขึ้นใน Technology ที่ใช้ ค่า Risk Factor ตัวนี้จะลดลง
ถูกต้องมั้ยครับ? ขอบคุณครับ
เป็นการพูดคุยที่ได้รสได้อารมณ์ดีมากเลยครับ ในคำถามของคุณ Kannique นั้นมีหลายประเด็นย่อยที่แอบๆอยู่ ยังไงก็ลองดูคำตอบด้านล่างดูนะครับ
ตอบข้อ 1
1. โดยทั่วไปแล้ว ถูกต้องครับที่เราจะทำการทดสอบ Feature ที่มีความเสี่ยงสูง หรือมีผลกระทบสุงก่อน หากมีข้อจำกัดด้านทรัพยากรเข้ามา แต่ถ้าไม่ได้มีข้อจำกัดหรือ unplanned incidence เราก็จะดำเนินการตามแผนที่ได้วางเอาไว้แต่แรกครับ เพื่อให้ flow ของงานไหลลื่นที่สุด เพราะการ Test นั้นบางครั้งต้องมีการทำเป็นลำดับขั้นตอน มีการส่งต่อผล เพราะแต่ละส่วนอาจจะมีการทำแบบ Parallel หรือไม่ก็ Overlap กันอยู่
และตัวที่มี Risk Score สุงๆ สมาชิกในทีมต้องตระหนักว่าควรจะทุ่มเทพลังงานในส่วนนี้เยอะๆ ทำ test case ให้ละเอียดขึ้น ออกแบบ Test Data ให้ครอบคลุมยิ่งขึ้น จากที่เมื่อก่อนเราอาจจะคำนวนเวลาตามขนาดของ Feature เราก็ใช้ตัวนี้มาช่วยได้อีกทางหนึ่ง
Risk Score นั้น เป็นค่าเฉลี่ยของ Risk Weight ที่กำหนดให้กับ Risk Factor นั้นๆครับ ยกตัวอย่างเช่น Function 1.4.2 Register New User มี Risk weight เป็น 100, 57 และ 90 Risk Score ก็จะเป็น 82.3 ยกเว้นในกรณีที่เรามีการถ่วงน้ำหนักไว้ที่ Factor ตัวใดตัวหนึ่งมากเป็นพิเศษ ก็เพิ่มตัวคูณ ไปตามเรื่องตามราว
Risk Score หลีกเลี่ยงไมไ่ด้ที่จะเกี่ยวข้องกับลูกค้าโดยตรง เพราะว่า Project มันเกิดขึ้นมาได้ ก็จาก Need ของลูกค้าจริงมั๊ยครับ แล้วถึงกลายเป็น requirements และ (Non)Funtional specs ของระบบ แต่ก็ไม่ได้หมายความว่าคนที่จะให้คะแนนได้จะเป็นลูกค้าแค่ส่วนเดียว เพราะในส่วนที่เกี่ยวข้องกับ Functional Specs หรือ Design คนที่จะรู้ดีที่สุดก็คือ PM, System Architecture หรือ ระดับ Head ของส่วนงานต่างๆ ที่จะมองออกถึงผลกระทบที่น่าจะเกิดขึ้นกับลูกค้าว่ามันรุนแรงแค่ไหน ส่วนลูกค้านั้นจะบอกเราได้แค่ว่า Requirement แต่ละอันมีความสำคัญกับเค้ามากน้อยแค่ไหนเท่านั้นเองครับ (ยกเว้นลูกค้าเป็นเซียน เช่นเราไป outsourcing ให้)
ตอบข้อ 2
ที่เข้าใจถูกต้องเลยครับ แต่่น่าจะใช้ได้กับ Software Project ปกติ และยิ่งใช้ได้ดีกับ Project ที่มีระยะเวลาค่อนข้างนาน การ update score ต่างๆเหล่านี้ ก็จะทำให้ PM นั้นรู้ตื้นลึกหนาบางของ Project ได้ทันกับเหตุการณ์ปัจจุบันมากที่สุด
แต่คำตอบที่ผมได้ตอบไปนั้นเป็นลักษณะของ Software Testing Project ซึ่งเมื่อเวลาผ่านไปนั้น การจะไปปรับเปลี่ยนตัว Score คงจะไม่เหมาะสม เนื่องจากการ Test Plan นั้นจะสับสนไปหมดและต้องมีการ Review กันใหม่ อาจถึงขั้นวาง Test Strategy ใหม่กันเลยทีเดียว แต่ก็ไม่ใช่ว่าจะห้ามเปลี่ยนถ้าหากว่าลูกค้านั้นมีความต้องการจริงๆ เช่น บาง Feature อาจจะไม่สำคัญกับเค้าแล้ว หรือลูกค้าต้องการเพิ่ม Function ให้กับ Feature ทำให้มันมีความซับซ้อนมากขึ้น และไม่ได้อยู่ Expertise Skill Area
ข้อสำคัญก็คือ สิ่งเหล่านี้จะไม่เกิดขึ้นเลย ถ้าเรามีระบบ Project Management ที่ดีตั้งแต่เริ่มต้น และ Change Management นั้นทำได้อย่างมีประสิทธิภาพ การกำหนด Risk Factor, Risk Weight, Risk Score ก็จะทำเพียงแค่น้อยครั้งมากๆ แล้วก็ใช้อ้างอิงได้ไปจนจบ Project
รายละเอียดของ Risk Based Testing นั้นมีเยอะพอสมควรครับ หากแต่เราควรเลือก เฉพาะที่จำเป็น และเหมาะสมกับ Testing Project นั้นๆ ซึ่งจะทำให้เราได้ผลงานที่มีทั้งประสิทธิภาพและประสิทธผล จากแรงงานและเวลาน้อยที่สุดเท่าที่จะเป็นไปได้ ไม่จำเป็นที่เราจะต้องตาม Standard หรือ ทฤษฎี ทั้งหมด เพราะสิ่งที่ดีที่สุด ก็คือสิ่งที่เหมาะที่สุดกับสภาพแวดล้อมนั้นๆ นำไปใช้งานได้จริง และสามารถวัดผลได้
ผมชอบ Slogan ของ Microsoft อันนึงครับ และก็ใช้เป็นหลักคิดมาจนทุกวันนี้
“Do more with less” ถ้าเราสังเกตการทำงานของเราในทุกๆงาน เราจะพบเห็นสิ่งเล็กๆน้อยที่จะพัฒนาปรับปรุงได้เสมอ และจะส่งผลให้เราใช้แรงน้อยลงแต่ได้งานเท่าเดิม เหลือเวลาไปทำอย่างอื่นได้อีกเยอะแยะเลยครับ
ขอบคุณครับ
ขอบคุณมากครับสำหรับคำอธิบาย
ผมจะลองเอาไปใช้ที่ทำงานด้วยครับ
ขอบคุณครับ วีระยุทธ (Bee77) สำหรับความเห็น และมุมมอง ดีๆ ครับผม
คนเดียวกันนะครับ แต่ตอนแรกตอบแบบไม่ได้ log in
จุดประสงค์หลักๆที่อยากจะเน้น ว่ามันจะได้เมื่อประยุกต์ใ้ช้ Risk Based Testing ก็คือ
เราจะใช้เวลาที่มีอยู่ได้อย่างคุ้มค่าที่สุด ได้ทำงานในส่วนที่สำคัญก่อนเสมอ หรือ First Thing First เพราะฉนั้นไม่ว่าเวลาจะลดจาก หนึ่งเดือนหลือเพียง 2 วัน เราก็ยังสามารถบอกตัวเองได้ว่าควรจะรับมืออย่างไรดี
และเราจะเข้าใกล้ Testing Project Management ที่สมบูรณ์ มากที่สุด เพราะว่า เหตุการณ์ไม่คาดคิดต่างๆที่เป็นความเสี่ยงของโปรเจ็ค ก็จะถูกจัดการอย่างถูกต้องเหมาะสม เหมือนเรามีการทำ Risk Mitigation ไปแล้วตั้งแต่เริ่มต้น ดังนั้น unplanned incidence ก็จะลดลง
แต่ในบางครั้ง การที่เราสามารถจะปรับเปลี่ยนกระบวนท่า ให้ไหลลื่นได้กับทุกสถานการณ์ ก็ต้องยืนอยู่บนหลักความเป็นจริง เวลาที่น้อยลง ย่อมแลกมาด้วย คุณภาพของงาน หรือ Quality ที่ลดลงตามไปด้วย ตรงนี้เป็นจุดที่ค่อนข้างละเอียดอ่อนมาก และต้องมีการทำความเข้าใจระหว่าง Tester และฝ่ายอื่นๆด้วย ว่า Scope ที่เราสามารถ Cover และคุณภาพของงานนั้นมันจะออกมาในรูปแบบไหน แล้วก็พยายามประสานงานกัน ให้ความผิดพลาดที่ไม่ได้คิดเอาไว้นั้นมันเกิดขึ้นน้อยที่สุด จะว่าไปแล้วทุกอย่างมันก็เริ่มตั้งแต่ Phase แรกของ Software Project นั่นแหละครับ ไอ้พวก Bug ที่เราเจอกันทุกวันนี้ มันก็หลุดมาจากแถวนั้นทั้งนั้น Fix Cost ก็เลย เลยเถิดกันไปไกล
หากเราบอกว่าค่าของคนนั้นอยู่ที่ผลของงาน ค่าของ Tester ก็อยู่ที่ Matrix หรือ Ratio ต่างๆที่ใช้วัดผล ไม่ได้วัดกันที่ความรู้สึกว่า Test ได้ดี Test ได้มาก คงต้องเค้าค่าต่างๆมาดูกัน เช่นพวก Test Coverage Matrix, Defect Discovery Rate และอื่นๆ แล้วนำมาประเมินผลเพื่อนำไปแก้ไขใน Project ต่อไป ยิ่ง Project อื่นมีลักษณะใกล้เคียงกับ Project ที่เคยทำมาแล้วมากเท่าไร ความเสี่ยงก็จะลดลงมากขึ้นเท่านั้น การนำการวัดผลแบบต่างๆเข้ามาช่วยในการ Test ด้วยก็จะทำให้การพัฒนาของเรานั้นเห็นผลชัดเจนยิ่งขึ้น ไม่เชื่อก็ลองวัดผลอะไรสักอย่างที่เราทำดู แล้วถ้าคราวหน้าเราทำได้ดีขึ้น เร็วขึ้น เราจะรู้สึกอย่างไร
เป็นความรู้ที่ดีมากๆเลยครับ
ถ้าหากว่าเรามีการ plan การ test เอาไว้เรียบร้อยแล้วแต่มีเหตุการณ์ไม่คาดคิดทำให้เกิด เวลาไม่เพียงพอ, scope เพิ่มขึ้น หรืออะไรก็ตามที่ทำให้มีแนวโน้มว่า testing project จะไม่เสร็จในเวลาที่กำหนด ผมขอแสดงความคิดเห็นว่าแบบนี้ครับ
ให้ใช้หลักของ Risk Based Testing ไปใช้ใน project ตั้งแต่เริ่มต้นด้วย เพื่อที่จะได้ใช้เวลาที่มีอยู่อย่างจำกัดให้คุ้มค่าที่สุด
วิธีการเคร่าๆก็ืคือ
1. เราต้องทำการกำหนด Risk factor ที่มีผลต่อระบบเสียก่อน เช่น ความสำคัญของ requirement นั้นๆต่อระบบ, ความสำคัญของ function นั้นๆต่อ Module, ระดับความเสียหายหาก function มีการทำงานผิดพลาด, ความถี่ในการใช้งาน, ความซับซ้อน, อยู่ใน area ที่ developer มีประสบการณ์หรือเป็น technology ใหม่ และอื่นๆ ซึ่งในแต่ละบริษัท หรือหน่วยงานต่างๆ อาจจะใช้ไม่เหมือนกัน ตามองค์ประกอบที่เกี่ยวของกับความเสี่ยงที่่น่าจะเป็นไปได้
2. เมื่อได้ Risk Factor มาแล้ว ก็ทำการคำนวน Risk Weighting ให้กับ requirements หรือ functional ต่างๆใน specification ของ software โดยพิจารณาทีละ Factor ซึ่งการกำหนดค่าเหล่านี้ต้องมีการประชุมกันระหว่าง member ใน project จะให้ดีควรเป็น stakeholders ด้วยจะดีมากๆ เพราะจะได้ค่าที่แม่นยำและใกล้เคียงความจริงที่สุด ในจุดนี้ทีมที่สำคัญมากๆก็คือ Developer และ Tester
ตรงจุดนี้อาจจะให้แต่ละ factor มีคะแนนเต็ม 100 หรือใช้หลักของเลขคู่ เ่่ช่น 1-10 จะได้ไม่ต้องประนีประนอมกันตรงกลาง
เมื่อได้ Risk Weight ของแต่ละ factor แล้วก็นำมาหาค่าเฉลี่ย ก็จะได้ Risk Score ของแต่ละ function ออกมา
3. เพิ่มตัว Risk Score เข้าไปใน Traceability Matrix เราก็จะมองเห็นภาพรวมได้เลยว่า ความเสี่ยงของระบบนั้นไปกองอยู่ตรงไหน เพราะอะไร (ส่วนใหญ่จะใช้สูงสุดที่ 100 ยิ่งถ้าค่าใกล้ 100 ก็แสดงว่าความเสี่ยงสูง และความเสียหายสูงหาก function ทำงานผิดพลาด) และก็วางแผนงานต่างๆจาก Risk Score เหล่านี้
ดังนั้นถ้าเวลาที่เรามีไม่ได้ยืดออกหรือหดลง เราก็ดำเนินการตามแผนเดิม แต่ถ้าเราโดนตัดเวลา หรือมีการเพิ่ม Requirement ใหม่ๆ หรือว่าโดนขโมย Tester ไปจากทีมชั่วคราว หรือมี Resource เพิ่ม PM ใจดีแถมให้ 10 วัน หรือ แถม Tester มาให้ 2 คน เราก็รู้ได้ว่าเราควรทำอย่างไร
กรณี Resource ต่างๆที่ประเมินไว้ ไม่ว่าจะเป็น เวลา หรือ คน ลดลง เราก็ plan ใหม่โดยเน้นความครอบคลุมไปที่ส่วนที่ Risk Score สูงๆก่อน ดังนั้นในเวลาที่จำกัด เราก็จะทุ่มเทสมองและเวลาไปในส่วนที่ควรจะทำ ไม่ใช่รีบๆไปซะทุก module หวานแหไปทั่วแต่ไม่ได้เนื้องานอะไรเลย
กรณี Resource ที่ประเมิินไว้เดิม อยู่ดีๆก็มีคนใจดีมาเพิ่มให้ ทั้งคน ทั้งเวลา เราก็จะได้ทำงานเพิ่มเติมในส่วนที่ Risk Score สูงๆ ให้ Test Scenario หรือ Test Case มันละเอียดและ cover จุดเสี่ยงต่างๆให้มากขึ้น หรือถ้าความเสี่ยงมันไปกองที่การ maintenance test data หรือ test bed เราก็จะได้เอาเวลาไปวางแผนเพิ่มเิ่ติม เพื่อออกแบบให้มันสามารถจัดการได้ง่ายในอนาคต
ข้างบนก็เป็นหลักการเบื้องต้นของการทำ Risk Based Testing จริงมันมีรายละเอียดเยอะกว่านี้ สนใจก็สอบถามได้นะครับ
ข้อควรระวังก็คือ หลังจาก Assign Risk Weight แล้วก็ให้เก็บมันเอาไว้อย่างนั้น ห้ามเปลี่ยนเด็ดขาด ยกเว้นเป็นความต้องการของลูกค้าจริงๆ เพราะไม่อย่างนั้นเราก็จะไม่สามารถควบคุมการทำงานได้ ถึงเวลาเร่งๆ PM อยากให้ Test อันนี้ก่อน เพราะอันนี้มันสำคัญกว่าอันโน้น อันนั้นเอาไว้ทีหลังก็ได้ ก็จะกลายเป็นว่า ที่เราทำมาทั้งหมดไม่เป็นประโยชน์อะไร Risk Weight ที่ได้ตกลงกันในทีมทั้งหมด หรือ Stakeholder ก็ควรถือเป็นที่สิ้นสุด และทุกคนก็เข้าใจและยอมรับตรงกันตามที่ได้ตกลงกันไว้
วิธีนี้ค่อนข้างดีมาก เพราะว่าเราสามารถที่จะปรับกระบวนท่าได้ตามสภาพความเป็นจริง และค่อนข้างยืดหยุ่นได้ตามสถานการณ์ต่างๆ ยกตัวอย่างเช่นเราอยากจะทำ Regression Test เราก็สามารถที่จะเลือก Function หรือ Test Case ที่มันมี Risk Score สูงๆออกมาได้เลย
ชักสนุกแหละครับกับเรื่องนี้
ถ้าผมจัดนั่งจิบกาแฟคุยกันเรื่องนี้ ทั้งพี่อิ๋ว, คุณ kannique และเพื่อนพ้องน้องพี่ ท่านอื่นๆ สนใจไหมครับ เป็นสักวันเสาร์บ่ายๆ สัก 2-3 ชั่วโมง อิอิ
สวัสดีค่ะ คุณ kannique
เรื่องเพิ่มคนระหว่าง project ถ้าเป็นคนใหม่ที่ไม่เคยรู้ระบบเลย คงไม่แนะนำค่ะ เพราะจะมีเรื่อง learning curve
แทนที่ tester จะทุมเวลาในการ test ระบบ แต่กลับมาต้องใช้เวลาในบางส่วน train คนใหม่ เท่าที่ทำ test มา
น้องในทีมจะเลือกขอทำ OT มากกว่า การเพิ่มคนใหม่มาใน project คะส่วนเรื่องที่จะให้ develper เข้ามาช่วย test ระบบนั้น
ยิ่งเป็นไปได้ค่อยข้างยาก เพราะ process ที่บริษัท ระบุไว้ว่า “คน code ห้าม test คน test ห้าม code”
ตอบเรื่อง UAT package คะ
1. project planning ปกติจะมี plan 2 แบบ
1.1 plan แบบที่เราสามารถกำหนดเองได้ คือ ลูกค้า จะให้ requirements(RM) และให้ทาง project lead กำหนด plan ให้กับ user
ซึ่ง plan แต่ละ phase จะต้องถูกกำหนดโดย lead แต่ละส่วน โดยทุกส่วนจะมี estimate sheet ของตนเองอยู่ เช่น project นี้
มีจำนวน RM = 500 โดยทุกส่วนจะใช้ RM อ้างอิงในการทำ estimate เช่น
phase RM ทาง BA จะกำหนดว่าจะใช้เวลา เก็บ RM 20 วัน
phase Design ทาง SA จะกำหนดว่าจะใช้เวลา design 20 วัน
phase DEV ทาง DEV จะกำหนดว่าจะใช้เวลา coding 40 วัน
phase Testing ทาง tester จะกำหนดว่าจะใช้เวลา test 30 วัน
phase deploy ทางทีม implement จะกำหนดว่าจะใช้เวลา 10 วัน
รวมทั้งหมด 120 วัน
*** ซึ่งถ้าเป็นเช่นนี้ ถ้า test team กำหนด test plan ได้เราจะเลือก Package : Platinum ให้ลูกค้าอยู่แล้ว
1.2 plan แบบที่ลูกค้ากำหนดวัน go live ให้(ที่บริษัทจะเรียกว่า “ฟ้าประทาน”) ในส่วน phase testing ก็จะทำเหมือนเดิมค่ะ
คือดูว่าจำนวน RM = 500 จะใช้เวลา test 30 วัน เมื่อทาง project lead ดูภาพรวมแล้ว จะแจ้งให้ทราบ
–> เช่น phase testing ทาง project lead แจ้งว่ามีเวลาให้แค่ 20 วัน(ซึ่งจริงๆ เราต้องใช้เวลา 30 วัน) ก็จะแจ้งกลับไปว่าให้ได้แค่ Package : Gold
–>หรือ ทาง project lead แจ้งว่ามีเวลาให้แค่ 10 วัน ก็จะแจ้งกลับไปว่า ให้ได้แค่ Package : Silver
เทคนิคอยู่ที่ว่า ถ้าเป็น Package : Platinum เราจะ fixed defect ที่ เป็น High Medium Low และรวม Cosmetic ให้ด้วย
ถ้าเป็น Package : Gold เราจะ fixed defect ที่ เป็น High Medium เท่านั้น
ถ้าเป็น Package : Silver เราจะ fixed defect ที่ เป็น High เท่านั้น
2. จำนวนวันที่ใช้ในการทดสอบระบบสำหรับ package ต่างๆ จะยึดจำนวนวันใน project plan เป็นหลักรึเปล่าครับ? อันนี้ถูกต้องค่ะ
ถ้าดูจากเทคนิคที่ใช้จะรู้ได้ทันทีว่า เพราะอะไรถึงใช้ effort แค่นั้น และรับประกัน quality ได้ตามนั้น เช่น silver ใช้เทคนิคคือ
fixed defect เฉพราะ severity ที่เป็น High นั้นหมายความว่า user จะต้องยอมรับ application ที่ go live จะมี defect ที่เป็น medim
กับ low ด้วย แต่ถ้ามีเวลาทาง test team ก็อาจจะ fixed defect severity medim กับ low ให้ด้วย แล้วแต่ case คะ
*** ที่บริษัทเป็น in house คะ อาจจะคุยกับ user ง่ายหน่อย
*** ที่สำคัญต้อง definition severity High medim และ low กับ user ให้เข้าใจตรงกัน
*** UAT report กำหนด 2 ส่วนนี้ให้ชัดเจน
1. Acceptance criteria ว่าเป็น type ใด ได้แก่ • High defect • Medium defect • Low defect • Cosmetic defect • No defect
ซึ่งจะต้องคุยกับ user ก่อนเสมอว่าจะเป็น type ไหน
2. แจ้ง covered testing กับ uncovered testing ไว้ด้วยนะคะ
เท่าที่ทำมาหลาย project โอกาสน้อยค่ะ ที่จะ go live ทันตามกำหนด หรือไม่ก็ ถ้าทันตามกำหนด จะต้องมี function ใด function หนึ่งถูกตัดทิ้งเสมอ
ดังกล่าวบอกไว้ว่า คุณภาพ(quality)” ไม่ได้เกิดขึ้นใน phase ใด phase หนึ่งเท่านั้น หากแต่ทุกคนในทุก phase ร่วมด้วยช่วยกัน คำว่า “Quality”
และ “Satisfaction” จะมีเกิดขึ้นใน project แน่นอนคะ
สวัสดีครับพี่ิอิ๋ว
ครับ การแก้ปัญหาโดยการเพิ่มคนเข้ามาระหว่าง project มันไม่แน่ว่าจะช่วยให้งานเสร็จเร็วขึ้นเสมอไป (จากในรูปผมใส่เครื่องหมาย ? ไว้หลัง RESOURCE INCREASE ฮะ
) พอดีว่าทีมผม Developer ไปช่วยงาน QA ได้ ปัญหาเลยลดลงไปเยอะเลยฮะ
เรื่อง UAT Package น่าสนใจมากนะครับ ผมมีคำถามนิดนึงฮะว่า
1. ช่วง project planning ไม่ได้ทำร่วมกันระหว่าง project leader, developer, QA หรอครับ? ถึงได้มี test plan แยกจาก project plan ครับ ผมสงสัยว่าคนอื่นจะ estimate งาน Test ได้ดีกว่า QA ได้ยังไงอะฮะ
2. จำนวนวันที่ใช้ในการทดสอบระบบสำหรับ package ต่างๆ จะยึดจำนวนวันใน project plan เป็นหลักรึเปล่าครับ? เช่น ถ้า test plan ใช้เวลา 15 วัน แต่ project plan ให้เวลาทดสอบระบบ 5 วัน เราก็ต้องทำเสร็จใน 5 วัน ดังนั้นเราจะใช้ effort ได้แค่ 33% จากที่เราคาดไว้ และรับประกัน Quality ไม่เกิน 33% ถูกมั้ยฮะ
ขอบคุณครับ
ข้อความดี ครับ สำหรับ หัวเรื่องนี้
ขอบคุณพี่ิอิ๋วสำหรับประสบการณ์ที่ร่วมแบ่งปันครับ
ขอร่วมด้วยช่วย share อีกคนค่ะ ที่บริษัทเองก็เจอปัญหาคล้าย ๆ เช่นนี้เหมือนกัน
และวิธีการที่ใช้ก็คล้าย ๆ คุณ Kannique แต่ใช้ชื่อเป็นทางการว่า UAT packages
และมีโอกาสได้ share แนวคิดเรื่อง UAT packages ไว้ที่งาน bug day
เมื่อวันเสาร์ที่ 19 ธันวาคม 2552 ที่ผ่านมา
ปัจจัยหลักก็มาจาก 3 ส่วนคือ scope,time,resources
–>ปัจจัยแรก คือเรื่อง scope ซึ่งเป็นปัจจัยที่ไม่ค่อยแปลกใจเท่าไหร่ ที่จะมีโอกาสเพิ่มขึ้นเรื่อย ๆ
เพราะตราบใดที่ user ไอเดียบรรเจิด เมื่อไหร่ก็เมื่อนั้น scope งานจะเพิ่มตามในทันที
–>ปัจจัยที่สอง เรื่องของเวลา ก็เป็นอีกหนึ่งปัจจัยที่ไม่ค่อยแปลกใจ เพราะหลาย ๆ project
เวลาที่ใช้ในการ develop มักจะถูกใช้เกินมาใน phase testing อยู่เป็นประจำ
–>ปัจจัยที่สาม เรื่อง resources ที่บริษัทเป็นไปได้ค่อยข้างน้อย ที่จะเพิ่ม resources เข้ามาใน
ช่วงกลาง project และการเพิ่ม resource เข้ามาในช่วงกลาง project ในบางครั้งก็ไม่ได้ช่วยให้
การทำงานเร็วขึ้น และอาจจะมีปัจจัยเรื่องการเริ่มเรียนรู้งานเข้ามาเกี่ยวข้องเสียด้วยซ้ำ และถ้าหากจะให้
developer เข้ามาช่วยข้อนี้ที่บริษัทคงเป็นไปค่อยข้างยากมากคะ
UAT packages นอกจาก3 ปัจจัยที่ได้กล่าวมาแล้ว ยังมีเรื่องการ plan เข้ามาเกี่ยวข้องอีกด้วย
การจัดทำ plan มี 2 ส่วน คือ
ส่วนแรกคือ project plan ส่วนนี้ทาง project lead จะเป็นผู้จัดทำและครอบคลุมทั้ง project
ส่วนที่สองคือ test plan จะเป็นส่วนหนึ่งใน project plan ส่วนนี้ทาง test team จัดทำ
โดยใช้ estimate sheet เข้ามาช่วยในการจัดทำ test plan
การเลือก UAT packages จะพิจารณาจาก project plan กับ test plan ว่ามีความสมดุลกันมากน้อยแค่ไหน ดังนี้
Package : Platinum ได้แก่ project plan กำหนดเวลาในการทดสอบให้ 20 วัน test plan กำหนดใช้เวลาในการทดสอบระบบ 20 วัน
ใช้ Effort 100% โดยรับประกัน Quality 90% ขึ้นไป
Package : Gold ได้แก่ project plan กำหนดเวลาในการทดสอบให้ 10 วัน test plan กำหนดใช้เวลาในการทดสอบระบบ 15 วัน
ใช้ Effort 80% โดยรับประกัน Quality ไม่เกิน 70%
Package : Silver ได้แก่ project plan กำหนดเวลาในการทดสอบให้ 4 วัน test plan กำหนดใช้เวลาในการทดสอบระบบ 10 วัน
ใช้ Effort 40% โดยรับประกัน Quality ไม่เกิน 40%
และปัจจัยอื่น ๆ ที่เข้ามาเกี่ยวข้องในการเลือก UAT packages คือ Standard testing โดยในบาง packages
จะทำการแจ้งส่วน uncorved testing ไว้ให้ทราบด้วย เพื่อให้ลูกค้าได้ quality ตามความเหมาะสมกับปัจจัยต่าง ๆ ที่เกิดขึ้นในการจัดทำ project
Software testing เป็นหนึ่งในกระบวนการพัฒนาระบบ(SDLC) คำว่า “คุณภาพ(quality)” ไม่ได้เกิดขึ้นใน phase ใด phase หนึ่งเท่านั้น
หากแต่ทุกคนในทุก phase ร่วมด้วยช่วยกัน คำว่า “Quality” และ “Satisfaction” จะมีเกิดขึ้นใน project แน่นอนคะ
<>