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 |
---|---|---|
การรวบรวมความต้องการ |
|
|
ออกแบบ |
|
|
การพัฒนา |
|
|
ตั้งค่าสภาพแวดล้อม |
|
|
การทดสอบ |
|
|
การปรับใช้ / การเปิดตัวผลิตภัณฑ์ |
|
|
ซ่อมบำรุง |
|
|
วัตถุประสงค์ทั่วไปของการทดสอบคือการค้นหาจุดบกพร่องโดยเร็วที่สุด และเมื่อแก้ไขข้อบกพร่องแล้วตรวจสอบให้แน่ใจว่าทำงานได้ตามที่คาดไว้และไม่ทำลายฟังก์ชันการทำงานอื่น ๆ
เพื่อให้บรรลุเป้าหมายเหล่านี้มีการกำหนดหลักการพื้นฐาน 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 ควรบันทึกและสามารถจัดทำพร้อมกับเอกสารการปิดรอบการทดสอบเพื่อสนับสนุนการดำเนินการทดสอบให้เสร็จสมบูรณ์
ข้อต่อสามารถเป็นภาพหน้าจอผลการสืบค้นฐานข้อมูลการบันทึกไฟล์บันทึก ฯลฯ