Operaตัวอย่างการทดสอบการยอมรับ (OAT)

ความหมายของ Operaการทดสอบการยอมรับแบบเดิม?

Operaการทดสอบการยอมรับแบบเดิม (OAT) การทดสอบการยอมรับการใช้งาน (Operational Acceptance Testing หรือ OTT) เป็นเทคนิคการทดสอบซอฟต์แวร์ที่ประเมินความพร้อมในการใช้งานของแอปพลิเคชันซอฟต์แวร์ก่อนที่จะนำไปใช้งานจริง เป้าหมายของการทดสอบการยอมรับการใช้งานคือการรับรองว่าระบบและส่วนประกอบต่างๆ เป็นไปตามมาตรฐาน และการทำงานของระบบเป็นไปอย่างราบรื่นตามมาตรฐานที่กำหนด Operaสภาพแวดล้อมเชิงกลยุทธ์ (SOE)

Operaการทดสอบการยอมรับตามขั้นตอน (National Acceptance Testing) เรียกอีกอย่างว่า Operaการทดสอบความพร้อมในการใช้งาน (Operational Readiness Testing หรือ ORT) หรือเรียกสั้นๆ ว่า การทดสอบการปฏิบัติงาน ทั้งสามชื่อนี้อธิบายถึงการตรวจสอบเดียวกัน นั่นคือ ซอฟต์แวร์อาจทำงานได้ตามที่ธุรกิจต้องการแล้ว แต่ยังไม่มีใครพิสูจน์ได้ว่าผู้ที่จะเป็นเจ้าของซอฟต์แวร์นั้นหลังจากการใช้งานจริงสามารถติดตั้ง สำรองข้อมูล รีสตาร์ท ตรวจสอบ และกู้คืนได้

ความแตกต่างดังกล่าวทำให้ OAT อยู่ในกลุ่มเดียวกับ... การทดสอบที่ไม่เกี่ยวข้องกับการทำงาน ประเภทต่างๆ โดยจะถามว่าระบบทำงานอย่างไรภายใต้สภาวะการใช้งานจริง มากกว่าที่จะถามว่าฟังก์ชันนั้นให้คำตอบที่ถูกต้องหรือไม่

ประเภทของ Operaการทดสอบเชิงตรรกะ

Operaการทดสอบระดับท้องถิ่นเป็นกิจกรรมที่ครอบคลุมหลายด้าน แต่ละรายการด้านล่างเป็นการตรวจสอบแยกต่างหากที่มีเงื่อนไขการเข้าและหลักฐานของตนเอง และโดยปกติแล้ววงจรการทดสอบระดับท้องถิ่น (OAT) จะครอบคลุมเกือบทุกรายการเหล่านี้

