License
งานที่เสร็จแต่ไม่สุดกับ UAT
11 Jul2009
กับคำพูดที่ว่า “แล้วเจอกันบน 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 สามารถเป็นเพื่อนกันได้(แต่อย่าหั้วก็แล้วกันนะค๊า)”
9 Responses to งานที่เสร็จแต่ไม่สุดกับ UAT
Zyracuze
July 11th, 2009 at 2:06 pm
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 =-.
Zyracuze
July 11th, 2009 at 2:07 pm
ขอบคุณพี่อิ๋ว สำหรับบทความครับ และขออนุญาติเข้าไปปรับแก้รูปแบบเล็กๆ น้อยๆ นะครับ
up1
July 11th, 2009 at 2:46 pm
ปัญหาที่ผมเจอเป็นประจำ และไม่คิดจะเปลี่ยนแปลงหรือปรับปรุงกันเลยคือ
1. เรื่อง environment ของ server ทั้ง Dev, Testing, Staging และ Production ไม่เหมือนกันเลย ทำให้เกิดปัญหาขึ้นมาแล้วขอบเขตของการค้นหาปัญหายากมากๆ
2. เรื่องของ Requirement ที่ไม่มีหรือไม่ชัดเจน ทำให้มีการสร้าง Test case ที่ไม่ครอบคลุม ทำให้ระบบ fail ได้อย่างง่ายดาย
ปล. เรื่องมี bug หรือไม่ใน program นั้น ผมมีความเชื่อลึกๆ ว่า ถ้าระบบไม่มี bug แสดงว่าไม่มีใครใช้งานระบบ ดังนั้นถ้ามี bug น่าจะยินดีมากกว่าไม่มี bug นะครับ แต่ขอให้ bug ที่เกิดขึ้นนั้น ไม่ใช่ bug แบบโง่ๆ หรือ bug แบบทั่วไป ที่ใครๆ ก็เจอ
patcharaporn
July 12th, 2009 at 9:22 am
ขอบคุณคุณ 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 เพิ่ม
มาอีกเป็นโหล ๆ เลยล่ะ
-0-
July 19th, 2009 at 10:24 pm
เห้อ ! ผมเกลียดทีม SIT Project ที่ผมทำจังเลยครับ เบื่อเป็นการส่วนตัวทำให้การทำงานไม่ราบรื่นเท่าไร
Zyracuze
July 20th, 2009 at 7:32 am
คุณ -0-
ฟังดูจะไม่ค่อย Happy เท่าไรกับทีมที่ทำงานอยู่นะครับ แต่ดูแล้วคำว่า เกลียด นี่มันจะดูแรงไปนิด ลองบอกเล่าปัญหาที่ประสบพบเจอมาได้นะครับที่ zyracuze@gmail.com เพื่อจะได้ร่วมด้วยช่วยกันแก้ไขปัญหาครับ
.-= Zyracuze´s last blog ..Software Testing Working Group Meeting#4/2009 =-.
Ton
July 20th, 2009 at 5:28 pm
สวัสดีครับ อ่านแล้วขอถามหน่อยนะครับ ผมทำงานด้านเทส เหมือนกันแต่เสต็ปไม่ทราบว่าเหมือนกันป่าว ผม UAT > ITR > STR > UATR สุดท้ายและท้ายสุด deploy ขึ้น Production ครับ ขนาดเทสกันกระทำแบบนี้ยังมีหลุด แต่นิดหน่อย ทำใจครับ
minimalist
August 1st, 2009 at 12:14 pm
สวัสดีครับ คุณ 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’ เชิงเปรียบเทียบกัน =-.
Patcharaporn
August 4th, 2009 at 7:40 am
ยินดีต้อนรับค่ะ คุณ minimalist สามารถเข้ามาแชร์ไอเดียได้นะคะ ร่วมด้วยช่วยก้นค๊า