ทำอย่างไรถ้าเวลาสำหรับ Software Testing เหลือนิดเดียว

“ทำอย่างไรถ้าเวลาสำหรับ 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 ได้ง่ายกว่าด้วย

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

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

หนุ่มครับ หาเวลาสักครึ่งวัน 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 มากที่สุดเลยครับ โปรเจกจบปริญญาโทก็เป็นงานที่เกี่ยวกับเรื่องนี้ ดีใจที่มีคนสนใจเรื่องเดียวกันครับ

ขอบคุณครับ

เป็นความรู้ที่ดีมากๆเลยครับ

ถ้าหากว่าเรามีการ 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

เรื่องเพิ่มคนระหว่าง 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% ถูกมั้ยฮะ

ขอบคุณครับ