การทดสอบแบบ Agile - คู่มือฉบับย่อ

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

ประกาศ Agile

Agile Manifesto ได้รับการเผยแพร่โดยทีมนักพัฒนาซอฟต์แวร์ในปี 2544 โดยเน้นถึงความสำคัญของทีมพัฒนารองรับความต้องการที่เปลี่ยนแปลงและการมีส่วนร่วมของลูกค้า

The Agile Manifesto is −

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

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

นั่นคือในขณะที่มีค่าในรายการทางด้านขวาเราให้ความสำคัญกับรายการทางด้านซ้ายมากขึ้น

Agile Testing คืออะไร?

Agile Testing คือการทดสอบซอฟต์แวร์ที่เป็นไปตามหลักการของการพัฒนาซอฟต์แวร์แบบ Agile

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

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

การทดสอบแบบ Agile ครอบคลุมทุกระดับของการทดสอบและการทดสอบทุกประเภท

เทียบกับการทดสอบ Agile การทดสอบน้ำตก

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

ต่อไปนี้เป็นจุดเด่นของความแตกต่างระหว่าง Agile Testing และ Waterfall Testing -

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

หลักการทดสอบแบบ Agile

หลักการของการทดสอบ Agile คือ -

• Testing moves the project forward- การทดสอบอย่างต่อเนื่องเป็นวิธีเดียวที่จะทำให้มั่นใจได้ว่ามีความคืบหน้าอย่างต่อเนื่อง Agile Testing ให้ข้อเสนอแนะอย่างต่อเนื่องและผลิตภัณฑ์ขั้นสุดท้ายตรงตามความต้องการของธุรกิจ

• Testing is not a phase- ทีม Agile ทำการทดสอบร่วมกับทีมพัฒนาเพื่อให้แน่ใจว่าฟีเจอร์ที่นำมาใช้ระหว่างการทำซ้ำนั้นทำได้จริง การทดสอบจะไม่ถูกเก็บไว้ในระยะต่อไป

• Everyone tests- ในการทดสอบแบบ Agile ทีมงานทั้งหมดรวมถึงนักวิเคราะห์นักพัฒนาและผู้ทดสอบจะทดสอบแอปพลิเคชัน หลังจากการทำซ้ำทุกครั้งแม้แต่ลูกค้าก็ทำการทดสอบการยอมรับของผู้ใช้

• Shortening Feedback Loops- ในการทดสอบแบบ Agile ทีมธุรกิจจะทำความรู้จักกับการพัฒนาผลิตภัณฑ์สำหรับการทำซ้ำทุกครั้ง พวกเขามีส่วนร่วมในการทำซ้ำทุกครั้ง ข้อเสนอแนะอย่างต่อเนื่องช่วยลดระยะเวลาตอบสนองของข้อเสนอแนะและทำให้ต้นทุนที่เกี่ยวข้องในการแก้ไขน้อยลง

• Keep the Code Clean- ข้อบกพร่องได้รับการแก้ไขเมื่อเกิดขึ้นภายในการทำซ้ำเดียวกัน สิ่งนี้ทำให้มั่นใจได้ว่าโค้ดจะสะอาดในทุกก้าวของการพัฒนา

• Lightweight Documentation - แทนที่จะเป็นเอกสารการทดสอบที่ครอบคลุมผู้ทดสอบ Agile -

  • ใช้รายการตรวจสอบที่ใช้ซ้ำได้เพื่อแนะนำการทดสอบ

  • เน้นที่สาระสำคัญของการทดสอบมากกว่ารายละเอียดที่บังเอิญ

  • ใช้รูปแบบเอกสาร / เครื่องมือที่มีน้ำหนักเบา

  • จับแนวคิดการทดสอบในกฎบัตรสำหรับการทดสอบเชิงสำรวจ

  • ใช้ประโยชน์จากเอกสารเพื่อวัตถุประสงค์หลายประการ

• Leveraging one test artifact for manual and automated tests- สามารถใช้สิ่งประดิษฐ์สคริปต์ทดสอบเดียวกันสำหรับการทดสอบด้วยตนเองและเป็นอินพุตสำหรับการทดสอบอัตโนมัติ สิ่งนี้ช่วยขจัดความต้องการของเอกสารคู่มือการทดสอบและสคริปต์การทดสอบอัตโนมัติที่เทียบเท่า

• “Done Done,” not just done - ใน Agile มีการกล่าวถึงฟีเจอร์ที่ไม่ได้ทำหลังจากการพัฒนา แต่หลังจากการพัฒนาและการทดสอบ

• Test-Last vs. Test Driven- กรณีการทดสอบเขียนขึ้นพร้อมกับข้อกำหนด ดังนั้นการพัฒนาสามารถขับเคลื่อนได้ด้วยการทดสอบ แนวทางนี้เรียกว่า Test Driven Development (TDD) และ Acceptance Test Driven Development (ATDD) ซึ่งตรงกันข้ามกับการทดสอบในช่วงสุดท้ายในการทดสอบน้ำตก

กิจกรรมการทดสอบ Agile

กิจกรรมการทดสอบ Agile ในระดับโครงการ ได้แก่ -

• การวางแผนการวางจำหน่าย (แผนการทดสอบ)

  • สำหรับการทำซ้ำทุกครั้ง

  • กิจกรรมการทดสอบ Agile ระหว่างการทำซ้ำ

• การทดสอบการถดถอย

• กิจกรรมการเปิดตัว (ที่เกี่ยวข้องกับการทดสอบ)

กิจกรรมการทดสอบ Agile ระหว่างการทำซ้ำ ได้แก่ -

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

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

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

บูรณาการอย่างต่อเนื่องคุณภาพอย่างต่อเนื่อง

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

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

วิธีการแบบ Agile

มีวิธีการแบบ Agile หลายประการที่สนับสนุนการพัฒนาแบบ Agile ระเบียบวิธีแบบ Agile ได้แก่ -

การต่อสู้

Scrum เป็นวิธีการพัฒนาแบบ Agile ที่เน้นการใช้ทีมเป็นศูนย์กลาง สนับสนุนการมีส่วนร่วมของทั้งทีมในกิจกรรมการพัฒนาโครงการทั้งหมด

XP

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

คริสตัล

คริสตัลขึ้นอยู่กับการเช่าเหมาลำการจัดส่งแบบวนรอบและการสรุป

• การเช่าเหมาลำเกี่ยวข้องกับการจัดตั้งทีมพัฒนาการวิเคราะห์ความเป็นไปได้เบื้องต้นการวางแผนเบื้องต้นและวิธีการพัฒนา

• การจัดส่งแบบหมุนเวียนที่มีรอบการจัดส่งตั้งแต่สองรอบขึ้นไปจะมุ่งเน้นไปที่ขั้นตอนการพัฒนาและการจัดส่งผลิตภัณฑ์แบบรวมขั้นสุดท้าย

• ในระหว่างการสรุปการปรับใช้ในสภาพแวดล้อมของผู้ใช้การทบทวนหลังการปรับใช้และการสะท้อนกลับจะดำเนินการ

FDD

Feature Driven Development (FDD) เกี่ยวข้องกับการออกแบบและสร้างคุณสมบัติ ความแตกต่างระหว่าง FDD และระเบียบวิธีการพัฒนาแบบ Agile อื่น ๆ คือคุณลักษณะต่างๆได้รับการพัฒนาในขั้นตอนเฉพาะและระยะสั้นแยกกัน

DSDM

Dynamic Software Development Method (DSDM) ขึ้นอยู่กับ Rapid Application Development (RAD) และสอดคล้องกับ Agile Framework DSDM มุ่งเน้นไปที่การส่งมอบผลิตภัณฑ์เป็นประจำโดยให้ผู้ใช้มีส่วนร่วมอย่างกระตือรือร้นและช่วยให้ทีมสามารถตัดสินใจได้อย่างรวดเร็ว

การพัฒนาซอฟต์แวร์แบบลีน

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

ของเสียรวมถึงงานที่ทำไปแล้วบางส่วนงานที่ไม่เกี่ยวข้องคุณลักษณะที่ลูกค้าไม่ได้ใช้งานข้อบกพร่อง ฯลฯ ที่เพิ่มความล่าช้าในการจัดส่ง

Lean Principles เป็น -

• กำจัดของเสีย
• ขยายการเรียนรู้
• ความมุ่งมั่นล่าช้า
• เพิ่มพลังให้กับทีม
• ส่งเร็ว
• สร้างความซื่อสัตย์ใน
• ดูทั้งหมด

