Tag Archives: defect

เพิ่มสีสันให้กับการกำหนดความรุนแรงของ Bug

colorful-butterfly
รูปจาก http://www.jachestudio.com

กราบสวัสดีเย็นย่ำวันจันทร์ที่ 11 สิงหาคม พ.ศ. 2557 วันที่หลายๆ คนหยุดพักอยู่บ้าน ขณะที่หลายๆ คนนั่งทำงานอยู่ พอดีนั่งอ่าน tweet ไปเรื่อยๆ จนมาเจอกับ Blog ของ Tester ฝรั่งท่านหนึ่งในนามปากกาว่า TestSheepNZ จั่วหัวเรื่องว่า A new defect severity hierarchy … พอเข้าไปนั่งอ่านดู เฮ้ย!!! เขาคิดได้ไงเนี่ย ชอบๆ เลยขอหยิบมาเขียนเป็นภาษาไทย สำหรับคนที่อยากอ่านต้นฉบับก็ Click ที่ นามปากกา หรือ ที่หัวเรื่องด้านบนได้เลยนะจ๊ะ

พออ่าน Blog นี้ A new defect severity hierachy แล้วก็ทำให้หยุดคิดว่า เออ…เวลาอธิบายถึงเรื่องระดับความรุนแรงของ Defect ผมก็มักจะยกตัวอย่างโดยอ้างอิงถึงการทำงานที่ผิดพลาดของ Software เสมอๆ แต่ถ้าไม่ใช่คนแบบ IT จ๋า จ๋า จ๋า และจ๋า เลยล่ะ จะอธิบายยังไง?

Continue reading เพิ่มสีสันให้กับการกำหนดความรุนแรงของ Bug

เมื่อไรควรใช้ และไม่ควรใช้ Defect Tracking System

เมื่อหลายๆๆๆ ปีก่อนสมัยยังละอ่อน นั่งทดสอบงาน และเขียน Defect ที่พบลงไปในระบบ Defect Tracking System (DTS) หรือ Bug Tracking ก็แล้วแต่สะดวกจะเรียกกัน ผมใช้เวลาพอสมควรในการเขียน Defect แต่ละตัวที่พบลงใน DTS ซึ่งกว่าจะจบได้แต่ละตัวก็นะ ใช้เวลาพอสมควร จนหลายๆ ครั้งมีการนั่งคุยในทีมว่า ทำไมเราจะต้องนั่งเขียน Defect เก็บไว้? ซึ่งคำถามนี้ได้หายไปจากแกนสมองนานพอสมควรจนกระทั่งมาอ่านหนังสือ Agile Testing: A Practical Guide for Testers and Agile Teams ของ Lisa Crispin และ Janet Gregory มาสะดุดกับตอนหนึ่งของหนังสือนี้

agile-testing-dts

ซึ่งทำให้ผมได้รับรู้ว่า เฮ้ย!!! นี่มันข้อสงสัยระดับโลกเลยนี่!!! 🙂 ก็เลยมานั่งจรดปลายนิ้วลงบนแป้นพิมพ์เพื่อเขียน Blog วันนี้โดยจะผสมผสานกันระหว่างหนังสือ Agile Testing และประสบการณ์ของตัวเอง

Continue reading เมื่อไรควรใช้ และไม่ควรใช้ Defect Tracking System

You can’t stop the waves, but you can learn how to surf

waves-surf

กราบสวัสดีบ่ายวันอังคารที่ 3 กันยายน พ.ศ. 2556  (-/\-) สืบเนื่องจากเช้าวันนี้เจอภาพนี้บน Timeline ของเพื่อนใน Facebook ผมนั่งมองนิ่งๆ อยู่ 10 วินาที พร้อมกับมีรอยยิ้มบนใบหน้าปลวกๆ ของตัวเอง 555 พร้อมกับ Post ขึ้นไปทั้ง Timeline ของตัวเอง Facebook Group WeLoveBug และ FanPage WeLoveBug (เข้าขั้นบ้า) ดูจากรูปภาพแล้วน่าจะเป็นหน้าบริษัทอะไรสักอย่าง แต่ข้อความบนกระจกมันโดนใจผม 10 วินาทีที่มองอย่างนิ่งๆ ทุกๆ เหตุการณ์ที่เกิดขึ้นระหว่างทางของการตั้งทีม Test กระบวนการการทดสอบ (Test Process) รวมทั้งทั้งผลักทั้งดันให้เรื่องของคุณภาพ (Quality) เกิดขึ้นในองค์กรที่ผมเองเคยอยู่ มันวิ่งกลับเข้ามาในสมองทันทีกับประโยค “You can’t stop the waves, but you can learn how to surf

