Tiến thoái lưỡng nan của QA so với các lần lặp

Trong công ty của tôi, chúng tôi làm việc thành công với các thực hành nhanh - nhưng không sử dụng các lần lặp. Lý do chính là chúng ta không thể tìm ra cách sạch để phù hợp với QA trong một chu kỳ lặp.

Chúng tôi hiểu QA là một chút xác minh cho một bản dựng nhất định (ứng viên phát hành) trước khi bản dựng này được triển khai cho khách hàng. Vấn đề là tránh một cam kết độc hại làm hỏng toàn bộ bản phát hành. Vì bạn không bao giờ biết đó là cái gì, QA phải đợi cho đến khi tất cả các tính năng / cam kết cho bản phát hành được xây dựng. (Không có từ cuối nổi tiếng "Đó chỉ là một thay đổi nhỏ" được cho phép.)

Nếu QA tìm thấy lỗi trong một ứng cử viên phát hành, các nhà phát triển sẽ sửa các lỗi này trong nhánh phát hành tương ứng (và hợp nhất nó vào thân cây). Khi tất cả các lỗi đã được sửa, bản dựng mới được triển khai để QA kiểm tra lại. Chỉ khi không tìm thấy lỗi trong một ứng cử viên phát hành nhất định, nó sẽ được cung cấp cho khách hàng để xác minh.

Điều này thường mất khoảng hai đến ba ứng cử viên, khoảng một tuần, mỗi lần phát hành. Thời gian để viết các bản sửa lỗi thường thấp hơn nhiều so với các nỗ lực thử nghiệm. Vì vậy, để giữ cho các nhà phát triển bận rộn, họ làm việc trên phiên bản N + 1 trong khi QA hoạt động trên N.

Không sử dụng các lần lặp, điều này không có vấn đề gì vì chúng ta có thể chồng chéo công việc cho các bản phát hành N và N + 1. Tuy nhiên, từ những gì tôi hiểu, điều này không tương thích với các cách tiếp cận dựa trên phép lặp như Scrum hoặc XP. Họ yêu cầu một lần lặp để có thể giải phóng được vào cuối với tất cả nỗ lực thử nghiệm được kết hợp trong lần lặp.

Tôi thấy rằng điều này nhất thiết dẫn đến một trong những kết quả không mong muốn sau:

(A) Các nhà phát triển không hoạt động khi kết thúc vì QA cần thời gian để xác minh một ứng cử viên phát hành và công việc sửa lỗi không hoàn toàn khiến các nhà phát triển bận rộn.

(B) QA bắt đầu hoạt động trước khi ứng viên phát hành đầu tiên sẵn sàng. Đây là những gì chủ yếu được khuyến nghị trên Stack Exchange. Nhưng đó không phải là những gì công ty tôi hiểu là QA vì không có ứng cử viên phát hành cụ thể nào được thử nghiệm. Và "thay đổi nhỏ" phá vỡ mọi thứ vẫn có thể được giới thiệu mà không được chú ý.

(C) Lỗi được chuyển sang lần lặp tiếp theo. Điều này cũng được khuyến nghị trên Stack Exchange. Tôi không nghĩ đó là một giải pháp. Về cơ bản, điều đó có nghĩa là chúng tôi sẽ không bao giờ nhận được bản dựng đã được xác minh bởi vì bất cứ khi nào sửa lỗi được thực hiện, các xác nhận mới, chưa được xác minh cũng được thêm vào cùng một nhánh.

Có cách nào thoát khỏi tình trạng khó xử này?

Chúng tôi hiểu QA là một chút xác minh cho một bản dựng nhất định (ứng viên phát hành) trước khi bản dựng này được triển khai cho khách hàng.

Không có gì vốn không tương thích giữa hình thức QA này và các phương pháp dựa trên lặp như Scrum.
Trong Scrum, nhóm cung cấp dịch vụ chuyển phát theo chu kỳ X hàng tuần cho khách hàng của mình. Phần quan trọng ở đây là, nếu nhóm phát triển đang thực hiện Scrum, thì khách hàng của họ là nhóm QA chứ không phải người dùng cuối của sản phẩm của bạn.

