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