Continue reading You can’t stop the waves, but you can learn how to surf

คำถามจากชั้นเรียน Software Quality Management รุ่น 1

question marks heap

สวัสดีเช้าวันจันทร์ที่ 19 สิงหาคม พ.ศ. 2556 สืบเนื่องจากวันเสาร์และอาทิตย์ที่ผ่านมา ได้มีโอกาสไปแบ่งปัน ความรู้ + ประสบการณ์ + ความเกรียน ในชั้นเรียนชื่อ Thailand SPIN: Software Quality Management 1 โดยมีผู้เรียนทั้งหมด 15 ท่าน ก็จบลงไปอย่างสนุกสนาน (มุมคนสอนนะครับ) และก็มีคำถามที่ผู้เข้าเรียนได้เขียนลง Post-It แปะไว้บนกระดานคำถาม ซึ่งส่วนใหญ่ก็ได้ตอบไปในห้องแล้ว มีคำถามบางส่วนที่ยังตอบไม่ได้ และจะมาหาคำตอบให้ครับ

เช้าวันนี้เลยขอนำคำถามที่ได้จากชั้นเรียนมาแบ่งปันกัน เผื่อเพื่อนพ้องน้องพี่จะช่วยกันตอบ หรือแนะนำแนวทาง จากประสบการณ์ทำงานของตัวเองครับ

Continue reading คำถามจากชั้นเรียน Software Quality Management รุ่น 1

24 คำตอบสุดฮิตของ Programmer เมื่อ Software มีปัญหา

สวัสดียามสายวันอังคารที่สองของเดือนกันยายนนะครับ เผลอนิดเดียวก็เกือบจะสิ้นปี 2552 อีกแล้ว เวลาเดินทางไวจริงๆ เลยนะครับนี่ ห่้างหายไปนานเลยที่ไม่ได้เขียนเรื่องลงบน welovebug วันนี้ก็เลยเข้ามาเขียนเรื่องลงซะหน่อยดีกว่า เก็บๆ ข้อมูลไว้เยอะเลย แต่ต้อง build อารมรณ์ตัวเองให้ได้ถึงจะเขียนได้ครับ

bug1

หลังจากที่เคยได้นำเสนอเรื่องขำๆ แอบเสียดสี Developer และ Programmer ไป กับเรื่อง คำตอบ 20 อันดับแรก ที่เหล่า Programmer มักจะตอบเมื่อพบ Bug และต่อยอดคัด 10 คำตอบเด็ดๆ ไป นำเสนอในงาน Barcamp Bangkok ครั้งที่ 3 โดยใช้ชื่อ Session ที่ไปพูดในวันนั้นว่า Top 10 programmer’s answer when tester find bugs วันนี้กลับมาอีกครั้งด้วยบทความหยิกแกมหยอก สำหรับเหล่า Developer และ Programmer อีกครั้ง กับ 24 คำตอบสุดฮิตของ Programmer เมื่อ Software มีปัญหา

ที่มาที่ไป ผู้เขียนได้ทำการค้นหาบน Google เพื่อจะหาชื่องานกิจกรรมพบปะพูดคุยของเหล่า Tester และผู้ที่เกี่ยวข้องกับเรื่องของ Software Testing ก็บังเอิญไปเจอบทความหนึ่งเข้า ด้วยคำค้นว่า Tester Day พอเข้าไปอ่าน อ้าว…ไม่ใช่ แต่ดันเขียนชื่อเรื่องว่า tester’s day! ซะงั้น แต่ในบทความเป็นเรื่องของ Top 24 replies by programmers when their programs don’t work