Kanban

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

Kanban ขึ้นอยู่กับ -

• Kanban Board (ภาพและความต่อเนื่องในการพัฒนา)
• ขีด จำกัด งานระหว่างดำเนินการ (WIP)
• เวลานำ

วิธีการทดสอบแบบ Agile

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

• การเขียนกรณีทดสอบเพื่อแสดงลักษณะการทำงานของระบบ

• การป้องกันการตรวจจับและการกำจัดข้อบกพร่องก่อนกำหนด

• ตรวจสอบให้แน่ใจว่าประเภทการทดสอบที่ถูกต้องทำงานในเวลาที่เหมาะสมและเป็นส่วนหนึ่งของระดับการทดสอบที่เหมาะสม

ใน Agile Methodologies ทั้งหมดที่เราพูดถึงการทดสอบ Agile นั้นเป็นวิธีการหนึ่ง ในทุกวิธีการทดสอบจะถูกเขียนขึ้นก่อนการเข้ารหัส

ในบทช่วยสอนนี้เราจะมุ่งเน้นไปที่การต่อสู้เป็นวิธีการทดสอบแบบ Agile

วิธีการทดสอบ Agile อื่น ๆ ที่ใช้กันทั่วไป ได้แก่ -

• Test-Driven Development (TDD) - Test-Driven Development (TDD) ขึ้นอยู่กับการเข้ารหัสที่แนะนำโดยการทดสอบ

• Acceptance Test-Driven Development (ATDD) - Acceptance Test-Driven Development (ATDD) ขึ้นอยู่กับการสื่อสารระหว่างลูกค้าผู้พัฒนาและผู้ทดสอบและขับเคลื่อนโดยเกณฑ์การยอมรับที่กำหนดไว้ล่วงหน้าและกรณีการทดสอบการยอมรับ

• Behavior-Driven Development (BDD) - การทดสอบ In Behavior-Driven Development (BDD) ขึ้นอยู่กับพฤติกรรมที่คาดหวังของซอฟต์แวร์ที่กำลังพัฒนา

วงจรการทดสอบแบบ Agile

ใน Scrum กิจกรรมการทดสอบประกอบด้วย -

• การมีส่วนร่วมในเรื่องราวของผู้ใช้ตามลักษณะการทำงานที่คาดหวังของระบบที่แสดงเป็นกรณีทดสอบ

• การวางแผนการวางจำหน่ายตามความพยายามในการทดสอบและข้อบกพร่อง

• การวางแผน Sprint ตามเรื่องราวของผู้ใช้และข้อบกพร่อง

• Sprint Execution พร้อมการทดสอบอย่างต่อเนื่อง

• การทดสอบการถดถอยหลังจาก Sprint เสร็จสิ้น

• การรายงานผลการทดสอบ

• การทดสอบอัตโนมัติ

การทดสอบเป็นแบบวนซ้ำและวิ่งตามที่แสดงในแผนภาพด้านล่าง -

Agile Development ยึดทีมเป็นศูนย์กลางและนักพัฒนาและผู้ทดสอบมีส่วนร่วมในโครงการและกิจกรรมการพัฒนาทั้งหมด การทำงานเป็นทีมช่วยเพิ่มความสำเร็จในการทดสอบในโครงการ Agile

ทีมผู้ทดสอบใน Agile ต้องเข้าร่วมและมีส่วนร่วมในกิจกรรมทั้งหมดของโครงการและในขณะเดียวกันก็ต้องใช้ความเชี่ยวชาญในการทดสอบ

ผู้ทดสอบ Agile ควรมีทักษะการทดสอบแบบดั้งเดิม นอกจากนี้ Agile tester ต้องการ -

• มีมนุษยสัมพันธ์ดี

• ความสามารถในการดำเนินการเชิงบวกและมุ่งเน้นการแก้ปัญหากับสมาชิกในทีมและผู้มีส่วนได้ส่วนเสีย

• ความสามารถในการแสดงความคิดที่สำคัญมุ่งเน้นคุณภาพและไม่เชื่อมั่นเกี่ยวกับผลิตภัณฑ์

• ความถนัดที่จะกระตือรือร้นในการรับข้อมูลจากผู้มีส่วนได้ส่วนเสีย

• ทักษะในการทำงานอย่างมีประสิทธิผลกับลูกค้าและผู้มีส่วนได้ส่วนเสียในการกำหนดเรื่องราวของผู้ใช้ที่สามารถทดสอบได้เกณฑ์การยอมรับ

• ความสามารถในการเป็นสมาชิกในทีมที่ดีในการทำงานร่วมกับนักพัฒนาในการผลิตโค้ดคุณภาพ

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

• ความสามารถในการประเมินและรายงานผลการทดสอบความคืบหน้าการทดสอบและคุณภาพของผลิตภัณฑ์

• เปิดกว้างเพื่อตอบสนองต่อการเปลี่ยนแปลงอย่างรวดเร็วรวมถึงการเปลี่ยนแปลงเพิ่มหรือปรับปรุงกรณีทดสอบ

• ศักยภาพในการจัดระเบียบงานด้วยตนเอง

• ความกระตือรือร้นในการเติบโตของทักษะอย่างต่อเนื่อง

• ความสามารถในการทดสอบอัตโนมัติ, การพัฒนาที่ขับเคลื่อนด้วยการทดสอบ (TDD), การพัฒนาที่ขับเคลื่อนด้วยการทดสอบการยอมรับ (ATDD), การพัฒนาการขับเคลื่อนด้วยพฤติกรรม (BDD) และการทดสอบตามประสบการณ์

บทบาทของผู้ทดสอบในทีม Agile

ผู้ทดสอบในทีม Agile มีส่วนร่วมในโครงการและกิจกรรมการพัฒนาทั้งหมดเพื่อสนับสนุนความเชี่ยวชาญด้านการทดสอบให้ดีที่สุด

กิจกรรมทดสอบ Agile ได้แก่ -

• ตรวจสอบการใช้เครื่องมือทดสอบอย่างเหมาะสม

• การกำหนดค่าใช้งานและจัดการสภาพแวดล้อมการทดสอบและข้อมูลการทดสอบ

• การให้คำปรึกษาสมาชิกในทีมคนอื่น ๆ ในแง่มุมที่เกี่ยวข้องของการทดสอบ

• ตรวจสอบให้แน่ใจว่ามีการจัดกำหนดการงานทดสอบที่เหมาะสมในระหว่างการวางแผนรุ่นและการวิ่ง

• การทำความเข้าใจการนำไปใช้และการปรับปรุงกลยุทธ์การทดสอบ

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

• ทำการทดสอบที่ถูกต้องในเวลาที่เหมาะสมและในระดับการทดสอบที่เหมาะสม

• รายงานข้อบกพร่องและทำงานร่วมกับทีมในการแก้ไข

• การวัดและการรายงานความครอบคลุมการทดสอบในมิติความครอบคลุมทั้งหมดที่เกี่ยวข้อง

• การมีส่วนร่วมในการวิ่งย้อนหลังเสนอแนะและดำเนินการปรับปรุงในเชิงรุก

ใน Agile Lifecycle ผู้ทดสอบมีบทบาทสำคัญใน -

• Teamwork
• การวางแผนการทดสอบ
• Sprint Zero
• Integration
• แนวปฏิบัติในการทดสอบแบบ Agile

การทำงานเป็นทีม

ในการพัฒนาแบบ Agile การทำงานเป็นทีมเป็นพื้นฐานดังนั้นจึงต้องมีสิ่งต่อไปนี้ -

• Collaborative Approach- ทำงานร่วมกับสมาชิกทีมข้ามสายงานในกลยุทธ์การทดสอบการวางแผนการทดสอบข้อกำหนดการทดสอบการดำเนินการทดสอบการประเมินผลการทดสอบและการรายงานผลการทดสอบ สนับสนุนความเชี่ยวชาญในการทดสอบร่วมกับกิจกรรมอื่น ๆ ของทีม

• Self-organizing - การวางแผนและจัดระเบียบที่ดีภายในการวิ่งเพื่อให้บรรลุเป้าหมายของการทดสอบโดยการรวมความเชี่ยวชาญจากสมาชิกในทีมคนอื่น ๆ ด้วย

• Empowerment - การตัดสินใจทางเทคนิคที่เหมาะสมเพื่อให้บรรลุเป้าหมายของทีม