• การทดสอบการติดตั้ง — ยืนยันว่าสามารถติดตั้ง อัปเกรด และย้อนกลับเวอร์ชันของโปรแกรมในสภาพแวดล้อมเป้าหมายได้ โดยใช้เอกสารประกอบที่ให้มา
• การทดสอบโหลดและประสิทธิภาพ Operaการ — ตรวจสอบว่าระบบสามารถรักษาอัตราการส่งข้อมูลและเวลาตอบสนองตามที่คาดหวังไว้ได้ภายใต้ปริมาณการใช้งานที่ใกล้เคียงกับสภาพการใช้งานจริง ดูเพิ่มเติม การทดสอบประสิทธิภาพ และ โหลดการทดสอบ สำหรับเทคนิคพื้นฐาน
• การทดสอบการสำรองและกู้คืน — พิสูจน์ให้เห็นว่าการสำรองข้อมูลสามารถทำได้ตามกำหนดเวลาและกู้คืนให้กลับมาใช้งานได้จริง ไม่ใช่แค่บันทึกลงดิสก์เท่านั้น
• การทดสอบความปลอดภัย — ตรวจสอบการควบคุมการเข้าถึง ข้อมูลประจำตัว ใบรับรอง และการเสริมความปลอดภัยในสภาพแวดล้อมการทำงาน โปรดดูที่ การทดสอบความปลอดภัย สำหรับวิธีการโดยละเอียด
• Code การวิเคราะห์ — การตรวจสอบแบบคงที่ของโค้ดและการกำหนดค่าที่ส่งมอบเพื่อความสามารถในการบำรุงรักษาและรูปแบบจุดอ่อนที่ทราบก่อนที่จะกลายเป็นภาระงานในระบบการผลิตของใครบางคน
• ล้มเหลวในการทดสอบ — บังคับให้โหนด บริการ หรือไซต์ใดไซต์หนึ่งล้มเหลว และสังเกตว่าโหนดสำรองสามารถเข้ามารับช่วงต่อได้ภายในเวลาที่ตกลงกันไว้หรือไม่
• การทดสอบการกู้คืน — วัดว่าระบบสามารถกลับมาใช้งานได้อย่างสมบูรณ์และรวดเร็วเพียงใดหลังจากเกิดข้อผิดพลาด การทดสอบการกู้คืน อธิบายเทคนิคนี้อย่างละเอียด
• จบสิ้น สภาพแวดล้อมการทดสอบ Operaการทดสอบเชิงตรรกะ — ดำเนินการควบคุมห่วงโซ่ของเซิร์ฟเวอร์ เครือข่าย งาน และอินเทอร์เฟซทั้งหมดเสมือนเป็นหน่วยปฏิบัติการเดียว
• Operaเอกสารแห่งชาติ Review — ตรวจสอบว่าคู่มือการใช้งาน แผนผังบริการ คำสั่งรีสตาร์ท และเส้นทางการแจ้งปัญหาตรงกับระบบที่สร้างขึ้นจริง

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

ทำไม Operaการทดสอบเชิงตรรกะ

Operaการทดสอบเชิงฟังก์ชันมีอยู่เพราะการปล่อยเวอร์ชันที่ตรงตามข้อกำหนดด้านฟังก์ชันการทำงานทุกประการอาจยังไม่สามารถใช้งานได้จริง

• ในระหว่างขั้นตอน OAT การกำหนดค่าซอฟต์แวร์และส่วนประกอบสนับสนุนการปฏิบัติงานจะถูกนำมารวมกันเป็นครั้งแรก
• เป็นการทดสอบการนำการเปลี่ยนแปลงเชิงฟังก์ชันหรือเชิงโครงสร้างไปใช้กับซอฟต์แวร์หรือบริการในสภาพแวดล้อมการทำงานหรือสภาพแวดล้อมที่ไม่เกี่ยวกับการทำงาน
• การทดสอบนี้จะตรวจสอบว่าแอปพลิเคชันสามารถติดตั้งใช้งานบนเครือข่ายได้ตามมาตรฐาน IT Infrastructure Library (ITIL) หรือไม่
• เป็นการบอกว่าซอฟต์แวร์จะทำงานได้ตามที่ออกแบบไว้โดยไม่รบกวนกระบวนการทางธุรกิจหรือไม่
• OAT มุ่งเน้นไปที่ประเด็นหลักๆ เหล่านี้ของผลิตภัณฑ์ซอฟต์แวร์:
  • ความยืดหยุ่น
  • ความสามารถในการฟื้นตัว
  • ความสามารถในการจัดการและการสนับสนุน
  • Integrity

ใครเป็นผู้แสดง Operaการทดสอบระดับชาติและเมื่อใด

รูปแบบการเป็นเจ้าของ OAT แตกต่างจากการทดสอบระดับก่อนหน้าทั้งหมด และความแตกต่างนั้นเองที่อธิบายถึงผลการค้นพบส่วนใหญ่ ผู้ที่ดำเนินการทดสอบนี้คือผู้ที่จะถูกเรียกตัวในเวลาตีสาม

