ประเภทของ Automation Testing Framework และวิธีเลือกให้เหมาะกับทีม

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

บทความนี้จะอธิบายถึงหกประเภทของเฟรมเวิร์กการทดสอบระบบอัตโนมัติแบบคลาสสิก ได้แก่ linear (เชิงเส้น), modular (แบบโมดูล), data-driven (ขับเคลื่อนด้วยข้อมูล), keyword-driven (ขับเคลื่อนด้วยคีย์เวิร์ด), hybrid (แบบไฮบริด) และ behavior-driven (ขับเคลื่อนด้วยพฤติกรรม) โดยจะอธิบายว่าแต่ละประเภทคืออะไร, ข้อดีคืออะไร และข้อเสียคืออะไร เพื่อให้คุณสามารถเลือกโครงสร้างที่เหมาะสมกับทีมของคุณ แทนที่จะใช้ตามที่วิศวกรคนสุดท้ายได้ตั้งค่าไว้ แนวคิดเหล่านี้สามารถนำไปใช้กับการทดสอบ UI, API และ unit testing ได้ทั้งหมด

เฟรมเวิร์กการทดสอบระบบอัตโนมัติคืออะไร

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

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

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

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

หกประเภทของเฟรมเวิร์ก

1. Linear (เชิงเส้น) (บันทึกและเล่นซ้ำ)

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

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

2. Modular (แบบโมดูล)

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

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

3. Data-driven (ขับเคลื่อนด้วยข้อมูล)

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

ประเภทนี้เหมาะอย่างยิ่งเมื่อต้องตรวจสอบเวิร์กโฟลว์เดียวกันกับชุดข้อมูลนำเข้าหลายสิบชุด เช่น การเข้าสู่ระบบที่ถูกต้อง, การเข้าสู่ระบบที่ไม่ถูกต้อง, ค่าขอบเขต, ความหลากหลายของภาษาและภูมิภาค สำหรับ API โดยเฉพาะอย่างยิ่ง แนวทางการทดสอบที่ขับเคลื่อนด้วยข้อมูลโดยใช้ CSV และ JSON จะเปลี่ยนคำขอเดียวให้กลายเป็นกรณีทดสอบหลายร้อยกรณี ข้อแลกเปลี่ยนคือตรรกะการทดสอบเองนั้นจะถูกกำหนดตายตัว โครงสร้างที่ขับเคลื่อนด้วยข้อมูลจะขยายส่วนของการป้อนข้อมูล ไม่ใช่พฤติกรรม

4. Keyword-driven (ขับเคลื่อนด้วยคีย์เวิร์ด)

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

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

5. Hybrid (แบบไฮบริด)

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

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

6. Behavior-driven (BDD) (ขับเคลื่อนด้วยพฤติกรรม)

เฟรมเวิร์กที่ขับเคลื่อนด้วยพฤติกรรมจะแสดงการทดสอบในภาษาที่ใกล้เคียงกับภาษาธรรมชาติโดยใช้รูปแบบ Given-When-Then ซึ่งโดยทั่วไปจะเขียนด้วย Gherkin และดำเนินการโดยเครื่องมือเช่น Cucumber สถานการณ์หนึ่งจะอ่านได้เหมือนประโยค: เมื่อผู้ใช้ที่ลงทะเบียนไว้ส่งข้อมูลประจำตัวที่ถูกต้อง พวกเขาจะเข้าถึงหน้าแดชบอร์ด

คุณค่าของ BDD คือความเข้าใจร่วมกัน ทีมผลิตภัณฑ์, QA และวิศวกรรมจะอ่านข้อกำหนดเดียวกัน ซึ่งช่วยลดช่องว่างระหว่างสิ่งที่ร้องขอและสิ่งที่สร้างขึ้น ค่าใช้จ่ายคือสองชั้น: Gherkin ที่อ่านได้ และการกำหนดขั้นตอนที่นำไปใช้งานจริง หากพนักงานฝ่ายผลิตภัณฑ์ไม่เคยอ่านสถานการณ์จริง คุณกำลังจ่ายภาษีของ BDD โดยไม่ได้รับประโยชน์จากมัน คู่มือ Gherkin สำหรับการทดสอบ API แบบ BDD ของเราแสดงรูปแบบที่นำไปใช้กับ API