• Commitment - มุ่งมั่นทำความเข้าใจและประเมินพฤติกรรมและคุณลักษณะของผลิตภัณฑ์ตามที่ลูกค้าและผู้มีส่วนได้ส่วนเสียต้องการ

• Transparent - เปิดกว้างสื่อสารและรับผิดชอบ

• Credibility- สร้างความมั่นใจในความน่าเชื่อถือของกลยุทธ์การทดสอบการนำไปใช้และการดำเนินการ แจ้งให้ลูกค้าและผู้มีส่วนได้ส่วนเสียทราบเกี่ยวกับกลยุทธ์การทดสอบ

• Open to Feedback- เข้าร่วมใน sprint retrospectives เพื่อเรียนรู้จากทั้งความสำเร็จและความล้มเหลว การค้นหาความคิดเห็นของลูกค้าและดำเนินการอย่างรวดเร็วและเหมาะสมเพื่อให้แน่ใจว่าได้ส่งมอบที่มีคุณภาพ

• Resilient - การตอบสนองต่อการเปลี่ยนแปลง

การวางแผนการทดสอบ

การวางแผนการทดสอบควรเริ่มต้นในระหว่างการวางแผนรุ่นและการอัปเดตในระหว่างการวิ่งแต่ละครั้ง การวางแผนการทดสอบควรครอบคลุมงานต่อไปนี้ -

• การกำหนดขอบเขตการทดสอบขอบเขตของการทดสอบการทดสอบและเป้าหมายการวิ่ง

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

• กำหนดการทดสอบคุณสมบัติและลักษณะเฉพาะ

• กำหนดเวลางานทดสอบและกำหนดความถี่ของการทดสอบ

• การระบุวิธีการทดสอบเทคนิคเครื่องมือและข้อมูลการทดสอบ

• การตรวจสอบข้อกำหนดเบื้องต้นเช่นงานก่อนหน้าความเชี่ยวชาญและการฝึกอบรม

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

• การกำหนดลำดับความสำคัญโดยพิจารณาจากความสำคัญของลูกค้า / ผู้ใช้และการอ้างอิง

• มาถึงช่วงเวลาและความพยายามในการทดสอบ

• การระบุงานในการวางแผนการวิ่งแต่ละครั้ง

Sprint Zero

Sprint Zero เกี่ยวข้องกับกิจกรรมการเตรียมความพร้อมก่อนการวิ่งครั้งแรก ผู้ทดสอบต้องทำงานร่วมกับทีมในกิจกรรมต่อไปนี้ -

• การระบุขอบเขต
• แบ่งเรื่องราวของผู้ใช้ออกเป็น sprints
• การสร้างสถาปัตยกรรมระบบ
• การวางแผนจัดหาและติดตั้งเครื่องมือ (รวมถึงเครื่องมือทดสอบ)
• การสร้างกลยุทธ์การทดสอบเริ่มต้นสำหรับทุกระดับการทดสอบ
• การกำหนดเมตริกการทดสอบ
• การระบุเกณฑ์การยอมรับหรือเรียกอีกอย่างว่าคำจำกัดความของ "เสร็จสิ้น"
• การกำหนดเกณฑ์การออก
• การสร้างบอร์ด Scrum
• การกำหนดทิศทางสำหรับการทดสอบตลอดทั้งสปรินต์

บูรณาการ

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

เพื่อให้บรรลุเป้าหมายนี้ผู้ทดสอบจำเป็นต้อง -

• เข้าใจกลยุทธ์การรวมกลุ่ม
• ระบุการอ้างอิงทั้งหมดระหว่างฟังก์ชันและคุณสมบัติ

แนวปฏิบัติในการทดสอบแบบ Agile

ผู้ทดสอบ Agile จำเป็นต้องปรับแนวทางปฏิบัติแบบ Agile สำหรับการทดสอบในโครงการ Agile

• Pairing- สมาชิกในทีมสองคนทำงานร่วมกันโดยใช้แป้นพิมพ์เดียวกัน จากการทดสอบหนึ่งในนั้นบทวิจารณ์ / วิเคราะห์การทดสอบอื่น ๆ สมาชิกในทีมทั้งสองคนสามารถ

  • ผู้ทดสอบหนึ่งคนและนักพัฒนาหนึ่งคน

  • ผู้ทดสอบหนึ่งคนและนักวิเคราะห์ธุรกิจหนึ่งคน

  • ผู้ทดสอบสองคน

• Incremental Test Design - กรณีทดสอบสร้างขึ้นจากเรื่องราวของผู้ใช้โดยเริ่มจากการทดสอบอย่างง่ายและเปลี่ยนเป็นการทดสอบที่ซับซ้อนมากขึ้น

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

สถานะการทดสอบสามารถสื่อสารได้ -

• ในระหว่างการประชุมประจำวัน
• การใช้เครื่องมือจัดการทดสอบมาตรฐาน
• ผ่านทางผู้ส่งสาร

สถานะการทดสอบที่กำหนดโดยสถานะการผ่านการทดสอบเป็นสิ่งสำคัญในการตัดสินใจว่างานนั้น“ เสร็จสิ้น” หรือไม่ เสร็จสิ้นหมายถึงการทดสอบทั้งหมดสำหรับงานผ่าน

ความคืบหน้าการทดสอบ

สามารถติดตามความคืบหน้าของการทดสอบได้โดยใช้ -

• Scrum Boards (บอร์ดงาน Agile)
• แผนภูมิ Burndown
• ผลการทดสอบอัตโนมัติ

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

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

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

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

คุณภาพของผลิตภัณฑ์

เมตริกคุณภาพผลิตภัณฑ์ ได้แก่ -

• การทดสอบผ่าน / ไม่ผ่าน
• พบข้อบกพร่อง / แก้ไข
• ความครอบคลุมการทดสอบ
• อัตราการผ่านการทดสอบ / ไม่ผ่าน
• อัตราการค้นพบข้อบกพร่อง
• ความหนาแน่นของข้อบกพร่อง

การรวบรวมและรายงานเมตริกคุณภาพผลิตภัณฑ์โดยอัตโนมัติช่วยใน -

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

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

ปัจจัยแห่งความสำเร็จ

ในโครงการ Agile สามารถส่งมอบผลิตภัณฑ์ที่มีคุณภาพได้หากการทดสอบ Agile สำเร็จ

ประเด็นต่อไปนี้ต้องได้รับการพิจารณาเพื่อความสำเร็จของการทดสอบ Agile -

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

• ลดเวลาในการทดสอบทั้งหมดโดยทำการทดสอบอัตโนมัติในช่วงก่อนหน้าของวงจรการพัฒนา

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

• การทดสอบด้วยตนเองคิดเป็น 80% ของการทดสอบในโครงการ ดังนั้นผู้ทดสอบที่มีความเชี่ยวชาญจะต้องเป็นส่วนหนึ่งของทีม Agile

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

  • การกำหนดเรื่องราวของผู้ใช้โดยเน้นถึงพฤติกรรมของผลิตภัณฑ์ที่ผู้ใช้ปลายทางคาดหวัง

  • การระบุเกณฑ์การยอมรับในระดับเรื่องราวของผู้ใช้ / ระดับงานตามความคาดหวังของลูกค้า

  • การประมาณความพยายามและระยะเวลาในการทดสอบกิจกรรม

  • การวางแผนกิจกรรมการทดสอบ

  • ทำงานร่วมกับทีมพัฒนาเพื่อให้แน่ใจว่าการผลิตโค้ดตรงตามข้อกำหนดด้วยการออกแบบการทดสอบล่วงหน้า

  • ทดสอบการทดสอบครั้งแรกและต่อเนื่องเพื่อให้แน่ใจว่าสถานะเสร็จสิ้นตรงตามเกณฑ์การยอมรับในเวลาที่คาดไว้

  • สร้างความมั่นใจในการทดสอบในทุกระดับภายในการวิ่ง

  • การทดสอบการถดถอยเมื่อสิ้นสุดการวิ่งแต่ละครั้ง

  • การรวบรวมและวิเคราะห์เมตริกผลิตภัณฑ์ที่เป็นประโยชน์ต่อความสำเร็จของโครงการ

  • การวิเคราะห์ข้อบกพร่องเพื่อระบุสิ่งที่ต้องได้รับการแก้ไขใน Sprint ปัจจุบันและอาจล่าช้าไปยัง Sprint ที่ตามมา

  • มุ่งเน้นไปที่สิ่งที่สำคัญจากมุมมองของลูกค้า