Là một nhà phát triển, tôi sẽ xem xét một sản phẩm có thể chuyển sang QA nếu nó có cơ hội chiến đấu vượt qua tất cả các thử nghiệm của họ. Điều này có thể có nghĩa là một số bài kiểm tra QA đã được thực hiện trên các bản dựng hàng ngày, nhưng điều đó ảnh hưởng đến các bài kiểm tra phát hành chính thức của nhóm QA tùy thuộc vào tổ chức của bạn.

Đối với hầu hết các tình huống thực tế, nhanh chóng dừng lại khi giao hàng đến QA / UAT hoặc bất cứ điều gì nó được gọi.

Nỗ lực chuyển từ QA sang Sản xuất trong môi trường thực tế thường bị đánh giá thấp. Trong nhiều trường hợp, điều này liên quan đến người dùng doanh nghiệp thực sự trong việc thử nghiệm, quản lý đăng xuất khỏi dòng quản lý doanh nghiệp thực sự, lên lịch phát hành với các hoạt động, v.v. Điều này không tầm thường!

Trong trường hợp cực đoan, phần mềm có thể cần chứng nhận của các cơ quan bên ngoài hoặc phải chịu kiểm tra bảo mật nghiêm ngặt.

Trong những trường hợp này, đơn giản là không thể dự kiến ​​nhiều hơn một bản phát hành mỗi quý trừ việc sửa lỗi.

Nó trở nên tồi tệ hơn cho một sản phẩm phần mềm nghiêm trọng. Tài liệu cần phải được chứng minh và công bố. Tài liệu tiếp thị cần được sửa đổi. Nhân viên bán hàng cần được cho biết những gì họ đang bán (không có nhiệm vụ dễ dàng!), V.v. Bạn thực sự không muốn đưa doanh nghiệp vượt qua điều này hơn một lần mỗi năm.

Giải pháp rất ngắn hạn là cung cấp cho QA thêm một khoảng thời gian sau khi lặp lại để hoàn thành thử nghiệm. I E. Nếu bạn có vòng lặp hai tuần, đừng phát hành đến tuần thứ 3. QA sẽ không có gì để kiểm tra lần lặp tiếp theo, trong tuần đầu tiên của nó, dù sao đi nữa.

Nhưng tôi sẽ cảnh báo bạn trước những gì sẽ xảy ra (đã thấy điều này trong một số đội): Bạn sẽ kết thúc trong tình huống một lần lặp bạn hoàn thành công việc trong hai tuần, QA bị quá tải, họ sẽ đến với bạn vì điều đó cả tuần QA và, lặp lại sau đây, bạn sẽ chỉ hoàn thành công việc một tuần. Lặp đi lặp lại, QA sẽ không có gì để làm và bạn sẽ nghĩ mình đã giải quyết được vấn đề. Nhưng sau đó, lần lặp lại tiếp theo bạn sẽ bắt đầu lại chu kỳ.

Vì vậy, ngay sau khi bạn thêm vào tuần đó, chỉ để đảm bảo bản phát hành của bạn ổn định (vì một điều tôi đã học được là nếu bạn mất niềm tin vào doanh nghiệp, Agile sẽ khó thực hiện hơn theo cấp số nhân), hãy thẳng thắn lên kế hoạch dài hạn.

Mua một bản sao Giao hàng liên tục của Jez Humble , đọc nó, che đậy, chuyển nó đi khắp đội. Lấy cảm hứng cho mọi người. Sau đó thực hiện mọi thứ bạn có thể từ nó.

Làm cho quá trình xây dựng trơn tru như bạn có thể. Thực hiện chính sách kiểm tra đơn vị và nhận những chính sách đang chạy trên mọi bản dựng. Làm cho quá trình triển khai trở thành điều khó khăn nhất bạn từng thấy. Ba lần nhấp? Không đủ trơn tru.

Khi bạn đã thực hiện tất cả điều này, sẽ không có vấn đề gì nhiều nếu lỗi hồi quy không thường xuyên xảy ra. Bạn biết tại sao mà? Vì bạn sẽ có thể (tùy chọn) quay lại, sửa chữa, triển khai lại trước khi doanh nghiệp rơi vào tình trạng khó khăn. Trong thực tế, người gác cổng ban đêm sẽ có thể quay lại cho bạn, quá trình sẽ rất đơn giản.

