Chiến lược thử nghiệm đúng đắn trong các nhóm Agile Scrum / Kanban là gì?

Vấn đề là:

Nhóm, tôi đang làm việc có tỷ lệ 10 nhà phát triển cho 2 người thử nghiệm, điều đó có nghĩa là chúng tôi sẽ tạo ra mã nhanh hơn so với "Thử nghiệm" được thực hiện.

Vì vậy, điều gì nên là cách tiếp cận đúng để theo dõi các hoạt động trong các tình huống như vậy theo các chuyên gia nhanh nhẹn?

Nỗi sợ hãi của tôi là sẽ sớm đến ngày, khi có rất nhiều thứ sẽ được gọi là "Xong" trong các lần chạy nước rút trước đó (không có thử nghiệm nào được thực hiện) nhưng khi thực sự thử nghiệm, có thể có một số khiếm khuyết tiềm ẩn.

Làm thế nào tôi có thể theo dõi các nỗ lực liền mạch? Có nên thử nghiệm là một phần của "Định nghĩa Xong"? Những cạm bẫy nếu nó không phải là gì?

Theo tôi, nó là một loại 'Thác nước' khi bạn đang gọi những câu chuyện "Xong" trước khi nó thực sự được thử nghiệm chức năng.

Có, kiểm tra hoàn toàn nên là một phần của định nghĩa "Hoàn thành". Không có câu hỏi.

Từ quan điểm hoàn toàn nhanh nhẹn, cách tiếp cận đúng đắn là mọi người trong nhóm đóng góp vào việc viết bài kiểm tra. Người kiểm thử sẽ là người phối hợp nỗ lực, nhưng trách nhiệm của toàn bộ nhóm là đảm bảo phần mềm được kiểm tra đúng cách.

Thứ nhất, tỷ lệ 10: 2 là xấu. Từ kinh nghiệm, tỷ lệ 3: 1 hoặc 4: 1 nhà phát triển cho người thử nghiệm hoạt động tốt. Do đó, bạn có thể sẽ cần ít nhất một người thử nghiệm nữa, nếu không, tồn đọng kiểm tra sẽ phát triển và không bao giờ bị xóa, hoặc bạn bị cắt góc ở đâu đó.

Nếu bạn kiểm tra các nhiệm vụ trong lần chạy nước rút tiếp theo, bạn đang thực hiện thác nước nhỏ hoặc "scrumfall" khi bạn đang tách ra thử nghiệm khỏi sự phát triển. Bạn đúng trong thử nghiệm đó hoàn toàn nên tạo thành một phần của định nghĩa thực hiện. Nếu một nhiệm vụ không được kiểm tra, làm thế nào nó có thể được tuyên bố là "hoàn thành"?

Do đó, cách tiếp cận đúng sẽ là:

1. Thêm một người thử nghiệm vào nhóm nếu có thể, nếu không thì các nhà phát triển thực hiện một số thử nghiệm (mặc dù họ có thể sẽ không làm tốt công việc như một người thử nghiệm chuyên nghiệp).
2. Sửa đổi bảng scrum / kanban của bạn để bao gồm các cột "sẵn sàng để thử nghiệm" và "trong thử nghiệm" và đồng ý với nhóm rằng một phần của quy trình làm việc phải có tất cả các nhiệm vụ đi qua các làn này.
3. Nhiệm vụ chỉ thực hiện ở cột "Xong" khi chúng được chấp nhận bằng cách thử nghiệm.

Điều này là khá phổ biến, nếu không điển hình. Để trả lời một số câu hỏi:

• Điều gì nên là cách tiếp cận đúng để theo dõi các hoạt động trong các tình huống như vậy?
• Các tính năng sẽ được thực hiện mà không có QA nhưng có khiếm khuyết?
• Làm thế nào tôi có thể theo dõi các nỗ lực liền mạch?
• Có nên thử nghiệm là một phần của "Định nghĩa Xong"?
• Những cạm bẫy nếu nó không phải là gì?

Tôi sẽ có một cách tiếp cận tổng thể rằng:

• cho phép người kiểm tra thêm giá trị
• trao cho họ quyền
• tối đa hóa giá trị của họ
• khuyến khích người QA đào tạo các nhà phát triển

và để làm điều đó (và trả lời câu hỏi của bạn) tôi sẽ:

• đảm bảo rằng họ có thể nhập các lỗi trong một hệ thống theo dõi lỗi dễ sử dụng cũng chứa các tính năng như Jira, Trello, Pivotal Tracker, v.v.

• đảm bảo rằng họ được đào tạo về việc tạo các báo cáo lỗi tốt mô tả:

  • các bước để tái sản xuất
  • giá trị ban đầu / thiết lập
  • nhập giá trị
  • ảnh chụp màn hình khi thích hợp
  • Nhật ký máy chủ khi thích hợp
• đảm bảo rằng họ thấy các lỗi được chỉ định, làm việc và hoàn thành.
• đào tạo họ trong thực tiễn tốt nhất và gửi chúng đến các hội nghị.
• đào tạo họ trong lập trình và sử dụng một khung kiểm tra.
• cho phép họ dạy các lập trình viên về các phương pháp và tư duy tốt để thử nghiệm.

