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

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

• กรณีทดสอบควรสั้น:นำตัวอย่างของ CMS กรณีทดสอบสั้น ๆ นั้นง่ายต่อการบำรุงรักษาและเพื่อระบุอินพุตและเอาต์พุต แต่ถ้าฉันต้องการทดสอบชุดการทำงานที่ยาวนาน (เช่นการเพิ่มเอกสารการส่งการแจ้งเตือนไปยังผู้ใช้รายอื่นผู้ใช้รายอื่นตอบกลับเอกสารการเปลี่ยนแปลงสถานะผู้ใช้จะได้รับการแจ้งเตือน) สำหรับฉันแล้วดูเหมือนว่ากรณีทดสอบควรแสดงถึงสถานการณ์ที่สมบูรณ์ แต่ฉันสามารถดูว่าสิ่งนี้จะผลิตเอกสารทดสอบที่ซับซ้อนมากเกินไป

• การทดสอบควรระบุอินพุตและเอาต์พุต::จะเป็นอย่างไรถ้าฉันมีรูปแบบยาวที่มีฟิลด์โต้ตอบจำนวนมากที่มีพฤติกรรมแตกต่างกัน ฉันจะเขียนหนึ่งการทดสอบสำหรับทุกสิ่งหรือไม่หรือสำหรับแต่ละการทดสอบ?

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

• กรณีทดสอบควรจัดทำเป็นเอกสารเล็กน้อย:หลักการนี้เฉพาะกับโครงการ Agile ดังนั้นคุณมีคำแนะนำเกี่ยวกับวิธีการใช้หลักการนี้หรือไม่?

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

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

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

ฉันใช้แตงกวาสำหรับการยอมรับของฉันและมีดังต่อไปนี้

Given A xxx 
And I am on the xxx page
And a clear email queue
And I should see "Total Payable xxxx"
And I supply my credit card details
When I the payment has been processed
Then my purchase should be complete
And I should receive an email
When I open the email with subject "xxx"
Then I should see the email delivered from "xx"
And there should be an attachment of type "application/pdf"
And attachment 1 should be named "xxxx"
And I should be on the xxx page
And I should see my receipt

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

การทดสอบนี้อยู่ที่ตอนท้ายของการซื้อซึ่งจะไป

สร้าง -> ยืนยัน -> การชำระเงิน -> พิมพ์ใบเสร็จรับเงิน

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

ครั้งแรกที่คุณจะต้องกำหนดทดสอบการยอมรับ

สิ่งที่คุณดูเหมือนจะอธิบายเป็นบูรณาการหรือการทดสอบระบบ

ดังนั้นในขณะที่ฉันไม่เห็นด้วย 100% กับคำจำกัดความของวิกิพีเดีย

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

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

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

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

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

เช่นเดียวกันกับซอฟต์แวร์

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

ฉันไม่ใช่แฟนตัวยงของเอกสารทดสอบขนาดยาวและใช้ภาพที่ได้อย่างมีประสิทธิภาพสำหรับโครงการขนาดเล็กไม่กี่แห่ง ลองดูสิ ชอบแผนภูมิการไหล (หรือแผนภาพ UML อื่น ๆ เช่นแผนภาพสถานะ ฯลฯ ) แทนที่จะใช้ข้อความเท่านั้นใช่หรือไม่ ระบุอินพุต, เอาต์พุต, เงื่อนไข, ลูป, เลน, สถานะ, การโต้ตอบกับส่วนประกอบอื่น ๆ และจากนั้นระบุว่าประสบความสำเร็จล้มเหลวโอนย้ายอื่น ๆ (?) ตามเกณฑ์ของคุณหรือไม่

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

HTH และขอให้โชคดี!

KM

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