Lisa Crispin ได้กำหนดปัจจัยสำคัญ 7 ประการสำหรับความสำเร็จในการทดสอบ Agile -

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

• Agile Testing Mindset - ผู้ทดสอบมีความกระตือรือร้นในการปรับปรุงคุณภาพอย่างต่อเนื่องและร่วมมือกับทีมอื่น ๆ อย่างต่อเนื่อง

• Automate Regression Testing- ออกแบบมาเพื่อทดสอบความสามารถและพัฒนาไดรฟ์พร้อมการทดสอบ เริ่มง่ายๆและให้ทีมงานเลือกเครื่องมือ พร้อมให้คำแนะนำ

• Provide and Obtain Feedback- เนื่องจากนี่เป็นค่า Agile หลักทีมงานทั้งหมดควรเปิดรับความคิดเห็น เนื่องจากผู้ทดสอบเป็นผู้ให้ข้อเสนอแนะจากผู้เชี่ยวชาญจึงต้องให้ความสำคัญกับข้อมูลที่เกี่ยวข้องและจำเป็น ในทางกลับกันการได้รับข้อเสนอแนะควรรองรับการเปลี่ยนแปลงกรณีทดสอบและการทดสอบ

• Build a Foundation of Core Agile Practices - มุ่งเน้นไปที่การทดสอบควบคู่ไปกับการเข้ารหัสการผสานรวมอย่างต่อเนื่องสภาพแวดล้อมการทดสอบการทำงานร่วมกันการทำงานเพิ่มขึ้นการยอมรับการเปลี่ยนแปลงการรักษาการทำงานร่วมกัน

• Collaborate with Customers - คัดลอกตัวอย่างทำความเข้าใจและตรวจสอบการแมปข้อกำหนดกับพฤติกรรมของผลิตภัณฑ์การตั้งค่าเกณฑ์การยอมรับการรับข้อเสนอแนะ

• Look at the Big Picture - ขับเคลื่อนการพัฒนาด้วยการทดสอบและตัวอย่างสำหรับธุรกิจโดยใช้ข้อมูลการทดสอบในโลกแห่งความเป็นจริงและคิดถึงผลกระทบในด้านอื่น ๆ

ในบทนี้เราจะเห็นคุณลักษณะที่สำคัญบางประการของการทดสอบแบบ Agile

ประโยชน์การทดสอบแบบ Agile

ประโยชน์ของการทดสอบ Agile คือ -

• ความพึงพอใจของลูกค้าด้วยผลิตภัณฑ์ที่ผ่านการทดสอบอย่างรวดเร็วและต่อเนื่องและแสวงหาความคิดเห็นของลูกค้า

• ลูกค้านักพัฒนาและผู้ทดสอบมีปฏิสัมพันธ์ซึ่งกันและกันอย่างต่อเนื่องซึ่งจะช่วยลดรอบเวลา

• ผู้ทดสอบ Agile มีส่วนร่วมในการกำหนดข้อกำหนดที่เอื้อให้ความเชี่ยวชาญในการทดสอบของพวกเขามุ่งเน้นไปที่สิ่งที่สามารถทำงานได้

• ผู้ทดสอบ Agile มีส่วนร่วมในการประมาณเพื่อประเมินความพยายามและเวลาในการทดสอบ

• การออกแบบการทดสอบในช่วงต้นสะท้อนถึงเกณฑ์การยอมรับ

• ข้อกำหนดในการทดสอบรวมโดยทั้งทีมเพื่อหลีกเลี่ยงข้อเสีย

• มุ่งเน้นที่คุณภาพของผลิตภัณฑ์อย่างต่อเนื่องโดยทีมงานทั้งหมด

• ความหมายของ Done ผ่านการทดสอบการสะท้อนสถานะเพื่อให้แน่ใจว่าตรงตามข้อกำหนด

• ข้อเสนอแนะอย่างต่อเนื่องเกี่ยวกับความล่าช้าหรือการอุดตันเพื่อให้สามารถแก้ไขปัญหาได้ทันทีด้วยความพยายามจากทั้งทีม

• ตอบสนองอย่างรวดเร็วต่อความต้องการที่เปลี่ยนแปลงและรองรับเร็ว ๆ นี้

• การทดสอบการถดถอยที่ขับเคลื่อนด้วยการผสานรวมอย่างต่อเนื่อง

• ไม่มีความล่าช้าระหว่างการพัฒนาและการทดสอบ ทดสอบก่อนตามแนวทางการทดสอบอย่างต่อเนื่อง

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

แนวทางปฏิบัติที่ดีที่สุดในการทดสอบแบบ Agile

ปฏิบัติตามแนวทางปฏิบัติที่ดีที่สุดด้านล่าง -

• การรวมผู้ทดสอบที่มีความเชี่ยวชาญในการทดสอบทุกประเภทในทุกระดับ

• ผู้ทดสอบที่มีส่วนร่วมในการกำหนดความต้องการร่วมมือกับลูกค้าเกี่ยวกับพฤติกรรมที่คาดหวังของผลิตภัณฑ์

• ผู้ทดสอบแบ่งปันข้อเสนอแนะอย่างต่อเนื่องกับนักพัฒนาและลูกค้า

• ทดสอบแนวทางการทดสอบก่อนและต่อเนื่องเพื่อให้สอดคล้องกับงานพัฒนา

• ติดตามสถานะการทดสอบและความคืบหน้าของการทดสอบอย่างรวดเร็วและต่อเนื่องโดยมุ่งเน้นที่การส่งมอบผลิตภัณฑ์ที่มีคุณภาพ

• การทดสอบระบบอัตโนมัติในช่วงต้นของวงจรการพัฒนาเพื่อลดเวลาในการทำงาน

• ในการดำเนินการทดสอบการถดถอยใช้ประโยชน์จากการทดสอบอัตโนมัติเป็นวิธีที่มีประสิทธิภาพ

ความท้าทายในการทดสอบแบบ Agile

ความท้าทายต่อไปนี้มีอยู่ในการทดสอบ Agile -

• การไม่เข้าใจแนวทาง Agile และข้อ จำกัด ของ Business and Management อาจนำไปสู่ความคาดหวังที่ไม่สามารถบรรลุได้

• Agile เป็นไปตามแนวทางทั้งทีม แต่ไม่ใช่ทุกคนที่รู้ถึงความจำเป็นของแนวปฏิบัติในการทดสอบ ขอแนะนำให้ผู้ทดสอบฝึกสอนคนอื่น ๆ แต่ในสถานการณ์จริงไม่สามารถทำได้ด้วย Sprints (การทำซ้ำ) แบบกล่องเวลา

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

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

• การรวมอย่างต่อเนื่องเรียกร้องให้มีการทดสอบการถดถอยที่ต้องใช้ความพยายามอย่างมากแม้ว่าจะต้องเป็นแบบอัตโนมัติก็ตาม

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

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

แนวทางการทดสอบ Agile

ใช้แนวทางต่อไปนี้ขณะทำการทดสอบ Agile

• เข้าร่วมใน Release Planning เพื่อระบุกิจกรรมการทดสอบที่จำเป็นและจัดทำแผนทดสอบเวอร์ชันเริ่มต้น

• เข้าร่วมในเซสชันการประมาณค่าเพื่อให้ได้ความพยายามและระยะเวลาในการทดสอบเพื่อให้กิจกรรมการทดสอบรองรับในการทำซ้ำ

• เข้าร่วมใน User Story Definition เพื่อไปที่ Acceptance Test Cases

• เข้าร่วมการประชุมวางแผน Sprint ทุกครั้งเพื่อทำความเข้าใจขอบเขตและอัปเดตแผนการทดสอบ

• ทำงานร่วมกับทีมพัฒนาอย่างต่อเนื่องในช่วง Sprint เพื่อให้การทดสอบและการเข้ารหัสประสบความสำเร็จใน Sprint

• เข้าร่วมการประชุมสแตนด์อัพรายวันและแจ้งความล่าช้าในการทดสอบหรือการอุดตันหากมีเพื่อรับการแก้ไขทันที

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

• เตรียมพร้อมที่จะรองรับการเปลี่ยนแปลงตอบสนองด้วยการปรับเปลี่ยนกรณีทดสอบข้อมูลการทดสอบ

• เข้าร่วมใน Sprint Retrospectives เพื่อทำความเข้าใจและมีส่วนร่วมในแนวทางปฏิบัติที่ดีที่สุดและบทเรียนที่ได้เรียนรู้

• ทำงานร่วมกันเพื่อรับคำติชมของลูกค้าในแต่ละ Sprint

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

