Tag Archives: UAT

UAT in Practice, Confirmation and Preparation

ก่อนอื่นต้องกราบขอโทษทุกๆ ท่านที่ลงทะเบียนมาครับ เรื่องจากใบสมัครเพื่อเข้าร่วมลงทะเบียนผมลืมให้ทุกๆ ท่านกรอกอีเมล เลยทำให้ต้องติดต่อประสานงานช้าไป จึงขอสรุปรายละเอียดการเตรียมเนื้อเตรียมตัวเข้าร่วมการแบ่งปันดังต่อไปนี้นะครับ

Continue reading UAT in Practice, Confirmation and Preparation

[Free Course] UAT in Practice on March 23, 2012 and March 24, 2012

วันนี้มาแจ้งรายละเอียดของคอร์ส UAT in Practice (ฟรี) ที่อยากจัดขึ้นเพราะความอยากส่วนตัวที่จะแบ่งปันเรื่องของการทำ  UAT (User Acceptance Testing) จากประสบการณ์ส่วนตัวที่ผ่านมาในสายงานของ Software Testing แต่ต้องบอกก่อนว่าเป็นในเชิงของการแบ่งปันประสบการณ์ และพูดคุย เพื่อแลกเปลี่ยน และให้ในส่วนของวิธีการทำ UAT และการบริหารจัดการครับ

Continue reading [Free Course] UAT in Practice on March 23, 2012 and March 24, 2012

What is UAT?

สวัสดียามเช้าวันอังคารเดือนตุลาคมครับ เช้าที่ท้องฟ้ามีทั้งเมฆฝน และแสงพระอาทิตย์ในเวลาเดียวกัน ในขณะที่น้องในทีมกำลัง ยิง programmer ตับแตก (Performance Testing) อยู่ ผมก็เลยมานั่งเขียนเรื่อง UAT หรือที่มีชื่อเต็มๆ อย่างเป็นทางการว่า User Acceptance Testing

รูปจาก http://geekandpoke.typepad.com

ในช่วงปีกว่าๆ มานี้กระแสเรื่องของ Software Testing มา แรงขึ้น แรงขึ้น และจากผลของตัวเก็บ Stat การเข้ามายัง welovebug ก็พบว่า หนึ่ง ใน keyword การค้นหาก็คือคำว่า UAT ก็เลยมาแนะนำเจ้า UAT ให้รู้จักกันก่อนว่า เขาคือใครคุณ UAT ?

Continue reading What is UAT?

งานที่เสร็จแต่ไม่สุดกับ 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 สามารถเป็นเพื่อนกันได้(แต่อย่าหั้วก็แล้วกันนะค๊า)”                           

Seminar – Win-Win UAT (User Acceptance Test): Experience Sharing

มาอย่างไวครับ เพื่อ 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 เพื่อให้ประสบความสำเร็จ

วันเวลา และสถานที่

กำหนดจัดงานสัมมานาในครั้งนี้

  • วันอังคารที่ 12 พฤษภาคม 2552
  • 13:00น. – 17:00น.
  • ห้องประชุมพุทธคยา ชั้นประชุม 21 อาคารอัมรินทร์พลาซ่า ถ. เพลินจิต  (BTS ชิดลม)  กรุงเทพมหานคร

Continue reading Seminar – Win-Win UAT (User Acceptance Test): Experience Sharing

Seminar – User Acceptance Testing, How To? Progression Update

สวัสดียามสายๆ วันอาทิตย์สุดท้ายของเดือนเมษายน 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 และโทรศัพท์ จนได้ข้อสรุป และรายละเอียดคราวๆ ของงานสัมมนานี้ เมื่อวันที่ 22 เมษายน 2552 ที่ผ่านมา ผู้เขียนก็เลยรีบนำมาลงใน We Love Bug ให้ทันทีเลยครับ

