STLC - คู่มือฉบับย่อ

STLC ย่อมาจาก Software Testing Life Cycle STLC คือลำดับของกิจกรรมต่างๆที่ดำเนินการโดยทีมทดสอบเพื่อรับรองคุณภาพของซอฟต์แวร์หรือผลิตภัณฑ์

  • STLC เป็นส่วนหนึ่งของ Software Development Life Cycle (SDLC) แต่ STLC เกี่ยวข้องกับขั้นตอนการทดสอบเท่านั้น

  • STLC เริ่มต้นทันทีที่มีการกำหนดข้อกำหนดหรือ SRD (Software Requirement Document) ถูกแบ่งปันโดยผู้มีส่วนได้ส่วนเสีย

  • STLC จัดเตรียมกระบวนการทีละขั้นตอนเพื่อให้แน่ใจว่าซอฟต์แวร์มีคุณภาพ

  • ในช่วงแรกของ STLC ในขณะที่ซอฟต์แวร์หรือผลิตภัณฑ์กำลังพัฒนาผู้ทดสอบสามารถวิเคราะห์และกำหนดขอบเขตของการทดสอบเกณฑ์การเข้าและออกรวมถึงกรณีทดสอบ ช่วยลดรอบเวลาการทดสอบพร้อมกับคุณภาพที่ดีขึ้น

  • ทันทีที่ขั้นตอนการพัฒนาสิ้นสุดลงผู้ทดสอบจะพร้อมสำหรับกรณีทดสอบและเริ่มต้นด้วยการดำเนินการ สิ่งนี้ช่วยในการค้นหาจุดบกพร่องในระยะเริ่มต้น

ขั้นตอน STLC

STLC มีขั้นตอนที่แตกต่างกันดังต่อไปนี้ แต่ไม่จำเป็นต้องปฏิบัติตามทุกขั้นตอน ขั้นตอนต่างๆขึ้นอยู่กับลักษณะของซอฟต์แวร์หรือผลิตภัณฑ์เวลาและทรัพยากรที่จัดสรรสำหรับการทดสอบและรูปแบบของ SDLC ที่จะปฏิบัติตาม

STLC มี 6 ขั้นตอนหลัก -

  • Requirement Analysis - เมื่อ SRD พร้อมและแบ่งปันกับผู้มีส่วนได้ส่วนเสียทีมทดสอบจะเริ่มการวิเคราะห์ระดับสูงเกี่ยวกับ AUT (แอปพลิเคชันภายใต้การทดสอบ)

  • Test Planning - ทีมทดสอบวางแผนกลยุทธ์และแนวทาง

  • Test Case Designing - พัฒนากรณีการทดสอบตามขอบเขตและเกณฑ์

  • Test Environment Setup - เมื่อสภาพแวดล้อมรวมพร้อมที่จะตรวจสอบผลิตภัณฑ์

  • Test Execution - การตรวจสอบผลิตภัณฑ์แบบเรียลไทม์และค้นหาจุดบกพร่อง

  • Test Closure - เมื่อการทดสอบเสร็จสิ้นเมทริกซ์รายงานผลลัพธ์จะถูกจัดทำเป็นเอกสาร

ในบทนี้เราจะเข้าใจปัจจัยของการเปรียบเทียบระหว่าง STLC และ SDLC ให้เราพิจารณาประเด็นต่อไปนี้และเปรียบเทียบ STLC และ SDLC

  • STLC เป็นส่วนหนึ่งของ SDLC อาจกล่าวได้ว่า STLC เป็นส่วนย่อยของชุด SDLC

  • STLC จำกัด เฉพาะขั้นตอนการทดสอบที่รับรองคุณภาพของซอฟต์แวร์หรือผลิตภัณฑ์ SDLC มีบทบาทสำคัญอย่างยิ่งในการพัฒนาซอฟต์แวร์หรือผลิตภัณฑ์อย่างสมบูรณ์

  • อย่างไรก็ตาม STLC เป็นขั้นตอนที่สำคัญมากของ SDLC และผลิตภัณฑ์ขั้นสุดท้ายหรือซอฟต์แวร์ไม่สามารถปล่อยออกมาได้โดยไม่ผ่านกระบวนการ STLC

  • STLC ยังเป็นส่วนหนึ่งของวงจรหลังการเผยแพร่ / อัปเดตขั้นตอนการบำรุงรักษาของ SDLC ที่ทราบข้อบกพร่องได้รับการแก้ไขหรือเพิ่มฟังก์ชันการทำงานใหม่ให้กับซอฟต์แวร์

ตารางต่อไปนี้แสดงปัจจัยการเปรียบเทียบระหว่าง SDLC และ STLC ตามขั้นตอน -

เฟส SDLC STLC
การรวบรวมความต้องการ
  • Business Analyst รวบรวมความต้องการ
  • ทีมพัฒนาวิเคราะห์ข้อกำหนด
  • หลังจากระดับสูงทีมพัฒนาจะเริ่มวิเคราะห์จากสถาปัตยกรรมและมุมมองการออกแบบ
  • ทีมทดสอบตรวจสอบและวิเคราะห์เอกสาร SRD
  • ระบุข้อกำหนดการทดสอบ - ประเด็นสำคัญขอบเขตการตรวจสอบและการตรวจสอบความถูกต้อง
  • ตรวจสอบข้อกำหนดสำหรับความสัมพันธ์เชิงตรรกะและเชิงฟังก์ชันระหว่างโมดูลต่างๆ สิ่งนี้ช่วยในการระบุช่องว่างในระยะเริ่มต้น
