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