บทช่วยสอนนี้อธิบายว่าสถานการณ์ทดสอบคืออะไร พร้อมทั้งความสำคัญ การนำไปใช้ ตัวอย่าง และเทมเพลตของสถานการณ์ทดสอบ:
ฟังก์ชัน/คุณลักษณะของซอฟต์แวร์ใดๆ ที่สามารถทดสอบได้ กล่าวกันว่าเป็นสถานการณ์ทดสอบ มุมมองของผู้ใช้ปลายทางจะถูกพิจารณาในขณะที่เขียนสถานการณ์ทดสอบใดๆ
บทช่วยสอนนี้จะช่วยคุณในการตอบคำถาม: เหตุใดจึงต้องมีสถานการณ์ทดสอบ เมื่อสถานการณ์ทดสอบเป็นเช่นนั้น เขียนและวิธีการเขียนสถานการณ์ทดสอบ
สถานการณ์ทดสอบคืออะไร?
พิจารณาสถานการณ์สมมุติ: มีมหาสมุทรกว้างใหญ่ คุณต้องเดินทางข้ามมหาสมุทรจากฝั่งหนึ่งไปยังอีกฝั่งหนึ่ง ตัวอย่างเช่น จากมุมไบ ชายทะเลอินเดียไปยังโคลัมโบ ชายทะเลศรีลังกา
รูปแบบการเดินทางที่คุณสามารถเลือกได้คือ:
(i) สายการบิน: ขึ้นเครื่องบินไปโคลัมโบ
(ii) ทางน้ำ: เลือกเรือเพื่อเดินทางไปยังโคลอมโบ
(iii) รถไฟ: นั่งรถไฟไปศรีลังกา
ตอนนี้สำหรับสถานการณ์ทดสอบ: การเดินทางจากชายทะเลมุมไบไปยังชายฝั่งโคลอมโบเป็นฟังก์ชันการทำงานที่ต้องทดสอบ
สถานการณ์ทดสอบประกอบด้วย:
- เดินทางโดยเครื่องบิน
- เดินทางทางน้ำ หรือ
- เดินทางโดยรถไฟ
สถานการณ์ทดสอบเหล่านี้จะมีกรณีทดสอบ
กรณีทดสอบที่สามารถเขียนสำหรับสถานการณ์การทดสอบข้างต้น ได้แก่:
การทดสอบภายในเครื่องและอัปโหลดเมื่อมีการเชื่อมต่ออินเทอร์เน็ต 6 การเปลี่ยนแปลงที่ทำโดยผู้ใช้หลายคนจะไม่ถูกเขียนทับ 7 ผู้ใช้หลายคนสามารถทำงานในเอกสารเดียวได้ 8 งานที่ทำเสร็จแล้วจะถูกเก็บไว้หากการเชื่อมต่ออินเทอร์เน็ตขาดหายไปขณะอัปโหลดไฟล์ 9 ใช้ข้อจำกัดการแชร์อย่างถูกต้อง 10 ผู้ใช้ที่มีข้อจำกัดในการดูจะไม่สามารถแก้ไขใดๆ ในเอกสารได้ 11 เอกสารสามารถเผยแพร่ทางอินเทอร์เน็ตสำหรับบุคคลทั่วไปได้ 12 การแก้ไขที่ทำกับ เอกสารจะถูกบันทึกด้วยการประทับเวลา & รายละเอียดผู้เขียน
จำนวนของสถานการณ์ทดสอบสำหรับ Google เอกสารจะมีจำนวนมากและมีขนาดใหญ่มาก ในกรณีดังกล่าวโดยทั่วไป เฉพาะเกณฑ์การยอมรับเท่านั้นที่กำหนดและอนุมัติโดยผู้มีส่วนได้ส่วนเสีย และสมาชิกในทีมจะทำงานตามเกณฑ์การยอมรับเหล่านี้ การเขียนกรณีทดสอบสำหรับหรือมากกว่าสถานการณ์ทดสอบอาจเป็นงานที่ละเอียดถี่ถ้วนสำหรับแอปพลิเคชันขนาดใหญ่
เกณฑ์การยอมรับเหล่านี้มีบทบาทสำคัญในการวางแผนกระบวนการซ้ำๆ และไม่ควรมองข้าม การกำหนดล่วงหน้าและล่วงหน้าเพื่อหลีกเลี่ยงความประหลาดใจหรือความตกใจเมื่อสิ้นสุดการวิ่งหรือออกตัว
กำหนด เงื่อนไขเบื้องต้น
เมื่อ เพื่อดำเนินการ
จากนั้น ผลลัพธ์ที่คาดหวัง
รูปแบบของการให้เวลาและจากนั้นมีประโยชน์ในการระบุเกณฑ์การยอมรับ
ตัวอย่างเทมเพลตสถานการณ์ทดสอบ
| ใช้รหัสเรื่องราว # | รหัสสถานการณ์ทดสอบ # | เวอร์ชัน # | สถานการณ์ทดสอบ | # จำนวนกรณีทดสอบ | ความสำคัญ |
|---|---|---|---|---|---|
| USID12.1 | TSID12.1.1 | Kin12.4 | ตรวจสอบว่า Kindle App เปิดอย่างถูกต้องหรือไม่ | 4 | สูง |
| USID12.1 | TSID12.1.2 | Kin12.4 | ตรวจสอบความจุของ Kindle App | 3 | ปานกลาง |
บทสรุป
ในการทดสอบซอฟต์แวร์ใดๆ ความเข้าใจวงจรชีวิตและการวางสถานการณ์ทดสอบ เป็นองค์ประกอบที่สำคัญมาก คุณภาพของซอฟต์แวร์สามารถปรับปรุงได้โดยมีพื้นฐานที่ดีสำหรับสถานการณ์การทดสอบ บ่อยครั้ง การใช้กรณีทดสอบและสถานการณ์ทดสอบอาจสลับสับเปลี่ยนกัน
อย่างไรก็ตาม กฎทั่วไปคือว่าสถานการณ์ทดสอบใช้เพื่อเขียนกรณีทดสอบหลายรายการ หรืออาจกล่าวได้ว่ากรณีทดสอบมาจากสถานการณ์ทดสอบ สถานการณ์การทดสอบที่กำหนดไว้อย่างดีทำให้มั่นใจได้ว่าซอฟต์แวร์มีคุณภาพดี
สถานการณ์: การเดินทางโดยสายการบินกรณีทดสอบอาจรวมถึงสถานการณ์เช่น:
- เที่ยวบินเป็นไปตามกำหนดเวลา .
- เที่ยวบินไม่เป็นไปตามกำหนดเวลา
- เกิดสถานการณ์ฉุกเฉินขึ้น (ฝนตกหนักและพายุ)
ในทำนองเดียวกัน สามารถเขียนชุดของกรณีทดสอบแยกต่างหากสำหรับสถานการณ์ที่เหลืออื่นๆ ได้
ตอนนี้ มาดูสถานการณ์การทดสอบทางเทคโนโลยีกัน
ทุกสิ่งที่สามารถทดสอบได้คือสถานการณ์ทดสอบ ดังนั้นเราจึงสามารถระบุได้ว่าฟังก์ชันซอฟต์แวร์ใดๆ ที่อยู่ภายใต้การทดสอบสามารถแบ่งออกเป็นฟังก์ชันย่อยหลายๆ ฟังก์ชันและสามารถเรียกว่า 'สถานการณ์ทดสอบ' ได้
ก่อนส่งมอบผลิตภัณฑ์ใดๆ ให้กับลูกค้า คุณภาพของผลิตภัณฑ์จำเป็นต้อง ได้รับการประเมินและประเมินผล สถานการณ์ทดสอบช่วยในการประเมินคุณภาพการทำงานของแอปพลิเคชันซอฟต์แวร์ที่สอดคล้องกับข้อกำหนดทางธุรกิจ
สถานการณ์ทดสอบคือกระบวนการที่ผู้ทดสอบทดสอบแอปพลิเคชันซอฟต์แวร์จากมุมมองของผู้ใช้ปลายทาง ประสิทธิภาพและคุณภาพของแอปพลิเคชันซอฟต์แวร์ได้รับการประเมินอย่างถี่ถ้วนก่อนนำไปใช้ในสภาพแวดล้อมการผลิต
ความสำคัญของสถานการณ์ทดสอบ
- สถานการณ์ทดสอบหนึ่งรายการสามารถมี 'กรณีทดสอบ' ได้หลายรายการ สามารถคิดเป็นภาพพาโนรามาขนาดใหญ่และกรณีทดสอบเป็นส่วนเล็กๆ ที่มีความสำคัญต่อภาพพาโนรามา
- เป็นคำสั่งและการทดสอบบรรทัดเดียวกรณีต่างๆ ประกอบด้วยคำอธิบายแบบเป็นขั้นเป็นตอนเพื่อให้บรรลุวัตถุประสงค์ของคำสั่งสถานการณ์ทดสอบ
- ตัวอย่าง:
สถานการณ์ทดสอบ: สร้าง การชำระเงินสำหรับบริการรถแท็กซี่ที่มีจำหน่าย
จะมีกรณีทดสอบหลายกรณีตามที่ระบุไว้ด้านล่าง:
(i) วิธีการชำระเงินที่จะใช้: PayPal, Paytm, บัตรเครดิต/เดบิต
(ii) ชำระเงินสำเร็จแล้ว
(iii) ชำระเงินไม่สำเร็จ
(iv) กระบวนการชำระเงินถูกยกเลิกในระหว่างนั้น
(v) ไม่สามารถเข้าถึงวิธีการชำระเงินได้
(vi) แอปพลิเคชัน แยกย่อยอยู่ระหว่างนั้น
- สถานการณ์ทดสอบจึงช่วยในการประเมินแอปพลิเคชันซอฟต์แวร์ตามสถานการณ์ในโลกแห่งความเป็นจริง
- สถานการณ์ทดสอบ เมื่อพิจารณาแล้ว ให้ช่วยในการแบ่งขอบเขตของการทดสอบ
- การแบ่งสองส่วนนี้เรียกว่าการจัดลำดับความสำคัญ ซึ่งจะช่วยในการกำหนดฟังก์ชันการทำงานที่สำคัญของแอปพลิเคชันซอฟต์แวร์
- การจัดลำดับความสำคัญของการทดสอบฟังก์ชัน จะช่วยได้มาก ขอบเขตในการใช้งานแอปพลิเคชันซอฟต์แวร์ที่ประสบความสำเร็จ
- เมื่อสถานการณ์ทดสอบได้รับการจัดลำดับความสำคัญ ฟังก์ชันการทำงานที่สำคัญที่สุดสามารถระบุและทดสอบตามลำดับความสำคัญได้อย่างง่ายดาย สิ่งนี้ทำให้มั่นใจได้ว่าฟังก์ชันการทำงานที่สำคัญส่วนใหญ่ทำงานได้ดีและข้อบกพร่องที่เกี่ยวข้องได้รับการบันทึกและแก้ไขอย่างถูกต้อง
- สถานการณ์ทดสอบกำหนดโฟลว์กระบวนการทางธุรกิจของซอฟต์แวร์และทำให้สามารถทดสอบแอปพลิเคชันแบบครบวงจรได้
ความแตกต่างระหว่างสถานการณ์ทดสอบและกรณีทดสอบ
| สถานการณ์ทดสอบ | กรณีทดสอบ |
|---|---|
| สถานการณ์ทดสอบคือแนวคิดหนึ่ง | กรณีทดสอบคือแนวทางแก้ไขในการตรวจสอบแนวคิดนั้น26 |
| Test Scenario เป็นฟังก์ชันระดับสูง | Test case คือขั้นตอนโดยละเอียดเพื่อทดสอบฟังก์ชันระดับสูง |
| Test Scenario ได้มาจากข้อกำหนด/ เรื่องราวของผู้ใช้ | กรณีทดสอบได้มาจากสถานการณ์ทดสอบ |
| สถานการณ์ทดสอบคือ 'ฟังก์ชันการทำงานใดบ้างที่จะทดสอบ' | กรณีทดสอบคือ ' วิธีทดสอบฟังก์ชันการทำงาน ' |
| สถานการณ์ทดสอบมีกรณีทดสอบหลายกรณี | กรณีทดสอบอาจหรืออาจไม่เชื่อมโยงกับสถานการณ์ทดสอบหลายรายการ |
| สถานการณ์ทดสอบเดียวไม่สามารถทำซ้ำได้ | กรณีทดสอบเดียวอาจใช้ได้หลายครั้งในสถานการณ์ที่แตกต่างกัน |
| จำเป็นต้องมีเอกสารประกอบโดยย่อ | จำเป็นต้องมีเอกสารประกอบโดยละเอียด |
| ต้องมีการระดมสมองเพื่อสรุปสถานการณ์การทดสอบ | ความรู้ด้านเทคนิคโดยละเอียดของแอปพลิเคชันซอฟต์แวร์ จำเป็น |
| ประหยัดเวลาเพราะไม่ต้องลงรายละเอียดทุกนาที | เสียเวลาเพราะต้องดูแลรายละเอียดทุกนาที |
| ค่าบำรุงรักษาต่ำเนื่องจากต้องใช้ทรัพยากรต่ำ | ค่าบำรุงรักษาสูงเนื่องจากทรัพยากรที่ต้องใช้สูง |
เหตุใดสถานการณ์ทดสอบจึงขาดไม่ได้
สถานการณ์ทดสอบมาจากข้อกำหนดหรือเรื่องราวของผู้ใช้
- ดูตัวอย่างสถานการณ์ทดสอบสำหรับการจองรถแท็กซี่
- สถานการณ์จำลอง อาจเป็นตัวเลือกการจองรถแท็กซี่ วิธีการชำระเงิน การติดตามด้วย GPS แผนที่ถนนแสดงถูกต้องหรือไม่ รายละเอียดรถแท็กซี่และคนขับแสดงถูกต้องหรือไม่ ฯลฯ ทั้งหมดนี้แสดงอยู่ในเทมเพลตสถานการณ์ทดสอบ
- ตอนนี้ สมมติว่าสถานการณ์ทดสอบคือ เพื่อตรวจสอบว่าบริการระบุตำแหน่งเปิดอยู่หรือไม่ หากไม่ได้เปิด ให้แสดงข้อความ 'เปิดบริการระบุตำแหน่ง สถานการณ์นี้ขาดหายไปและไม่ได้แสดงอยู่ในเทมเพลตสถานการณ์ทดสอบ
- สถานการณ์จำลอง 'บริการตำแหน่ง' ทำให้เกิดสถานการณ์ทดสอบอื่นๆ ที่เกี่ยวข้อง
สิ่งเหล่านี้สามารถ :
-
- บริการระบุตำแหน่งเป็นสีเทา
- บริการระบุตำแหน่งเปิดอยู่แต่ไม่มีอินเทอร์เน็ต
- ข้อจำกัดบริการระบุตำแหน่ง .
- แสดงตำแหน่งที่ไม่ถูกต้อง
- การพลาดสถานการณ์เดียว อาจหมายถึงการพลาด สถานการณ์สำคัญหรือกรณีทดสอบอื่นๆ อีกมากมาย . สิ่งนี้สามารถมี ผลกระทบเชิงลบ อย่างมากในขณะที่ใช้งานแอปพลิเคชันซอฟต์แวร์ ซึ่งส่งผลให้เกิดการสูญเสียการไล่เบี้ยอย่างหนัก (กำหนดเวลา)
- สถานการณ์การทดสอบช่วยได้มากใน การหลีกเลี่ยงการทดสอบอย่างละเอียดถี่ถ้วน มันทำให้มั่นใจได้ว่าสิ่งสำคัญทั้งหมดและกระแสธุรกิจที่คาดไว้จะได้รับการทดสอบ ซึ่งช่วยในการทดสอบแอปพลิเคชันตั้งแต่ต้นทางถึงปลายทาง
- สิ่งเหล่านี้ช่วยประหยัดเวลา นอกจากนี้ ไม่จำเป็นต้องมีคำอธิบายโดยละเอียดมากขึ้นตามกรณีทดสอบ มีการระบุคำอธิบายสั้นๆ เกี่ยวกับสิ่งที่จะทดสอบ
- สถานการณ์ทดสอบเขียนขึ้นหลังจาก เซสชันการระดมความคิด ของสมาชิกในทีม ดังนั้นความน่าจะเป็นที่จะพลาดสถานการณ์ใดๆ (สำคัญหรือเล็กน้อย) จึงมีน้อยมาก โดยคำนึงถึงเทคนิคและขั้นตอนทางธุรกิจของแอปพลิเคชันซอฟต์แวร์ด้วย
- ยิ่งกว่านั้น สถานการณ์ทดสอบสามารถได้รับการอนุมัติโดย Business Analyst Client หรือทั้งคู่ที่มีความรู้อย่างชัดเจนเกี่ยวกับแอปพลิเคชันที่ทดสอบ
สถานการณ์ทดสอบจึงเป็นส่วนสำคัญของ SDLC
การใช้งานสถานการณ์ทดสอบ
ให้เราดูการใช้งานสถานการณ์ทดสอบหรือวิธีเขียนสถานการณ์ทดสอบ:
- Epics/ความต้องการทางธุรกิจถูกสร้างขึ้น
- ตัวอย่าง Epic : สร้างบัญชี Gmail Epic สามารถเป็นคุณสมบัติหลักของแอปพลิเคชันหรือความต้องการทางธุรกิจ
- Epics แบ่งออกเป็นเรื่องราวของผู้ใช้ที่มีขนาดเล็กกว่าใน Sprints
- เรื่องราวของผู้ใช้นั้นมาจาก Epics เรื่องราวของผู้ใช้เหล่านี้ต้องมีพื้นฐานและได้รับอนุมัติจากผู้มีส่วนได้ส่วนเสีย
- สถานการณ์ทดสอบได้มาจากเรื่องราวของผู้ใช้หรือ BRS (เอกสารข้อกำหนดทางธุรกิจ), SRS (ข้อกำหนดของระบบเอกสารข้อกำหนด) หรือ FRS (เอกสารข้อกำหนดการทำงาน) ซึ่งได้รับการสรุปผลและเป็นข้อมูลพื้นฐาน
- ผู้ทดสอบเขียนสถานการณ์การทดสอบ
- สถานการณ์การทดสอบเหล่านี้ได้รับการอนุมัติโดยหัวหน้าทีม นักวิเคราะห์ธุรกิจ หรือผู้จัดการโครงการ ขึ้นอยู่กับองค์กร
- แต่ละสถานการณ์การทดสอบต้องเชื่อมโยงกับเรื่องราวของผู้ใช้อย่างน้อยหนึ่งเรื่อง
- ต้องมีการระบุสถานการณ์ทดสอบเชิงบวกและเชิงลบ
- เรื่องราวของผู้ใช้ประกอบด้วย เกณฑ์การยอมรับ เช่น :
- เกณฑ์การยอมรับคือรายการเงื่อนไขหรือสถานะความตั้งใจสำหรับข้อกำหนดของลูกค้า ความคาดหวังของลูกค้าและความเข้าใจผิดได้รับการพิจารณาในขณะที่เขียนเกณฑ์การยอมรับ
- สิ่งเหล่านี้ไม่ซ้ำกันสำหรับเรื่องราวของผู้ใช้หนึ่งคน และเรื่องราวของผู้ใช้แต่ละคนต้องมีเกณฑ์การยอมรับอย่างน้อยหนึ่งเกณฑ์ที่ควรทดสอบโดยอิสระ
- เกณฑ์การยอมรับช่วยในการพิจารณาว่าคุณลักษณะใดอยู่ในขอบเขตและอยู่นอกขอบเขตของโครงการ เกณฑ์เหล่านี้ควรรวมคุณสมบัติที่ใช้งานได้และไม่ใช่ฟังก์ชั่น
- นักวิเคราะห์ธุรกิจเขียนเกณฑ์การยอมรับและเจ้าของผลิตภัณฑ์อนุมัติ
- หรือในบางกรณี เจ้าของผลิตภัณฑ์สามารถเขียนเอง เกณฑ์
- สามารถรับสถานการณ์ทดสอบได้จากเกณฑ์การยอมรับ
ตัวอย่างสถานการณ์ทดสอบ
#1) สถานการณ์ทดสอบสำหรับ Kindle App
Kindle เป็นแอปที่ช่วยให้ e-reader สามารถค้นหาได้e-books ออนไลน์ ดาวน์โหลด และซื้อ Amazon Kindle มอบประสบการณ์ในชีวิตจริงให้กับผู้อ่าน e-book ด้วยการถือหนังสือในมือและอ่านหนังสือ แม้แต่การพลิกหน้าก็ยังจำลองมาอย่างดีในแอป
ตอนนี้ เรามาจดบันทึกสถานการณ์การทดสอบกัน ( หมายเหตุ: สถานการณ์จำลองที่จำกัดแสดงไว้ด้านล่างเพื่อรับแนวคิดทั่วไปสำหรับการเขียนสถานการณ์ทดสอบ อาจมีกรณีทดสอบหลายกรณีที่ได้รับจากสถานการณ์ดังกล่าว)
| สถานการณ์ทดสอบ # | สถานการณ์ทดสอบ |
|---|---|
| 1 | ตรวจสอบว่า Kindle App เปิดตัวอย่างถูกต้องหรือไม่ |
| 2 | ตรวจสอบว่าปรับความละเอียดหน้าจอตามอุปกรณ์ต่างๆ หลังจากเปิดแอปแล้ว |
| 3 | ตรวจสอบว่าข้อความที่แสดงสามารถอ่านได้ |
| 4 | ตรวจสอบว่าตัวเลือกการซูมเข้าและซูมออกทำงานอยู่ |
| 5 | ตรวจสอบว่าไฟล์ที่เข้ากันได้ซึ่งนำเข้าในแอป Kindle สามารถอ่านได้ |
| 6 | ตรวจสอบความจุของ แอป Kindle |
| 7 | ตรวจสอบว่าฟังก์ชันการดาวน์โหลดทำงานอย่างถูกต้อง |
| 82 | ตรวจสอบว่าการจำลอง Page Turn ทำงานอย่างถูกต้อง |
| 9 | ตรวจสอบว่ารูปแบบ eBook เข้ากันได้กับแอป Kindle |
| 10 | ตรวจสอบแบบอักษรที่แอป Kindle รองรับ |
| 11 | ตรวจสอบอายุแบตเตอรี่ที่ใช้โดยแอป Kindle |
| 12 | ตรวจสอบประสิทธิภาพของ Kindle ขึ้นอยู่กับการเชื่อมต่อเครือข่าย (Wi-Fi, 3G หรือ 4G) |
สามารถรับกรณีทดสอบหลายกรณีจากแต่ละสถานการณ์การทดสอบที่ระบุไว้ข้างต้น
#2) เกณฑ์การยอมรับสำหรับ Google เอกสาร
'Google เอกสาร' เป็นแอปพลิเคชันบนเว็บสำหรับสร้าง แก้ไข และแบ่งปันเอกสารคำ สเปรดชีต สไลด์ และแบบฟอร์ม ไฟล์ทั้งหมดสามารถเข้าถึงได้ทางออนไลน์โดยใช้เว็บเบราว์เซอร์ที่มีการเชื่อมต่ออินเทอร์เน็ต
เอกสารที่สร้างขึ้นสามารถใช้ร่วมกันเป็นหน้าเว็บหรือเอกสารพร้อมพิมพ์ ผู้ใช้สามารถตั้งข้อจำกัดว่าใครสามารถดูและแก้ไขเอกสารได้ เอกสารฉบับเดียวสามารถแบ่งปันร่วมกันและทำงานร่วมกันโดยบุคคลที่หลากหลายจากที่ตั้งทางภูมิศาสตร์ที่แตกต่างกัน
สถานการณ์การทดสอบที่จำกัดมีการกล่าวถึงด้านล่างเพื่อความเข้าใจโดยทั่วไป สถานการณ์การทดสอบเชิงลึกสำหรับ Google เอกสารสามารถเป็นได้ หัวข้อแยกต่างหากโดยสิ้นเชิง
| เกณฑ์การยอมรับ # | เกณฑ์การยอมรับ |
|---|---|
| 1 | Word, Sheets หรือ Forms สามารถเปิดได้สำเร็จโดยไม่มีข้อผิดพลาด |
| 2 | เทมเพลตพร้อมใช้งานสำหรับเอกสาร แผ่นงาน และสไลด์ |
| 3 | ผู้ใช้สามารถเข้าถึงเทมเพลตที่มีอยู่ได้ |
| 4 | เทมเพลตที่ใช้สามารถแก้ไขได้ (เช่น ฟอนต์ ขนาดฟอนต์ การเพิ่มข้อความ การลบข้อความ แทรกสไลด์) |
| 5 | หากไม่มีการเชื่อมต่ออินเทอร์เน็ตชั่วคราว สามารถจัดเก็บไฟล์ได้ |