Tôi biết bạn đang nghĩ gì: Chúng tôi không có thời gian để làm tất cả điều đó. Hãy để tôi nói với bạn, bạn làm. Nếu bạn đang quá tải QA, bạn đang triển khai quá nhiều cho mỗi lần lặp. Vì vậy, không. Nếu bạn chưa quá tải thì hãy hỏi họ tại sao họ chưa có bộ kiểm tra tự động. Bạn sẽ sớm được.

Làm tất cả điều này với tầm nhìn đầy đủ cho doanh nghiệp. Ước tính thấp hơn và tiêm một số công việc này vào vòng lặp. Hoặc, tốt hơn nữa, chia nó thành những câu chuyện và khiến họ ưu tiên nó, bên cạnh mọi thứ khác.

Giải thích cho họ rằng a) nó sẽ cải thiện tính ổn định của bản phát hành và b) nó sẽ cải thiện khả năng của bạn để đối phó với các vấn đề cho họ và c) nó sẽ mua cho họ nhiều vận tốc hơn sau này. Đó là một công ty hiếm hoi không muốn những thứ này. Đó chắc chắn không phải là một công ty Agile không muốn họ như vậy, nếu bạn gặp phải sự kháng cự, bạn sẽ biết bạn có một vấn đề khác.

Khi bạn đã nhận được Giao hàng liên tục, bạn có thể bắt đầu rút ngắn thời gian QA nhận được khi kết thúc vòng lặp. Đó là lợi ích của mọi người để mang các vòng lặp trở lại song song, càng sớm càng tốt. Có thể bạn sẽ có một ngày vào cuối vòng lặp, nơi bạn cần điền thời gian. Tôi đã trả lời phải làm gì về điều đó ở nơi khác .

Không sử dụng các lần lặp, điều này không có vấn đề gì vì chúng ta có thể chồng chéo công việc cho các bản phát hành N và N + 1.

Dường như có một vấn đề với cách bạn quyết định chính xác những gì cấu thành work for release N.

Vì một số lý do kỳ lạ (tôi chỉ có thể đoán có một số hiểu lầm về các công thức nấu ăn Agile cụ thể), bằng cách nào đó bạn đã quyết định rằng cách tiếp cận nhanh nhẹn bắt buộc tất cả các nỗ lực của nhóm QA được kết hợp trong phép lặp.

• ^{Nếu đó thực sự là trường hợp, tôi cho rằng sự phổ biến của Agile thậm chí sẽ không gần với những gì chúng ta thấy bây giờ. Tôi không thể tưởng tượng nhiều dự án có thể "tồn tại" đồng bộ hóa bắt buộc của các lần lặp nhóm dev với chu kỳ kiểm tra QA.}

Có thêm một chút về sự nhanh nhẹn bên dưới nhưng trước tiên, hãy sắp xếp work for release N...

Hãy nhìn xem, không có lý do thuyết phục nào để nhóm phát triển định nghĩa công việc theo cách đó. Hoàn toàn ngược lại, từ mô tả của bạn, rõ ràng thay vì "đơn vị công việc" nguyên khối, có một số đơn vị như vậy, với các cột mốc dễ cảm thấy ...

• ^{Ví dụ: "đơn vị" đầu tiên được biểu thị bằng cột mốc riêng biệt khi bản dựng ứng cử viên được chuyển cho người kiểm tra và các cột mốc tiếp theo tương ứng với các thay đổi liên quan đến chu kỳ kiểm tra được thực hiện bởi QA, v.v.}

Cũng lưu ý rằng cách bạn xác định work for release Nkhông bị ép buộc bởi luồng công việc QA. Từ những gì bạn mô tả mọi thứ có vẻ như họ có lịch trình riêng (và khá hợp lý).

Đưa ra ở trên, cách thực tế hơn để xác định các đơn vị công việc trong trường hợp của bạn có thể như sau:

1. Các hoạt động phát triển tính đến thời điểm xây dựng được chuyển cho QA
   Release Candidate N
2. Các hoạt động phát triển liên quan đến chu kỳ kiểm tra QA đầu tiên
   Release Candidate N patch 1
3. Các hoạt động phát triển liên quan đến chu kỳ kiểm tra QA thứ hai
   Release Candidate N patch 2
4. vv, cho đến khi xây dựng cuối cùng

Trên đây là các đơn vị công việc của bạn, bất kể bạn làm Agile hay gì.

Đây là tự nhiên và thuận tiện để xác định, theo dõi và theo dõi. Điều này cũng kết hợp tốt với lịch trình QA, cho phép phối hợp thuận tiện giữa các nhà phát triển và các nỗ lực QA.

Tuy nhiên, từ những gì tôi hiểu, điều này không tương thích với các cách tiếp cận dựa trên phép lặp như Scrum hoặc XP. Họ yêu cầu một lần lặp để có thể giải phóng được vào cuối với tất cả nỗ lực thử nghiệm được kết hợp trong lần lặp.

Hiểu biết về khả năng tương thích với Agile về cơ bản là sai và đây là lý do tại sao ...

Giả định bạn đưa ra không liên quan gì đến Agile, nếu chúng ta lấy triết lý của nó theo mệnh giá như được chỉ ra bởi chính tên của nó, đó là một cách tiếp cận ủng hộ và thực hành sự nhanh nhẹn .

Từ quan điểm đó, gắn bó với quy trình làm việc "cố định" cụ thể và bỏ qua việc nó có thuận tiện hay không chỉ đơn giản là mâu thuẫn với tinh thần của Agile. Nghiêm túc tuân theo "thủ tục" dẫn đến các thực tiễn bị chê bai rất hùng hồn trong Tuyên ngôn Agile Half-Arsed "... chúng tôi có các quy trình và công cụ bắt buộc để kiểm soát cách các cá nhân đó (chúng tôi thích thuật ngữ 'tài nguyên') tương tác" .

Bạn có thể tìm hiểu thêm về điều này trong một câu trả lời cho một câu hỏi khác , được trích dẫn dưới đây. Hãy xem ghi chú về "phát hành shippable", có vẻ như hồi đó OP đã bị nhầm lẫn theo cách tương tự:

người ta nên nhanh nhẹn về việc áp dụng các nguyên tắc nhanh nhẹn. Ý tôi là, nếu các yêu cầu của dự án không nhanh nhẹn (ổn định hoặc thay đổi chậm), thì tại sao phải bận tâm? Tôi đã từng quan sát quản lý hàng đầu buộc Scrum trong các dự án đang hoạt động hoàn hảo mà không có. Thật là một sự lãng phí. Không chỉ không có cải tiến trong việc giao hàng của họ mà tệ hơn, tất cả các nhà phát triển và người thử nghiệm đều trở nên không hài lòng.

Đối với tôi, một trong những phần quan trọng nhất của Agile là có một bản phát hành có thể chuyển đổi vào cuối mỗi lần chạy nước rút. Điều đó ngụ ý một số điều. Đầu tiên, một mức độ thử nghiệm phải được thực hiện để đảm bảo không có lỗi hiển thị nếu bạn nghĩ rằng bạn có thể phát hành bản dựng cho khách hàng ...

Shippable phát hành tôi thấy. Hừm. Hừm. Cân nhắc thêm một hoặc hai Lean vào ly cocktail Agile của bạn. Ý tôi là, nếu đây không phải là nhu cầu của khách hàng / thị trường thì điều này chỉ có nghĩa là lãng phí tài nguyên (thử nghiệm).

Tôi không thấy tội phạm gì khi coi việc phát hành cuối Sprint chỉ là một số điểm kiểm tra thỏa mãn nhóm.

• ^{dev: yeah rằng một cái nhìn đủ tốt để vượt qua người kiểm tra; QA: yeah rằng một cái có vẻ đủ tốt cho trường hợp nếu cần thử nghiệm thêm shippable - thứ như thế. Nhóm (dev + QA) hài lòng, đó là nó.}