• การทดสอบหน่วย
• การทดสอบการผสานรวม
• การทดสอบระบบ
• การทดสอบการยอมรับของผู้ใช้

การทดสอบหน่วย

• ทำควบคู่กับ Coding โดย Developer
• สนับสนุนโดยผู้ทดสอบที่เขียนกรณีทดสอบเพื่อให้แน่ใจว่าครอบคลุมการออกแบบ 100%
• ต้องมีการทบทวนกรณีทดสอบหน่วยและผลการทดสอบหน่วย
• ข้อบกพร่องสำคัญที่ยังไม่ได้รับการแก้ไข (ตามลำดับความสำคัญและความรุนแรง) จะไม่ถูกทิ้งไว้
• การทดสอบหน่วยทั้งหมดเป็นแบบอัตโนมัติ

การทดสอบการผสานรวม

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

การทดสอบระบบ

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

การทดสอบการยอมรับของผู้ใช้

• เสร็จสิ้นในตอนท้ายของแต่ละ Sprint และเมื่อสิ้นสุดโครงการ

• ทำโดยลูกค้า ข้อเสนอแนะถูกนำโดยทีมงาน

• คำติชมจะเป็นข้อมูลใน Sprints ที่ตามมา

• เรื่องราวของผู้ใช้ใน Sprint ได้รับการยืนยันล่วงหน้าว่าสามารถทดสอบได้และเป็นไปตามเกณฑ์การยอมรับที่กำหนดไว้

ประเภทการทดสอบ

• การทดสอบส่วนประกอบ (การทดสอบหน่วย)
• การทดสอบการทำงาน (การทดสอบเรื่องราวของผู้ใช้)
• การทดสอบที่ไม่สามารถใช้งานได้ (ประสิทธิภาพการโหลดความเครียด ฯลฯ )
• การทดสอบการยอมรับ

การทดสอบสามารถทำได้ทั้งแบบแมนนวลอัตโนมัติเต็มรูปแบบการผสมผสานระหว่างด้วยตนเองและอัตโนมัติหรือด้วยตนเองที่เครื่องมือสนับสนุน

สนับสนุนการเขียนโปรแกรมและการทดสอบผลิตภัณฑ์ที่สำคัญ

การทดสอบสามารถสำหรับ -

• Supporting Development (Support Programming) - Support Programming Tests ใช้โดย Programmer

  • เพื่อตัดสินใจว่าพวกเขาต้องเขียนโค้ดอะไรเพื่อให้บรรลุพฤติกรรมบางอย่างของระบบ

  • ต้องมีการทดสอบอะไรบ้างหลังจาก Coding เพื่อให้แน่ใจว่า Code ใหม่จะไม่ขัดขวางพฤติกรรมที่เหลือของระบบ

• Verification only (Critique Product) - Critique Product Tests ใช้สำหรับค้นหาความไม่เพียงพอในผลิตภัณฑ์สำเร็จรูป

การเผชิญหน้าทางธุรกิจและการทดสอบการเผชิญกับเทคโนโลยี

ในการตัดสินใจว่าจะทำการทดสอบใดเมื่อใดคุณต้องพิจารณาว่าการทดสอบนั้น -

• หันหน้าไปทางธุรกิจหรือ
• หันหน้าไปทางเทคโนโลยี

การทดสอบการเผชิญหน้าทางธุรกิจ

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

การทดสอบการเผชิญกับเทคโนโลยี

การทดสอบเป็นการทดสอบที่ต้องเผชิญกับเทคโนโลยีหากตอบคำถามที่มีกรอบคำจากโดเมนเทคโนโลยี โปรแกรมเมอร์เข้าใจสิ่งที่ต้องดำเนินการตามคำชี้แจงเกี่ยวกับเทคโนโลยี

ประเภทการทดสอบทั้งสองนี้สามารถดูได้โดยใช้ Agile Testing Quadrants ที่กำหนดโดย Brian Marick

Quadrants การทดสอบ Agile

การรวมสองด้านของประเภทการทดสอบเข้าด้วยกัน Quadrants การทดสอบ Agile ต่อไปนี้ได้มาจาก Brian Marick -

Agile Testing Quadrants ให้อนุกรมวิธานที่เป็นประโยชน์เพื่อช่วยทีมระบุวางแผนและดำเนินการทดสอบที่จำเป็น

• Quadrant Q1- ระดับหน่วยการเผชิญกับเทคโนโลยีและสนับสนุนนักพัฒนา การทดสอบหน่วยเป็นของ Quadrant นี้ การทดสอบเหล่านี้อาจเป็นการทดสอบอัตโนมัติ

• Quadrant Q2- ระดับระบบการเผชิญหน้าทางธุรกิจและสอดคล้องกับพฤติกรรมของผลิตภัณฑ์ การทดสอบการทำงานเป็นของ Quadrant นี้ การทดสอบเหล่านี้เป็นแบบแมนนวลหรือแบบอัตโนมัติ

• Quadrant Q3- ระดับการยอมรับของระบบหรือผู้ใช้การหันหน้าเข้าหาธุรกิจและมุ่งเน้นไปที่สถานการณ์แบบเรียลไทม์ การทดสอบการยอมรับของผู้ใช้เป็นของส่วนนี้ การทดสอบเหล่านี้เป็นแบบแมนนวล

• Quadrant Q4- ระดับการยอมรับของระบบหรือการปฏิบัติงานการหันหน้าเข้าหาเทคโนโลยีและมุ่งเน้นไปที่ประสิทธิภาพการโหลดความเครียดการบำรุงรักษาการทดสอบความสามารถในการปรับขยาย สามารถใช้เครื่องมือพิเศษสำหรับการทดสอบเหล่านี้ร่วมกับการทดสอบอัตโนมัติ

การรวมสิ่งเหล่านี้เข้าด้วยกัน Quadrants การทดสอบ Agile ที่สะท้อนให้เห็น What-Testing-When สามารถมองเห็นได้ดังนี้ -

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

ทั้งทีมทำงานร่วมกันในกลยุทธ์การทดสอบการวางแผนการทดสอบข้อกำหนดการทดสอบการดำเนินการทดสอบการประเมินผลการทดสอบและการรายงานผลการทดสอบ

การสร้างเรื่องราวของผู้ใช้ร่วมกัน

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

ผู้ทดสอบยังกำหนดเกณฑ์การยอมรับสำหรับทุกสถานการณ์ที่ลูกค้าตกลง

ผู้ทดสอบมีส่วนช่วยในการสร้างเรื่องราวของผู้ใช้ที่สามารถทดสอบได้

การวางแผนการวางจำหน่าย

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

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

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

การวางแผน Sprint

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

ผู้ทดสอบควร -

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

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

การวิเคราะห์การทดสอบ

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

การทดสอบ

สมาชิกทุกคนในทีม Scrum ควรเข้าร่วมการทดสอบ

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

• ผู้ทดสอบแสดงคุณสมบัติที่ใช้งานได้และไม่ใช้งานได้ของเรื่องราวของผู้ใช้

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

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

• มีการรวบรวมและดูแลผลการทดสอบ

การทดสอบอัตโนมัติ

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

การทดสอบด้วยตนเองมุ่งเน้นไปที่การทดสอบเชิงสำรวจความเปราะบางของผลิตภัณฑ์การทำนายข้อบกพร่อง

ระบบอัตโนมัติของกิจกรรมการทดสอบ

ระบบอัตโนมัติของกิจกรรมการทดสอบช่วยลดภาระในการทำงานซ้ำ ๆ และทำให้ประหยัดต้นทุน อัตโนมัติ

• ทดสอบการสร้างข้อมูล
• ทดสอบการโหลดข้อมูล
• สร้างการปรับใช้ในสภาพแวดล้อมการทดสอบ
• ทดสอบการจัดการสภาพแวดล้อม
• การเปรียบเทียบเอาต์พุตข้อมูล

การทดสอบการถดถอย

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

การจัดการการตั้งค่า

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

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

แนวปฏิบัติในการทดสอบแบบ Agile

ผู้ทดสอบในทีม Scrum สามารถปฏิบัติตาม Agile Practices ต่อไปนี้ -

• Pairing- สมาชิกในทีมสองคนนั่งด้วยกันและทำงานร่วมกัน ทั้งสองคนสามารถเป็นผู้ทดสอบสองคนหรือผู้ทดสอบหนึ่งคนและนักพัฒนาหนึ่งคน