ผู้เขียนก็เลยหยิบมานำเสนอแก่เหล่าเพื่อนพ้องน้องพี่ไม่ว่าจะเป็น Tester หรือ Programmer หรือ Developer หรือ ผู้ที่สนใจ ได้อ่านกันแบบ ขำ ขำ ครับ 🙂
Continue reading 24 คำตอบสุดฮิตของ Programmer เมื่อ Software มีปัญหา

งานที่เสร็จแต่ไม่สุดกับ UAT

กับคำพูดที่ว่า “แล้วเจอกันบน Production” ประโยคนี้บ่งบอกอะไรกับ Software หรือ Application บ้าง

  • คุณมีการเตรียมความพร้อมเรื่อง Test Environment ได้ดีแค่ไหน
  • UAT แล้วไม่เจอ แต่ไงไปเจอ Case ที่ Production แล้วทำ Case ไม่ Cover หรือเปล่า
  • คุณมีการเตรียมข้อมูลสำหรับใช้ Test พอเพียงหรือเปล่า ถ้าเทียบกับข้อมูลที่ลูกค้าจะใช้งานจริง
  • คุณเตรียมความพร้อมเรื่องการ Set Configuration ครบถ้วนกระบวนความแค่ไหน

หรือคำถามอื่น ๆ ที่มักจะเกิดขึ้นเมื่อระบบถูกนำไปใช้งานจริงแล้วเกิด Defect บน Production

การนำระบบขึ้นใช้งานจริงที่ Production คงไม่ได้โชคดีทุกครั้งที่ระบบไม่มีปัญหา อยู่ที่ว่าระบบจะมีความสมบูรณ์กี่เปอร์เซ็นต์ และอีกไม่นาน Defect ที่เกิดขึ้นจริงบน Production ต้องนำมาถูกเข้าสู่วงจร SDLC ใหม่อีกครั้ง และเป็นที่มาของคำว่า เสร็จแต่ไม่สุด

การเตรียม Resources เพื่อ Support หลังจากใช้งานจริงบน Production ก็มีความสำคัญไม่น้อยกว่าช่วงเวลาพัฒนาระบบ โดยส่วนมากวันที่สามารถ Go Live ระบบได้ทุกคนมักจะดีใจเป็นการใหญ่ สักพักคุณก็จะได้เห็น Defect ประเภทที่คิดไม่ถึงหรืองงไปตาม ๆ กัน ถ้าโชคดี Defect ไม่กระทบกับ  Business ก็คงไม่เท่าไหร่ แต่ถ้า Defect นั้น กระทบ Business และคาดถึงต้องหยุดใช้งานระบบชั่วคราว คุณจะได้เห็นกึ๋นหัวหน้างานคุณแน่นอน

สุดท้ายฝากทิ้งไว้ ”อย่าเชื่อ Developer หรือ Programmer เขียนโปรแกรมไม่มี Bug จนคุณจะได้พิสูจน์ด้วยตัวคุณเอง

ท้ายสุด  “เชื่อได้ว่า Developer หรือ Programmer กับ Tester สามารถเป็นเพื่อนกันได้(แต่อย่าหั้วก็แล้วกันนะค๊า)”                           

[Forum] มักจะได้คำตอบจาก Developer ว่า Out of Scopes ทำไงดีค่ะ!!!

สวัสดียามค่ำคืนวันจันทร์ที่ฝนตกโปรยปรายครับ อากาศเย็นสบาย แต่ก็ระมัดระวังที่จะไม่สบายกันด้วยนะครับ เข้าเรื่องเลยละกันนะครับ ได้มีเพื่อนพ้องน้องพี่ของเราได้ไปถามไว้ที่ Software Testing Forum ไว้ ดังนี้ครับ

ตอนนี้กำลังสับสนว่า เวลา Log Issue ไป มักจะได้คำตอบจาก Developer ว่า Out of Scopes.

ในมุมมอง QA ที่ถ้าเจอ Issue ก็จะ Log เพราะ Concern ในเรื่อง Quality
แต่ ในมุมมอง Developer หรือ Project Team ถ้าเรื่องที่เจออยู่นอกเหนือ Scopes งานที่ต้องแก้ไข ในโปรเจคที่มีเรื่อง Budget และ เวลาเป็นเงื่อนไข ที่เขาต้องใช้ไปในการ Investigate งานที่นอกเหนือ Scopes