การเปรียบเทียบประเภทของเฟรมเวิร์ก

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

ข้อผิดพลาดทั่วไปของเฟรมเวิร์ก

แม้แต่ทีมที่เลือกประเภทที่สมเหตุสมผลก็มักจะบ่อนทำลายมันในการปฏิบัติจริง ข้อผิดพลาดสามประการนี้เกิดขึ้นซ้ำแล้วซ้ำเล่า

ข้อผิดพลาดแรกคือการสร้าง abstraction ก่อนเวลาอันควร ทีมใช้โครงสร้างแบบ keyword-driven หรือ hybrid สำหรับชุดทดสอบที่มีเพียงสิบห้ารายการ เลเยอร์ abstraction มีค่าใช้จ่ายในการสร้างและบำรุงรักษามากกว่าการทดสอบที่มันให้บริการ โครงสร้างควรเป็นไปตามขนาด ให้การทำซ้ำที่แท้จริงเป็นเหตุผลสำหรับการนำกลับมาใช้ซ้ำในชั้นถัดไป

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

ข้อผิดพลาดที่สามคือการเลือกประเภทสำหรับกลุ่มเป้าหมายที่ไม่มีอยู่จริง BDD จะให้ผลตอบแทนก็ต่อเมื่อผู้ที่ไม่ใช่วิศวกรอ่าน Gherkin จริงๆ Keyword-driven จะให้ผลตอบแทนก็ต่อเมื่อนักวิเคราะห์สร้างการทดสอบจริงๆ หากคนเหล่านั้นไม่เคยแตะชุดทดสอบเลย คุณจะต้องแบกรับค่าใช้จ่ายของเลเยอร์เพิ่มเติมโดยไม่ได้รับประโยชน์ใดๆ จับคู่ประเภทกับผู้ที่มีส่วนร่วมอย่างแท้จริง ไม่ใช่กับผู้ที่อาจจะทำในทางทฤษฎี

วิธีการเลือกประเภทเฟรมเวิร์ก

เลือกให้เข้ากับทีมและโปรเจกต์ของคุณ ไม่ใช่ตามกระแสแฟชั่น

1. ขนาดและอายุการใช้งาน สคริปต์ที่ใช้แล้วทิ้งอาจเป็นแบบเชิงเส้น สิ่งใดก็ตามที่ต้องบำรุงรักษานานกว่าหนึ่งไตรมาสควรเป็นแบบโมดูลเป็นอย่างน้อย
2. ใครเป็นผู้เขียนการทดสอบ วิศวกรทั้งหมดชี้ไปที่แบบโมดูลหรือไฮบริด บทบาทที่หลากหลายชี้ไปที่แบบ keyword-driven หรือ BDD
3. ความหลากหลายของข้อมูลนำเข้า การรวมกันของข้อมูลนำเข้าจำนวนมากกับเวิร์กโฟลว์ที่มั่นคงชี้ไปที่แบบ data-driven
4. ช่องว่างในการสื่อสาร ความเข้าใจผิดบ่อยครั้งระหว่างผลิตภัณฑ์และวิศวกรรมชี้ไปที่ BDD เนื่องจากข้อกำหนดร่วมกันคือผลตอบแทนหลัก
5. ทักษะที่มีอยู่ ประเภทเฟรมเวิร์กที่ดีที่สุดคือสิ่งที่ทีมของคุณสามารถบำรุงรักษาได้จริง โครงสร้างที่สวยงามที่ไม่มีใครเข้าใจจะล้มเหลวเร็วกว่าโครงสร้างธรรมดาที่ทุกคนเข้าใจ