• Incremental Test Design - กรณีทดสอบได้รับการพัฒนาเมื่อ Sprints ก้าวหน้าขึ้นเรื่อย ๆ และเพิ่มเรื่องราวของผู้ใช้

เมตริก Agile

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

แนะนำเมตริกหลายรายการสำหรับการพัฒนา Scrum เมตริกที่สำคัญ ได้แก่ -

• Ratio of Successful Sprints - (Number of successful Sprints / Total number of Sprints) * 100. Sprint ที่ประสบความสำเร็จคือสิ่งที่ทีมสามารถตอบสนองความมุ่งมั่น

• Velocity- Velocity ของทีมขึ้นอยู่กับจำนวน Story Points ที่ทีมได้รับระหว่างการวิ่ง Story Points คือการวัดเรื่องราวของผู้ใช้ที่นับระหว่างการประมาณค่า

• Focus Factor - (Velocity / Team’s Work Capacity) / 100. Focus Factor คือเปอร์เซ็นต์ของความพยายามของทีมที่ทำให้เกิดเรื่องราวที่เสร็จสมบูรณ์

• Estimation Accuracy - (Estimated effort / Actual effort) / 100. ความแม่นยำในการประมาณการคือความสามารถของทีมในการประเมินความพยายามอย่างแม่นยำ

• Sprint Burndown- งาน (ใน Story Points หรือเป็นชั่วโมง) ที่เหลือเทียบกับ งานที่ต้องอยู่ในอุดมคติ (ตามการประมาณการ)

  • หากมีมากกว่านั้นแสดงว่าทีมมีงานมากเกินกว่าที่จะทำได้

  • หากน้อยกว่าแสดงว่าทีมประเมินไม่ถูกต้อง

• Defect Count- จำนวนข้อบกพร่องใน Sprint จำนวนข้อบกพร่องคือจำนวนข้อบกพร่องในซอฟต์แวร์เทียบกับสินค้าค้างส่ง

• Severity of Defects- ข้อบกพร่องสามารถแบ่งออกเป็นเล็กน้อยใหญ่และสำคัญตามความรุนแรง ผู้ทดสอบสามารถกำหนดการจัดหมวดหมู่

Sprint Retrospectives

ใน Sprint Retrospectives สมาชิกในทีมทุกคนจะเข้าร่วม พวกเขาแบ่งปัน -

• สิ่งที่เป็นไปด้วยดี
• Metrics
• ขอบเขตสำหรับการปรับปรุง
• รายการการดำเนินการที่จะใช้

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

ในบทนี้คุณจะได้รับความเข้าใจเกี่ยวกับวิธีการ -

• ทดสอบขับเคลื่อนการพัฒนา (TDD)
• การทดสอบการยอมรับการขับเคลื่อนการพัฒนา (ATDD)
• พฤติกรรมขับเคลื่อนการพัฒนา (BDD)

ทดสอบขับเคลื่อนการพัฒนา

ในวิธี Test Driven Development (TDD) รหัสได้รับการพัฒนาตามแนวทาง Testfirst ที่กำหนดโดย Automated Test Cases กรณีทดสอบถูกเขียนขึ้นก่อนที่จะล้มเหลวโค้ดได้รับการพัฒนาขึ้นโดยยึดตามนั้นเพื่อให้แน่ใจว่าการทดสอบผ่าน วิธีการทำซ้ำการปรับโครงสร้างจะกระทำผ่านการพัฒนาโค้ด

TDD สามารถเข้าใจได้ด้วยความช่วยเหลือของขั้นตอนต่อไปนี้ -

• Step 1 - เขียนกรณีทดสอบเพื่อสะท้อนพฤติกรรมที่คาดหวังของฟังก์ชันการทำงานของโค้ดที่ต้องเขียน

• Step 2- ทำการทดสอบ การทดสอบล้มเหลวเนื่องจากโค้ดยังไม่ได้รับการพัฒนา

• Step 3 - พัฒนาโค้ดตามกรณีทดสอบ

• Step 4- ทำการทดสอบอีกครั้ง คราวนี้การทดสอบจะต้องผ่านเนื่องจากมีการเข้ารหัสฟังก์ชันการทำงาน ทำซ้ำขั้นตอนที่ (3) และขั้นตอนที่ (4) จนกระทั่งการทดสอบผ่านไป

• Step 5 - สร้างรหัสใหม่

• Step 6 - ทำการทดสอบอีกครั้งเพื่อให้แน่ใจว่าผ่าน

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

การทดสอบสามารถอยู่ในระดับหน่วยการรวมหรือระบบ ต้องมีการสื่อสารอย่างต่อเนื่องระหว่างผู้ทดสอบและผู้พัฒนา

การทดสอบการยอมรับการขับเคลื่อนการพัฒนา

ในวิธี Acceptance Test Driven Development (ATDD) โค้ดนี้ได้รับการพัฒนาตามแนวทางการทดสอบก่อนที่กำหนดโดย Acceptance Test Cases โฟกัสอยู่ที่เกณฑ์การยอมรับและกรณีการทดสอบการยอมรับที่เขียนโดยผู้ทดสอบระหว่างการสร้างเรื่องราวของผู้ใช้โดยร่วมมือกับลูกค้าผู้ใช้ปลายทางและผู้มีส่วนได้ส่วนเสียที่เกี่ยวข้อง

• Step 1 - เขียนกรณีการทดสอบการยอมรับพร้อมกับเรื่องราวของผู้ใช้ร่วมกับลูกค้าและผู้ใช้

• Step 2 - กำหนดเกณฑ์การยอมรับที่เกี่ยวข้อง

• Step 3 - พัฒนารหัสตามการทดสอบการยอมรับและเกณฑ์การยอมรับ

• Step 4 - เรียกใช้การทดสอบการยอมรับเพื่อให้แน่ใจว่าโค้ดทำงานตามที่คาดไว้

• Step 5- ทำการทดสอบการยอมรับโดยอัตโนมัติ ทำซ้ำStep 3 – Step 5 จนกว่าเรื่องราวของผู้ใช้ทั้งหมดในการทำซ้ำจะถูกนำไปใช้

• Step 6 - ทำการทดสอบการถดถอยโดยอัตโนมัติ

• Step 7 - เรียกใช้การทดสอบการถดถอยอัตโนมัติเพื่อให้แน่ใจว่าการถดถอยอย่างต่อเนื่อง

พฤติกรรมขับเคลื่อนการพัฒนา (BDD)

Behavior Driven Development (BDD) คล้ายกับ Test Driven Development (TDD) และมุ่งเน้นไปที่การทดสอบโค้ดเพื่อให้แน่ใจว่าระบบทำงานได้ตามที่คาดหวัง

ใน BDD มีการใช้ภาษาเช่นภาษาอังกฤษเพื่อให้เหมาะสมกับผู้ใช้ผู้ทดสอบและนักพัฒนา ช่วยให้มั่นใจ -

• การสื่อสารอย่างต่อเนื่องระหว่างผู้ใช้ผู้ทดสอบและนักพัฒนา
• ความโปร่งใสในสิ่งที่กำลังพัฒนาและทดสอบ

เทคนิคการทดสอบจากการทดสอบแบบดั้งเดิมสามารถใช้ในการทดสอบ Agile ได้เช่นกัน นอกจากนี้ยังมีการใช้เทคนิคการทดสอบและคำศัพท์เฉพาะของ Agile ในโครงการ Agile

พื้นฐานการทดสอบ

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

เพื่อให้แน่ใจว่ามีการทดสอบคุณภาพคุณสามารถพิจารณาสิ่งต่อไปนี้เพิ่มเติมเป็นพื้นฐานการทดสอบ -

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

คำจำกัดความของ Done

คำจำกัดความของ Done (DoD) คือเกณฑ์ที่ใช้ในโครงการ Agile เพื่อให้แน่ใจว่ากิจกรรมใน Sprint backlog เสร็จสมบูรณ์ DoD อาจแตกต่างกันไปในแต่ละทีม Scrum แต่ควรสอดคล้องกันภายในทีมเดียว

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

DoD ทั่วไปสำหรับเรื่องราวของผู้ใช้สามารถมี -

• เกณฑ์การยอมรับโดยละเอียดที่ทดสอบได้
• เกณฑ์เพื่อให้แน่ใจว่าเรื่องราวของผู้ใช้สอดคล้องกับเรื่องอื่น ๆ ในการทำซ้ำ
• เกณฑ์เฉพาะที่เกี่ยวข้องกับผลิตภัณฑ์
• ด้านพฤติกรรมการทำงาน
• ลักษณะที่ไม่ทำงาน
• Interfaces
• ทดสอบข้อกำหนดข้อมูล
• ความครอบคลุมการทดสอบ
• Refactoring
• ข้อกำหนดการตรวจสอบและการอนุมัติ