ออกแบบ
  • สถาปัตยกรรมของ SDLC ช่วยให้คุณพัฒนาการออกแบบซอฟต์แวร์ระดับสูงและระดับต่ำตามข้อกำหนด
  • นักวิเคราะห์ธุรกิจทำงานเกี่ยวกับการจำลองการออกแบบ UI
  • เมื่อออกแบบเสร็จแล้วผู้มีส่วนได้ส่วนเสียจะลงนาม
  • ใน STLC โดยทั่วไปแล้ว Test Architect หรือ Test Lead จะวางแผนกลยุทธ์การทดสอบ
  • ระบุจุดทดสอบ
  • การจัดสรรทรัพยากรและไทม์ไลน์สรุปได้ที่นี่
การพัฒนา
  • ทีมพัฒนาเริ่มพัฒนาซอฟต์แวร์
  • ผสานรวมกับระบบต่างๆ
  • เมื่อการรวมทั้งหมดเสร็จสิ้นจะมีการจัดเตรียมซอฟต์แวร์หรือผลิตภัณฑ์ที่พร้อมสำหรับการทดสอบ
  • ทีมทดสอบเขียนสถานการณ์การทดสอบเพื่อตรวจสอบคุณภาพของผลิตภัณฑ์
  • กรณีการทดสอบโดยละเอียดถูกเขียนขึ้นสำหรับโมดูลทั้งหมดพร้อมกับพฤติกรรมที่คาดหวัง
  • ข้อกำหนดเบื้องต้นและเกณฑ์การเข้าและออกของโมดูลทดสอบจะระบุไว้ที่นี่
ตั้งค่าสภาพแวดล้อม
  • ทีมพัฒนาตั้งค่าสภาพแวดล้อมการทดสอบด้วยผลิตภัณฑ์ที่พัฒนาขึ้นเพื่อตรวจสอบความถูกต้อง
  • ทีมทดสอบยืนยันสภาพแวดล้อมที่ตั้งขึ้นตามข้อกำหนดเบื้องต้น
  • ทำการทดสอบควันเพื่อให้แน่ใจว่าสภาพแวดล้อมมีความเสถียรสำหรับผลิตภัณฑ์ที่จะทดสอบ
การทดสอบ
  • การทดสอบจริงจะดำเนินการในระยะนี้ ซึ่งรวมถึงการทดสอบหน่วยการทดสอบการรวมการทดสอบระบบการทดสอบข้อบกพร่องการทดสอบการถดถอย ฯลฯ
  • ทีมพัฒนาจะแก้ไขข้อบกพร่องที่รายงานหากมีและส่งกลับไปยังผู้ทดสอบเพื่อทดสอบซ้ำ
  • การทดสอบ UAT ดำเนินการที่นี่หลังจากออกจากระบบจากการทดสอบ SIT
  • การทดสอบการรวมระบบจะเริ่มขึ้นตามกรณีการทดสอบ
  • หากมีรายงานข้อบกพร่องจะได้รับการทดสอบและแก้ไขอีกครั้ง
  • การทดสอบการถดถอยจะดำเนินการที่นี่และผลิตภัณฑ์จะถูกลงชื่อออกเมื่อตรงตามเกณฑ์การออก
การปรับใช้ / การเปิดตัวผลิตภัณฑ์
  • เมื่อได้รับการลงชื่อออกจากทีมทดสอบต่างๆแล้วแอปพลิเคชันจะถูกปรับใช้ในสภาพแวดล้อม prod สำหรับผู้ใช้จริง
  • การทดสอบควันและความมีสติสัมปชัญญะในสภาพแวดล้อมการผลิตเสร็จสมบูรณ์ที่นี่ทันทีที่นำผลิตภัณฑ์ไปใช้งาน
  • รายงานการทดสอบและการเตรียมเมทริกซ์ทำได้โดยทีมทดสอบเพื่อวิเคราะห์ผลิตภัณฑ์
ซ่อมบำรุง
  • ครอบคลุมถึงการสนับสนุนหลังการปรับใช้การเพิ่มประสิทธิภาพและการอัปเดตหากมี
  • ในระยะนี้การดูแลกรณีทดสอบชุดการถดถอยและสคริปต์อัตโนมัติจะเกิดขึ้นตามการปรับปรุงและการปรับปรุง

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

เพื่อให้บรรลุเป้าหมายเหล่านี้มีการกำหนดหลักการพื้นฐาน 7 ประการสำหรับการทดสอบซอฟต์แวร์ -

การทดสอบแสดงอะไร

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

การทดสอบแบบละเอียดเป็นไปได้หรือไม่?

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

การทดสอบเบื้องต้น

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

การจัดกลุ่มข้อบกพร่อง

จากการวิเคราะห์ข้อบกพร่องของผลิตภัณฑ์ก่อนหน้านี้สามารถกล่าวได้ว่าข้อบกพร่องส่วนใหญ่ถูกระบุจากโมดูลชุดเล็ก ๆ ซึ่งมีความสำคัญต่อการใช้งาน โมดูลเหล่านี้สามารถระบุได้ตามความซับซ้อนการโต้ตอบของระบบที่แตกต่างกันหรือการพึ่งพาโมดูลอื่น ๆ หากผู้ทดสอบสามารถระบุโมดูลที่สำคัญเหล่านี้ได้พวกเขาสามารถมุ่งเน้นไปที่โมดูลเหล่านี้มากขึ้นเพื่อระบุจุดบกพร่องที่เป็นไปได้ทั้งหมด จากการศึกษาพบว่ามีข้อบกพร่อง 8 ใน 10 ข้อจากการทำงาน 20% ของ AUT

ยาฆ่าแมลง Paradox

