Giai đoạn nào của Agile (SCRUM) chúng ta nên bắt đầu tạo các thử nghiệm tự động hóa?

Một chút nền tảng của tôi - Tôi là người thử nghiệm thủ công trong gần 2 năm trong môi trường Agile sử dụng SCRUM (1-2 tuần nước rút). Vì vậy, tôi muốn giới thiệu thử nghiệm tự động hóa trong công việc của mình bằng Selenium WebDriver (với Java).

Câu hỏi của tôi là khi nào tôi nên kiểm tra chức năng bằng tay và khi nào tôi nên chuyển đổi chúng để kiểm tra tự động hóa?

Tôi đã đọc và nhận được cách tiếp cận khác nhau, chẳng hạn như:

1. Khi một lần chạy nước rút mới đang bắt đầu, hãy chuyển đổi các câu chuyện của người dùng thành các tập lệnh tự động từ lần chạy nước rút trước đó, OR;
2. Chuyển đổi các câu chuyện của người dùng trong cùng một lần chạy nước rút.

Bất kỳ lời khuyên / s sẽ được rất nhiều đánh giá cao. Cảm ơn bạn trước.

Tự động hóa thử nghiệm (và tất cả các thử nghiệm khác) nên là một phần của định nghĩa thực hiện . Điều này để làm cho một sản phẩm có khả năng shippable. Bạn có thể gửi nếu nó không được thử nghiệm?

Kiểm thử cũng phải là một cách tiếp cận toàn đội, vì vậy tự động hóa kiểm thử không phải là trách nhiệm của người kiểm thử. Bắt đầu suy nghĩ về thử nghiệm càng sớm càng tốt trong quá trình.

Tự động hóa thử nghiệm rất quan trọng trong Agile vì:

Agility tổ chức bị hạn chế bởi Agility kỹ thuật

Nói cách khác, khi bạn chậm thực hiện các thay đổi cho sản phẩm của mình, thì việc bạn cấu trúc các nhóm, tổ chức của bạn hoặc khuôn khổ bạn áp dụng là gì, bạn sẽ chậm phản ứng với các thay đổi.

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

Nếu bạn hoãn thử nghiệm cho đến khi lặp lại, bạn sẽ luôn bị tụt lại phía sau. Làm cho việc thay đổi hướng của sản phẩm trở nên khó khăn hơn vì khó tái cấu trúc và bảo vệ an toàn cho hành vi bên ngoài của sản phẩm. Có bất kỳ thử nghiệm thủ công lặp đi lặp lại là chìa khóa trong việc làm chậm bạn, tự động hóa nó!

Rất nhiều người thử nghiệm sẽ nói với bạn rằng bạn không nên bắt đầu thử nghiệm từ đầu đến cuối cho đến khi giao diện sản phẩm ổn định. Đừng chờ đợi, thay vào đó hãy sử dụng tốt PageObjects và đảm bảo các bài kiểm tra của bạn có thể duy trì được và khiến cho nhà phát triển có trách nhiệm tạo và sửa chúng.

Điều quan trọng là bạn không đánh dấu một câu chuyện hoàn chỉnh trừ khi bạn đã viết các bài kiểm tra tự động cho câu chuyện đó.

Vì vậy, 1 dường như đã hết, vì bạn đang viết bài kiểm tra cho một nhiệm vụ đã hoàn thành trong lần chạy nước rút trước đó. Nếu xét nghiệm thất bại thì sao?

Tốt nhất bạn nên viết các bài kiểm tra tự động trong cùng một lần chạy nước rút mà mã được viết. Mã không nên được coi là "hoàn thành" cho đến khi các bài kiểm tra tự động được viết và bạn phải đưa mã về trạng thái "hoàn thành" vào cuối giai đoạn nước rút.

Bạn nên bắt đầu quá trình vào ngày đầu tiên của cuộc chạy nước rút bằng cách làm việc với nhà phát triển để hiểu mã và để giúp họ hiểu nhu cầu của bạn như một người thử nghiệm. Ví dụ: nếu bạn đang xây dựng các trang web, bạn có thể giúp họ hiểu nhu cầu thêm số nhận dạng duy nhất cho mọi thành phần trang mà bạn cần tương tác.

Hãy nhớ rằng trong scrum, công việc của bạn không phải là viết bài kiểm tra. Công việc của bạn là làm việc với nhóm để hoàn thành các mục tiêu nước rút. Điều đó có nghĩa là giao tiếp và hợp tác, điều sẽ xảy ra rất sớm trong giai đoạn nước rút. Bạn có thể bắt đầu làm việc với các thiết kế thử nghiệm và kế hoạch thử nghiệm trước khi mã sẵn sàng để được thử nghiệm.

Nếu bạn định kiểm tra tự động, bạn cũng có thể tạo các bài kiểm tra trả trước. Điều này sẽ giúp bạn xác định hành vi nào bạn đang mong đợi và kích thích bạn suy nghĩ như một khách hàng, cuối cùng nó sẽ giúp phần mềm của bạn có thể sử dụng được nhiều hơn. Và bạn sẽ được hưởng lợi từ thử nghiệm ngay lập tức khi bạn đang thực hiện chức năng.

Bạn có thể làm một trong hai, nhưng thông thường bạn muốn nhắm mục tiêu kiểm tra hồi quy với các kiểm tra tự động hóa. Điều đó có nghĩa là tôi sẽ làm thủ công cho đến khi bạn chắc chắn rằng nó đủ vững chắc để làm bài kiểm tra hồi quy. Điều này có thể ở giữa giai đoạn nước rút cho một số chức năng và có thể là trong giai đoạn nước rút trong tương lai cho chức năng khác.

Như đã nêu trong một câu trả lời khác , khi thử nghiệm xảy ra nên là một phần của định nghĩa thực hiện . Tuy nhiên, tôi không đồng ý với một số câu trả lời đó, vì vậy tôi muốn mở rộng với những trải nghiệm mà tôi đã gặp.

Trong một môi trường Agile thực sự, mọi người đều có thể làm mọi thứ. Sẽ không có ai đó tận tâm 100% để thử nghiệm, bạn cũng sẽ phát triển các kỹ năng để trợ giúp một số công việc UI cơ bản hoặc một cái gì đó khác. Tuy nhiên, chúng ta hiếm khi sống trong một thế giới lý tưởng.

Những gì tôi muốn giới thiệu sẽ là làm một chút của một phương pháp lai. Đối với Định nghĩa Hoàn thành của bạn, tôi sẽ nói rằng kiểm tra thủ công phải là một phần của Sprint, công việc được mã hóa. Bạn biết nó hoạt động và mọi lỗi có thể được báo cáo ngay lập tức, có thể được sửa, trước khi Sprint kết thúc để bạn có thể lập kế hoạch tiếp theo một. Bằng cách tập trung vào kiểm tra thủ công, bạn trở nên quen thuộc với những gì mã phải làm. Vào đầu Sprint tiếp theo khi bạn không có nhiều việc phải làm, bạn có thể thiết lập các bài kiểm tra tự động có thể chạy như một phần của quy trình xây dựng để ngăn ngừa lỗi hồi quy.