Ngoài ra, có, một số tính năng có thể được thực hiện mà không có QA nhưng có khiếm khuyết. Tôi thường thấy QA là một đôi mắt thứ hai. Đôi khi vai trò này có thể được lấp đầy bởi một nhà phát triển khác. Cá nhân tôi thấy điều này tìm thấy một số lỗi, nhưng không phải tất cả những lỗi mà một tư duy QA khác có thể tìm thấy.

Kiểm tra nên là một phần của việc thực hiện nhưng điều đó không có nghĩa là người QA phải thực hiện kiểm tra. Do sự thiếu hụt tài nguyên và môi trường Agile mà eschews đặc tả mà QA có thể xem xét, QA cần tham gia vào việc tìm hiểu miền người dùng, thiết kế các cuộc họp, các cuộc họp chải chuốt, đứng lên, hồi tưởng, v.v.

Đối với câu hỏi lớn về chiến lược thử nghiệm, hãy sử dụng các góc phần tư thử nghiệm Agile để hướng dẫn bạn:

                   |
      Integrated   |     Performance
_________________________________________
                   |     
           Unit    |     Exploratory

Các nhà phát triển có thể đã thực hiện Bài kiểm tra đơn vị. Một lĩnh vực quan trọng mà QA có thể thêm giá trị bằng cách bao gồm là trong Thử nghiệm tích hợp và bằng cách sử dụng tự động hóa giao diện người dùng. Thử nghiệm khám phá tốt cũng rất có giá trị - không chỉ nhấp vào mỗi liên kết trên trang, đó là về việc tìm hiểu miền người dùng cuối và việc sử dụng ứng dụng có ý nghĩa gì với họ.

Đối với tỷ lệ của QA so với người kiểm tra cũng xem xét tam giác thử nghiệm:

    Exploratory
  Integrated Tests
Individual Unit Tests

trong đó một thử nghiệm thăm dò hoặc tích hợp có thể đại diện cho hàng chục nếu không phải là hàng trăm thử nghiệm đơn vị bằng cách thực hiện toàn bộ 'ngăn xếp'.

Cũng xem xét rằng như trong các nhóm Agile thường nên có cách tiếp cận của bất kỳ ai có thể viết mã, bất kỳ ai cũng có thể kiểm tra. Chìa khóa của khóa học là cung cấp cho mọi người hướng dẫn và cấu trúc để họ có thể làm những gì cần thiết và cho họ đào tạo cho khu vực khác.

Về tỷ lệ thực tế, tôi không đồng ý về tính chính xác của câu trả lời của David là 3: 1 hoặc 4: 1 Trong một số tổ chức nơi các nhà phát triển đang viết đơn vị tốt và các bài kiểm tra tích hợp, điều này có thể được chấp nhận là 7: 1 Trong một tổ chức có rất ít thử nghiệm được thực hiện bởi các nhà phát triển, điều này có thể cần phải là 1: 1 Nó thực sự 'phụ thuộc' vào tổ chức, cấu trúc, kiến ​​thức, ngành công nghiệp, v.v.

Khi chúng tôi bắt đầu xây dựng sản phẩm của mình , chúng tôi cũng đã triển khai Kanban và cùng với đó, chúng tôi đã thực hiện một chiến lược tự động hóa thử nghiệm hoàn chỉnh. Do đó, hôm nay chúng tôi không có người thử nghiệm trong nhóm của mình. Thay vào đó, các nhà phát triển phải viết các trường hợp thử nghiệm và tự động hóa chúng như là một phần của hoạt động trên bất kỳ câu chuyện, nâng cao hoặc khiếm khuyết nào của người dùng. Định nghĩa của chúng tôi về Dev Complete bao gồm thử nghiệm đơn vị và tự động hóa chức năng.

Chúng tôi vẫn có giai đoạn "Xác thực" sau khi Dev hoàn thành - nơi tất cả các nhà phát triển mới (tính năng, sửa lỗi) được triển khai trên máy chủ dàn và ai đó - bất kỳ ai có chức năng hiểu về tính năng - phải xác thực tính năng này. Chúng tôi sử dụng những người trong nhóm Tài liệu cũng như Quản lý sản phẩm - và đôi khi là lãnh đạo / kiến ​​trúc sư của Sr - để xác thực. Mỗi bản phát hành phải ở lại tối thiểu 1 tuần để dàn dựng trước khi được triển khai sản xuất.

Dưới đây là ảnh chụp bảng Kanban của chúng tôi -

Quá trình và Kanban đã làm việc cho chúng tôi. Chúng tôi có gần 100% tự động hóa thử nghiệm, chúng tôi có nhịp phát hành sản xuất 3-4 tuần và tốt nhất, hầu hết các thành viên trong nhóm có thể linh hoạt để làm việc trên hầu hết các phần của sản phẩm!

Vì vậy, trong khi điều này có thể không đáp ứng các mục tiêu ngắn hạn của bạn, bạn chắc chắn có thể muốn xem xét cách bạn có thể cơ cấu lại nhóm của mình trong thời gian dài và nếu chưa thực hiện, thì hãy xem các chiến lược tự động hóa thử nghiệm chắc chắn sẽ giúp nhóm của bạn cung cấp nhiều hơn chất lượng trong khoảng thời gian ngắn hơn.