ความขัดแย้งของสารกำจัดศัตรูพืชคืออะไร - หากมีการใช้สารกำจัดศัตรูพืชบ่อยๆในพืชผลจะเกิดขึ้นเมื่อแมลงพัฒนาความต้านทานบางชนิดและค่อยๆยาฆ่าแมลงที่ฉีดพ่นดูเหมือนจะไม่ได้ผลกับแมลง

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

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

การทดสอบขึ้นอยู่กับบริบท

หลักการนี้ระบุว่าไม่สามารถทดสอบแอปพลิเคชันสองประเภทโดยใช้แนวทางเดียวกันได้จนกว่าทั้งสองแอปพลิเคชันจะมีลักษณะเดียวกัน ตัวอย่างเช่นหากผู้ทดสอบใช้แนวทางเดียวกันสำหรับ Web Based Application และ Mobile Application นั่นเป็นสิ่งที่ผิดอย่างสิ้นเชิงและมีความเสี่ยงสูงที่คุณภาพของผลิตภัณฑ์จะไม่ดี ผู้ทดสอบควรใช้แนวทางวิธีการเทคนิคและความครอบคลุมที่แตกต่างกันสำหรับประเภทและลักษณะการใช้งานที่แตกต่างกัน

ไม่มีข้อผิดพลาด - เข้าใจผิด

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

การวิเคราะห์ความต้องการเป็นขั้นตอนแรกของ STLC และจะเริ่มทันทีที่แชร์ SRD / SRS กับทีมทดสอบ ให้เราพิจารณาประเด็นต่อไปนี้เพื่อทำความเข้าใจการวิเคราะห์ความต้องการใน STLC

  • เกณฑ์การเริ่มต้นของระยะนี้คือข้อกำหนดของ SRS (ข้อกำหนดข้อกำหนดของซอฟต์แวร์); ขอแนะนำว่าสถาปัตยกรรมแอปพลิเคชันมีประโยชน์

  • ในระยะนี้ทีม QA จะวิเคราะห์ในระดับที่สูงขึ้นว่าจะทดสอบอะไรและจะทดสอบอย่างไร

  • ทีม QA ติดตามผู้มีส่วนได้ส่วนเสียต่างๆเช่น Business Analyst, System Architecture, Client, Test Manager / Lead ในกรณีที่จำเป็นต้องมีการสอบถามหรือคำชี้แจงเพื่อทำความเข้าใจข้อกำหนด

  • ข้อกำหนดอาจใช้งานได้หรือไม่ทำงานเช่นประสิทธิภาพการทำงานความปลอดภัยการใช้งาน ฯลฯ หรือทั้งฟังก์ชันและไม่ทำงาน

  • เกณฑ์การออกของขั้นตอนนี้คือการกรอกเอกสาร RTM รายงานความเป็นไปได้ของระบบอัตโนมัติและรายการคำถามหากมีความเฉพาะเจาะจงมากขึ้นเกี่ยวกับข้อกำหนด

กิจกรรมที่ดำเนินการเพื่อการวิเคราะห์ความต้องการ

มีกิจกรรมหลักสามอย่างที่ดำเนินการโดยทีม QA ในระยะนี้ กิจกรรมได้อธิบายไว้ด้านล่าง

การกำหนดขอบเขต

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

เตรียม RTM

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

เมทริกซ์ถูกสร้างขึ้นที่จุดเริ่มต้นของโปรเจ็กต์เนื่องจากเป็นพื้นฐานของขอบเขตของโปรเจ็กต์และสิ่งที่ส่งมอบที่จะเกิดขึ้น

เมทริกซ์เป็นแบบสองทิศทางเนื่องจากติดตามความต้องการไปข้างหน้าโดยการตรวจสอบผลลัพธ์ของสิ่งที่ส่งมอบและย้อนหลังโดยดูความต้องการทางธุรกิจที่ระบุไว้สำหรับคุณลักษณะเฉพาะของผลิตภัณฑ์

การวิเคราะห์อัตโนมัติ

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

ในบทนี้เราจะเห็นเกณฑ์การเข้าและออกในระดับต่างๆใน STLC ต้องพิจารณาประเด็นต่อไปนี้เพื่อทำความเข้าใจกับเกณฑ์

ตามหลักการแล้วทีม QA จะไม่ดำเนินการในขั้นตอนต่อไปจนกว่าจะตรงตามเกณฑ์การออกของเฟสปัจจุบัน เกณฑ์การเข้าควรรวมถึงเกณฑ์การออกจากเฟสก่อนหน้านี้

ตามเวลาจริงจะไม่สามารถรอเฟสถัดไปได้จนกว่าจะถึงเกณฑ์การออก ตอนนี้สามารถเริ่มขั้นตอนต่อไปได้หากการส่งมอบที่สำคัญของเฟสก่อนหน้าเสร็จสมบูรณ์

ในแต่ละขั้นตอนของ STLC ควรกำหนดเกณฑ์การเข้าและออก

เกณฑ์การเข้า

เกณฑ์รายการสำหรับขั้นตอน STLC สามารถกำหนดเป็นเงื่อนไขเฉพาะ หรือเอกสารทั้งหมดที่จำเป็นในการเริ่มขั้นตอนเฉพาะของ STLC ควรมีอยู่ก่อนที่จะเข้าสู่เฟส STLC ใด ๆ

เกณฑ์การเข้าคือชุดของเงื่อนไขที่อนุญาตให้งานดำเนินการหรือหากไม่มีเงื่อนไขใด ๆ เหล่านี้งานจะไม่สามารถดำเนินการได้

ในขณะที่ตั้งค่าเกณฑ์การเข้าเป็นสิ่งสำคัญเช่นกันที่จะต้องกำหนดกรอบเวลาเมื่อรายการเกณฑ์รายการพร้อมใช้งานเพื่อเริ่มกระบวนการ

