ถ้าเวลาในการ test ไม่เพียงพอที่จะตัดสินใจได้ว่าเป็น bug ในส่วนไหนแนะนำให้ทำ Traceability Matrix ตั้งแต่แรกจะได้รู้เลยว่า Test case ที่ทำอยุ่มันอยู่ใน Area ไหนครับ

ถ้าไม่มีเอกสารต่างๆในระดับที่ใช้งานได้ดี ก็ต้องไปศึกษาเอกสารของ Core Product แล้วก็อาศัยความชำนาญของ tester เองแล้วล่ะครับ ว่าเป็น bug ในส่วนไหน แล้วพยายามออกแบบวิธีการ Test ให้ใช้เวลาในการ Classify bug ให้น้อยที่สุด อาจจะต้องมี procedure ร่างขึ้นมาเผื่อเอาไว้ให้สมาชิกในอนาคตด้วย

2. ถ้า Tester ถูกกำหนดให้ใช้เวลาไปกับ Customization มากเกินไปจนไม่มีเวลาเหลือให้ Core Product ซึ่งก็น่าจะเป็นไปตามความเหมาะสมที่ถูกต้อง คิดว่าน่าจะทำ Regression Test สำหรับ Core Product เพราะจะใช้เวลา test ไม่นาน และพยายามทำในรูปแบบของ Automation จะได้สั่งรันตอนกลับบ้าน ตื่นเช้ามาทำงานก็ใช้ผลได้เลย ทั้งนี้ทั้งนั้นต้องเคลียร์ในส่วนของความสำคัญของ Customization และ Core Product ให้ดีนะครับ จะได้ Plan เวลาให้ถูกจุด จะได้ใช้ resource ให้คุ้มค่า

ขอบคุณที่แวะเข้ามาชมครับ ผมว่าเราเป็นเพื่อนกันอยู่ใน twitter นะ และขอบคุณสำหรับความคิดเห็น และมุมมองในมุมของ Developer ครับ ซึ่งมีประโยชน์นะ เพื่อจะมาช่วยทำให้ Tester และ Developer สามารถ ทำงานร่วมกันได้อย่างมีความสุขครับ

ยินดีเป็นอย่างยิ่งในการเข้ามาร่วมด้วยช่วยกันครับ ในการสมัครสมาชิกก็เข้าไปที่นี่เลยครับ http://www.welovebug.com/wp-login.php?action=register

หลังจาก Register เสร็จ ส่ง Username มาที่ zyracuze@gmail.com ผมจะเปลี่ยนสิทธิ์ให้เป็น ผู้เขียน ครับ

ถ้า dev จะต้องเสียเวลามาดูว่าอยู่ใน scope ของเขาหรือไ่ม่นั้น ก็ต้องทำ ถ้า 60% ของ issue มันมาจาก core product แล้วก็เป็นเรื่องของ management ต้องคิดว่าทำไม bug ของ core product มันหลุดออกมาถึงเราได้เยอะขนาดนี้ test-case ของ core product นั้นครอบคลุมดีพอแล้วหรือไม่ ผมว่าควรจะค่อยๆทำอย่างนี้ไปเรื่อยๆ เจอ bug แล้วส่งต่อไปเรื่อยๆ จน core-product มัน stable พอ งานของ dev ก็จะน้อยลงเองครับ

สรุปว่า ถ้าเจอและมั่นใจว่าผิด ยังไงก็ต้อง log ครับ จะ scope ของใครแก้ส่วนไหน อีกเรื่องหนึ่ง

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

แต่ อีก Blog นึงที่น่าสนใจ ใน Yahoo Group คือ CQAFolks น่าสนใจมากครับ

ความรู้เพียบเลย

พอดีเข้าไปดู WP มันฉลาดเกิน Detect ว่าอาจจะเป็น SPAM เลยจัดการ Block ซะครับ

ขอบคุณในความคิดเห็นดีดีครับ

ถ้าเราจะให้ Definition ของแต่ละ role ข้างล่างนี้ แตกต่างกันอย่างไร

QA
QC
Test Manager
Test Lead
Test Engineer
Tester
Test Support
Test Coordinator