วันอังคารที่ 28 เมษายน 2552 นี้ทางสมาชิก Thailand SPIN Software Testing Working Group จะประชุมกันแบบเห็นหน้าเห็นตา และเจอกันตัวเป็นๆ เพื่อสรุปงานสัมมานาครั้งนี้ให้จบ และดำเนินการประชาสัมพันธ์ สำหรับผู้ที่สนใจที่จะเข้าร่วมงานสัมมานาครั้งนี้ ดังนั้นวันนี้ผู้เขียนขอนำเสนอข้อมูลรายละเอียดต่างๆ ก่อนนำเข้าที่ประชุมให้เพื่อนพ้องน้องพี่ได้รับทราบกันก่อนเลยละกัน
[ad#adsense-468×60]
Continue reading Seminar – User Acceptance Testing, How To? Progression Update

Event – User Acceptance Testing, How To? Brainstorming

User Acceptance Testing

สวัสดีเช้าวันจันทร์ที่ 20 เมษายน 2552 วันที่พยากรณ์อากาศว่าจะร้อนถึง 38 องศา ร้อนตับแลบ กันเลยทีเดียว ช่วงนี้ We Love Bug อ่านจะแผ่วๆ ไปหน่อยเนื่องจากเทศกาลหยุดโน้นนี่นั่นเยอะไปหมด (ข้ออ้าง) แต่มิใช่ว่าหมดมุขแล้วนะครับ ของยังมีอีกเยอะ ก็จะทยอยลงบทความต่างๆ ทั้งที่เป็นจากประสบการณ์การทำงาน และแปลมาจากบทความของเมืองนอกเมืองนาครับ

จั่วหัวไว้เรื่องของ User Acceptance Testing, How To? เนื่องจากปัจจุบันเรื่องของคุณภาพเริ่มจะมาแรง ดังนั้นจะเห็นได้ว่างานด้าน Software Testing จะเริ่มมีความต้องการมากขึ้น แต่ Knowledge และ Know How ของบ้านเราเองยังมีไม่มากนัก หรือว่าจริงๆ แล้วอาจจะมีเยอะ แต่หลบอยู่ในมุมเล็กๆ ซึ่ง User Acceptance Testing หรือ UAT ก็เป็นหนึ่งในเรื่องที่มีคนสนใจ ถามไถ่ มาในเรื่องของวิธีการทำ UAT อย่างไรบ้าง

ดังนั้นทางทีมงาน Thailand SPIN Software Testing Working Group จึงได้จะจัด Event เกี่ยวกับเรื่องของ UAT โดยจะจัดกันในแนวของการแบ่งปันประสบการณ์จากผู้ที่มีประสบการณ์ในการทำ UAT

[ad#adsense-468×60]

Continue reading Event – User Acceptance Testing, How To? Brainstorming

“Get To Know The Writer” “มาทำความรู้จักกับผู้เขียนกันเถอะ”

ได้ฤกษ์งามยามดีเสียทีนะคะ สำหรับการเข้ามาเจิม คอลัมน์ UAT: User Acceptance Test หลังจากที่ซุ่ม(โป่ง) มาหลายอาทิตย์แล้ว แต่ก็ถือว่าโชคยังเข้าข้างอยู่บ้าง ที่ยังไม่โดนประธานของเว็บ ตัดหางปล่อยวัดไปเสียก่อน อันเนื่องจากไม่ยอมแบ่งปันเรื่องราว ดีๆ ให้ชาว Tester แห่งสยาม เสียที

ก่อนที่จะประเดิม เรื่องแรกให้กับ We Love Bug ก็จะถือ โอกาสนี้ เปิดตัว คอลัมน์ UAT เป็นทางการ แล้วก็ อยากจะเชิญชวน พี่ ๆ น้องๆ ชาว Tester แห่งประเทศสยาม เข้ามาร่วมจอยกับเราด้วย ไม่ว่าจะเป็นการแชร์ประสบการณ์จากการทำงาน หรือมาร่วม แบ่งปัน เพิ่มพูน ความรู้ และวิธีการ ในการทำ Test ไม่ว่าจะเป็น Test ประเภทไหนก็ตาม ผ่าน We Love Bug แห่งนี้ค่ะ

เนื่องจากผู้เขียนเองก็ทำงานในวงการไอทีสาย Software Development มาประมาณเกือบ ๆ สิบปี เริ่มงานตั้งแต่ Junior Programmer, Analyst programmer, Software Architect, Senior software engineer etc… ซึ่งส่วนใหญ่ ก็ล้วนเป็นองค์กรประเภท software industry อย่าเพิ่งแปลกใจว่า ทำไมต้องกล่าวถึงสายงานเหล่านั้น ก็เพราะว่า ต้องเกี่ยวข้องและคุ้นเคยกับการ Test ทั้งสิ้น ไม่ว่าจะเป็น Unit Test, System Test, Integration Test, Performance Test … แล้วเมื่อมองย้อนไปในอดีตประมาณสัก 5- 6 ปี ในงานเทสที่ผู้เขียนเคยผ่านมานั้น ก็ต้องยอมรับกันตรงๆ ว่าความเข้มข้น หรือจริงจังในการทำเทสในสายงานยังมีไม่มากพอ หรือพูดอีกอย่างคือ ให้ความสำคัญน้อยกว่า การที่จะ code program หรือ design ระบบให้เสร็จทันกับ timeline ซึ่งโดยสถิติส่วนตัวแล้ว เป็นไปได้น้อยมากที่จะเทสได้ครบทุก case ที่วางไว้หรือทำได้ดีที่สุดก็คือเลือกเทสได้บางเคสเท่านั้น แล้วผลก็คือ เมื่อต้องไปส่งมอบระบบแล้วต้องไปทำ UAT ร่วมกับลูกค้า ก็มักจะพบเจอกับ ดีเฟคที่คาดไม่ถึงเสมอๆ ไม่ว่าจะเป็น บั๊คที่ไม่ควรจะให้ลูกค้าเจอ (unwanted defect) หรือควรจะหาเจอตั้งแต่ในกระบวนการพัฒนาแล้ว และอีกประเภทคือ ระบบไม่สามารถรองรับการทำงานในปัจจุบันของลูกค้าได้อย่าง 100% ซึ่งปัญหานี้ โดยส่วนตัวมองว่า เป็นดีเฟคที่มีโอกาสที่จะเจอได้ในทุกๆ ระบบ หรือทุกบริษัทผู้ผลิตซอฟแวร์ตามสั่ง ซึ่งอาจจะเกิดจากกระบวนการ requirement ซึ่งเป็นต้นทางของการพัฒนาไม่สมบูรณ์ หรือปัญหาจากการ design ที่ไม่สอดคล้องกับความต้องการของลูกค้า ทั้งนี้ทั้งนั้นส่วนหนึ่ง ก็ขึ้นอยู่กับว่าลูกค้าจะสามารถยอมรับระบบนั้นได้ในเงื่อนไขอะไรบ้างเช่น ใช้งานขนานกับระบบเดิมตามช่วงเวลาที่กำหนด เพื่อเก็บดีเฟค เป็นต้น เพราะจะให้ไม่มีดีเฟคเลยนั้น คงเป็นไปได้ยากส์ (no defect free)

และประสบการณ์ต่อจากนั้นของผู้เขียนในช่วงประมาณหกปีหลังนี้ก็เริ่มเข้าใกล้ คำว่า Software Quality มากขึ้น เมื่อมีโอกาสได้เป็นส่วนหนึ่งในการทำงานในส่วนการวางระบบกระบวนการพัฒนาระบบอย่างมีแบบแผนหรือตอนนั้นก็คือ CMM (ปัจจุบัน CMMI) ซึ่งก็ยังต้องทำงานด้าน develop ไปด้วย(พูดง่ายๆ งานเพิ่มขึ้น) ซึ่งตรงนี้ล่ะได้มีโอกาส เรียนรู้ และได้เขียนโพรเซสการทำงานอย่างมีขั้นตอนในเฟสที่ตัวเองรับผิดชอบ รวมถึงการได้เข้าใจและให้ความสำคัญของการ Test เพราะเราได้มีการก่อตั้ง Unit ของการ Test ขื้นมาอีกด้วย และด้วยนโยบายจากเบื้องบนในเรื่องการให้ความสำคัญใน quality ของ ซอฟต์แวร์ ในทุกเฟสของการ develop เราในฐานะ SA ตอนนั้น ก็ต้องควบคุมคุณภาพในระบบที่ตัวเองรับผิดชอบ ไม่ว่าจะ ออกแบบเทสเคสเอง หรือลงมือเทสเพื่อตรวจสอบผลการ unit test ของ PG เองก่อนที่จะส่งออกไปยัง Test Team ก็ทำให้ SA หลายๆ คน alert กันพอสมควรเพราะเท่ากับงานเพิ่มนะเนี่ย(คิดตอนนั้น) แต่ก็สนุกและได้เพิ่มมุมมอง เพราะจากการได้ลองเทส หรือ รีวิว code ของคนอื่นนั้น ก็ทำให้เห็นสไตล์การเขียน โปรแกรมหรือการจัดวางรูปแบบ กระบวนการคิดของแต่ละคนต่างๆกัน อีกอย่างนะคะ ถึงแม้ว่าจะมีการรีวิวกันแล้ว ส่งออกไปให้ Test Team ยังอุตส่าห์ หาบั๊คเจออีก (งานยิ่งเร่งๆ อยู่ ต้องมา ประกอบระบบใหม่อีกละ) ก็มีบ้างที่ SA กับ Test Lead จะไม่ค่อยจะลงรอยกัน (เฉพาะเวลางานนะ)

แต่ ณ วันนี้ ผู้เขียนได้มานั่งอยู่ในมุมอีกมุมหนึ่งของสายงาน คือ IT Test Management ในฐานะ Test Lead ซึ่งโฟกัสการทำเทสใน ส่วน UAT and E2E ใน industry Telco มาได้ เกือบๆจะ สามปีละ เพื่อนๆ พี่ๆ ที่รู้จัก ก็มีถามไถ่ในตอนแรกๆ ว่าเราตัดสินใจดีแล้วหรือ จะเหมาะกับเราเหรอเพราะอาจจะคิดว่าผู้เขียนน่าจะเหมาะที่จะทำสายเดิม คำถามและความห่วงใยมากมายตามมาระยะนึง แต่ก็เข้าใจทุกๆคนที่เป็นห่วงค่ะ แต่จะขอบอกว่าถึงแม้จะหนัก แต่รู้สึกว่าเนี่ยล่ะใช่เลยที่อยากทำ เพราะได้เรียนรู้ระบบใหญ่ๆ ใหม่ๆ หลากหลาย (เพราะว่าทีมนี้รับเทสทั่วราชอาณาจักร 555) บางระบบก็เชื่อมโยงกันซับซ้อน(ซ่อนเงื่อน ไม่ให้เพื่อนรู้) ท้าทายในการทำเทส และท้าทายกับโรคกระเพาะเหลือเกิน และนอกจากจะมี In-house develop แล้ว ก็ยังต้องทำงานกับ supplier มากมายที่ต้องการใบผ่านด่านจากทีมเรา(จะจ่ายเงินหรือไม่ก็ทีมนี้ก็เป็นส่วนหนึ่งล่ะ) ว่าแล้วก็ต้องย้อนกลับไปสมัยเป็น supplier เอง ก็มียากบ้างง่ายบ้าง ในการ ทำ UAT ยิ่งบริษัทไหนไม่มี IT Team เคี่ยวๆ ล่ะก็ สบายไปเลย ได้ sign-off มาง่ายดาย (อิอิ) แต่ตอนนี้มาอยู่ในมุมนี้ ได้มีส่วนในการ ตรวจรับระบบที่มีคุณภาพให้กับบริษัท รู้สึกปลื้มใจจริงๆ ว่าแล้วก็ไม่รอช้า พยายามหาทางงัดกลยุทธิ์ เท่าที่ตัวเองมี หรือจากประสบการณ์ มาใช้ทำงานโดยด่วนเลย ไม่ว่าจะเป็นการ วางแผนการเทส การออกแบบเทสเคส การบริหารจัดการทีม กับ user ที่เชิญมาร่วมกันทำ UAT แล้วไหนจะ มีเรือ่ง test process improvement อีก สนุกนะคะขอบอก

ก็ได้รู้จักกับผู้เขียนไปแล้วนะคะ หวังว่าจะมีผู้สนใจและคอยติดตามผลงานของผู้เขียนและทีมงานท่านอื่นๆกันต่อไป และหวังเป็นอย่างยิ่งว่าเราจะสามารถสร้างสังคมแห่งการเรียนรู้ Software Testing ในประเทศไทย เพื่อยกระดับ คุณภาพของบุคลากรในสายงานนี้ให้ทัดเทียมกับนานาประเทศ

เตรียมตัวพบกับสาระและประสบการณ์ที่น่าสนใจเกี่ยวกับ UAT เร็วๆ นี้ ในหัวข้อ

“มาทำความรู้จัก กับ User Acceptance Testing กันเถอะ

Coming next, we are going to take a closer look at “What is User Acceptance Testing”

“A journey of a thousand miles begins with a single step” Let’s take the first step

LeeFong..