สำหรับอินสแตนซ์ในการเริ่มขั้นตอนการพัฒนากรณีทดสอบควรปฏิบัติตามเงื่อนไขต่อไปนี้ -

  • ควรมีเอกสารข้อกำหนด
  • จำเป็นต้องมีความเข้าใจอย่างสมบูรณ์เกี่ยวกับขั้นตอนการสมัคร
  • เอกสารแผนการทดสอบควรพร้อม

ออกจากเกณฑ์

เกณฑ์การออกสำหรับขั้นตอน STLC สามารถกำหนดเป็นรายการ / เอกสาร / การดำเนินการ / งานที่ต้องทำให้เสร็จก่อนที่จะสรุปเฟสปัจจุบันและย้ายไปยังเฟสถัดไป

เกณฑ์การออกคือชุดของความคาดหวัง ควรปฏิบัติตามก่อนที่จะสรุปขั้นตอน STLC

สำหรับอินสแตนซ์เพื่อสรุปขั้นตอนการพัฒนากรณีทดสอบควรปฏิบัติตามความคาดหวังดังต่อไปนี้ -

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

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

เกณฑ์การยอมรับคือชุดของข้อความที่กล่าวถึงอย่างชัดเจนเกี่ยวกับผลลัพธ์ที่คาดว่าจะผ่าน / ล้มเหลว เกณฑ์การยอมรับระบุทั้งข้อกำหนดด้านฟังก์ชันและไม่ใช้งาน ข้อกำหนดเหล่านี้แสดงถึง“ เงื่อนไขของความพึงพอใจหรือพฤติกรรมที่คาดหวัง” ไม่มีการยอมรับบางส่วน ตรงตามเกณฑ์หรือไม่ตรงตามเกณฑ์

เกณฑ์เหล่านี้กำหนดขอบเขตและพารามิเตอร์ของฟังก์ชัน / โมดูลและกำหนดว่าฟังก์ชัน / โมดูลเสร็จสมบูรณ์และทำงานตามที่คาดไว้หรือไม่

เกณฑ์การยอมรับระดับสูงจะกล่าวถึงในระดับแผนการทดสอบ เกณฑ์การยอมรับจะถูกแปลงเป็นรายการจุดที่ต้องตรวจสอบหรือผลลัพธ์ที่คาดหวังในระดับกรณีทดสอบ

เกณฑ์การยอมรับถูกกำหนดบนพื้นฐานของคุณลักษณะต่อไปนี้ -

  • ความถูกต้องตามหน้าที่และความสมบูรณ์
  • ความสมบูรณ์ของข้อมูล
  • การแปลงข้อมูล
  • Usability
  • Performance
  • Timeliness
  • การรักษาความลับและความพร้อมใช้งาน
  • ติดตั้งและอัพเกรดความสามารถ
  • Scalability
  • Documentation

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

แผนการทดสอบประกอบด้วยอะไรบ้าง?

แผนการทดสอบมีดังต่อไปนี้

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

ประเด็นสำคัญสำหรับการวางแผนการทดสอบ

ประเด็นต่อไปนี้ต้องได้รับการพิจารณาสำหรับการวางแผนการทดสอบใน STLC

  • ตามหลักการแล้วนักวิเคราะห์การทดสอบ (หัวหน้า) / ผู้จัดการจะเตรียมเอกสารกลยุทธ์การทดสอบ / แผนการทดสอบ

  • การวิเคราะห์มุ่งเน้นไปที่ข้อมูล / สารสนเทศที่เกี่ยวข้องกับแอปพลิเคชัน

  • เป็นช่วงแรกของงานทดสอบจริง

  • ระยะนี้จะตอบว่า“ ต้องทดสอบอะไร” และ“ ต้องใช้ทรัพยากรอะไรในการทดสอบ”

  • เกณฑ์การเข้าขั้นพื้นฐานของเฟสนี้คือการจัดเตรียมเอกสารความต้องการ (เวอร์ชันปรับปรุงของข้อกำหนดที่ไม่ชัดเจน / ขาดหายไป / ชี้แจง) พร้อมกับเมทริกซ์การตรวจสอบย้อนกลับความต้องการ

  • หากระบบอัตโนมัติอยู่ในขอบเขตควรจัดทำรายงานความเป็นไปได้ของระบบอัตโนมัติก่อนเข้าสู่ขั้นตอนนี้

  • เกณฑ์การออกของขั้นตอนนี้คือการเสร็จสิ้นของเอกสารกลยุทธ์การทดสอบ / แผนการทดสอบและเอกสารประมาณการความพยายามในการทดสอบ

ด้านของขั้นตอนการวางแผนการทดสอบ

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

ขอบเขตของการส่งมอบ

กิจกรรมต่อไปนี้ต้องดำเนินการเพื่อสรุปขอบเขตของการส่งมอบ -

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

การประเมินความพยายาม

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

การประมาณจะกำหนดจำนวนเงินความพยายามทรัพยากรและเวลาที่ต้องใช้ในการสร้างระบบหรือผลิตภัณฑ์เฉพาะ การประมาณขึ้นอยู่กับ -

  • ข้อมูลในอดีต / ประสบการณ์ในอดีต
  • เอกสาร / ความรู้ที่มีอยู่
  • Assumptions
  • ระบุความเสี่ยง

ขั้นตอนพื้นฐานสี่ขั้นตอนในการประมาณค่าการทดสอบ ได้แก่ -

  • การประมาณขนาดของ AUT (Application Under Test)
  • การประมาณความพยายามเป็นเดือนคนหรือคน - ชั่วโมง
  • การประมาณกำหนดการในเดือนปฏิทิน
  • การประมาณต้นทุนโครงการในสกุลเงินที่ตกลงกัน