เราจะมีวิธีการจัดการกับปัญหานี้อย่างไรดี รบกวนช่วยแนะนำด้วยคะ

ยกตัวอย่างเคส เช่น ลูกค้าทำการ Upgrade ระบบจาก Version 1.0 เป็น 2.0

ปัญหาหนึ่ง
Tester แจ้ง Bug ที่ Developer ตรวจสอบแล้วพบว่าเป็น Bug ที่เกิดจาก Core Product ไม่ได้เกิดจากการ Customization ซึ่งนโยบายของบริษัทจะไม่ทำการแก้ไข Bug ที่เกิดจาก Core Product

เนื่องด้วยเวลาที่จำกัด ทำให้ Tester ไม่สามารถพิสูจน์ว่า Issue ที่เจอเป็น Issue จาก Core Product หรือไม่
Developer ก็ต้องเสียเวลาในการพิสูจน์ Issue ที่หากเป็น Issue ที่เกิดจาก Core Product ก็จะไม่ Fix ซึ่ง 60% ของ Issue ที่ทำการรายงาน เกิดจาก Core Product ทั้งนั้น

เราจะมีวิธีการอย่างไรที่จะทำให้ Tester สามารถเรียนรู้ว่า Issue ที่เจอ เกิดจาก Core Product ของแต่ละเวอร์ชั่น ซึ่งแน่นอนว่าจะมีการรายงาน Bug ใหม่ๆ อยู่เสมอ

ปัญหาสอง
ด้วย เวลาที่จำกัด Tester จึงถูกจำกัดให้เน้นเทสในส่วนที่เป็น Customization แทนที่จะทำการทดสอบระบบโดยรวม เช่นนี้แล้วเราจะรับประกันคุณภาพของ Software นี้ได้อย่างไร

เลยหยิบยกมาให้เพื่อนพ้องน้องพี่ของเราได้ร่วมด้วยช่วยกันแสดงความคิดเห็น และคำแนะนำดีๆ ครับ 🙂

ที่มา: http://forum.sanook.com/forum/2848317_Out_of_Scopes.html

My Defect Management ตอนที่1 Overview

สวัดดีค่ะ สำหรับตอน My Defect Management ที่เขียนเรื่องนี่ เนื่องจากมีโอกาศได้รับมอบหมายให้เขียนลง Wiki ของทีมเลยอยากเอาแชให้พี่น้องชาว WeLoveBug  ดูค่ะ แต่จะเขียนเป็น My Defect Management นะค่ะ เนื่องจากแต่ละองค์กร อาจมีวิธีการจัดการกับ Defect ที่พบต่างกันและใช้ตัวช่วยที่ต่างกัน ค่ะ

Defect Management คือ การจัดการ Defect ที่พบในช่วงของ Phase  Testing โดย Tool ที่ผู้เขียนใช้คือ Mantis การนำ Tool เข้ามาใช้ใน Project นั้นๆ เพื่อใช้ Report Defect ที่พบเพื่อแจ้งทีมที่เกียวข้อง และเพื่อใช้ข้อมูลสรุปปัญหาของโปรเจ็คนั้นๆ ว่าจะสามารถ Launch ได้ตาม Plan หรือไม่

Defect คือ ปัญหาที่พบในการทดสอบระบบ ซึ่งปัญหาเหล่านี้อาจกระทบต่อ Function การทำงานของระบบ เช่น ระบบแสดง Error ต่างๆ หรือ Defect ที่พบอาจจะไม่กระทบกับ Function การทำงาน เช่น การแสดงผลที่อาจเกิดจาก Design หรือ การแสดงผลของข้อความ ซึ่งปัญหาเหล่านี้จะไม่ส่งผลกระทบกับระบบ

Defect Life Cycle คือ วงจรการทำงานของ Defect ที่เริ่มตั้งแต่เมื่อพบ Defect แล้ว Assign ให้ทางทีม Developer แก้ไข จนกระทั่ง Developer แก้ไขเสร็จ ซึ่งมีรายละเอียด ดังนี้