นอกจาก DoD สำหรับเรื่องราวของผู้ใช้แล้ว DoD ยังจำเป็น -

• ในทุกระดับของการทดสอบ
• สำหรับแต่ละคุณสมบัติ
• สำหรับการทำซ้ำแต่ละครั้ง
• สำหรับการเปิดตัว

ข้อมูลการทดสอบ

ผู้ทดสอบต้องมีข้อมูลการทดสอบดังต่อไปนี้ -

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

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

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

การออกแบบการทดสอบการทำงานและไม่ใช้งาน

ในโครงการ Agile สามารถใช้เทคนิคการทดสอบแบบเดิมได้ แต่เน้นที่การทดสอบในระยะเริ่มต้น ต้องมีกรณีทดสอบก่อนที่จะเริ่มการใช้งาน

สำหรับการออกแบบการทดสอบฟังก์ชันผู้ทดสอบและนักพัฒนาสามารถใช้เทคนิคการออกแบบการทดสอบ Black Box แบบดั้งเดิมเช่น -

• การแบ่งพาร์ติชันความเท่าเทียมกัน
• การวิเคราะห์มูลค่าขอบเขต
• ตารางการตัดสินใจ
• การเปลี่ยนสถานะ
• ต้นไม้คลาส

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

การทดสอบเชิงสำรวจ

ในโครงการ Agile เวลามักเป็นปัจจัย จำกัด สำหรับการวิเคราะห์ทดสอบและการออกแบบการทดสอบ ในกรณีเช่นนี้เทคนิคการทดสอบเชิงสำรวจสามารถใช้ร่วมกับเทคนิคการทดสอบแบบเดิมได้

Exploratory Testing (ET) หมายถึงการเรียนรู้พร้อมกันการออกแบบการทดสอบและการดำเนินการทดสอบ ในการทดสอบเชิงสำรวจผู้ทดสอบจะควบคุมการออกแบบการทดสอบอย่างแข็งขันในขณะที่ดำเนินการและใช้ข้อมูลที่ได้รับขณะทดสอบเพื่อออกแบบการทดสอบใหม่และดีกว่า

การทดสอบเชิงสำรวจมีประโยชน์เพื่อรองรับการเปลี่ยนแปลงในโครงการ Agile

การทดสอบตามความเสี่ยง

การทดสอบตามความเสี่ยงคือการทดสอบตามความเสี่ยงของความล้มเหลวและลดความเสี่ยงโดยใช้เทคนิคการออกแบบการทดสอบ

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

• ความเสี่ยงในการทำงาน
• ความเสี่ยงด้านประสิทธิภาพที่ไม่สามารถใช้งานได้
• ความเสี่ยงในการใช้งานที่ไม่สามารถใช้งานได้

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

• ความเสี่ยงสูงต้องการการทดสอบที่กว้างขวาง
• ความเสี่ยงต่ำต้องใช้การทดสอบเคอร์เซอร์เท่านั้น

การทดสอบได้รับการออกแบบโดยใช้เทคนิคการทดสอบที่เหมาะสมตามระดับความเสี่ยงและลักษณะความเสี่ยงของแต่ละความเสี่ยง จากนั้นจะทำการทดสอบเพื่อลดความเสี่ยง

การทดสอบพอดี

Fit Tests คือการทดสอบการยอมรับโดยอัตโนมัติ Tools Fit และ FitNesse สามารถใช้สำหรับการทดสอบการยอมรับโดยอัตโนมัติ

FIT ใช้ JUnit แต่ขยายฟังก์ชันการทดสอบ ตาราง HTML ใช้เพื่อแสดงกรณีทดสอบ Fixture คือคลาส Java ที่อยู่หลังตาราง HTML ฟิกซ์เจอร์รับเนื้อหาของตาราง HTML และรันกรณีทดสอบในโครงการที่กำลังทดสอบ

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

เนื้อหาทั่วไปของแผนการทดสอบ ได้แก่ -

• กลยุทธ์การทดสอบ
• สภาพแวดล้อมการทดสอบ
• ความครอบคลุมการทดสอบ
• ขอบเขตการทดสอบ
• ทดสอบความพยายามและกำหนดเวลา
• เครื่องมือทดสอบ

ในโครงการ Agile สมาชิกในทีมทุกคนต้องรับผิดชอบต่อคุณภาพของผลิตภัณฑ์ ดังนั้นทุกคนจึงมีส่วนร่วมในการวางแผนการทดสอบเช่นกัน

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

เรื่องราวของผู้ใช้

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

ผู้ทดสอบยังตรวจสอบให้แน่ใจว่าเรื่องราวของผู้ใช้ทั้งหมดสามารถทดสอบได้และตรวจสอบเกณฑ์การยอมรับ

การทดสอบด้วยตนเองและอัตโนมัติ

ในระหว่างการทดสอบครั้งแรกจะใช้การทดสอบด้วยตนเอง ได้แก่ -

• การทดสอบหน่วย
• การทดสอบการรวมระบบ
• การทดสอบการทำงาน
• การทดสอบที่ไม่ใช่หน้าที่
• การทดสอบการยอมรับ

จากนั้นการทดสอบจะเป็นแบบอัตโนมัติสำหรับการรันในภายหลัง

ใน Test Driven Development, การทดสอบหน่วยจะถูกเขียนก่อนที่จะล้มเหลว, โค้ดได้รับการพัฒนาและทดสอบเพื่อให้แน่ใจว่าการทดสอบผ่าน

ใน Acceptance Test Driven Development, การทดสอบการยอมรับจะเขียนก่อนที่จะล้มเหลว, โค้ดได้รับการพัฒนาและทดสอบเพื่อให้แน่ใจว่าการทดสอบผ่าน

ในวิธีการพัฒนาอื่น ๆ ผู้ทดสอบจะทำงานร่วมกับทีมที่เหลือเพื่อให้แน่ใจว่ามีการครอบคลุมการทดสอบ

ในวิธีการทุกประเภทการรวมแบบต่อเนื่องจะเกิดขึ้นซึ่งรวมถึงการทดสอบการรวมแบบต่อเนื่อง

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

ใน Scrumการทำซ้ำเป็นแบบกำหนดเวลา ดังนั้นหากการทดสอบ User Story ไม่สามารถเสร็จสิ้นใน Sprint เฉพาะผู้ทดสอบสามารถรายงานในการประชุม standup รายวันว่าเรื่องราวของผู้ใช้ไม่สามารถเข้าถึง Done Status ภายใน Sprint นั้นได้และด้วยเหตุนี้จึงต้องรอการดำเนินการ Sprint ถัดไป

ผลการทดสอบ

เนื่องจากการทดสอบส่วนใหญ่ในโครงการ Agile เป็นแบบอัตโนมัติเครื่องมือจึงสร้างบันทึกผลการทดสอบที่จำเป็น ผู้ทดสอบตรวจสอบบันทึกผลการทดสอบ ผลการทดสอบจะต้องได้รับการดูแลสำหรับแต่ละ sprint / release

นอกจากนี้ยังสามารถจัดเตรียมสรุปการทดสอบซึ่งประกอบด้วย -

• ขอบเขตการทดสอบ (สิ่งที่ทดสอบและสิ่งที่ไม่ได้ทดสอบ)
• Defect Analysis along with Root Cause Analysis if possible
• Regression Testing Status after Defect Fixes
• Issues and the corresponding Resolution
• Pending Issues, if any
• Any modifications required in Test Strategy
• Test Metrics

Test Metrics Reports

In Agile Projects, the Test Metrics include the following for each Sprint −

• Test Effort
• Test Estimation Accuracy
• Test Coverage
• Automated Test Coverage
• No. of Defects
• Defect Rate (No. of Defects per User Story Point)
• Defect Severity
• Time to Fix a Defect in the same Sprint (It costs 24x as much to fix a bug that escapes the current sprint)
• No. of Defects fixed in the same Sprint
• Completion of Acceptance Testing by Customer within the Sprint

Sprint Review and Retrospective Reports

Testers also contribute to the Sprint Review and Retrospective Reports. The typical contents are −

• Test Metrics
• Test Result Logs review results
• What went right and what can be improved from Testing Point of View
• Best Practices
• Lessons Learned
• Issues
• Customer Feedback