แผนทรัพยากร

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

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

เวิร์กโฟลว์ปกติสำหรับแผนทรัพยากรคือ -

  • วางแผนโดยผู้จัดการโครงการ
  • ร้องขอโดยผู้จัดการโครงการ
  • อนุมัติ / แก้ไข / ปฏิเสธโดยผู้จัดการทรัพยากร
  • เสร็จสมบูรณ์ - ปิดคำขอหลังจากลงชื่อออกโดยผู้จัดการทรัพยากร

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

ประเด็นต่อไปนี้ต้องได้รับการพิจารณาสำหรับ Test Case Development ใน STLC

  • ในขั้นตอนนี้ทีม QA จะเขียนกรณีทดสอบด้วยวิธีการทีละขั้นตอน จากนั้น Test Case จะถูกลงนามโดย Business Analyst หลังจากตรวจสอบหรือทำงานซ้ำในกรณีทดสอบในกรณีที่จำเป็นต้องมีการปรับเปลี่ยน

  • เมื่อกรณีทดสอบพร้อมทีม QA จะเตรียมข้อมูลการทดสอบตามเงื่อนไขเบื้องต้น

  • เกณฑ์การเริ่มต้นของระยะนี้คือกิจกรรมในการวางแผนการทดสอบควรเสร็จสิ้นและแผนการทดสอบควรพร้อม

  • เกณฑ์การออกของขั้นตอนนี้คือกรณีทดสอบควรได้รับการลงชื่อออกข้อมูลการทดสอบควรพร้อมและสคริปต์ทดสอบที่เตรียมไว้หากระบบอัตโนมัติอยู่ในขอบเขต

  • กรณีทดสอบควรจับคู่กับ Requirement Traceability Matrix เพื่อติดตามความครอบคลุมของข้อกำหนดหากพลาดสิ่งใด

กิจกรรมในขั้นตอนการพัฒนากรณีทดสอบ

ต่อไปนี้เป็นกิจกรรมสามอย่างที่ดำเนินการในขั้นตอนการพัฒนากรณีทดสอบ -

การระบุสถานการณ์ทดสอบ

สถานการณ์ช่วยลดการทดสอบและประเมินระบบที่ซับซ้อน กลยุทธ์ต่อไปนี้ช่วยในการสร้างสถานการณ์ที่ดี -

  • ระบุผู้ใช้ที่เป็นไปได้การกระทำและวัตถุประสงค์ของพวกเขา

  • ประเมินผู้ใช้ด้วยความคิดของแฮ็กเกอร์และระบุสถานการณ์ที่เป็นไปได้ของการละเมิดระบบ

  • แสดงรายการเหตุการณ์ของระบบและวิธีการจัดการกับคำขอดังกล่าว

  • แสดงรายการสิทธิประโยชน์และสร้างงานแบบ end-to-end เพื่อตรวจสอบ

  • อ่านเกี่ยวกับระบบที่คล้ายกันและพฤติกรรมของระบบ

  • การศึกษาข้อร้องเรียนเกี่ยวกับผลิตภัณฑ์ของคู่แข่งและรุ่นก่อน

การเขียนกรณีทดสอบ

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

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

การเตรียมข้อมูลการทดสอบ

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

  • ระบุแหล่งข้อมูลการทดสอบหรือข้อกำหนด
  • ระบุเงื่อนไข / การทำงานที่จะทดสอบ
  • กำหนดเงื่อนไขการทดสอบลำดับความสำคัญ
  • เลือกเงื่อนไขสำหรับการทดสอบ
  • กำหนดผลลัพธ์ที่คาดหวังของการประมวลผลกรณีทดสอบ
  • สร้างกรณีทดสอบ
  • เงื่อนไขการทดสอบเอกสาร
  • ทำการทดสอบ
  • ตรวจสอบและแก้ไขกรณีทดสอบตามการปรับเปลี่ยน

แผนภาพบล็อกกิจกรรม

แผนภาพต่อไปนี้แสดงกิจกรรมต่างๆที่เป็นส่วนหนึ่งของการพัฒนากรณีทดสอบ

สภาพแวดล้อมการทดสอบประกอบด้วยองค์ประกอบที่สนับสนุนการดำเนินการทดสอบด้วยซอฟต์แวร์ฮาร์ดแวร์และเครือข่ายที่กำหนดค่าไว้ การกำหนดค่าสภาพแวดล้อมการทดสอบต้องเลียนแบบสภาพแวดล้อมการใช้งานจริงเพื่อเปิดเผยปัญหาที่เกี่ยวข้องกับสภาพแวดล้อม / การกำหนดค่า

ประเด็นต่อไปนี้ต้องได้รับการพิจารณาในการตั้งค่าสภาพแวดล้อมการทดสอบ

  • เป็นการผสมผสานระหว่างฮาร์ดแวร์และสภาพแวดล้อมซอฟต์แวร์ที่จะทำการทดสอบ

  • ประกอบด้วยการกำหนดค่าฮาร์ดแวร์การตั้งค่าระบบปฏิบัติการการกำหนดค่าซอฟต์แวร์เทอร์มินัลทดสอบและการสนับสนุนอื่น ๆ เพื่อทำการทดสอบ

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

  • ในทางปฏิบัติทีม QA ไม่สามารถเริ่มงานจริงได้หากไม่มีสภาพแวดล้อมที่เหมาะสมในการทดสอบ

  • เป็นกิจกรรมอิสระและสามารถเริ่มต้นได้พร้อมกับการพัฒนากรณีทดสอบ

  • โดยทั่วไปแล้วกิจกรรมนี้จะดำเนินการโดยนักพัฒนาในด้านเทคนิคในขณะที่ลูกค้า / นักวิเคราะห์ธุรกิจสามารถทำได้

  • ความพร้อมของสภาพแวดล้อมการทดสอบสามารถตรวจสอบได้โดยการทดสอบควันและดำเนินการโดยทีม QA

  • ตามหลักการแล้วเราสามารถพูดได้ว่าเกณฑ์การเข้าของระยะนี้คือการจัดเตรียมแผนการทดสอบความพร้อมของกรณีทดสอบควันและการเตรียมข้อมูลการทดสอบ

  • เกณฑ์การออกของระยะนี้คือสภาพแวดล้อมการทดสอบควรพร้อมและควรดำเนินการทดสอบควันให้สำเร็จด้วยผลลัพธ์ที่คาดหวัง