[ad#adsense-468×60]

Continue reading My Defect Management ตอนที่1 Overview

ทำยังไงดี Bug โดน Reject อีกแล้ว

สวัสดีครับ หลังจากที่คราวที่แล้วเล่าเรื่อง Test Efficiency & Effectiveness ให้ฟังกันไปแล้ว คราวนี้มาลองคุยกันเรื่องเบาๆ (แต่อาจจะเป็นเรื่องที่ทำให้หลายๆคนเกิดอาการเซ็งกันได้บ่อยๆ) กันหน่อยดีกว่าครับ

คำพูดที่หลายๆคนคุ้นหู

“ตัวนี้มันไม่ใช่ Bug นะครับคุณTester นี่มัน Expect Behavior มันต้องเป็นอย่างนี้แหล่ะ เชื่อผมๆ”

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

1. “เอ่อออ เหรอ จริงเหรอ มันต้องเป็นอย่างนี้จริงๆเหรอ… อ่า แต่มันดูแปลกๆนะ อ่า…. เหรอ ไม่ใช่จริงๆ หรอ… อืมๆๆ ไม่ใช่ก็ได้แหล่ะมั้ง เดี๋ยวไป reject ให้ละกันนะ”

หรือแบบที่สอง (หลังจากที่โดน Reject มาสิบตัว อารมณ์กำลังคุกรุ่น อาจจะเป็นแบบนี้)

2. “อะไรนะ ไม่ใช่อีกแล้วเหรอ ทำไม Report มาสิบตัว มันไม่ใช่ Bug หมดเลยเนี่ย มั่วป่าว ทำไมไม่ยอมรับอะไรเลยเนี่ย….(ตูม ตาม ตูม ตาม)

คือ สรุปว่า ถ้าไม่ยอมให้ Reject (แบบไม่เต็มใจ) ก้อจะออกแนว หงุดหงิด โมโห น้อยใจในโชคชะตากันไปเลย หรือถ้าแย่กว่านั้นคือ ต่อไป Tester คนนั้นก็จะเลิก Record Bug ที่เจอ หรือไม่ก็เวลาเจออะไรที่คิดว่าเป็น Bug ก็จะวิ่งไปถาม Developer ก่อน แล้วก้อจะโดนบอกมาว่าไม่ใช่ Bug แล้วก้อจะปล่อยมันผ่านไปไม่ Record อะไรใดๆทั้งสิ้น

จริงๆแล้ว วิธีรับมือกับปัญหาประเภทนี้ ทำได้ไม่ยากหรอกครับ

Continue reading ทำยังไงดี Bug โดน Reject อีกแล้ว

จุดประกาย : ทำไม Softwareต้องมี bug (ตอนที่ 2)

จุดประกาย : ทำไม Softwareต้องมี bug (ตอนที่ 2)

– การพัฒนาระบบอย่างต่อเนื่องเพื่อไล่ตาม requirement

จุดประสงค์ของ software ที่ใช้ในธุรกิจส่วนใหญ่ ทำออกมาเพื่อตอบรับความต้องการของธุรกิจหลักขององค์กรที่ใช้ระบบนั้นๆ เพื่อให้ธุรกิจเป็นไปอย่างแข่งขัน (low cost + high efficiency) กลยุทธ์ของธุรกิจจึงมีการเปลี่ยนแปลงตลอดเวลา ส่งผลให้ระบบ software requirement ต่างๆจำเป็นจะต้องมีการปรับเปลี่ยนอยู่บ่อยๆ หากแต่การปรับเปลี่ยนโครงสร้างของระบบให้สอดคล้องกับความเปลี่ยนแปลงที่เกิดขึ้นเรื่อยๆนั้น นับมีความท้าทายอยู่อย่างมาก โดยเฉพาะอย่างยิ่ง เมื่อเวลาผ่านไปจนบุคคลกรที่พัฒนา software เกิดการหมุนเวียน บางคนถูกย้ายไปทำงาน project อื่น บางคนลาออกจากบริษัท หรือบริษัท/ตัว product ถูกซื้อไป การรับช่วงต่อเปลี่ยนมือคนทำ software ที่ไม่ได้มีการดำเนินการที่ดี โดยเฉพาะเอกสารที่ไม่ครบถ้วนหรือ update ก็เป็นการเปิดโอกาสที่ทำให้เกิดbug ได้เช่นเดียวกัน

– การ test ทุกอย่างที่เป็นไปไม่ได้
ลองนึกถึง web application ตัวนึงที่มี 5 use case แต่ละ use case มี 20 test cases เท่ากับว่าเรามีทั้งหมด 100 test cases หากในตลาดมี browser เป็น ie, firefox, safari ก็คูณไปอีก 3 = 300 แต่ว่าแต่ละ browser ก็ยังมีการ settings/addon (javascript, flash, security options) ต่างๆกัน และมี major/minor version ก็ทวีคูณกันขึ้นไปอีก (นี่ยังไม่รวม version ของ OS, screen resolution และลำัดับการกรอกข้อมุลและอื่นๆ) การ test ทุกอย่างในทุก environment จึงเป็นไปไม่ได้ที่จะทำให้เกิดขึ้นใน timelineของprojectและคุ้มค่ากับต้นทุนการ testได้ ดังนั้นการออกแบบกลยุทธ์ในการ test (test strategy)ที่ทำให้เกิด Smart Testing โดยไม่testทุกอย่างแต่ยังได้ testสิ่งที่ควรจะถูกtest และให้ได้coverage ที่ดีที่สุดจึงเป็นหัวใจสำคัญและเป็นความท้าทายที่ถูกถกเถียงกันในวงการ testing มานาน อย่างไรก็ตาม แม้ว่า test strategy จะถูกคัดสรรค์มาดีแค่ไหน การที่ไม่ได้ test ทุกอย่างและเว้นไปในแค่รายละเอียดย่อยเล็กน้อยล้วนก็เป็นการเปิดช่องให้มีโอกาสให้มี software bug เกิดขึ้นได้ หากแต่ว่าผลกระทบของการมี bug เหล่านั้นน่าจะส่งผลที่น้อยที่สุดต่อผู้ใช้และธุรกิจของผู้ใช้ระบบนั่นเอง พบกับการบรรยายหลากหลายมุม เรื่อง Smart Testing ได้ในงาน SPIN Day เดือน พ.ค นี้ครับ

Continue reading จุดประกาย : ทำไม Softwareต้องมี bug (ตอนที่ 2)

จุดประกาย : ทำไม Softwareต้องมี bug (ตอนที่ 1)

ผมขอเริ่มต้นการจุดประกายครั้งแรก ด้วยหัวข้อ “ทำไม Softwareต้องมี bug” ด้วยเหตุผลสองประการครับ

หนึ่งการมีตัวตนของ software bug เป็นต้นกำเนิดของอาชีพ software tester (สงสัยนี่ก็อาจเป็นส่วนนึงที่ทำให้ชื่อ webนี้เป็น welovebug กระมังครับ 555)

สอง เคยมีคน(นอกวงการ IT)ถามผมว่า ทำไมคนในวงการ ITก็มีแต่เก่งๆทั้งนั้น projectแต่ละอันก็ราคาหลายแสนหลายล้านแต่ก็ยังทำระบบที่ไม่มีbugออกมากันไม่ได้ แม้กระทั่งบริษัทชื่อดังและรวยที่สุดอย่าง Microsoftก็ตาม (ตอนโดนถามก็จุกใช่เล่นครับ)

ก่อนที่จะไปไล่ดูสาเหตุของ software bug/defect กัน เรามาลองทำความเข้าใจให้ตรงกันก่อนดีมั๊ยครับ ว่า bug คืออะไรผมได้ไปรวบรวมมาจาก 3 แหล่งซึ่งความหมายค่อนข้างใกล้เคียงกันครับ

Continue reading จุดประกาย : ทำไม Softwareต้องมี bug (ตอนที่ 1)

ถ้าเวลามีจำกัดจะ Test อย่างไงดีให้ครอบคลุม

“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 จะทำไงได้ เมื่อเบื้องบนฟันธงลงมาแล้วแบบนั้น?

Continue reading ถ้าเวลามีจำกัดจะ Test อย่างไงดีให้ครอบคลุม