นักพัฒนาซอฟต์แวร์ควรรับผิดชอบการทดสอบอื่น ๆ นอกเหนือจากการทดสอบหน่วยหากเป็นเช่นนั้น

35

ขณะนี้ฉันกำลังทำงานในโครงการที่ค่อนข้างใหญ่และฉันได้ใช้ JUnit และ EasyMock เพื่อฟังก์ชั่นการทดสอบหน่วยอย่างกว้างขวาง ตอนนี้ฉันสนใจในการทดสอบประเภทอื่นที่ฉันควรกังวล ในฐานะนักพัฒนาฉันต้องรับผิดชอบเกี่ยวกับสิ่งต่างๆเช่นการทำงานหรือการทดสอบการถดถอยหรือไม่ มีวิธีที่ดีในการรวมสิ่งเหล่านี้เข้าด้วยกันในเครื่องมือเช่น Maven / Ant / Gradle หรือไม่? สิ่งเหล่านี้เหมาะสำหรับผู้ทดสอบหรือปริญญาตรีหรือไม่? มีการทดสอบประเภทอื่น ๆ ที่มีประโยชน์อีกหรือไม่

testing

— แจ๊คกี้
แหล่งที่มา

2

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

— Aaron McIver

1

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

— neontapir

เกณฑ์ที่ดีเป็นวิธีautomatableการทดสอบที่มี โปรแกรมเมอร์เขียนโปรแกรมอัตโนมัติด้วยรหัส

— rwong

44

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

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

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

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

— ไบรอัน Oakley
แหล่งที่มา

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

— Jackie

10

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

— Aaron McIver

2

"การทดสอบโปรแกรมอาจเป็นวิธีที่มีประสิทธิภาพมากในการแสดงสถานะของข้อบกพร่อง แต่มันก็ไม่เพียงพอสำหรับการแสดงตนที่ไม่มีอยู่" - Edsger W. Dijkstra, "The Humble Programmer" (บรรยายเรื่องทัวริงรางวัล), 1972

— John R. Strohm

1

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

— Jason Sebring

4

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

— Carson63000

13

สิ่งนี้อาจช่วยคุณได้:

การทดสอบความคล่องตัว

Q1 เขียนโดยนักพัฒนา

Q2 ดำเนินการโดยอัตโนมัติโดยนักพัฒนาและเขียนร่วมกับธุรกิจและ / หรือผู้ทดสอบ

— foobarcode
แหล่งที่มา

นักพัฒนามักจะมีส่วนร่วมในการทดสอบ Q4 เช่นกัน

— neontapir

ไม่พบไฟล์ที่ลิงก์อีกต่อไป

— DušanRychnovský

3

มีการทดสอบประเภทอื่น ๆ ที่มีประโยชน์อีกหรือไม่

มีการทดสอบการยอมรับที่ฉันจะแนะนำกรอบรูปแบบ BDD ที่ใช้ภาษา Gherkin : JBehave (Java), แตงกวา (Ruby), Behat (PHP) ฯลฯ การทดสอบประเภทนี้มีข้อดีเหนือการทดสอบหน่วย:

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

— scriptin
แหล่งที่มา

3

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

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

มีหลายเฟรมเวิร์กสำหรับการทดสอบประเภทนี้เรากำลังใช้fitnesseกับผลลัพธ์ที่ดีมาก มีห้องสมุดที่ดีมากสำหรับการทดสอบหน้าเว็บ (เราใช้สำหรับทดสอบแอปพลิเคชันเว็บและบริการบนเว็บของเรา) และมันทำงานร่วมกับMavenและJenkinsได้เป็นอย่างดี

เราเคยทำ "cross functional testing" ระหว่างนักพัฒนา แต่การทดสอบแบบนี้ไม่ได้ "ทำซ้ำ" ดังนั้นประโยชน์ของมันจึงมี จำกัด ...

— Pablo Lascano
แหล่งที่มา

2

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

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

แต่นั่นเป็นผลงานของทีมไม่ใช่แค่ของคุณเท่านั้น