กิจกรรมที่ดำเนินการสำหรับการตั้งค่าสภาพแวดล้อมการทดสอบ

กิจกรรมต่อไปนี้จะดำเนินการในระยะนี้

ออกแบบสภาพแวดล้อมการทดสอบ

ปัจจัยต่อไปนี้มีบทบาทสำคัญสำหรับการออกแบบสภาพแวดล้อมการทดสอบ

  • ตรวจสอบว่าสภาพแวดล้อมการทดสอบต้องการการเก็บถาวรหรือไม่เพื่อสำรองข้อมูล

  • ตรวจสอบการกำหนดค่าเครือข่าย

  • ระบุระบบปฏิบัติการเซิร์ฟเวอร์ฐานข้อมูลและส่วนประกอบอื่น ๆ ที่ต้องการ

  • ระบุจำนวนใบอนุญาตที่ทีมทดสอบต้องการ

การตั้งค่าสภาพแวดล้อม

วิเคราะห์ข้อกำหนดการตั้งค่าสภาพแวดล้อมและจัดเตรียมรายการข้อกำหนดของซอฟต์แวร์และฮาร์ดแวร์สำหรับการตั้งค่า รับคำยืนยันอย่างเป็นทางการสำหรับการตั้งค่าสภาพแวดล้อมการทดสอบและกำหนดค่าเพื่อเข้าถึงสภาพแวดล้อมการทดสอบ

การทดสอบควัน

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

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

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

ต้องพิจารณาประเด็นต่อไปนี้สำหรับการดำเนินการทดสอบ

  • ในขั้นตอนนี้ทีม QA จะทำการตรวจสอบความถูกต้องของ AUT ตามกรณีการทดสอบที่เตรียมไว้และเปรียบเทียบผลลัพธ์แบบทีละขั้นกับผลลัพธ์ที่คาดไว้

  • เกณฑ์การเข้าสู่ระยะนี้คือการเสร็จสิ้นของแผนการทดสอบและขั้นตอนการพัฒนากรณีทดสอบข้อมูลการทดสอบควรพร้อมด้วย

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

  • เกณฑ์การออกต้องมีการตรวจสอบความถูกต้องของกรณีทดสอบทั้งหมด ข้อบกพร่องควรปิดหรือรอการตัดบัญชี การดำเนินการกรณีทดสอบและรายงานสรุปข้อบกพร่องควรพร้อม

กิจกรรมสำหรับการดำเนินการทดสอบ

วัตถุประสงค์ของขั้นตอนนี้คือการตรวจสอบความถูกต้องของ AUT แบบเรียลไทม์ก่อนที่จะดำเนินการผลิต / เผยแพร่ ในการออกจากขั้นตอนนี้ทีม QA จะทำการทดสอบประเภทต่างๆเพื่อรับรองคุณภาพของผลิตภัณฑ์ นอกจากนี้การรายงานข้อบกพร่องและการทดสอบซ้ำยังเป็นกิจกรรมที่สำคัญในระยะนี้ ต่อไปนี้เป็นกิจกรรมสำคัญของช่วงนี้ -

การทดสอบการรวมระบบ

การตรวจสอบความถูกต้องของผลิตภัณฑ์ / AUT เริ่มต้นที่นี่ System Integration Testing (SIT) เป็นเทคนิคการทดสอบกล่องดำที่ประเมินความสอดคล้องของระบบกับข้อกำหนดที่ระบุ / กรณีทดสอบที่เตรียมไว้

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

  • สถานะข้อมูลภายในเลเยอร์การรวม
  • สถานะข้อมูลภายในชั้นฐานข้อมูล
  • สถานะข้อมูลภายในเลเยอร์แอปพลิเคชัน

Note- ในการทดสอบ SIT ทีม QA พยายามค้นหาข้อบกพร่องให้ได้มากที่สุดเพื่อให้มั่นใจในคุณภาพ วัตถุประสงค์หลักคือการค้นหาจุดบกพร่องให้ได้มากที่สุด

การรายงานข้อบกพร่อง

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

ในขณะที่ทำการทดสอบ SIT ทีม QA พบข้อบกพร่องประเภทนี้และจำเป็นต้องรายงานให้สมาชิกในทีมที่เกี่ยวข้องทราบ สมาชิกดำเนินการเพิ่มเติมและแก้ไขข้อบกพร่อง ข้อดีอีกประการหนึ่งของการรายงานคือช่วยลดการติดตามสถานะของข้อบกพร่อง มีเครื่องมือยอดนิยมมากมายเช่น ALM, QC, JIRA, Version One, Bugzilla ที่รองรับการรายงานและการติดตามข้อบกพร่อง

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

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

การทำแผนที่ข้อบกพร่อง

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

การทดสอบซ้ำ

