Ý chính cơ bản của hầu hết các phương thức Agile là một tính năng không được "thực hiện" cho đến khi nó được phát triển, thử nghiệm và trong nhiều trường hợp được phát hành. Điều này được cho là xảy ra trong những khoảng thời gian quay vòng nhanh, chẳng hạn như "Nước rút" trong quy trình Scrum.
Một phần phổ biến của Agile cũng là TDD, trong đó tuyên bố rằng các bài kiểm tra được thực hiện trước tiên.
Nhóm của tôi làm việc trên một chương trình GUI có nhiều bản vẽ cụ thể và như vậy. Để cung cấp các bài kiểm tra, nhóm thử nghiệm cần có khả năng làm việc với một cái gì đó ít nhất là cố gắng thực hiện những điều họ đang cố gắng kiểm tra. Chúng tôi đã tìm thấy không có cách nào xung quanh vấn đề này.
Tôi rất có thể thấy họ đến từ đâu bởi vì nếu tôi cố gắng viết phần mềm nhắm vào giao diện cơ bản bí ẩn nào đó thì tôi sẽ có một khoảng thời gian rất khó khăn. Mặc dù chúng tôi có hành vi được chỉ định khá rõ ràng, quá trình tương tác chính xác với các yếu tố UI khác nhau khi nói đến tự động hóa dường như quá độc đáo đối với một tính năng để cho phép người kiểm tra viết các tập lệnh tự động để điều khiển thứ gì đó không tồn tại. Ngay cả khi chúng ta có thể, rất nhiều thứ cuối cùng sẽ xuất hiện sau khi bị thiếu trong đặc tả.
Một điều chúng tôi cân nhắc làm là yêu cầu người kiểm tra viết "kịch bản" kiểm tra giống như một tập hợp các bước phải được thực hiện, như được mô tả từ góc độ trường hợp sử dụng, để chúng có thể được "tự động hóa" bởi con người. Điều này sau đó có thể được thực hiện bởi (các) nhà phát triển viết tính năng và / hoặc xác minh bởi người khác. Khi những người thử nghiệm sau đó có cơ hội, họ tự động hóa "kịch bản" cho mục đích hồi quy là chủ yếu. Điều này cuối cùng đã không bắt kịp trong đội.
Phần thử nghiệm của nhóm thực sự đang tụt lại phía sau chúng tôi khá nhiều. Đây là một lý do tại sao rõ ràng có thêm thời gian để phát triển một "kịch bản" để con người thực hiện chỉ không xảy ra .... họ đang ở trong tình trạng khó khăn để theo kịp các nhà phát triển của chúng tôi. Nếu chúng tôi chờ đợi họ, chúng tôi sẽ không làm được gì. Đó thực sự không phải là lỗi của họ, họ là một cái cổ chai nhưng họ đang làm những gì họ nên làm và làm việc nhanh nhất có thể. Quá trình này dường như được thiết lập để chống lại họ.
Rất thường xuyên, chúng tôi cuối cùng phải quay lại một tháng hoặc hơn trong những gì chúng tôi đã làm để khắc phục các lỗi mà người kiểm tra cuối cùng đã kiểm tra. Đó là một sự thật xấu xí mà tôi muốn làm gì đó.
Vì vậy, các đội khác làm gì để giải quyết thác thất bại này? Làm thế nào chúng ta có thể đưa người kiểm tra đi trước chúng ta và làm thế nào chúng ta có thể làm điều đó để thực sự có thời gian để họ viết bài kiểm tra cho các tính năng chúng ta làm trong một lần chạy nước rút mà không khiến chúng ta ngồi và vặn ngón tay cái trong lúc này? Như hiện tại, để có được một tính năng "hoàn thành", sử dụng các định nghĩa nhanh, sẽ có các nhà phát triển làm việc trong 1 tuần, sau đó người kiểm tra làm việc vào tuần thứ hai và các nhà phát triển hy vọng có thể khắc phục tất cả các lỗi họ gặp phải trong vài ngày qua Điều đó sẽ không xảy ra, ngay cả khi tôi đồng ý, đó là một giải pháp hợp lý. Tôi cần những ý tưởng tốt hơn ...