— nunomvbarreiro
แหล่งที่มา

1

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

ปัญหาของโครงการขนาดใหญ่โดยเฉพาะอย่างยิ่ง Java ที่อยู่ในคอนเทนเนอร์คือการทดสอบการรวมเป็นเรื่องยาก ดังนั้นเพื่อความสะดวกในการทดสอบการรวมระบบในโครงการขนาดใหญ่จำเป็นต้องมีกรอบการทดสอบซึ่งทำขึ้นเป็นพิเศษสำหรับโครงการซึ่งเป็นหน้าที่ของนักพัฒนาในการกำหนดรหัส เมื่อเร็ว ๆ นี้มีการปรับปรุงอย่างมากในพื้นที่นี้และแพลตฟอร์มเช่นArquillianทำให้การเขียนเฟรมเวิร์กการทดสอบง่ายขึ้น (หรือทดแทนได้)

— m3th0dman
แหล่งที่มา

1

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

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

หากคำถามของคุณมีประโยชน์ในการติดตามบั๊กฉันชอบ bugzilla, google docs, zendesk หรือ basecamp ในแง่ของระบบการสื่อสาร

— เจสันซีบริง
แหล่งที่มา

1

ฉันไม่คิดว่าสิ่งนี้ได้รับการคุ้มครองแล้ว - ขออภัยถ้าฉันไม่ได้รับมัน

ประเด็นหนึ่งคือการใช้เวลาของนักพัฒนาอย่างมีประสิทธิภาพ

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

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

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

— Steve314
แหล่งที่มา

0

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

— Honus Wagner
แหล่งที่มา

ฉันคิดว่าสิ่งที่ฉันพยายามทำคือการใช้“ การตอก” อย่างมีประสิทธิภาพ

— Jackie

นั่นเป็นเรื่องส่วนตัวแน่นอน ฉันจะบอกว่าการทดสอบทุกรูปแบบที่ใช้กับโครงการของคุณ (แน่นอนว่าการทดสอบทุกประเภทไม่สามารถใช้กับโครงการทั้งหมดได้) นี่คือรายการที่ดี: softwaretestinghelp.com/types-of-software-testing สิ่งที่คุณทำด้วยตัวคุณเองและสิ่งที่คุณเลือกก่อนหน้านี้แน่นอนขึ้นอยู่กับเวลาทรัพยากรและความสามารถของคุณเอง ตัวอย่างเช่นคุณอาจไม่สามารถทำการทดสอบการยอมรับได้เนื่องจากมีกฎบางอย่างที่ผู้ใช้เท่านั้นที่รู้ว่าต้องทำตาม กล่าวโดยย่อคือทำทุกอย่างที่ทำได้ในเวลาที่คุณมี

— Honus Wagner

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

— Honus Wagner

0

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

ในอาชีพการพัฒนาของฉันฉันพบว่าโครงการจบลงด้วยผลลัพธ์ที่ดีกว่าคือมีการบูรณาการระหว่างทีมพัฒนาและทีมทดสอบอย่างแน่นหนา

สมาชิกอย่างน้อยหนึ่งคนจากแต่ละทีมควรนั่งในการวางแผนและการประชุมอื่น ๆ ด้วย

— Michelle Cannon
แหล่งที่มา

1

ปัญหาเดียวที่ฉันมีคือควรมีระดับการแยกระหว่างนักพัฒนาและทีมทดสอบมิฉะนั้นทีมทดสอบจะเสียความเห็นกับ "ความคิดเห็นของรหัสทำงาน" ของนักพัฒนาซอฟต์แวร์ QA และนักพัฒนาซอฟต์แวร์มีเป้าหมายที่ตรงกันข้าม นักพัฒนาพยายามที่จะทำให้มันทำงานในขณะที่ทีมงาน QA พยายามที่จะทำลายมันและนักพัฒนาไม่ได้มีมุมมองที่ดีที่สุดในการทดสอบความเกี่ยวข้อง

— Robert Harvey

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

— Michelle Cannon

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

— มิเชลแคนนอน

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

— Michelle Cannon