[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
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 ให้คุ้มค่า
คุณ DevGuli
ขอบคุณที่แวะเข้ามาชมครับ ผมว่าเราเป็นเพื่อนกันอยู่ใน twitter นะ
และขอบคุณสำหรับความคิดเห็น และมุมมองในมุมของ Developer ครับ ซึ่งมีประโยชน์นะ เพื่อจะมาช่วยทำให้ Tester และ Developer สามารถ ทำงานร่วมกันได้อย่างมีความสุขครับ
คุณ Nick ครับ
ยินดีเป็นอย่างยิ่งในการเข้ามาร่วมด้วยช่วยกันครับ ในการสมัครสมาชิกก็เข้าไปที่นี่เลยครับ http://www.welovebug.com/wp-login.php?action=register
หลังจาก Register เสร็จ ส่ง Username มาที่ zyracuze@gmail.com ผมจะเปลี่ยนสิทธิ์ให้เป็น ผู้เขียน ครับ
ผมอ่านคำถามไม่ค่อยเข้าใจ แต่ถ้าเดาตามที่คุณ 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 ของใครแก้ส่วนไหน อีกเรื่องหนึ่ง
อืม Blog นี้น่าสนใจดีครับผม
นาน ๆ จะได้เห็นสักที ในเมืองไทย เลยเข้ามาแจมครับ แล้วสมัครไงครับเนี่ย
แต่ อีก Blog นึงที่น่าสนใจ ใน Yahoo Group คือ CQAFolks น่าสนใจมากครับ
ความรู้เพียบเลย
Comment กลับมาแล้วครับ คุณ Nick
พอดีเข้าไปดู 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
ตอบแบบเร็ว ๆ อาจจะไม่ ครบ ถ้วนเท่าไหร่หน่ะครับ
ส่วนปัญหาข้อสองที่บอกว่ามีเวลาไม่พอ เลยทำให้ 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
ขอบคุณคุณโอมากครับ สำหรับคำแนะนำ
หลังจากเกริ่นแนวคิดไปแล้ว ในแง่ปฏิบัติ หนึ่งในแนวทางที่จะเป็นไปได้
สำหรับปัญหา 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 ที่จะส่งมาถึงบริษัทเราอีกตัวนึงนั่นเอง …
สวัสดีครับ พูดตรงๆปัญหานี้ค่อนข้างตอบยาก ถ้าไม่ได้อยู่ในสถานการณ์นั้นจริงๆ ผมคงต้องลอง 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 ถัดไปละกันนะครับ …