Testing Doesn't Finish…It's Just STOP!
งานที่เสร็จแต่ไม่สุดกับ 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 สามารถเป็นเพื่อนกันได้(แต่อย่าหั้วก็แล้วกันนะค๊า)”
| Print article | This entry was posted by patcharaporn on July 11, 2009 at 1:40 pm, and is filed under Software Testing, User Acceptance Testing. Follow any responses to this post through RSS 2.0. You can leave a response or trackback from your own site. |
No trackbacks yet.
What is UAT?
about 11 months ago - 14 comments
สวัสดียามเช้าวันอังคารเดือนตุลาคมครับ เช้าที่ท้องฟ้ามีทั้งเมฆฝน และแสงพระอาทิตย์ในเวลาเดียวกัน ในขณะที่น้องในทีมกำลัง ยิง programmer ตับแตก (Performance Testing) อยู่ ผมก็เลยมานั่งเขียนเรื่อง UAT หรือที่มีชื่อเต็มๆ อย่างเป็นทางการว่า User Acceptance Testing รูปจาก http://geekandpoke.typepad.com ในช่วงปีกว่าๆ มานี้กระแสเรื่องของ Software Testing มา แรงขึ้น แรงขึ้น และจากผลของตัวเก็บ Stat การเข้ามายัง welovebug ก็พบว่า หนึ่ง ใน keyword การค้นหาก็คือคำว่า UAT ก็เลยมาแนะนำเจ้า UAT ให้รู้จักกันก่อนว่า เขาคือใครคุณ UAT ? UAT คืออะไร? บทความนี้เขียนขึ้นจากประสบการณ์ และความรู้ที่มีอยู่ในตัวเกี่ยวกับเรื่องของ UAT เพื่อที่จะสร้างความรู้ และความเข้า ให้กับเพื่อนพ้องน้องพี่หลายๆ ท่าน ที่อาจจะยังไม่รู้จักคุณ UAT ซึ่งหา่กเพื่อนพ้องน้องพี่ท่านอื่นๆ ที่
24 คำตอบสุดฮิตของ Programmer เมื่อ Software มีปัญหา
about 1 year 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 อีกครั้ง กับ
[Forum] มักจะได้คำตอบจาก Developer ว่า Out of Scopes ทำไงดีค่ะ!!!
about 1 year ago - 12 comments
สวัสดียามค่ำคืนวันจันทร์ที่ฝนตกโปรยปรายครับ อากาศเย็นสบาย แต่ก็ระมัดระวังที่จะไม่สบายกันด้วยนะครับ เข้าเรื่องเลยละกันนะครับ ได้มีเพื่อนพ้องน้องพี่ของเราได้ไปถามไว้ที่ Software Testing Forum ไว้ ดังนี้ครับ ตอนนี้กำลังสับสนว่า เวลา Log Issue ไป มักจะได้คำตอบจาก Developer ว่า Out of Scopes. ในมุมมอง QA ที่ถ้าเจอ Issue ก็จะ Log เพราะ Concern ในเรื่อง Quality แต่ ในมุมมอง Developer หรือ Project Team ถ้าเรื่องที่เจออยู่นอกเหนือ Scopes งานที่ต้องแก้ไข ในโปรเจคที่มีเรื่อง Budget และ เวลาเป็นเงื่อนไข ที่เขาต้องใช้ไปในการ Investigate งานที่นอกเหนือ Scopes เราจะมีวิธีการจัดการกับปัญหานี้อย่างไรดี รบกวนช่วยแนะนำด้วยคะ ยกตัวอย่างเคส เช่น ลูกค้าทำการ Upgrade ระบบจาก
Seminar – Win-Win UAT (User Acceptance Test): Experience Sharing
about 1 year ago - 7 comments
มาอย่างไวครับ เพื่อ Update ข่าวเรื่องของงานสัมมานา User Acceptance Testing, How To? ที่จะจัดขึ้นโดย Thailand SPIN Software Testing Working Group หลังจากที่ได้ประชุมกันเกือบๆ 3 ชั่วโมง เมื่อวันที่ 28 เมษายน 2552 ที่ผ่านมาก็ได้ข้อสรุปของงานสัมมานาในครั้งนี้ออกมาดังต่อไปนี้ครับ ชื่องานสัมมานา หลังจากพูดคุย และเสนอความคิดเห็นต่างๆ กันในที่ประชุมถึง Theme รวมทั้งจุดประสงค์ของงานสัมมานาในครั้งนี้อยู่นาน หลังจากสรุปได้ ก็คิดถึงเรื่องของชื่องานสัมมานานครั้งนี้ จากเดิมที่ปักป้ายไว้เล่นๆ ว่า User Acceptance Testing, How To? ทางสมาชิกก็ลงความเห็นว่าน่าจะใช้ชื่องานที่ดูเจาะลงไปเลยว่างานสัมมานาในครั้งนี้เราจะบอกถึงอะไร สมาชิกได้สรุป และเห็นชอบที่จะใช้ชื่อของงานสัมมานาครั้งนี้ว่า Win-Win UAT (User Acceptance Test): Experience Sharing ที่มาของชื่อก็มองกันว่าอยากจะให้สื่อถึงการร่วมไม้ร่วมมือกันของส่วนต่างๆ ที่เกี่ยวข้องกับการทำ User Acceptance Testing เพื่อให้ประสบความสำเร็จ
Seminar – User Acceptance Testing, How To? Progression Update
about 1 year ago - 4 comments
สวัสดียามสายๆ วันอาทิตย์สุดท้ายของเดือนเมษายน 2552 ครับ เข้ามาแจ้งความคืบหน้าในส่วนของงานสัมมนา User Acceptance Testing, How To? ที่จัดโดย Thailand SPIN Software Testing Working Group ก็เป็นงานสัมมานาแรกของปี 2552 หลังจากงานสัมมานา Performance Testing by Sanook.com ที่จัดไปเมื่อปลายปี 2551 ที่ผ่านมาครับ หลังจากที่ได้ทำการระดมสมองกันภายในสมาชิกของ Thailand SPIN Software Testing Working Group ก็ได้ข้อสรุปของหัวข้อที่จะนำมาสนทนากันในงานออกเป็น 9 หัวข้อ ตามที่ได้นำเสนอไปจากบทความแรกของงาน User Acceptance Testing, How To? ไปแล้วนั้น ทางสมาชิกของ Thailand SPIN Software Testing Working Group ก็ได้พูดคุยกันผ่าน Email และโทรศัพท์ จนได้ข้อสรุป
Event – User Acceptance Testing, How To? Brainstorming
about 1 year ago - 4 comments
สวัสดีเช้าวันจันทร์ที่ 20 เมษายน 2552 วันที่พยากรณ์อากาศว่าจะร้อนถึง 38 องศา ร้อนตับแลบ กันเลยทีเดียว ช่วงนี้ We Love Bug อ่านจะแผ่วๆ ไปหน่อยเนื่องจากเทศกาลหยุดโน้นนี่นั่นเยอะไปหมด (ข้ออ้าง) แต่มิใช่ว่าหมดมุขแล้วนะครับ ของยังมีอีกเยอะ ก็จะทยอยลงบทความต่างๆ ทั้งที่เป็นจากประสบการณ์การทำงาน และแปลมาจากบทความของเมืองนอกเมืองนาครับ จั่วหัวไว้เรื่องของ User Acceptance Testing, How To? เนื่องจากปัจจุบันเรื่องของคุณภาพเริ่มจะมาแรง ดังนั้นจะเห็นได้ว่างานด้าน Software Testing จะเริ่มมีความต้องการมากขึ้น แต่ Knowledge และ Know How ของบ้านเราเองยังมีไม่มากนัก หรือว่าจริงๆ แล้วอาจจะมีเยอะ แต่หลบอยู่ในมุมเล็กๆ ซึ่ง User Acceptance Testing หรือ UAT ก็เป็นหนึ่งในเรื่องที่มีคนสนใจ ถามไถ่ มาในเรื่องของวิธีการทำ UAT อย่างไรบ้าง ดังนั้นทางทีมงาน Thailand SPIN
My Defect Management ตอนที่1 Overview
about 1 year ago - 11 comments
สวัดดีค่ะ สำหรับตอน 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 ต่างๆ หรือ
ทำยังไงดี Bug โดน Reject อีกแล้ว
about 1 year ago - 9 comments
สวัสดีครับ หลังจากที่คราวที่แล้วเล่าเรื่อง Test Efficiency & Effectiveness ให้ฟังกันไปแล้ว คราวนี้มาลองคุยกันเรื่องเบาๆ (แต่อาจจะเป็นเรื่องที่ทำให้หลายๆคนเกิดอาการเซ็งกันได้บ่อยๆ) กันหน่อยดีกว่าครับ คำพูดที่หลายๆคนคุ้นหู “ตัวนี้มันไม่ใช่ Bug นะครับคุณTester นี่มัน Expect Behavior มันต้องเป็นอย่างนี้แหล่ะ เชื่อผมๆ” มีใครเคยได้ยินประโยคคลาสสิคแนวๆนี้มั่งมั๊ยครับ แล้วลองคิดดูนะครับ ว่าที่ผ่านมาเรามี reaction อย่างไรกับคำพูดนี้ เท่าที่ผมเคยเห็น หรือเคยได้ฟังคนมาบ่นบ่อยๆ ก็จะมีสองกรณีหลักๆ 1. “เอ่อออ เหรอ จริงเหรอ มันต้องเป็นอย่างนี้จริงๆเหรอ… อ่า แต่มันดูแปลกๆนะ อ่า…. เหรอ ไม่ใช่จริงๆ หรอ… อืมๆๆ ไม่ใช่ก็ได้แหล่ะมั้ง เดี๋ยวไป reject ให้ละกันนะ” หรือแบบที่สอง (หลังจากที่โดน Reject มาสิบตัว อารมณ์กำลังคุกรุ่น อาจจะเป็นแบบนี้) 2. “อะไรนะ ไม่ใช่อีกแล้วเหรอ ทำไม Report มาสิบตัว
จุดประกาย : ทำไม Softwareต้องมี bug (ตอนที่ 2)
about 2 years ago - 4 comments
จุดประกาย : ทำไม Softwareต้องมี bug (ตอนที่ 2) – การพัฒนาระบบอย่างต่อเนื่องเพื่อไล่ตาม requirement จุดประสงค์ของ software ที่ใช้ในธุรกิจส่วนใหญ่ ทำออกมาเพื่อตอบรับความต้องการของธุรกิจหลักขององค์กรที่ใช้ระบบนั้นๆ เพื่อให้ธุรกิจเป็นไปอย่างแข่งขัน (low cost + high efficiency) กลยุทธ์ของธุรกิจจึงมีการเปลี่ยนแปลงตลอดเวลา ส่งผลให้ระบบ software requirement ต่างๆจำเป็นจะต้องมีการปรับเปลี่ยนอยู่บ่อยๆ หากแต่การปรับเปลี่ยนโครงสร้างของระบบให้สอดคล้องกับความเปลี่ยนแปลงที่เกิดขึ้นเรื่อยๆนั้น นับมีความท้าทายอยู่อย่างมาก โดยเฉพาะอย่างยิ่ง เมื่อเวลาผ่านไปจนบุคคลกรที่พัฒนา software เกิดการหมุนเวียน บางคนถูกย้ายไปทำงาน project อื่น บางคนลาออกจากบริษัท หรือบริษัท/ตัว product ถูกซื้อไป การรับช่วงต่อเปลี่ยนมือคนทำ software ที่ไม่ได้มีการดำเนินการที่ดี โดยเฉพาะเอกสารที่ไม่ครบถ้วนหรือ update ก็เป็นการเปิดโอกาสที่ทำให้เกิดbug ได้เช่นเดียวกัน – การ test ทุกอย่างที่เป็นไปไม่ได้ ลองนึกถึง web application ตัวนึงที่มี 5 use
จุดประกาย : ทำไม Softwareต้องมี bug (ตอนที่ 1)
about 2 years ago - 1 comment
ผมขอเริ่มต้นการจุดประกายครั้งแรก ด้วยหัวข้อ “ทำไม Softwareต้องมี bug” ด้วยเหตุผลสองประการครับ หนึ่ง – การมีตัวตนของ software bug เป็นต้นกำเนิดของอาชีพ software tester (สงสัยนี่ก็อาจเป็นส่วนนึงที่ทำให้ชื่อ webนี้เป็น welovebug กระมังครับ 555) สอง – เคยมีคน(นอกวงการ IT)ถามผมว่า ทำไมคนในวงการ ITก็มีแต่เก่งๆทั้งนั้น projectแต่ละอันก็ราคาหลายแสนหลายล้านแต่ก็ยังทำระบบที่ไม่มีbugออกมากันไม่ได้ แม้กระทั่งบริษัทชื่อดังและรวยที่สุดอย่าง Microsoftก็ตาม (ตอนโดนถามก็จุกใช่เล่นครับ) ก่อนที่จะไปไล่ดูสาเหตุของ software bug/defect กัน เรามาลองทำความเข้าใจให้ตรงกันก่อนดีมั๊ยครับ ว่า bug คืออะไรผมได้ไปรวบรวมมาจาก 3 แหล่งซึ่งความหมายค่อนข้างใกล้เคียงกันครับ Wikipedia ซึ่งดูเหมือนจะเข้าใจง่ายที่สุด: A software bug (or just “bug”) is an error, flaw, mistake, “undocumented feature”, failure,
about 1 year ago
ยินดีต้อนรับค่ะ คุณ minimalist สามารถเข้ามาแชร์ไอเดียได้นะคะ ร่วมด้วยช่วยก้นค๊า
about 1 year ago
สวัสดีครับ คุณ patcharaporn
ผม ณรงค์ นะครับ ตามมาสมัครเป็นสมาชิกเว็บนี้อย่างเป็นทางการครับ หลังจากเข้ามาอ่านเอาความรู้ดี ๆ มานานแล้ว
ผมฝากเผยแพร่ approach ด้าน Software Architectural Testing และ Software Architectural Test Case ด้วยนะครับ ลอง discuss แลกเปลี่ยนกันนะครับ แล้วผมจะแวะมาเยี่ยมบ่อย ๆ เลยครับ แล้วผมจะขอมาแชร์ไอเดียและขอแวะมาเขียน blog มั่งนะครับ และอยากได้ไอเดียหลาย ๆ อย่างจากชุมชมแห่งนี้เช่นเดียวกัน
สุดท้ายขอแจม blog ของคุณ patcharaporn มั่งครับ
“การเขียน Architectural Test Case นั้นมันมาก แต่เขียนยากเอาเรื่อง เพราะลงเทคนิคมาก”
และ
“การเขียน Test Script โดยเฉพาะเขียนให้เป็น Program Script ยิ่งโหด-มัน-ฮา”
ส่วนเรื่องการ set environment, เตรียม test data, set baseline และ configuration management เห็นด้วยครับ ซึ่งสำคัญมาก ๆ
นอกจากนี้เห็นด้วยกับคุณ up1 ที่ต้องเขียน test case ให้ครอบคลุม การจินตนาการและการคิดนอกกรอบช่วยได้เยอะเลยครับ แต่ที่สำคัญสุด ๆ คือความเข้าใจ requirements และ domain knowledge
และเห็นด้วยกับคุณ Zyracuze ครับว่าโปรแกรมทุกตัวย่อมมี bug / defect ทั้งนั้นครับ เพราะในการพัฒนาโปรแกรมเรามีข้อจำกัดสำคัญคือ เงิน คน เวลา ดังนั้นคุณภาพของโปรแกรมจึงต้องมีข้อจำกัดด้วย การตีกรอบคุณภาพ (Quality Zone / Area) จึงสำคัญ
แต่อย่างที่คุยกันน่ะครับ เรามักพบปัญหาจาก requirements บ่อย ๆ ที่มักไม่สมบูรณ์เพียงพอ
เอาไว้จะมาแจมใหม่นะครับ
ณรงค์
.-= minimalist´s last blog ..ทำความเข้าใจกับ ‘Software Architecture’ เชิงเปรียบเทียบกัน =-.
about 1 year ago
สวัสดีครับ อ่านแล้วขอถามหน่อยนะครับ ผมทำงานด้านเทส เหมือนกันแต่เสต็ปไม่ทราบว่าเหมือนกันป่าว ผม UAT > ITR > STR > UATR สุดท้ายและท้ายสุด deploy ขึ้น Production ครับ ขนาดเทสกันกระทำแบบนี้ยังมีหลุด แต่นิดหน่อย ทำใจครับ
about 1 year ago
คุณ -0-
ฟังดูจะไม่ค่อย Happy เท่าไรกับทีมที่ทำงานอยู่นะครับ แต่ดูแล้วคำว่า เกลียด นี่มันจะดูแรงไปนิด ลองบอกเล่าปัญหาที่ประสบพบเจอมาได้นะครับที่ zyracuze@gmail.com เพื่อจะได้ร่วมด้วยช่วยกันแก้ไขปัญหาครับ
.-= Zyracuze´s last blog ..Software Testing Working Group Meeting#4/2009 =-.
about 1 year ago
เห้อ ! ผมเกลียดทีม SIT Project ที่ผมทำจังเลยครับ เบื่อเป็นการส่วนตัวทำให้การทำงานไม่ราบรื่นเท่าไร
about 1 year ago
ขอบคุณคุณ up1 มากคะ
1. เรื่อง environment ก็เจอเหมือนกัน UAT ใช้ 1 server แต่พอ production ทำแบบ load balance มี 8 server
จะมีประเด็นกับงาน interface file คือ 1 วันต้องการ interface 1 file บางวันมี file ถูก interface มากกว่า 1 file
ทำให้ข้อมูลซ้ำกัน ทาง programmer ต้องเขียนโปรแกรมดัก case เพิ่ม
2. เรื่อง Requirement ถ้าไม่ชัดเจน ที่บริษัทจะใช้เทคนิคคือ test team ทำ test case แล้ว เชิญประชุม
USER,BA,SA ,DEV สรุป test case ด้วยกัน บางที test case ที่เราเขียน BA ก็นำกลับไปเพิ่มเป็น requirement ก็มี
แต่ถ้า Requirement ไม่ชัดเจนจาก user เชื่อได้เลยว่า ตอนที่พี่แกทำ UAT ไอเดียบรรเจิด แน่นอน ตอนนั้นละ new requirment เพิ่ม
มาอีกเป็นโหล ๆ เลยล่ะ
about 1 year ago
ปัญหาที่ผมเจอเป็นประจำ และไม่คิดจะเปลี่ยนแปลงหรือปรับปรุงกันเลยคือ
1. เรื่อง environment ของ server ทั้ง Dev, Testing, Staging และ Production ไม่เหมือนกันเลย ทำให้เกิดปัญหาขึ้นมาแล้วขอบเขตของการค้นหาปัญหายากมากๆ
2. เรื่องของ Requirement ที่ไม่มีหรือไม่ชัดเจน ทำให้มีการสร้าง Test case ที่ไม่ครอบคลุม ทำให้ระบบ fail ได้อย่างง่ายดาย
ปล. เรื่องมี bug หรือไม่ใน program นั้น ผมมีความเชื่อลึกๆ ว่า ถ้าระบบไม่มี bug แสดงว่าไม่มีใครใช้งานระบบ ดังนั้นถ้ามี bug น่าจะยินดีมากกว่าไม่มี bug นะครับ แต่ขอให้ bug ที่เกิดขึ้นนั้น ไม่ใช่ bug แบบโง่ๆ หรือ bug แบบทั่วไป ที่ใครๆ ก็เจอ
about 1 year ago
ขอบคุณพี่อิ๋ว สำหรับบทความครับ และขออนุญาติเข้าไปปรับแก้รูปแบบเล็กๆ น้อยๆ นะครับ
about 1 year ago
Defect อยู่กับ Software หรือ Application ตลอดเวลาครับ อยู่ที่ใครจะเจอ เมื่อไรครับ
There will always be a chance that software will contain errors.
Software testing does not prove that software is error-free.
Software testing is to minimize the risk of errors occurring.
ต้องปรับมุมมอง และความเข้าใจ ของ Developer ว่า Tester เข้ามาร่วมด้วยช่วยกันเพื่อให้ Defect ลดลงให้ได้มากที่สุด และกำจัด Defect ที่จะส่งผลต่อ Business ให้ได้มากที่สุดครับ
.-= Zyracuze´s last blog ..Instructor at CU: Software Testing Experience Sharing =-.