ทีมส่วนใหญ่จะจบลงที่แบบไฮบริด: การนำโมดูลมาใช้ซ้ำเป็นแกนหลัก, ข้อมูลนำเข้าแบบ data-driven สำหรับกรณีที่มีความหลากหลายสูง และ BDD ในจุดที่การทำงานร่วมกันมีความสำคัญสูงสุด เริ่มต้นง่ายๆ และให้ความเจ็บปวดจริง ไม่ใช่ทฤษฎี เป็นเหตุผลในการเพิ่มโครงสร้าง สำหรับกลยุทธ์การทดสอบที่นอกเหนือจากประเภทเฟรมเวิร์ก ความแตกต่างในคู่มือ สถานการณ์ทดสอบเทียบกับกรณีทดสอบ ของเราจะช่วยให้คุณกำหนดขอบเขตว่าการทดสอบแต่ละรายการควรครอบคลุมอะไรบ้าง

แพลตฟอร์มช่วยได้อย่างไร

การเลือกประเภทเฟรมเวิร์กเป็นการตัดสินใจทางสถาปัตยกรรม การนำไปใช้งานให้ดีก็ยังคงต้องใช้เครื่องมือที่เหมาะสม สำหรับการทดสอบ API โดยเฉพาะ Apidog รองรับการนำโมดูลกลับมาใช้ซ้ำผ่านคำขอที่ใช้ร่วมกันและมีพารามิเตอร์, การรันที่ขับเคลื่อนด้วยข้อมูลจากไฟล์ CSV และ JSON และตัวสร้างการทดสอบแบบภาพที่ช่วยให้ผู้ที่ไม่ใช่โปรแกรมเมอร์สามารถประกอบการทดสอบได้ ซึ่งเป็นเจตนารมณ์ของโครงสร้างแบบ keyword-driven โดยไม่ต้องมีไลบรารีคีย์เวิร์ดที่สร้างด้วยมือ

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

คำถามที่พบบ่อย

ความแตกต่างระหว่างเครื่องมืออัตโนมัติ (automation tool) กับเฟรมเวิร์กการทดสอบอัตโนมัติ (automation testing framework) คืออะไร?

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

ประเภทเฟรมเวิร์กการทดสอบอัตโนมัติใดดีที่สุด?

ไม่มีประเภทที่ดีที่สุดสำหรับทุกกรณี Linear เหมาะกับสคริปต์ที่ใช้แล้วทิ้ง, Modular เหมาะกับทีมวิศวกรส่วนใหญ่, Data-driven เหมาะกับข้อมูลนำเข้าที่หลากหลาย, Keyword-driven และ BDD เหมาะกับทีมที่มีทักษะหลากหลาย และ Hybrid เหมาะกับชุดทดสอบขนาดใหญ่ที่พัฒนาเต็มที่แล้ว จับคู่ประเภทให้เข้ากับทักษะของทีมและอายุการใช้งานของโปรเจกต์ของคุณ แทนที่จะเลือกตัวเลือกที่ได้รับความนิยมมากที่สุด

BDD ใช้ได้เฉพาะสำหรับการทดสอบ API หรือ UI เท่านั้นหรือไม่?

ไม่ใช่ทั้งคู่ BDD เป็นรูปแบบโครงสร้าง ไม่ใช่เลเยอร์ รูปแบบ Given-When-Then สามารถใช้ได้กับการทดสอบ unit, API และ UI ได้ทั้งหมด ข้อกำหนดที่แท้จริงไม่ใช่เลเยอร์การทดสอบแต่เป็นกลุ่มเป้าหมาย: BDD จะให้ผลตอบแทนก็ต่อเมื่อผู้ที่ไม่ใช่วิศวกรอ่านหรือเขียนสถานการณ์จริงเท่านั้น

ฉันสามารถเปลี่ยนประเภทเฟรมเวิร์กได้หรือไม่หลังจากสร้างชุดทดสอบไปแล้ว?

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

โปรเจกต์ขนาดเล็กจำเป็นต้องมีเฟรมเวิร์กเลยหรือไม่?

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