ผมลองให้ความคิดเห็นกับปัญหา ทั้งสองด้วยดังดนี้ครับ ต่อ จาก คุณ Ekaluck เพิ่มเติมครับ

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

อันนี้ ผมคงต้อง Assume เหมือนกันว่า Root Cause ถูกต้่อง คือ เป็นปัญหา ที่ Core Product จริง ๆ

ตอบ
1. โดยปกติ บริษัท เจ้าของ Software จะมี service support ในการรับแจ้งปัญหา Defect ที่มาจาก Core Product จริง ๆ เราควรจะแจ้งไปให้เขา Analysis ว่า เป็น Defect จาก Core จริงเหรอ เปล่า โดยส่ง Test Case and Data ไป
2. ถ้า เจ้าของ Software พิสูจน์ ว่าไม่ได้ เป็นที่ Core Product เราคงต้องกลับมาดูกัน กับทีม Develop อีกทีหล่ะครับ
3. ถ้า team develop ยังคงไม่รับ defect ตัวนี้ เราก็ต้องดูว่า มัน รุนแรงขนาดไหน ตาม defect category ที่ กำหนดไว้ (เช่น 1 2 3 4) แล้วแต่ว่ามันตกอยู่ใน level ไหน ถ้า 1 และ 2 ค่อนข้างรุนแรง เราควรจะ eหcalate defect ตัวนี้ สู่ Project Manager เพื่อ ขอ accept risk หรือบาง องค์กร มี CCB (change control board) เราก็ควรจะ แสดง defect outstanding ตัวนี้พร้อมทั้งความเสี่ยงของมัน ว่ารุนแรง แค่ไหน เพื่อ ตัดสินใจว่า จะ golive system หรือไม่

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

คำตอบ อันนี้ผมเสนอ ให้ escalate กลุ่ม defect พวกนี้ให้ Executive หรือ User ทราบถึง ความรุนแรง ของ Defect พวกนี้ว่าเสี่ยงขนาดไหน มัน ไม่ตอบโจทย์ Business ยังไง ถ้าให้ขึ้นไปบน Production ถ้า Business Accept Risk ได้ เราก็ให้เขา Signed Off Accept Risk ที่เรา ได้ Identify ไว้ (60% นี่ ผมว่าน่ากลัวมากครับ)

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

คำตอบ ในโลก แห่งความเป็นจริง ปัญหา นี้ เจอกันทุก องค์กรครับกระผม

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

risk ต้องมีการ accept ร่วมกัน ทั้งสามฝ่าย โดย โครงการ Test Manager และ Business User

ตอบแบบเร็ว ๆ อาจจะไม่ ครบ ถ้วนเท่าไหร่หน่ะครับ

- มี regression test ที่มีอยู่แล้วตัวไหน (ไม่ว่าจะเป็น automate หรือ manual) เลือกเอามาใช้ได้มั๊ย
- change ที่เกิดขึ้นในการ upgrade นี้มี risk ที่จะทำให้เกิด regression issue กับ main flow และ core function ได้มากน้อยแค่ไหน
- document scope ในการทำ test ให้ดีและ get agreement/buy in จากคนที่เกี่ยวข้องให้เค้าเห็นด้วยให้ได้ ใน test document ส่วนใหญ่ คนจะให้สำคัญกับส่วน “Items to be tested” มาก และไม่ได้ให้ความสำคัญกับ section “Items NOT to be tested” เพียงพอ ผมว่า challenge อย่างนึงในฐานะ qa/tester คือ จะ วาง items not to be tested ยังไงให้ได้เหมาะสม และสามารถ convince คนอื่นๆได้ว่า เราทำการบ้่านมาดีแล้วว่า ส่วนเหล่านี้เรา plan ที่จะไม่ cover เพราะ …. และมัีนหมายความว่ายังไงกับ user/คนฟัง …. หากไม่มี section นี้ เป็นการยากมากที่เราจะ manage expectationใครได้ เพราะคนส่วนใหญ่ก็จะ assume ว่าtest น่าจะ cover อยู่แล้ว … การ manage expectation ถือเป็นกุญแจสำคัญมากที่จะำทำให้ project บรรลุเป้าหมายได้ครับ

หวังว่าคงพอช่วยได้บ้างนะครับ

have a nice day