สำรวจวิธีรวมการทดสอบประเภทต่างๆ ให้เป็นกลยุทธ์ที่สมเหตุสมผลซึ่งตรงกับโปรเจ็กต์ของคุณ
ยินดีต้อนรับกลับมา บทความสุดท้ายได้วางรากฐานมากมายเกี่ยวกับวิธีใช้การทดสอบประเภทต่างๆ และความหมายของประเภทการทดสอบต่างๆ รวมถึงให้ความกระจ่างเกี่ยวกับคำจำกัดความของประเภทการทดสอบ จำรูปภาพมีมเล็กๆ นี้ไหม คุณอาจสงสัยว่าการทดสอบประเภทต่างๆ ที่ได้เรียนรู้มาจะทำงานร่วมกันได้อย่างไร
ต่อไปคุณจะได้เรียนรู้อย่างแน่ชัด บทความนี้จะแนะนำวิธีรวมการทดสอบประเภทต่างๆ เหล่านี้เข้ากับกลยุทธ์ที่สมเหตุสมผล และเลือกการทดสอบที่ตรงกับโปรเจ็กต์ของคุณ
คุณสามารถเปรียบเทียบกลยุทธ์กับรูปร่างต่างๆ เพื่อให้เข้าใจความหมายได้ดีขึ้น ต่อไปนี้เป็นรายการกลยุทธ์ที่มีขนาดและขอบเขตการพัฒนาที่เกี่ยวข้อง
มาดูรายละเอียดของกลยุทธ์ต่างๆ และเรียนรู้ความหมายของชื่อของแต่ละกลยุทธ์กัน
กำหนดเป้าหมายการทดสอบ: คุณต้องการบรรลุเป้าหมายอะไรจากการทดสอบเหล่านี้
ก่อนจะเริ่มสร้างกลยุทธ์ที่ดี ให้กำหนดเป้าหมายการทดสอบ เมื่อใดที่คุณพิจารณาว่าแอปพลิเคชันของคุณได้รับการทดสอบเพียงพอแล้ว
การบรรลุเป้าหมายด้านการทดสอบในระดับสูงมักเป็นเป้าหมายสูงสุดสำหรับนักพัฒนาซอฟต์แวร์ แต่นี่เป็นวิธีที่ดีที่สุดเสมอใช่ไหม อาจมีปัจจัยสำคัญอีกอย่างที่ต้องพิจารณาเมื่อตัดสินใจเลือกกลยุทธ์การทดสอบ ซึ่งก็คือการให้บริการตามความต้องการของผู้ใช้
ในฐานะนักพัฒนาซอฟต์แวร์ คุณยังใช้แอปพลิเคชันและอุปกรณ์อื่นๆ อีกมากอีกด้วย ในด้านนี้ คุณคือผู้ใช้ที่พึ่งพาระบบเหล่านี้ทั้งหมดเพื่อ "ทำงาน" ซึ่งก็ต้องอาศัยนักพัฒนาซอฟต์แวร์จำนวนนับไม่ถ้วนในการทำให้แอปพลิเคชันและอุปกรณ์ของตนทำงานได้อย่างดีที่สุด ในฐานะนักพัฒนาแอป ก็ต้องพยายามรักษาความเชื่อใจนี้ให้เป็นจริงด้วยเช่นกัน ดังนั้นเป้าหมายแรกของคุณควรเป็นการส่งมอบซอฟต์แวร์ที่ใช้งานได้และให้บริการผู้ใช้เสมอ ซึ่งครอบคลุมถึงการทดสอบที่คุณเขียนเพื่อยืนยันคุณภาพของแอปพลิเคชัน Kent C. Dodds สรุปได้เป็นอย่างดีในโพสต์การทดสอบแบบคงที่ เทียบกับ หน่วย เทียบกับ E2E สำหรับแอปฟรอนท์เอนด์
ยิ่งการทดสอบของคุณคล้ายคลึงกับวิธีการใช้ซอฟต์แวร์ของคุณมากเท่าใด การทดสอบก็ยิ่งมีความมั่นใจมากขึ้นเท่านั้น
โดย Kent C. ดอดส์
เคนต์อธิบายว่ามันเป็นการสร้างความมั่นใจในการทดสอบ ยิ่งคุณได้เชื่อมต่อกับผู้ใช้อย่างใกล้ชิดมากขึ้นโดยการเลือกประเภทการทดสอบที่เหมาะสม คุณก็ยิ่งสามารถเชื่อถือได้ว่าการทดสอบของคุณจะได้รับผลลัพธ์ที่ถูกต้อง กล่าวอีกนัยหนึ่งคือ ยิ่งคุณปีนพีระมิดสูงขึ้นเท่าใด คุณยิ่งมั่นใจมากขึ้นเท่านั้น แต่เดี๋ยวก่อน พีระมิดคืออะไร
การกำหนดกลยุทธ์การทดสอบ: วิธีเลือกกลยุทธ์การทดสอบ
ในขั้นตอนแรก ให้คุณพิจารณาว่าส่วนใดของข้อกำหนดที่ต้องตรวจสอบเพื่อให้แน่ใจว่าเป็นไปตามข้อกำหนด ดูว่าควรใช้การทดสอบประเภทใดและรายละเอียดที่ระดับใดที่จะได้รับความมั่นใจมากที่สุดโดยที่ยังรักษาโครงสร้างต้นทุนที่มีประสิทธิภาพไว้ได้ นักพัฒนาซอฟต์แวร์จำนวนมากเข้าถึงหัวข้อนี้โดยใช้การอุปมาอุปไมย ต่อไปนี้คือสาเหตุที่พบบ่อยที่สุด เริ่มต้นจากหนังสือคลาสสิกที่รู้จักกันดี
คลาสสิก: พีระมิดทดสอบ
ทันทีที่คุณเริ่มมองหากลยุทธ์การทดสอบ คุณอาจเจอกับพีระมิดทดสอบอัตโนมัติซึ่งเป็นการอุปมาอุปไมยแรก ไมค์ โคห์น (Mike Cohn) ได้แนะนำแนวคิดนี้ในหนังสือ "Succeeding with Agile" ต่อมา Martin Fowler ได้ต่อยอดแนวคิดนี้ในบทความPractical Test Pyramid คุณสามารถแทนพีระมิดด้วยภาพได้ดังนี้
ดังที่แสดงในภาพวาดนี้ พีระมิดทดสอบประกอบด้วย 3 เลเยอร์ ดังนี้
Unit คุณจะพบการทดสอบเหล่านี้ที่เลเยอร์ฐานของพีระมิด เนื่องจากการทดสอบเหล่านี้ทำได้เร็วและดูแลรักษาได้ง่าย โดยจะแยกออกมาและกำหนดเป้าหมายเป็นหน่วยทดสอบย่อยที่สุด เช่น ดูการทดสอบ 1 หน่วยทั่วไปสำหรับผลิตภัณฑ์ขนาดเล็กมาก
การผสานรวม การทดสอบเหล่านี้อยู่ตรงกลางของพีระมิดเนื่องจากมีความเร็วในการดำเนินการที่ยอมรับได้ แต่ทำให้คุณใกล้ชิดกับผู้ใช้มากกว่าการทดสอบ 1 หน่วย ตัวอย่างของการทดสอบการผสานรวมคือการทดสอบ API คุณยังจัดประเภทการทดสอบคอมโพเนนต์เป็นประเภทนี้ได้ด้วย
การทดสอบ E2E (เรียกอีกอย่างว่าการทดสอบ UI) การทดสอบเหล่านี้จะจำลองการโต้ตอบของผู้ใช้จริง การทดสอบดังกล่าวต้องใช้เวลาในการดำเนินการมากขึ้นจึงแพงกว่า พวกมันอยู่ที่ด้านบนของพีระมิด
ความเชื่อมั่นกับทรัพยากร
อย่างที่กล่าวไปก่อนหน้านี้ ลำดับของเลเยอร์ไม่ใช่เรื่องบังเอิญ โดยจะแสดงลำดับความสำคัญและค่าใช้จ่ายที่เกี่ยวข้อง ซึ่งจะช่วยให้คุณเห็นภาพของจำนวนการทดสอบที่คุณควรเขียนสำหรับแต่ละเลเยอร์อย่างชัดเจน คุณเห็นสิ่งนี้ในคำจำกัดความของประเภทการทดสอบแล้ว
เนื่องจากการทดสอบ E2E นั้นใกล้เคียงกับผู้ใช้ของคุณมากที่สุด จึงช่วยให้คุณมั่นใจมากที่สุดว่าแอปพลิเคชันของคุณทำงานได้ตามที่ต้องการ แต่จำเป็นต้องใช้สแต็กแอปพลิเคชันที่สมบูรณ์และผู้ใช้จำลอง ดังนั้นจึงอาจมีราคาแพงที่สุดด้วย ความเชื่อมั่นจึงอยู่ในการแข่งขันโดยตรงกับทรัพยากรที่จำเป็นต้องใช้ในการทดสอบ
พีระมิดพยายามแก้ไขปัญหานี้โดยให้คุณมุ่งเน้นที่การทดสอบ 1 หน่วยมากขึ้น และจัดลำดับความสำคัญของกรณีต่างๆ ที่ครอบคลุมโดยการทดสอบ E2E เช่น เส้นทางของผู้ใช้ที่สำคัญที่สุดหรือสถานที่ที่มีข้อบกพร่องมากที่สุด ตามที่มาร์ติน ฟาวเลอร์ ได้เน้นย้ำไว้ 2 ประเด็นสำคัญที่สุดในพีระมิดของโคห์ ได้แก่
- เขียนการทดสอบด้วยรายละเอียดที่ต่างกัน
- ยิ่งได้ระดับสูงมากเท่าไร คุณก็ควรมีการทดสอบน้อยลงเท่านั้น
พีระมิดพัฒนาแล้ว! การปรับเปลี่ยนพีระมิดทดสอบ
เป็นเวลาหลายปีทีเดียวที่ยังมีการอภิปรายประเด็นต่างๆ เกี่ยวกับพีระมิด พีระมิดดูเหมือนจะทำให้กลยุทธ์การทดสอบซับซ้อนเกินไป ขาดประเภทการทดสอบมากมาย และไม่เหมาะสมกับโปรเจ็กต์ที่มีอยู่จริงทั้งหมดอีกต่อไป ดังนั้นจึงอาจทำให้เกิดการเข้าใจผิดได้ พีระมิดหล่นไม่เป็นรูปร่างใช่ไหม Guillermo Rauch แสดงความคิดเห็นเกี่ยวกับสิ่งนี้
เขียนข้อมูลการทดสอบ ไม่มากเกินไป ส่วนใหญ่เป็นการผสานรวม
โดย Guillermo Rauch
เป็นคำกล่าวที่พูดถึงมากที่สุดอย่างหนึ่งในเรื่องนี้ ดังนั้นเราจะดูรายละเอียดต่อไปนี้
- "เขียนการทดสอบ" เพราะนอกจากจะสร้างความเชื่อมั่นแล้วยังช่วยประหยัดเวลาในการบำรุงรักษาอีกด้วย
- "ไม่มากเกินไป" การครอบคลุม 100% อาจไม่ได้ผลเสมอไปเพราะการทดสอบไม่ได้จัดลำดับความสำคัญและจะต้องมีการบำรุงรักษาจำนวนมาก
- "ส่วนใหญ่เป็นการผสานรวม" ขอเน้นย้ำอีกครั้งที่การทดสอบการผสานรวมว่ามีคุณค่าทางธุรกิจมากที่สุด เนื่องจากทำให้คุณมีความเชื่อมั่นสูงในแต่ละวัน ขณะเดียวกันก็รักษาเวลาในการดำเนินการที่สมเหตุสมผล
ซึ่งจะทำให้คุณคิดถึงการทดสอบแบบพีระมิดอีกครั้งและหันมาโฟกัสที่การทดสอบแบบผสานรวม ในช่วง 2-3 ปีที่ผ่านมา ได้มีการเสนอการปรับเปลี่ยนมากมาย เรามาดูการปรับเปลี่ยนที่พบบ่อยที่สุดกัน
เพชรทดสอบ
การปรับครั้งแรกจะลบการเน้นการทดสอบ 1 หน่วยมากเกินไป ดังที่เห็นในพีระมิดทดสอบ ลองนึกภาพว่าคุณมีการครอบคลุมการทดสอบ 100% ถึง 100% แล้ว แต่ครั้งต่อไปที่เปลี่ยนโครงสร้างภายใน คุณจะต้องอัปเดตแบบทดสอบหลายหน่วยเหล่านี้ และอาจจะอยากข้ามการทดสอบไป จึงเกิดการกัดเซาะ
ผลที่ตามมาคือหลังจากการมุ่งเน้นที่การทดสอบการผสานรวมที่สูงขึ้น อาจมีรูปร่างต่อไปนี้เกิดขึ้น:
พีระมิดพัฒนาเป็นเพชร คุณสามารถดูเลเยอร์ 3 เลเยอร์ก่อนหน้านี้ได้ แต่มีขนาดต่างกัน และเลเยอร์ของหน่วยถูกตัดออก
- Unit การเขียน 1 หน่วยทดสอบตามแบบที่คุณกำหนดไว้ก่อนหน้านี้ อย่างไรก็ตาม เนื่องจากข้อผิดพลาดดังกล่าวมีแนวโน้มที่จะลดลง ให้จัดลำดับความสำคัญและครอบคลุมเฉพาะกรณีที่ร้ายแรงที่สุด
- การผสานรวม การทดสอบการผสานรวมที่คุณรู้จัก โดยการทดสอบชุดค่าผสมของหน่วยเดี่ยว
- E2E เลเยอร์นี้จะจัดการการทดสอบ UI ที่คล้ายกับพีระมิดทดสอบ โปรดเขียนเฉพาะการทดสอบ E2E สำหรับกรอบการทดสอบที่ร้ายแรงที่สุด
การทดสอบรังผึ้ง
และยังมีการปรับอีก 1 อย่างซึ่งมาจาก Spotify ซึ่งคล้ายกับ Test Diamond แต่มีเฉพาะสำหรับระบบซอฟต์แวร์แบบ Microservice มากกว่า รังผึ้งทดสอบเป็นการเปรียบเทียบด้วยภาพอีกอย่างหนึ่งสำหรับรายละเอียด ขอบเขต และจำนวนการทดสอบที่จะเขียนสำหรับระบบซอฟต์แวร์แบบ Microservice เนื่องจากมีขนาดเล็ก ความซับซ้อนมากที่สุดใน Microservice ไม่ได้อยู่ที่ตัวบริการเอง แต่อยู่ภายในวิธีการโต้ตอบกับผู้อื่น ดังนั้นกลยุทธ์การทดสอบสําหรับ Microservice ควรมุ่งเน้นที่การทดสอบการผสานรวมเป็นหลัก
รูปทรงนี้ทำให้เรานึกถึงรังผึ้ง และเป็นชื่อ โดยมีเลเยอร์ต่อไปนี้
- การทดสอบแบบผสานรวม บทความโดย Spotify ใช้ข้อความที่ยกมาจาก J B. Rainsberger เพื่อกำหนดเลเยอร์นี้: "การทดสอบที่จะผ่านหรือล้มเหลวตามความถูกต้องของระบบอื่น" การทดสอบดังกล่าวมีการพึ่งพาภายนอกที่คุณต้องพิจารณา และในทางตรงกันข้าม ระบบของคุณอาจเป็นทรัพยากร Dependency ที่ทำให้ระบบอื่นหยุดชะงัก เช่นเดียวกับการทดสอบ E2E ในการเปรียบเทียบอื่นๆ ให้ใช้การทดสอบเหล่านี้อย่างระมัดระวัง เฉพาะในกรณีที่จำเป็นที่สุดเท่านั้น
- การทดสอบการผสานรวม คุณควรมุ่งเน้นที่เลเยอร์นี้เช่นเดียวกับการปรับอื่นๆ ซึ่งมีการทดสอบที่ยืนยันความถูกต้องของบริการในลักษณะแยกต่างหากมากยิ่งขึ้น แต่ยังใช้ร่วมกับบริการอื่นๆ ซึ่งหมายความว่าการทดสอบจะรวมระบบอื่นๆ บางระบบด้วย และมุ่งเน้นที่จุดโต้ตอบ เช่น ผ่านการทดสอบ API
- การทดสอบรายละเอียดการใช้งาน การทดสอบเหล่านี้คล้ายกับ 1 หน่วย ซึ่งเป็นการทดสอบที่เน้นไปที่ส่วนต่างๆ ของโค้ดที่แยกออกมาตามธรรมชาติจึงมีความซับซ้อนภายในเป็นของตัวเอง
หากต้องการทราบข้อมูลเพิ่มเติมเกี่ยวกับกลยุทธ์การทดสอบนี้ โปรดดูโพสต์ที่เปรียบเทียบพีระมิดทดสอบกับรังผึ้งของ Martin Fowler และบทความต้นฉบับจาก Spotify
ถ้วยรางวัลการทดสอบ
คุณดูการมุ่งเน้นซ้ำในการทดสอบการผสานรวมได้อยู่แล้ว อย่างไรก็ตาม อีกประเภทหนึ่งที่เราพบในบทความก่อนหน้าไม่ใช่การทดสอบในเชิงทฤษฎี แต่ก็ยังคงเป็นสิ่งสำคัญที่คุณควรพิจารณาในกลยุทธ์การทดสอบ การวิเคราะห์แบบคงที่หายไปจากพีระมิดทดสอบและในการดัดแปลงส่วนใหญ่ที่คุณเห็นจนถึงตอนนี้ มีประโยชน์ในการใช้ถ้วยรางวัลสำหรับทดสอบซึ่งนำการวิเคราะห์แบบคงที่มาพิจารณาขณะเดียวกันก็ยังคงมุ่งเน้นไปที่การทดสอบแบบบูรณาการ ถ้วยรางวัลที่ใช้ทดสอบมาจากคำกล่าวก่อนหน้านี้ของ Guillermo Rauch และพัฒนาโดย Kent C. ด็อดส์:
ถ้วยรางวัลในการทดสอบเป็นตัวอย่างที่แสดงรายละเอียดการทดสอบแตกต่างออกไปเล็กน้อย ซึ่งมี 4 เลเยอร์ ดังนี้
- การวิเคราะห์แบบคงที่ ซึ่งมีบทบาทสำคัญในการอุปมาอุปไมยนี้และช่วยให้คุณสามารถตรวจจับการพิมพ์ผิด ข้อผิดพลาดเกี่ยวกับรูปแบบ และข้อบกพร่องอื่นๆ โดยเพียงแค่เรียกใช้ขั้นตอนการแก้ไขข้อบกพร่องที่ระบุไว้แล้วเท่านั้น
- การทดสอบหน่วย เพื่อให้แน่ใจว่าเครื่องที่เล็กที่สุดของคุณนั้นได้รับการทดสอบอย่างเหมาะสม แต่ถ้วยรางวัลการทดสอบจะไม่เน้นหน่วยวัดดังกล่าวในขอบเขตเดียวกับพีระมิดทดสอบ
- การผสานรวม จุดนี้เป็นจุดโฟกัสหลักเพราะเป็นการสร้างสมดุลระหว่างค่าใช้จ่ายกับความเชื่อมั่นที่สูงขึ้นในทางที่ดีที่สุด เช่นเดียวกับการปรับรูปแบบอื่นๆ
- การทดสอบ UI ทั้ง E2E และการทดสอบด้วยภาพ เป็นดาวเด่นในถ้วยรางวัลที่ใช้ทดสอบ คล้ายกับบทบาทของพวกเขาในพีระมิดทดสอบ
หากต้องการอ่านเพิ่มเติมเกี่ยวกับถ้วยรางวัลการทดสอบ โปรดดูบล็อกโพสต์ของ Kent C. ด็อดส์ในเรื่องนี้
แนวทางอื่นๆ ที่เน้น UI
ทั้งหมดเรียบร้อยดี แต่ไม่ว่าคุณจะเรียกกลยุทธ์ว่าอย่างไร "พีระมิด" "รังผึ้ง" หรือ "เพชร" ก็ยังมีบางอย่างขาดหายไป แม้ว่าการทดสอบอัตโนมัติจะเป็นสิ่งที่มีประโยชน์ แต่สิ่งสำคัญที่ควรทราบคือการทดสอบด้วยตนเองยังคงเป็นสิ่งจำเป็น การทดสอบอัตโนมัติควรแบ่งเบาภาระของงานที่ทำเป็นประจำ และทำให้วิศวกรรับประกันคุณภาพมีเวลาไปทุ่มเทกับงานที่สำคัญแทน การทำงานอัตโนมัติควรเข้ามาช่วยเสริมแทนการทดสอบด้วยตนเอง มีวิธีผสานรวมการทดสอบด้วยตนเองกับการทำงานอัตโนมัติเพื่อให้ได้ผลลัพธ์ที่ดีที่สุดหรือไม่
กำลังทดสอบไอศกรีมโคนและปู
มีการดัดแปลง 2 แบบจากพีระมิดทดสอบที่มุ่งเน้นวิธีการทดสอบที่เน้น UI เหล่านี้มากขึ้น ทั้ง 2 วิธีนี้มีข้อได้เปรียบด้านความเชื่อมั่นสูง แต่ก็จะมีต้นทุนมากกว่าอยู่แล้วเนื่องจากการดำเนินการทดสอบที่ช้ากว่า
อันแรก ไอศกรีมโคนทดสอบ หน้าตาเหมือนพีระมิดกลับด้าน หากไม่มีขั้นตอนการทดสอบด้วยตนเอง ก็เรียกอีกอย่างว่าการทดสอบพิซซ่า
Ice Cone จะมุ่งเน้นการทดสอบด้วยตนเองหรือการทดสอบ UI มากกว่า และมุ่งเน้นที่การทดสอบ 1 หน่วยน้อยที่สุด ซึ่งมักก่อตัวขึ้นในโปรเจ็กต์ที่นักพัฒนาซอฟต์แวร์เริ่มทำโดยมีความคิดไม่กี่อย่างเกี่ยวกับกลยุทธ์การทดสอบ รหัสน้ำแข็งถือเป็นรูปแบบที่ต่อต้านและกล่าวได้ถูกต้อง รหัสน้ำแข็งมีราคาสูงในแง่ของทรัพยากรและการทำงานด้วยตนเอง
ปูทดสอบนั้นคล้ายกับไอศกรีมโคนทดสอบ แต่เน้น E2E และการทดสอบด้วยภาพมากกว่า
กลยุทธ์การทดสอบนี้รวมอีก 1 แง่มุมคือ เป็นการยืนยันว่าแอปพลิเคชันใช้งานได้และดูดี ปูการทดสอบเน้นความสำคัญของการทดสอบด้วยภาพตามที่ระบุไว้ในบทความก่อนหน้านี้ การทดสอบการผสานรวมซึ่งแบ่งออกเป็นการทดสอบคอมโพเนนต์และ API จะย้ายไปทำงานเบื้องหลัง และการทดสอบ 1 หน่วยมีบทบาทรองมากขึ้นสำหรับที่นี่ ดูรายละเอียดเพิ่มเติมเกี่ยวกับกลยุทธ์การทดสอบนี้ได้ในบทความเรื่องปูทางทดสอบนี้
แม้ว่าจะมีค่าใช้จ่ายสูงกว่า แต่กลยุทธ์การทดสอบทั้ง 2 อย่างนี้มีความแตกต่างกัน เช่น ในโครงการเล็กๆ ที่ต้องทดสอบให้น้อยลง หรือต้องครอบคลุมความซับซ้อนให้น้อยลง ในกรณีนี้ กลยุทธ์การทดสอบเต็มรูปแบบที่มุ่งเน้นการทดสอบการผสานรวมอาจเป็นกลยุทธ์ที่มากเกินไป
แม้ว่ากลยุทธ์การทดสอบทั้ง 2 แบบจะมีต้นทุนสูงกว่า เช่น ในกรณีของโปรเจ็กต์เล็กๆ ที่ต้องใช้การทดสอบน้อยกว่าและไม่จำเป็นต้องครอบคลุมความซับซ้อนมากนัก ในกรณีนี้ กลยุทธ์การทดสอบเต็มรูปแบบที่มุ่งเน้นการทดสอบการผสานรวมอาจซับซ้อนโดยไม่จำเป็น
คำแนะนำที่ใช้ได้จริง: มาวางกลยุทธ์กัน!
ตอนนี้คุณก็ได้เรียนรู้เกี่ยวกับกลยุทธ์การทดสอบที่ใช้กันมากที่สุดไปแล้ว คุณเริ่มต้นด้วยเกมคลาสสิก พีระมิดทดสอบ และรู้จักการดัดแปลงต่างๆ ของเกม ตอนนี้คุณจะต้องประเมินผลิตภัณฑ์เหล่านั้นสำหรับผลิตภัณฑ์และตัดสินใจว่าเครื่องมือใดเหมาะกับโครงการของคุณมากที่สุด คำตอบสำหรับคำถามนี้ควรขึ้นต้นด้วย "ขึ้นอยู่กับ" ที่ทุกคนชื่นชอบ แต่นั่นไม่ได้ทำให้ความแม่นยำน้อยลง
การเลือกกลยุทธ์การทดสอบที่เหมาะสมที่สุดจากที่อธิบายไป หรือแม้แต่กลยุทธ์ที่ไม่ได้ใช้นั้น ขึ้นอยู่กับแอปพลิเคชันของคุณ ควรกำหนดโครงสร้าง ข้อกำหนด และสุดท้ายแต่ไม่ท้ายสุดคือผู้ใช้และข้อกำหนดของผู้ใช้ โดยข้อมูลทั้งหมดอาจแตกต่างกันไปตามแต่ละแอปพลิเคชัน ซึ่งเป็นเรื่องปกติ อย่าลืมว่าเป้าหมายที่สำคัญที่สุดของคุณคือการให้บริการแก่ผู้ใช้ ไม่ใช่คำนิยามของตำราเรียน
การทดสอบในสถานการณ์จริงมักจะแยกและกำหนดแยกกันได้ยาก แม้แต่ Martin Fowler ก็ยังเน้นย้ำถึงแง่มุมเชิงบวกของคำจำกัดความที่แตกต่างกัน เช่น ในกรณีของการทดสอบ 1 หน่วย ดังที่ Justin Searls ระบุไว้อย่างถูกต้องในทวีตดังนี้
[...] เขียนการทดสอบแบบชัดเจนที่กำหนดขอบเขตที่ชัดเจน ดำเนินการอย่างรวดเร็วและเชื่อถือได้ และไม่สำเร็จด้วยเหตุผลที่เป็นประโยชน์เท่านั้น
โดย Justin Searls
มุ่งเน้นการทดสอบที่รายงานข้อผิดพลาดจริงที่ผู้ใช้อาจพบ และไม่ทำให้คุณเสียสมาธิจากเป้าหมายของคุณ การทดสอบควรออกแบบมาเพื่อให้ประโยชน์แก่ผู้ใช้ ไม่ใช่แค่ให้ความครอบคลุม 100% หรือเพื่อถกเถียงกันว่าควรเขียนการทดสอบประเภทใด
มุ่งเน้นการทดสอบที่รายงานข้อผิดพลาดในสถานการณ์จริงที่ผู้ใช้อาจพบและไม่เบนความสนใจไปจากเป้าหมายของคุณ การทดสอบควรได้รับการออกแบบมาเพื่อให้เป็นประโยชน์ต่อผู้ใช้ ไม่ใช่แค่ให้ความครอบคลุม 100% หรือสร้างการอภิปรายเกี่ยวกับเปอร์เซ็นต์การทดสอบประเภทใดประเภทหนึ่งที่คุณควรเขียน