ขั้นตอนใดของ Agile (SCRUM) ที่เราควรเริ่มสร้างการทดสอบระบบอัตโนมัติ

พื้นหลังเล็กน้อยของฉัน - ฉันเป็นผู้ทดสอบด้วยตนเองเป็นเวลาเกือบ 2 ปีในสภาพแวดล้อม Agile โดยใช้ SCRUM (1-2 สัปดาห์ในการวิ่ง) ดังนั้นฉันต้องการที่จะแนะนำการทดสอบระบบอัตโนมัติในงานของฉันโดยใช้ Selenium WebDriver (กับ Java)

คำถามของฉันอยู่ในระหว่างเมื่อฉันควรทดสอบการทำงานด้วยตนเองและเมื่อฉันควรแปลงพวกเขาสำหรับการทดสอบอัตโนมัติ

ฉันได้อ่านและรับแนวทางที่แตกต่างเช่น:

1. เมื่อเริ่มการวิ่งใหม่ให้แปลงเรื่องราวของผู้ใช้เป็นสคริปต์อัตโนมัติจากการวิ่งก่อนหน้านี้หรือ;
2. แปลงเรื่องราวของผู้ใช้ภายในการวิ่งเดียวกัน

คำแนะนำใด ๆ / s จะได้รับการชื่นชมอย่างมาก ขอบคุณล่วงหน้า.

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

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

การทดสอบระบบอัตโนมัติมีความสำคัญอย่างยิ่งใน Agile เพราะ:

ความคล่องตัวขององค์กรถูก จำกัด ด้วยความคล่องตัวทางเทคนิค

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

https://less.works/less/technical-excellence/index.html

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

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

สิ่งสำคัญคือคุณจะไม่ทำเครื่องหมายเรื่องราวให้สมบูรณ์เว้นแต่คุณจะเขียนแบบทดสอบอัตโนมัติสำหรับเรื่องนั้น

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

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

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

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

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

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

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

ในสภาพแวดล้อมที่คล่องตัวอย่างแท้จริงทุกคนสามารถทำทุกอย่างได้ จะไม่มีใครทุ่มเทให้กับการทดสอบ 100% คุณจะต้องพัฒนาทักษะเพื่อช่วยในการทำงาน UI พื้นฐานหรืออย่างอื่น อย่างไรก็ตามเราไม่ค่อยมีชีวิตอยู่ในโลกอุดมคติ

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