• ผู้ดูแลระบบและวิศวกรโครงสร้างพื้นฐาน — ดำเนินการติดตั้ง สลับระบบเมื่อเกิดข้อผิดพลาด และรีสตาร์ทระบบในสภาพแวดล้อมเป้าหมาย
• Operaข้อเสนอแนะและทีมสนับสนุน — ตรวจสอบความถูกต้องของการแจ้งเตือน เกณฑ์ เส้นทางการยกระดับ และเอกสารการแก้ไขปัญหาที่อ้างอิงถึงในการแจ้งเตือนแต่ละรายการ
• ผู้ดูแลระบบฐานข้อมูลและการสำรองข้อมูล — ทำการสำรองข้อมูลและกู้คืนข้อมูล รวมถึงการกู้คืนไปยังไซต์สำรองแห่งที่สอง
• เจ้าหน้าที่รักษาความปลอดภัยและการปฏิบัติตามกฎระเบียบ — ยืนยันการเสริมความปลอดภัย การควบคุมการเข้าถึง และการบันทึกการตรวจสอบในสภาพแวดล้อมเสมือนจริง
• ผู้จัดการทดสอบ — รวบรวมหลักฐานเข้าไว้ในชุดเอกสารประกอบการตัดสินใจก่อนเปิดใช้งานระบบ

ตัว Vortex Indicator ได้ถูกนำเสนอลงในนิตยสาร วงจรชีวิตการทดสอบซอฟต์แวร์การทดสอบการใช้งานจะอยู่ขั้นตอนสุดท้าย การทดสอบระบบ การทดสอบการยอมรับของผู้ใช้ (User Acceptance Testing: OAT) พิสูจน์ว่าผลิตภัณฑ์ที่ประกอบเสร็จแล้วใช้งานได้ การทดสอบการยอมรับของผู้ใช้พิสูจน์ว่าธุรกิจยอมรับผลิตภัณฑ์นั้น และ OAT พิสูจน์ว่าองค์กรสามารถใช้งานได้จริง เนื่องจาก OAT ต้องการสภาพแวดล้อมที่คล้ายกับสภาพแวดล้อมการใช้งานจริง จึงมักกำหนดเวลา OAT ไว้หลังจากที่เวอร์ชันทดสอบเสร็จสมบูรณ์แล้ว การเปลี่ยนแปลงโค้ดใดๆ หลังจากนั้นจะทำให้กระบวนการกลับไปเริ่มต้นใหม่

ตัวอย่างกรณีทดสอบสำหรับ Operaการทดสอบแห่งชาติหรือข้าวโอ๊ต

ต่อไปนี้คือเช็คลิสต์ที่ใช้งานง่ายสำหรับการทำ OAT แต่ละบรรทัดเขียนขึ้นเพื่อให้ผลลัพธ์เป็นการผ่านหรือไม่ผ่านอย่างชัดเจน ซึ่งเป็นสิ่งที่คณะกรรมการตรวจสอบก่อนการใช้งานจริงต้องการ

1. ไฟล์สำรองข้อมูลที่สร้างไว้ในไซต์หนึ่ง สามารถกู้คืนไปยังไซต์เดียวกันได้
2. ไฟล์สำรองข้อมูลที่สร้างไว้ในไซต์หนึ่ง สามารถกู้คืนไปยังไซต์อื่นได้
3. การนำฟีเจอร์ใหม่ใดๆ มาใช้ในสภาพแวดล้อมการใช้งานจริงจะไม่ส่งผลเสียต่อความสมบูรณ์ของบริการการใช้งานปัจจุบัน
4. กระบวนการดำเนินการสามารถทำซ้ำได้โดยใช้เอกสารที่ถูกต้อง
5. แต่ละส่วนประกอบสามารถปิดและเริ่มต้นการทำงานได้อย่างสำเร็จภายในระยะเวลาที่ตกลงกันไว้
6. สำหรับการแจ้งเตือน การแจ้งเตือนที่สำคัญทั้งหมดจะต้องส่งไปยัง TEC และอ้างอิงถึงเอกสารวิธีแก้ไขที่ถูกต้อง
7. มีการตั้งค่าระบบแจ้งเตือนไว้แล้ว และจะมีการออกประกาศหากค่าที่กำหนดไว้เกินขีดจำกัดที่ตกลงกันไว้
8. เอกสารการกู้คืนระบบใดๆ ที่จัดทำหรือแก้ไข รวมถึงแผนผังการบริการ ถือว่าถูกต้องสมบูรณ์ และควรส่งมอบเอกสารเหล่านี้ให้กับฝ่ายสนับสนุนที่เกี่ยวข้อง
9. ส่วนประกอบใดๆ ที่ได้รับผลกระทบจากความล้มเหลว จะแสดงลำดับการเริ่มต้นใหม่ที่แนะนำ ระยะเวลาในการดำเนินการ และส่วนประกอบที่เกี่ยวข้อง