การทดสอบซ้ำกำลังดำเนินการทดสอบที่ล้มเหลวก่อนหน้านี้กับ AUT เพื่อตรวจสอบว่าปัญหาได้รับการแก้ไขหรือไม่ หลังจากแก้ไขข้อบกพร่องแล้วให้ทำการทดสอบซ้ำเพื่อตรวจสอบสถานการณ์ภายใต้สภาวะแวดล้อมเดียวกัน

ในระหว่างการทดสอบซ้ำผู้ทดสอบจะมองหารายละเอียดแบบละเอียดในส่วนของฟังก์ชันการทำงานที่เปลี่ยนแปลงไปในขณะที่การทดสอบการถดถอยครอบคลุมฟังก์ชันหลักทั้งหมดเพื่อให้แน่ใจว่าไม่มีฟังก์ชันใดเสียหายเนื่องจากการเปลี่ยนแปลงนี้

การทดสอบการถดถอย

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

การทดสอบการถดถอยเป็นเทคนิคการทดสอบกล่องดำที่ประกอบด้วยการดำเนินการทดสอบอีกครั้งที่มีผลกระทบเนื่องจากการเปลี่ยนแปลงรหัส การทดสอบเหล่านี้ควรดำเนินการให้บ่อยที่สุดตลอดวงจรชีวิตการพัฒนาซอฟต์แวร์

ประเภทของการทดสอบการถดถอย

  • Final Regression Tests- มีการดำเนินการ "การทดสอบการถดถอยขั้นสุดท้าย" เพื่อตรวจสอบความถูกต้องของโครงสร้างที่ไม่ผ่านการเปลี่ยนแปลงในช่วงเวลาหนึ่ง โครงสร้างนี้ถูกปรับใช้หรือจัดส่งให้กับลูกค้า

  • Regression Tests - การทดสอบการถดถอยตามปกติจะดำเนินการเพื่อตรวจสอบว่าบิวด์ไม่ได้ทำลายส่วนอื่น ๆ ของแอปพลิเคชันหรือไม่โดยการเปลี่ยนแปลงโค้ดล่าสุดสำหรับการแก้ไขข้อบกพร่องหรือเพื่อการปรับปรุง

แผนภาพบล็อกกิจกรรม

แผนภาพบล็อกต่อไปนี้แสดงกิจกรรมสำคัญที่ดำเนินการในระยะนี้ นอกจากนี้ยังแสดงการพึ่งพาจากขั้นตอนก่อนหน้า -

Defect Life Cycle หรือที่เรียกว่า Bug Life Cycle คือการเดินทางของข้อบกพร่องซึ่งเป็นวัฏจักรที่ความบกพร่องเกิดขึ้นตลอดอายุการใช้งาน มันแตกต่างกันไปในแต่ละองค์กรและในแต่ละโครงการเนื่องจากอยู่ภายใต้กระบวนการทดสอบซอฟต์แวร์และยังขึ้นอยู่กับเครื่องมือที่ใช้

วงจรชีวิตที่บกพร่อง - เวิร์กโฟลว์

แผนภาพต่อไปนี้แสดงขั้นตอนการทำงานของวงจรชีวิตที่บกพร่อง

สถานะของวงจรชีวิตที่บกพร่อง

ต่อไปนี้เป็นสถานะต่างๆของวงจรชีวิตที่บกพร่อง

  • New - ข้อบกพร่องที่อาจเกิดขึ้นและยังไม่ได้รับการตรวจสอบ

  • Assigned - ได้รับมอบหมายจากทีมพัฒนาที่จะได้รับการแก้ไข

  • Active- ข้อบกพร่องกำลังได้รับการแก้ไขโดยนักพัฒนาและกำลังดำเนินการตรวจสอบ ในขั้นตอนนี้มีสองผลลัพธ์ที่เป็นไปได้ - รอการตัดบัญชีหรือปฏิเสธ

  • Test / Fixed / Ready for Retest - ข้อบกพร่องได้รับการแก้ไขและพร้อมสำหรับการทดสอบ

  • Verified - ข้อบกพร่องที่ได้รับการทดสอบซ้ำและการทดสอบได้รับการตรวจสอบโดย QA

  • Closed - สถานะสุดท้ายของข้อบกพร่องที่สามารถปิดได้หลังจากการทดสอบ QA อีกครั้งหรือสามารถปิดได้หากข้อบกพร่องนั้นซ้ำกันหรือถือว่าไม่ใช่ข้อบกพร่อง

  • Reopened - เมื่อไม่ได้รับการแก้ไขข้อบกพร่อง QA จะเปิด / เปิดใช้งานข้อบกพร่องอีกครั้ง

  • Deferred - เมื่อไม่สามารถแก้ไขข้อบกพร่องในรอบนั้นได้จะถูกเลื่อนออกไปในอนาคต

  • Rejected - ข้อบกพร่องสามารถปฏิเสธได้ด้วยเหตุผลสามประการ - ข้อบกพร่องที่ซ้ำกันไม่ใช่ข้อบกพร่องไม่สามารถทำซ้ำได้

ข้อบกพร่องถูกจำแนกจากมุมมองของทีม QA เป็น Priority และจากมุมมองของการพัฒนาเช่น Severity(ความซับซ้อนของรหัสในการแก้ไข) นี่คือการจำแนกประเภทหลักสองประเภทที่มีบทบาทสำคัญในกรอบเวลาและปริมาณงานที่ต้องดำเนินการเพื่อแก้ไขข้อบกพร่อง

Priority คืออะไร?

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

ตัวอย่างเช่นหากวางโลโก้ บริษัท ไม่ถูกต้องในหน้าเว็บของ บริษัท ลำดับความสำคัญจะสูง แต่มีความรุนแรงต่ำ

รายการลำดับความสำคัญ