Agile Testing activities can be managed effectively using Kanban concepts. The following ensure testing to be completed in time within an iteration / sprint and thus focus on the delivery of quality product.

• User Stories that are testable and effectively sized result in development and testing within the specified time limits.

• WIP (Work-In-Progress) limit allows to focus on a limited number of user stories at a time.

• Kanban board that represents the workflow visually, helps to track the testing activities and bottlenecks, if any.

• Kanban team collaboration concept lets resolution of bottlenecks as they are identified, without wait time.

• Preparation of Test Cases upfront, maintaining the test suite as the development progresses and obtaining Customer Feedback helps in eliminating Defects within the iteration / sprint.

• Definition of Done (DoD) is said to be Done-Done in the sense that a Story reaches a completion state only after the testing is also complete.

Testing Activities in Product Development

In Product development, the releases can be tracked with feature Kanban board. Features for a particular release are assigned to the Feature Kanban board that tracks the feature development status visually.

The Features in a release are broken into stories and developed within the release using agile approach.

The following Agile Testing activities ensure quality delivery in every release and at the end of all releases as well −

• Testers participate in User Story Creation and thus ensure −

  • All the possible Behaviors of the System are captured by means of User Stories and the Non-functional Requirements that are part of the User Stories.

  • User Stories are Testable.

  • Size of the User Stories allow Development and Testing to be complete (DoneDone) within the Iteration.

• Visual Task Kanban Board −

  • Depicts the status and progress of the Tasks

  • Bottlenecks are identified immediately as they occur

  • Facilitates to measure the cycle time which can then be optimized

• Team Collaboration helps in −

  • Accountability of the entire Team for Quality product

  • Resolution of bottlenecks as and when they occur, saving on wait time

  • Contribution of every expertise in all the activities

• Continuous Integration that focuses on Continuous Integration Testing

• Automation of Tests to save on Testing Effort and Time

• Defect Prevention with Test Cases written earlier to Development and mentoring the Developers on what is anticipated by different behaviors of the System −

  • WIP Limit to focus on a limited number of User Stories at a Time

• Continuous Testing as the Development progresses, to ensure Defect Fixes within the Iteration −

  • Ensure Test Coverage

  • Keep the Open Defects Count Low

Story Exploration

Story Exploration is the communication within an Agile team to explore Story understanding when the product owner passes a story for acceptance for development.

The product owner comes up with the story based on the functionality expected by the system. The developers do more exploring on each story before they mark it ready for acceptance. Testers also participate in the communication from testing perspective to make it as testable as possible.

Finalization of the Story is based on constant and continuous communication among the Product Owner, Developers and Testers.

Estimation

Estimation happens in Release Planning and each Iteration Planning.

In Release Planning, the testers provide −

• Information on what testing activities are required
• Effort Estimation for the same

In Iteration planning, the testers contribute to deciding on what and how many stories can be included in an iteration. The decision depends on the Test Effort and Test Schedule Estimation. The Story Estimation reflects the test estimation as well.

In Kanban, Done-Done is accomplished only when a story is developed and tested and marked as complete without defects.

Hence, Test Estimation plays a major Role in story estimation.

Story Planning

Story Planning begins after a Story has been estimated and assigned to current Iteration.

Story Planning includes the following test tasks −

• Prepare Test Data
• Extend Acceptance Tests
• Execute Manual Tests
• Conduct Exploratory Testing sessions
• Automate Continuous Integration Tests

In addition to these Testing Tasks, other tasks also may be required, such as −

• Performance Testing
• Regression Testing
• Updates of related Continuous Integration Tests

Story Progression

Story Progression uncovers additional tests that are required resulted by continuous communication between the developers and testers. In situations where the developers need more clarity on implementation, testers perform exploratory testing.

Continuous Testing is performed during Story Progression and includes Continuous Integration Testing. The entire team participates in the testing activities.

Story Acceptance

Story Acceptance occurs when the story reaches the Done-Done state. i.e., the story is developed and tested and signaled as complete.

Story testing is said to be completed when all the tests relevant to the story pass or level of test automation is met.

In Agile Projects, Testers are responsible for the following daily tasks −

• Support the developers in coding, with clarifications on the expected behavior of the system.

• Help developers in creating effective and efficient unit tests.

• Develop automation scripts.

• Integrate automation testing tools / scripts with continuous integration for regression testing.

For an effective and fast implementation of these tasks, a Continuous Integration (CI) system that supports CI of Code and test components is used in most of the Agile projects.

The testers and the developers in agile projects can benefit from various tools to manage testing sessions and to create and submit Defect reports. In addition to specialized tools for agile testing, agile teams can also benefit from test automation and test management tools.

Note − Record-and-Playback, Test-Last, Heavyweight, and Test Automation Solutions are not Agile as −

• The test-last workflow encouraged by such tools does not work for Agile teams.

• The unmaintainable scripts created with such tools become an impediment to change

• Such specialized tools create a need for Test automation specialists and thus foster silos

The Tools that are widely used are −

S.No.	Tool & Purpose
1	Hudson CI Framework
2	Selenium Functional Testing – Integrated with Hudson
3	CruiseControl CI Framework
4	Junit Java Unit Test
5	Nunit .Net Unit Test
6	Cobertura / JavaCodeCoverage / JFeature / JCover / Java Test Coverage
7	Jester Java - Mutation Testing/ Automated Error Seeding
8	Gretel Java Test Coverage Monitoring Tool
9	TestCocoon C/C++ or C# - reduces the amount of Tests by finding redundant Tests and finds Dead Code
10	JAZZ Java - Branch, Node, and Defuse Coverage and implements a GUI, Test Planners, Dynamic Instrumentation, and a Test Analyzer
11	Ant Java – Automation Build
12	Nant .Net - Automation Build
13	Bonfire Agile Testing add-on for JIRA

Agile Test Automation Tools

Effective Agile test automation tools support −

• Early test automation using a test-first approach.

• Writing test automation code using real languages, domain specific languages.

• Focusing on the expected behavior of the system.

• Separating the essence of the Test from the implementation details, thus making it Technology independent.

• Fostering Collaboration.

Automated Unit Tests (using Junit or NUnit) support test-first approach for coding. These are white-box tests and ensure that the design is sound, and that there are no defects. Such tests are built by developers with support from testers, and can be independent of the functionality that is required. This results in delivering a product that may not meet customer requirements and hence with no business value.

This concern is addressed by automating Acceptance Tests that are written with collaboration of customer, other stakeholders, testers and developers. The automated Acceptance Tests are written by the customers or product owners/business analysts reflecting the expected behavior of the product. The developers’ involvement ensures the production of code as per the requirements. However, if the testing is focused only on acceptance, the resulting code may remain non-extensible.

Thus, Automated Unit Tests and Automated Acceptance Tests are complimentary and both are needed in Agile Development.

Agile Tools and Frameworks that support Automated Acceptance Testing are −

• Fit
• Fitnesse
• Concordion
• Ruby
• Cucumber

Fit

Ward Cunningham developed the tool Fit that can be used for Acceptance Test Automation. Fit allows −

• Customers or Product Owners to give examples of product behavior using Microsoft Word and Microsoft Excel

• Programmers to easily turn those examples into automated tests.

Fit 1.1 supports both Java and .NET.

FitNesse

FitNesse is a wiki, which is a style of web server that allows any visitor to make any edits, including changing existing pages and creating new pages. A simple markup language lets you easily create headings, make text bold, underline, and italic, create bulleted lists, and do other kinds of simple formatting.

In FitNesse, Acceptance Test Automation is as follows −

• Express tests as tables of input data and expected output data.

• Use FitNesse to put the test table on the page that you can edit.

  • Alternatively, put the test table in Microsoft Excel, copy to clipboard and then use the Spreadsheet to FitNesse command to have FitNesse format your table properly

• Run the test

• You get the test results by color coding of the cells in the test table

  • green cells represent that the expected values are obtained

  • red cells represent that a different value than what you expected is obtained

  • yellow cells represent that an exception was thrown

Cucumber

Cucumber is a tool based on Behavior Driven Development (BDD) framework. The key features are −

• Is used to write acceptance tests for web applications.

• Allows automation of functional validation in easily readable and understandable format like plain English.

• Was implemented in Ruby and then extended to Java framework. Both support Junit.

• Supports other languages like Perl, PHP, Python, .Net etc.

• Can be used along with Selenium, Watir, Capybara, etc.