about 2 weeks ago - 3 comments
สวัสดีเช้าวันพุธที่ 24 กุมภาพันธ์ 2553 ครับเพื่อนพ้องน้องพี่ เช้าวันนี้มานั่งเขียนเรื่องลงใน welovebug ก่อนที่จะเริ่มงานประจำวัน โดยใช้ชื่อออกแนวปลุกใจเล็กน้อยว่า “We are Tester” อันสืบเนื่องมาจากเมื่อค่ำคืนที่ 23 กุมภาพันธ์ ผมได้คุยกับคุณโอ (Ekaluck) ทาง MSN และชอบประโยคที่คุณโอใช้เป็นหัวของ MSN
I don’t make software, I make it better.
ได้อ่านแล้วมันโดนมากๆ ครับ กับผมที่ทำงานเป็น Software Tester มาตลอด 5 ปีนี้ แม้ ณ ตอนนี้หน้าที่การงานจะไม่ได้ลงมือไปทำการ Test เอง แต่ผมก็ยังเป็น Software Tester
ตลอดระยะเวลาการทำงานบทบาทของ Software Tester ตั้งแต่สมัยที่ยังไม่ค่อยมีใครจะรู้จักว่า Software Tester คือใคร? มีหน้าที่ทำอะไร? ไม่ว่าจะเป็นในองค์กรขนาด ใหญ่ กลาง และเล็ก จะมีเพียงบางองค์กรที่มีทีม [...]
about 2 months ago - 21 comments
เพื่อนพ้องน้องพี่ทั้งหลายคงจะเจอกับประโยคสุดยอด 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 [...]
about 2 months ago - 3 comments
โบกมือร่ำลาปี พ.ศ. 2552 และอ้าแขนต้อนรับปี พ.ศ. 2553 เป็นที่เรียบร้อยแล้ว เพื่อนพ้องน้องพี่หลายๆ ท่านก็คงจพกำลังสนุกสนาน และใช้เวลากับเพื่อนพ้อง หรือครอบครัวในช่วงเทศกาลแห่งความสุขเช่นนี้ วันว่างๆ สบายๆ แบบนี้ ผมก็เลยลองมานั่งดูเรื่องราว และความเป็นไปต่างๆ บน welovebug ตลอดปี พ.ศ. 2552 ที่ผ่านมา
หลังจากที่นั่งอ่านบทความต่างๆ ที่เพื่อนพ้องน้องพี่หลายๆ ท่านได้นำมาแบ่งปันผ่าน welovebug ก็เลยขอเขียนบทสรุปของเรื่องราว และเหตุการณ์ที่เกิดขึ้นบน welovebug ตลอดปี พ.ศ. 2552 ที่ผ่านมาครับ
มกราคม 2552
14 มกราคม 2552 เป็นวันเกิดครบ 1 ขวบปีของ welovebug (ไม่น่าเชื่อว่าจะอยู่ได้มาถึงปี ) เอาของเก่ามาปัดฝุ่นขายอีกครั้งเผื่อว่าเพื่อนพ้องน้องพี่หลายๆ คนไม่เคยทราบมาก่อน
วันจันทร์ที่ 14 มกราคม พ.ศ. 2551 เวลา 16:31 น., welovebug ลืมตาดูโลกเป็นครั้งแรก
คำตอบ 20 [...]
about 4 months ago - 6 comments
Verification and Validation (V&V) สองคำนี้เพื่อนพ้องน้องพี่หลายๆ คน คงจะคุ้นเคย และก็เกี่ยวข้อง โดยเฉพาะอย่างยิ่ง Software Tester ทั้งหลาย เชื่อได้ว่าหลายๆ คนก็ยังคง งง งง กับเจ้าสองคำนี้อยู่ว่ามันคืออะไร วันนี้ผมก็เลยหยิบยกมาเป็นเรื่องที่จะเขียนลงใน welovebug ครับ
ผมว่าหลายๆ คนคงจะเคยใช้ Verification and Validation ไปค้นใน Search Engine หาว่า ความหมายของเจ้าสองคำนี้คืดอะไร? หรือหลายๆ คนโดนสั่งให้ไปทำ Verification and Validation ของ Software ที่จะพัฒนาขึ้นมา หรือไม่ก็ตรวจรับ Software ทั้งๆ ที่คนสั่ง ก็ไม่รู้เหมือนกันว่า Verification and Validation คืออะไร (แอบนินทา)
บมความนี้ผมเขียนขึ้นมาจากสิ่งที่ได้อ่านมาจาก ตำรา, เอกสารอบรม, บทความบน internet และจากประสบการณ์ทำงานส่วนตัวในงานด้าน Software Testing เผื่อว่าจะเป็นประโยชน์ไม่มากก็น้อยกับเพื่อนพ้องน้องพี่ทั้งหลายครับ
Verification: [...]
about 4 months ago - 12 comments
สวัสดียามค่ำคืนวันเสาร์กลางเดือนตุลาคม 2552 ขณะที่เขียนเรื่องอยู่นี้ อุณหภูมิ 28 องศา (ไม่ได้เกี่ยวอะไรกับเรื่องที่จะเขียนครับ) สองวันที่ผ่านมาผมได้เห็น comment หนึ่ง จากเพื่อนสมาชิกของ welovebug เรา เกี่ยวกับเรื่องของประสบการณ์ และการเตรียมตัวในการสอบ Certified Software Tester หรือที่รู้จักกันในชื่อเล่นว่า CSTE
ในสายงานของ Software Testing เราก็มีการสอบ Certificate เหมือนๆ กับสายงานอื่นนะครับ เพื่อนพ้องน้องพี่ท่านใดที่สนใจก็ติดตามข้อมูลได้จาก http://www.softwarecertifications.org/
เข้าเรื่องเลยละกัน วันนี้ผมนำ comment ของคุณ Nick มาเขียนเป็นเรื่องไว้ เพื่อจะได้เป็นประโยชน์สำหรับเพื่อนพ้องน้องพี่ที่กำลังเตรียมตัวในการสอบ CSTE
การเตรียมตัว ข้อสอบ แนวของ Software Testing
Nick Says:
October 16th, 2009 at 9:24 am
มาร่วมให้ข้อมูลก่อนครับ
สำหรับผม มีประสบการณ์ โดยตรง กับการ สอบ CSQA ซึ่ง CSTE ก็จะเป็น cer ต่อไปที่ [...]
about 5 months ago - 8 comments
วันนี้มาเชิญชวนเพื่อนพ้องร้องพี่ร่วมทำบุญช่วยเหลือน้องๆ ผู้ด้อยโอกาส ณ บ้านเด็กตาบอดผู้พิการซ้ำซ้อน เป็นหนึ่งในกิจกรรมของงาน BugDay ครั้งที่ 1 ที่จะจัดขึ้นใน วันเสาร์ที่ 19 ธันวาคม 2552 วันเสาร์ที่ 28 พฤศจิกายน 2552 นี้
บ้านเด็กตาบอดผู้พิการซ้ำซ้อน
เด็กตาบอดและพิการอย่างอื่นร่วมด้วย เช่น พิการทางสมอง โปลิโอ ฯลฯ ประมาณ 45 คน
ส่วนหนึ่งจะช่วยเหลือตัวเองไม่ได้ แต่อีกส่วนหนึ่งกำลังฟื้นฟู ให้เข้าร่วมเรียนหนังสือกับเด็กปกติ
รับบริจาคทั้งเงินและสิ่งของเครื่องใช้ประจำวัน
ตั้งอยู่ที่ 21/13 ซ.รามอินทรา34 แยก 19 ถ.รามอินทรา แขวงท่าแร้ง เขตบางเขน กรุงเทพมหานคร
โทรศัพท์ 0-2510-4895 / 0-2510-3625
โทรสาร 0-2943-6235
สิ่งของที่จำเป็นให้กับน้องๆ ณ บ้านเด็กตาบอดผู้พิการซ้ำซ้อน
สบู่เดทตอล ( ก้อน/เหลว/ขวด )
น้ำยาฆ่าเชื้อเดทตอล
แป้ง / ยาสีฟัน
แชมพู / ครีมนวด
ถุงมือยางแพทย์ M
น้ำยาถูพื้น / ล้างห้องน้ำ
กางเกงขาสั้น เด็ก ไซร์ S,M,L,XL
ผงซักฟอกสำหรับซักเครื่อง / [...]
about 5 months ago - 2 comments
สวัสดียามเช้าวันอังคารที่ 29 กันยายน 2552 ครับ เช้าวันนี้แวะมาแจ้งข่าวเพิ่มเติมของงาน BugDay ที่จะจัดขึ้น ตอนนี้เปิดรับลงทะเบียนผู้ที่สนใจเข้าร่วมงานในครั้งนี้แล้วครับ
กำหนดการของงาน BugDay
วันเสาร์ที่ 19 ธันวาคม พ.ศ. 2552 วันเสาร์ที่ 28 พฤศจิกายน พ.ศ. 2552
เวลา 09:00 น. – 17:00 น.
สถานที่ จะแจ้งให้ทราบอีกครั้งง ต้องรอดูจำนวนของผู้ที่จะเข้าร่วมงาน BugDay ก่อนครับ ว่าประมาณเท่าไรครับ
งานนี้ ฟรี ครับ ไม่เสียค่าใช้ใจใดๆ ในการร่วมงาน
ลงทะเบียนเข้าร่วมงาน BugDay
http://www.eventpro.in.th/registration/8/BugDay-Bangkok-2009
เริ่มเปิดรับ: วันอังคารที่ 29 กันยายน 2552
ปิดรับ: วันเสาร์ที่ 14 พฤศจิกายน 2552 วันเสาร์ที่ 31 ตุลาคม 2552
รายชื่อผู้ลงทะเบียนงาน BugDay
http://www.eventpro.in.th/registration/report/BugDay-Bangkok-2009
รายละเอียดเพิ่มเติมของงาน BugDay
พบปะ พูดคุย แลกเปลี่ยนประสบการณ์ และทำบุญ กับงาน BugDay
ร่วมกันเสนอเรื่องที่อยากฟัง และอยากแบ่งปันในงาน BugDay
จบข่าวครับ [...]
about 5 months ago - 3 comments
สองสามปีที่ผ่านมานี้ในบ้านในเมืองเรามีกิจกรรมดีๆ เหล่าตระกูล Camp และ Day เกิดขึ้นหลากหลายงานครับ ถ้าที่จะได้ยินกันอย่างกว้างขวางก็คงไม่พ้นงาน BarcampBangkok ผมเองก็ได้มีโอกาสไปร่วมงาน และปล่อยของไปเหมือนกันในงานครั้งที่ผ่านมาครับ
ในส่วนของ Software Testing ในบ้านเรา กิจกรรมแนวๆ เดียวกันก็จะเป็นของทาง ThailandSPIN เป็นผู้จัดงานสัมมานาต่างๆ ซึ่งเพื่อนพ้องน้องพี่หลายๆ ท่านก็ได้มีโอกาสไปร่วมงาน
ผมเองก็ไปร่วมงานทั้ง 2 แบบที่กล่าวมาข้างต้นอยู่หลายๆ ครั้ง ก็มีความคิดขึ้นมาในหัวว่าอยากจะจัดงานแบบนี้เหมือนกัน แต่ก็ปล่อยมันเป็นเพียงความคิดมาตลอด จนกระทั่งต้นเดือนกันยายนนี้ ได้ปรึกษากับเพื่อนพ้องน้องพี่ สองสามคน ได้ข้อสรุปมาว่า จัดเถอะ เอา จัดก็จัดครับ
BugDay
พอตัดสินใจว่าจะจัดงาน คำถามแรกที่ผุดขึ้นมาในหัวก็คือ “ชื่องานไรดี?”
Tester Day ?
BugDay ?
ทั้งสองเป็นชื่อที่นึกขึ้นมาได้ในหลายๆ สัปดาห์ ลองถามๆ กับ เพื่อนพ้องน้องพี่ หลายๆ คนว่า ชอบชื่อไหน บ้างก็ชอบ Tester Day บ้างก็ชอบ BugDay เอาหล่ะ งานเข้าซิครับแบบนี้ คะแนน vote พอๆ กันเลย !!!
ผมเอง [...]
about 6 months ago - 12 comments
สวัสดียามสายวันอังคารที่สองของเดือนกันยายนนะครับ เผลอนิดเดียวก็เกือบจะสิ้นปี 2552 อีกแล้ว เวลาเดินทางไวจริงๆ เลยนะครับนี่ ห่้างหายไปนานเลยที่ไม่ได้เขียนเรื่องลงบน welovebug วันนี้ก็เลยเข้ามาเขียนเรื่องลงซะหน่อยดีกว่า เก็บๆ ข้อมูลไว้เยอะเลย แต่ต้อง build อารมรณ์ตัวเองให้ได้ถึงจะเขียนได้ครับ
หลังจากที่เคยได้นำเสนอเรื่องขำๆ แอบเสียดสี Developer และ Programmer ไป กับเรื่อง คำตอบ 20 อันดับแรก ที่เหล่า Programmer มักจะตอบเมื่อพบ Bug และต่อยอดคัด 10 คำตอบเด็ดๆ ไป นำเสนอในงาน Barcamp Bangkok ครั้งที่ 3 โดยใช้ชื่อ Session ที่ไปพูดในวันนั้นว่า Top 10 programmer’s answer when tester find bugs วันนี้กลับมาอีกครั้งด้วยบทความหยิกแกมหยอก สำหรับเหล่า Developer และ Programmer อีกครั้ง กับ 24 [...]
about 8 months ago - 7 comments
ในที่สุดเราก็มาถึง Phase สุดท้าย แต่คงไม่ท้ายสุดกันแล้วล่ะค่ะ (เย้ ๆๆๆ …….) ที่บอกว่า Phase สุดท้ายนั้น เพราะในขั้นตอนนี้จะเป็นขั้นตอนการทำงานที่เราจะปิด หรือ สรุปงานทั้งหมดกันแล้วล่ะค่ะ (งานเสร็จ แว้ววววว) อ๊ะ ๆๆ แต่ก็อย่างที่กล่าวค่ะ ว่า แต่มันไม่ท้ายสุด เพราะอะไรเหรอค่ะ จากประสบการณ์ที่ผ่านมา มันจะมี Defects อยู่จำนวนหนึ่ง ที่มีการสรุปไว้ว่า “เดี๋ยวค่อยแก้อีกทีนะ …..” (เหอ ๆๆๆ “เดี๋ยว” คำ ๆ นี้ ช่างทำร้ายจิตใจน้อย ๆ ของ tester ยิ่งนัก เพราะช่วงความกว้างของเวลาช่างนานแสนนาน…… เลยทีเดียว) ทั้งนี้ ก็อาจจะด้วยหลาย ๆ ปัจจัยนะค่ะ
เวลา [...]
about 1 month ago
1. ถ้ามีการเก็บตัว specs ของ product ที่บริษัททำเอาไว้ ค่อนข้างดีและมี log ของการเปลี่ยนแปลงเอาไว้สมบูรณ์ ถ้าอ้างอิิงจากตรงนั้นก็จะทำให้รู้ว่า มันเป็น Bug ในส่วนของ customization หรือ Core Product ได้ไม่ยากครับ
ถ้าเวลาในการ 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 ให้คุ้มค่า
about 7 months ago
คุณ DevGuli
ขอบคุณที่แวะเข้ามาชมครับ ผมว่าเราเป็นเพื่อนกันอยู่ใน twitter นะ
และขอบคุณสำหรับความคิดเห็น และมุมมองในมุมของ Developer ครับ ซึ่งมีประโยชน์นะ เพื่อจะมาช่วยทำให้ Tester และ Developer สามารถ ทำงานร่วมกันได้อย่างมีความสุขครับ
about 7 months ago
คุณ Nick ครับ
ยินดีเป็นอย่างยิ่งในการเข้ามาร่วมด้วยช่วยกันครับ ในการสมัครสมาชิกก็เข้าไปที่นี่เลยครับ http://www.welovebug.com/wp-login.php?action=register
หลังจาก Register เสร็จ ส่ง Username มาที่ zyracuze@gmail.com ผมจะเปลี่ยนสิทธิ์ให้เป็น ผู้เขียน ครับ
about 7 months ago
ผมอ่านคำถามไม่ค่อยเข้าใจ แต่ถ้าเดาตามที่คุณ Ekaluck ว่าคือ core product หมายถึง 3rd-party product ผมก็ยังสงสัยว่าเราสามารถเลือกจะไ่ม่ fix ได้ด้วยหรือครับ จริงๆแล้วจะหมายความว่าไม่ fix โดยทีมเรา แต่สามารถส่งต่อไปให้เจ้าของ core-product ทีมนั้นทำแทนอย่างนี้ใช่ไหมครับ ผมคิดว่าที่ tester ทำการ log defect ไปนั้นก็ถูกต้องแล้ว เพราะ tester ทำการ test ตาม use-case ซึ่ง use-case มันก็คือสิ่งที่เราคิดว่า user ต้องใช้ (ใช้มากใช้นอยอีกเรื่องหนึ่ง) ถ้า test ตาม use-case แล้วไม่ผ่านก็หมายความว่า user จะใช้ product เราใน scenario นั้นไม่ได้ ซึ่ง user คงไม่ได้สนใจว่าไม่ได้นี่เพราะส่วน core หรือส่วน customization คงต้องเป็นเรื่องของฝ่าย management ที่ต้องคุยกันกับ 3rd-party หรือทีม core product ว่าจะส่งต่อ defect กันยังไง
ถ้า dev จะต้องเสียเวลามาดูว่าอยู่ใน scope ของเขาหรือไ่ม่นั้น ก็ต้องทำ ถ้า 60% ของ issue มันมาจาก core product แล้วก็เป็นเรื่องของ management ต้องคิดว่าทำไม bug ของ core product มันหลุดออกมาถึงเราได้เยอะขนาดนี้ test-case ของ core product นั้นครอบคลุมดีพอแล้วหรือไม่ ผมว่าควรจะค่อยๆทำอย่างนี้ไปเรื่อยๆ เจอ bug แล้วส่งต่อไปเรื่อยๆ จน core-product มัน stable พอ งานของ dev ก็จะน้อยลงเองครับ
สรุปว่า ถ้าเจอและมั่นใจว่าผิด ยังไงก็ต้อง log ครับ จะ scope ของใครแก้ส่วนไหน อีกเรื่องหนึ่ง
about 7 months ago
อืม Blog นี้น่าสนใจดีครับผม
นาน ๆ จะได้เห็นสักที ในเมืองไทย เลยเข้ามาแจมครับ แล้วสมัครไงครับเนี่ย
แต่ อีก Blog นึงที่น่าสนใจ ใน Yahoo Group คือ CQAFolks น่าสนใจมากครับ
ความรู้เพียบเลย
about 7 months ago
Comment กลับมาแล้วครับ คุณ Nick
พอดีเข้าไปดู WP มันฉลาดเกิน Detect ว่าอาจจะเป็น SPAM เลยจัดการ Block ซะครับ
ขอบคุณในความคิดเห็นดีดีครับ
about 7 months ago
เอ่อ ตอบไป ตั้งเยอะ เมจเสจ หายไปครับผม
about 7 months ago
พอดีอ่านบทความอันนี้ แล้ว ก็ อยากทราบมุมมอง ของแต่ละคนครับ
ถ้าเราจะให้ 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
ตอบแบบเร็ว ๆ อาจจะไม่ ครบ ถ้วนเท่าไหร่หน่ะครับ
about 8 months ago
ส่วนปัญหาข้อสองที่บอกว่ามีเวลาไม่พอ เลยทำให้ test ได้แค่ส่วน customization เท่านั้น ปัญหานี้เป็นปัญหาที่เจอทั่วไปสำหรับงาน QA อยู่แล้ว สำหรับในกรณีนี้ ที่เป็นการ upgrade version ก็คงต้องดูว่า
- มี 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
about 8 months ago
ขอบคุณคุณโอมากครับ สำหรับคำแนะนำ
about 8 months ago
หลังจากเกริ่นแนวคิดไปแล้ว ในแง่ปฏิบัติ หนึ่งในแนวทางที่จะเป็นไปได้
สำหรับปัญหา 1 ก็คือ
- Evaluate impact ของ issue ที่เจอกับลูกค้าจริงๆ ถ้าจำนวน issue มันเยอะถึง 60 % ของ issue ที่เคย log ไป ลองปรึกษา project manager ดูว่าน่าจะดีมั๊ยถ้าจะจัดเป็น mini workshop/meeting สั้นๆที่จะ evaluate real impact โดยรวมที่จะเกิดขึ้นกับลูกค้าจริง โดยinclude ตัวแทนลูกค้าแค่ซักคนสองคน ถึงผมจะเป็น QA แต่บางครั้งเราก็ต้องยอมรับว่ามีกรณีที่ tester เจตนาดีและคิดแทนลูกค้ามากเกินไป ทำให้นึกว่า issue หรือ featureนั้นๆจำเป็นสำหรับลูกค้าแน่ๆ ในขณะที่จริงๆแล้วสำหรับลูกค้า อาจไม่ได้เป็น big deal ขนาดนั้น ทั้งนี้ทั้งนั้น ประเด็นที่สำคัญคือเราต้องสามารถสื่อสารประเด็นของเราได้อย่างดีว่า สิ่งที่เรา concern คือต่อให้ไม่ใช่ scope หรือ bug ของเราโดยตรง แต่หาก impact กับลูกค้ามันสูงจริง ทำให้ลูกค้าใช้บางอย่างในระบบไม่ได้ ลูกค้าที่ไม่ happy เค้าก็ไม่อยากทำงานร่วมกับเราหรือใช้ระบบที่เราส่งมอบไปอยู่ดี สิ่งที่อยากหาคำตอบตอนนี้คือมัน impact ลูกค้าเยอะจริงรึเปล่า
- ด้วย output จาก workshop ตรงนี้ น่าจะทำให้เราเห็นภาพความเสี่ยงโดยรวมว่า impact ในเชิง quality กับลูกค้าเป็นอย่างไร หากอยู่ในเกณฑ์ที่ลูกค้ารับได้ ทุกคนเข้าใจตรงนี้ตรงกันผมว่า tensionก็น่าจะลดลง ทุกคนก็น่าจะอุ่นใจในระดับนึง แต่หากว่าไม่ ok ก็คงจะต้องมี action ต่อๆไป ไม่ว่าจะเป็นว่าทางเราหา workaround ให้ลูกค้า หรือติดต่อเจ้าของ core product เพื่อ report defect และ follow up เรื่อง patch ของเจ้า core product ต่อไป
- หากว่าข้อสรุปคือ issue ส่วนใหญ่ ok ไม่ได้ impact อะไรมาก สิ่งที่อยากจะเสนอให้ลองดูก็คือ ทำอย่างไรให้ “help me(QA) help you(dev) … โดยมีโจทย์ที่ว่า เรารู้สึกว่ามันไม่คุ้มเวลาทั้งเค้าและเราที่จะต้องมา report issue core product แล้วก็ investigate โดยที่สุดท้ายมันอาจจะไม่ให้ value เรามาก มีทางไหนมั๊ยที่เค้าจะ guide เราว่าจะดูยังไง ว่ามันน่าจะเป็นspecific กับ core product รึเปล่า หรือมันมี reference พวก release note หรือ known issues ของ core product อยู่แล้ว หากมีข้อมูลนี้คร่าวๆแล้วค่อยๆเสริมเติมไปเรื่อยๆ ก็น่าจะลดจำนวน issue ที่เรา report ไปแล้ว reject กลับได้ ที่สำคัญคือต้องคอย document เก็บไว้ (แต่อาจไม่จำเป็นต้อง formal อะไรมาก) และคอย update เมื่อพบว่ามีจุดที่ขาดหรือพลาดไปที่ guideline ไม่ cover … ข้อดีอีกอย่างนึงที่มี doc ตรงนี้เก็บไว้ ก็คือ วันนึงลูกค้าก็เอาระบบเราไปใช้งานอยู่ดี และคงเป็นไปได้ยากว่าเค้าจะรู้ดีกว่า qa ว่าissue เป็น core product มั๊ย ..doc ตัวนี้ก็จะเป็นตัวช่วยกรอง issue ที่จะส่งมาถึงบริษัทเราอีกตัวนึงนั่นเอง …
about 8 months ago
สวัสดีครับ พูดตรงๆปัญหานี้ค่อนข้างตอบยาก ถ้าไม่ได้อยู่ในสถานการณ์นั้นจริงๆ ผมคงต้องลอง make assumption 1ข้อแล้วเริ่มให้ความเห็นจากตรงนั้นละกันครับ
Assumption คือ Core Product เป็น product ที่ไม่ได้ถูกพัฒนาขึ้นโดยบริษัทเรา แต่เป็น 3rd party application
ที่ทางบริษัททำมา customized เพื่อให้ meet กับ requirement ของลูกค้า
ถ้า assumption นี้ไม่ถูก ความเห็นนี้ก็คงไม่ fit กับ caseดังกล่าว
แต่ถ้า assumption นี้ใช้ได้ ผมก็อยากจะขอเริ่มความเห็นด้วยสองประเด็นครับ
1. ในบางกรณี บริษัทกับลูกค้าอาจมีข้อตกลงในสัญญากันไว้อยู่แล้วว่า หากเป็น issue ที่เกิดขึ้นจากตัว 3rd party application ทางบริษัทจะขอไม่รับผิดชอบสำหรับ issue หรือ defectนั้นๆ
ซึ่งในนัยหนึ่งก็สมเหตุสมผล เพราะบริษัทไม่มี access ถึง source code และความรู้ภายในเชิงลึกของ 3rd party app นั้นๆ
2. ในกรณีที่คนสองฝ่ายมีความเห็นไม่ตรงกัน (ในกรณีนี้ dev vs. qa) อาจจะไม่มีฝ่ายไหนคิดถูกเลยก็ได้ แทนที่จะยึดความคิดของฝ่ายใดฝ่ายนึง น่าจะมองปัญหาจากภาพรวมและ collaborate ด้วยกันเพื่อนำไปสู่จุดหมายสุดท้ายร่วมกัน
เดี๋ยวจะยาวเกินไปสำหรับ comment ผมจะ post ที่เหลือไว้ใน comment ถัดไปละกันนะครับ …