ลำดับความสำคัญสามารถแบ่งได้ดังต่อไปนี้ -

  • Low - ข้อบกพร่องนี้สามารถแก้ไขได้หลังจากแก้ไขข้อบกพร่องที่สำคัญแล้ว

  • Medium - ข้อบกพร่องควรได้รับการแก้ไขในรุ่นต่อ ๆ ไป

  • High - ข้อบกพร่องต้องได้รับการแก้ไขทันทีเนื่องจากข้อบกพร่องส่งผลกระทบต่อแอปพลิเคชันในระดับมากและไม่สามารถใช้โมดูลที่เกี่ยวข้องได้จนกว่าจะได้รับการแก้ไข

  • Urgent - ข้อบกพร่องต้องได้รับการแก้ไขทันทีเนื่องจากข้อบกพร่องส่งผลกระทบต่อการใช้งานหรือผลิตภัณฑ์อย่างรุนแรงและไม่สามารถใช้ผลิตภัณฑ์ได้จนกว่าจะได้รับการแก้ไข

ความรุนแรงคืออะไร?

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

Example - สำหรับเว็บไซต์ปฏิบัติการเที่ยวบินข้อบกพร่องในการสร้างหมายเลขตั๋วเทียบกับการจองนั้นมีความรุนแรงสูงและมีลำดับความสำคัญสูงด้วย

รายการความรุนแรง

สามารถแบ่งประเภทความรุนแรงได้ดังต่อไปนี้ -

  • Critical /Severity 1- ข้อบกพร่องส่งผลกระทบต่อการทำงานที่สำคัญที่สุดของแอปพลิเคชันและทีม QA ไม่สามารถดำเนินการตรวจสอบความถูกต้องของแอปพลิเคชันต่อไปได้ภายใต้การทดสอบโดยไม่แก้ไข ตัวอย่างเช่นแอป / ผลิตภัณฑ์ขัดข้องบ่อยครั้ง

  • Major / Severity 2- ข้อบกพร่องส่งผลต่อโมดูลการทำงาน ทีม QA ไม่สามารถทดสอบโมดูลนั้น ๆ ได้ แต่ดำเนินการตรวจสอบความถูกต้องของโมดูลอื่นต่อไป ตัวอย่างเช่นการจองเที่ยวบินไม่ทำงาน

  • Medium / Severity 3- ข้อบกพร่องมีปัญหากับหน้าจอเดียวหรือเกี่ยวข้องกับฟังก์ชันเดียว แต่ระบบยังคงทำงานอยู่ ข้อบกพร่องที่นี่ไม่ได้ปิดกั้นฟังก์ชันการทำงานใด ๆ ตัวอย่างเช่น Ticket # คือการแทนค่าที่ไม่ได้ต่อท้ายอักขระที่เป็นตัวเลขและตัวอักษรที่ถูกต้องเช่นอักขระห้าตัวแรกและห้าตัวสุดท้ายเป็นตัวเลข

  • Low / Severity 4- ไม่ส่งผลกระทบต่อการทำงาน อาจเป็นข้อบกพร่องด้านเครื่องสำอางความไม่สอดคล้องของ UI สำหรับฟิลด์หรือข้อเสนอแนะในการปรับปรุงประสบการณ์ของผู้ใช้ปลายทางจากฝั่ง UI ตัวอย่างเช่นสีพื้นหลังของปุ่มส่งไม่ตรงกับสีของปุ่มบันทึก

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

เกณฑ์การเริ่มต้นของระยะนี้คือการดำเนินการกรณีทดสอบเสร็จสมบูรณ์ผลการทดสอบพร้อมใช้งานและรายงานข้อบกพร่องพร้อมแล้ว

เกณฑ์สำหรับการทดสอบเสร็จสิ้นมีดังต่อไปนี้ -

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

เกณฑ์การออกของขั้นตอนนี้คือการจัดเตรียมรายงานการปิดการทดสอบและการจัดทำเมทริกซ์ซึ่งลูกค้าจะลงชื่อออกในภายหลัง

ให้เราพูดคุยเกี่ยวกับ activities involved in the closure of Test Cycle.

รายงานการทดสอบเสร็จสิ้น

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

รายงานการทดสอบเสร็จสิ้นประกอบด้วยข้อมูลต่อไปนี้

  • ตัวระบุรายงานสรุปผลการทดสอบ
  • Summary
  • Variances
  • ผลสรุป
  • Evaluation
  • วางแผนเทียบกับความพยายามที่เกิดขึ้นจริง
  • ออกจากระบบ

รายงานการทดสอบเสร็จสิ้นที่ดีบ่งบอกถึงคุณภาพวัดความเสี่ยงที่โดดเด่นและระบุระดับของซอฟต์แวร์ที่ผ่านการทดสอบ

เมทริกซ์การทดสอบเสร็จสิ้น

เมื่อเสร็จสิ้นการทดสอบเมทริกซ์ต่างๆจะถูกรวบรวมเพื่อจัดทำรายงานการทดสอบ เกณฑ์ในการจัดทำรายงานมีดังต่อไปนี้ -

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

ผลการทดสอบ

ในขณะดำเนินการกรณีทดสอบให้ทำการทดสอบข้อบกพร่องอีกครั้งและดำเนินการกรณีทดสอบการถดถอย Test results articulate ควรบันทึกและสามารถจัดทำพร้อมกับเอกสารการปิดรอบการทดสอบเพื่อสนับสนุนการดำเนินการทดสอบให้เสร็จสมบูรณ์

ข้อต่อสามารถเป็นภาพหน้าจอผลการสืบค้นฐานข้อมูลการบันทึกไฟล์บันทึก ฯลฯ