สิ่งที่ควรเพิ่มเข้าไปในรายการคือกรณีเชิงลบ: จงใจทำลายการพึ่งพาอย่างใดอย่างหนึ่ง จากนั้นตรวจสอบว่าการแจ้งเตือนทำงาน พบ Runbook และลำดับการเริ่มต้นใหม่ที่ระบุไว้ในเอกสารสามารถกู้คืนบริการได้ รายการตรวจสอบที่บันทึกเฉพาะความสำเร็จเท่านั้น ไม่ได้ทดสอบการทำงานเลย

Operaการทดสอบเชิงกระบวนการเทียบกับการทดสอบการยอมรับของผู้ใช้

โอเอทีและ การทดสอบการยอมรับของผู้ใช้ ทั้งสองอย่างเป็นกิจกรรมการอนุมัติ และทั้งสองอย่างมักล่าช้า ซึ่งเป็นเหตุผลที่ทำให้หลายคนสับสน เพราะกิจกรรมทั้งสองตอบคำถามต่างกัน และมีผู้ลงนามอนุมัติต่างกัน

ทั้งสองอย่างเป็นสิ่งที่เสริมซึ่งกันและกัน ไม่ใช่ทางเลือกอื่น เวอร์ชันที่ผ่านการทดสอบ UAT แต่ไม่ผ่านการทดสอบ OAT คือเวอร์ชันที่จะทำงานได้อย่างถูกต้องจนกว่าจะเกิดการขัดข้องครั้งแรก

ข้อดีและข้อเสียของ Operaการทดสอบเชิงตรรกะ

ทีมที่นำ OAT มาใช้มักจะกล่าวถึงประโยชน์ที่คล้ายคลึงกัน และพบกับอุปสรรคที่คล้ายคลึงกัน

ข้อดี

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

ชาเลนจ์ (Challenge)

• สภาพแวดล้อมที่เหมือนกับการใช้งานจริงนั้นมีราคาแพง และการจำลองแบบย่อส่วนจะซ่อนข้อผิดพลาดที่ OAT ตั้งใจจะค้นหาเอาไว้ได้อย่างแนบเนียน
• กิจกรรมดังกล่าวแย่งชิงพื้นที่ในปฏิทินกับกำหนดการวางจำหน่าย ดังนั้นจึงเป็นกิจกรรมแรกที่ถูกตัดออกเมื่อกำหนดการเลื่อนออกไป
• กรณีที่อาจก่อให้เกิดความเสียหายร้ายแรง เช่น การสลับระบบเมื่อเกิดข้อผิดพลาดและการกู้คืนระบบ จำเป็นต้องได้รับการอนุมัติและช่วงเวลาที่เหมาะสม ซึ่งเป็นเรื่องยากที่จะได้รับ
• ผลลัพธ์ขึ้นอยู่กับเจ้าหน้าที่ฝ่ายปฏิบัติการที่กำลังดำเนินการให้บริการจริงอยู่พร้อมกัน

โดยทั่วไปแล้ว วิธีแก้ไขปัญหาคือเริ่มจากสิ่งเล็กๆ ก่อน เช่น ทำให้กระบวนการสำรองข้อมูล กู้คืน และรีสตาร์ทเป็นแบบอัตโนมัติก่อน เนื่องจากกระบวนการเหล่านี้เกิดขึ้นซ้ำทุกครั้งที่มีการออกเวอร์ชันใหม่ และให้สัญญาณที่ชัดเจนที่สุดว่าผ่านหรือไม่ผ่าน จากนั้น รายการตรวจสอบสามารถขยายใหญ่ขึ้นได้ในแต่ละรอบ และการเปลี่ยนแปลงใดๆ ในคู่มือการปฏิบัติงานก็จะกลายเป็นสิ่งที่ต้องตรวจสอบเพิ่มเติม การทดสอบการถดถอย ในเวอร์ชันถัดไป

คำถามที่พบบ่อย