Có đúng không khi sửa lỗi mà không cần thêm tính năng mới khi phát hành phần mềm để kiểm tra hệ thống?

Câu hỏi này là để kiểm tra có kinh nghiệm hoặc dẫn thử nghiệm. Đây là một kịch bản từ một dự án phần mềm:

Giả sử nhóm phát triển đã hoàn thành lần lặp đầu tiên của 10 tính năng và phát hành nó để thử nghiệm hệ thống. Nhóm thử nghiệm đã tạo các trường hợp thử nghiệm cho 10 tính năng này và ước tính 5 ngày để thử nghiệm. Nhóm dev tất nhiên không thể ngồi yên trong 5 ngày và họ bắt đầu tạo ra 10 tính năng mới cho lần lặp tiếp theo. Trong thời gian này, nhóm thử nghiệm đã tìm thấy lỗi và đưa ra một số lỗi. Các lỗi được ưu tiên và một số trong số chúng phải được sửa trước khi lặp lại tiếp theo. Điều hấp dẫn là họ sẽ không chấp nhận bản phát hành mới với bất kỳ tính năng mới hoặc thay đổi nào đối với các tính năng hiện có cho đến khi tất cả các lỗi đó được sửa. Nhóm thử nghiệm cho biết đó là cách chúng tôi có thể đảm bảo bản phát hành ổn định để thử nghiệm nếu chúng tôi cũng giới thiệu các tính năng mới cùng với sửa lỗi. Họ cũng không thể thực hiện các bài kiểm tra hồi quy của tất cả các trường hợp kiểm tra của họ mỗi lần lặp.

Điều này có nghĩa là nhóm nhà phát triển phải tạo một nhánh mã chỉ để sửa lỗi và một nhánh khác nơi họ tiếp tục phát triển. Có nhiều chi phí hợp nhất đặc biệt với tái cấu trúc và thay đổi kiến ​​trúc.

Bạn có thể đồng ý nếu đây là một nguyên tắc thử nghiệm phổ biến. Là mối quan tâm của nhóm thử nghiệm hợp lệ. Bạn đã gặp điều này trong thực tế trong dự án của bạn.

Thay vào đó, tôi muốn nói rằng mỗi bản phát hành các tính năng mới nên nằm trên một nhánh riêng biệt. Điều này cho phép phát triển và phát hành được tách rời.

Làm thế nào để phát hành của bạn cho người dùng cuối làm việc trong quá trình này? Nhóm thử nghiệm hệ thống của bạn nên ít quan tâm đến lịch trình phát triển và thay vào đó tập trung vào lịch phát hành của khách hàng.

Có rất ít điểm khi cố gắng chính thức kiểm tra các tính năng mới trong khi tiếp tục phát triển, bởi vì rất có thể 10 tính năng tiếp theo của bạn sẽ chạm vào cùng chức năng và yêu cầu chúng kiểm tra lại các khu vực đó.

Họ có thể tiếp tục thử nghiệm các bản phát hành nội bộ tạm thời trong quá trình phát triển và thiết kế thử nghiệm của họ (hy vọng sẽ bắt được hầu hết các lỗi trong các tính năng mới này), nhưng họ sẽ cần một giai đoạn bổ sung khi kết thúc phát triển để thử nghiệm chính thức các tính năng mới và hồi quy thử nghiệm.

Khi họ ước tính 5 ngày cần thiết để thử nghiệm 10 tính năng mới của bạn, điều họ nên xem xét là họ cần 5 ngày vào cuối chu kỳ phát triển, trước khi phát hành cho khách hàng, để xác thực các tính năng mới (và có lẽ cần nhiều thời gian hơn để lặp lại nếu lỗi được tìm thấy). Trong giai đoạn này, bản phát hành khách hàng có thể được phân nhánh để thử nghiệm và phát triển tính năng mới có thể tiếp tục cho bản phát hành tiếp theo.

Chúng tôi sử dụng một phương pháp lai. Để phát hành cho khách hàng, chúng tôi chắc chắn có chi nhánh riêng chỉ dành cho sửa lỗi nghiêm trọng.

Phát triển thường xuyên tiếp tục trên nhiều phiên bản phần mềm. Ví dụ: giả sử phiên bản phát hành ổn định mới nhất là 2.0. Tất cả các tính năng rủi ro sẽ được thêm vào chi nhánh 3.0. Chỉ sửa lỗi đi vào chi nhánh 2.0. Kiểm tra bởi nhóm QA chuyên dụng chỉ được thực hiện trên các nhánh ổn định. Phát hành của khách hàng tất nhiên được thực hiện từ một chi nhánh khác dựa trên 2.0. Các tính năng chạy dài như phát triển nền tảng gen tiếp theo sẽ được thực hiện trong 4.0 thậm chí 3.0.

Tất cả điều này có vẻ tốt trên giấy. Nhưng nếu khách hàng muốn một tính năng cụ thể, nó cần được thêm vào chi nhánh 2.0 vì 3.0 không đủ ổn định để phát hành cho khách hàng. Điều này có nghĩa là nhóm QA sẽ phải chạy lại toàn bộ bộ hồi quy.

Một điều chúng tôi làm là thực hiện bảo hiểm mã của từng trường hợp kiểm tra hồi quy. Chỉ những trường hợp kiểm tra hồi quy mới được chạy sẽ bị ảnh hưởng bởi những thay đổi mã cho tính năng. Tất nhiên, đối với một bản phát hành của khách hàng, bộ hồi quy đầy đủ được chạy.

Điều đó thực sự phụ thuộc vào mức độ kết hợp chặt chẽ của các tính năng mới với các phần yêu cầu sửa lỗi. Ví dụ: nếu bạn thêm tính năng kéo và thả mới vào một phần nhỏ của giao diện người dùng, thì 'không nên' ảnh hưởng đến lỗi liên quan đến việc phân tích cú pháp tệp do người dùng tải.

Có nói rằng, có thể hiểu được (không nhất thiết là hợp lý) cho những người thử nghiệm muốn kiểm tra các bản sửa lỗi 'Ceteris paribus' (tất cả 'những thứ khác' đều bằng nhau).

Có thể có một số mối quan tâm khác với cách phát hành và kỳ vọng của người dùng cuối. Ví dụ: bạn có thể chỉ cần phát hành sau một lần sửa lỗi + kiểm tra và thêm một tính năng mới + kiểm tra vì người dùng CHỈ muốn cài đặt lại hoặc nâng cấp khi có các tính năng mới. Một số có thể yêu cầu sửa chữa là ưu tiên hàng đầu càng sớm càng tốt.

Bạn có thể giải quyết vấn đề (phổ biến) này bằng cách hợp nhất cả hai đội.

Những người thử nghiệm trong nhóm phát triển, thử nghiệm khi các tính năng được sản xuất, có thể giúp hầu hết các nhóm tăng chất lượng đầu ra.

Tôi đề nghị bạn đọc bài đăng blog tuyệt vời này từ Henrik Kniberg giải thích Kaban . Bạn sẽ tìm thấy nhiều ý tưởng trong quy trình Scrum (một cuốn sách miễn phí cũng của Henrik Kniberg ).

Ông cũng đã viết một bài viết Kanban VS Scrum tuyệt vời trên blog của mình.

Thưởng thức.

Nhóm thử nghiệm chắc chắn có một mối quan tâm hợp lệ, nhưng tôi sẽ đặt câu hỏi về sự cần thiết phải lặp lại nhiều lần thử nghiệm cho mỗi bản phát hành. Tại sao phải trải qua toàn bộ vòng thử nghiệm trên một phiên bản mã mà người dùng sẽ không bao giờ thấy?

Nếu những người thử nghiệm đang cố gắng để có được một bản phát hành được xác định cho khách hàng, điều đó không mong đợi các tính năng mới thì yêu cầu của họ là hợp lý, hợp lý và bạn nên cúi xuống để cung cấp nó.

Nếu đây chỉ là để hỗ trợ cho các "quy trình" của họ trong các giai đoạn phát triển bình thường và đảm bảo rằng danh sách lỗi không bị mất kiểm soát thì không gây ra vấn đề gì, hãy hỏi người đứng đầu kiểm tra xem liệu có thể nới lỏng một chút cho đến khi chúng ta tiến gần hơn đến điểm phát hành.

Xem xét thay đổi hệ thống kiểm soát nguồn của bạn thành một sản phẩm phân tán. Điều này sẽ làm cho nó dễ dàng hơn nhiều để cung cấp một bản phát hành như vậy.

"Bạn có thể đồng ý nếu đây là một nguyên tắc thử nghiệm phổ biến.

Yes

Mối quan tâm của nhóm thử nghiệm có hợp lệ không

Yes

Bạn đã gặp điều này trong thực tế trong dự án của bạn. "

Yes

:

and Yes Merging is the downside of it 

Bạn không hỏi ai là người chịu trách nhiệm nhưng đó là trách nhiệm của Trình quản lý cấu hình. Chiến lược stream này nên có trong CMP của anh ấy. Nếu không thì sa thải anh ấy / cô ấy. Tôi nghĩ rằng phản hồi từ Pierre 303 cũng rất tốt nhưng tất nhiên là có thể về mặt kỹ thuật (ví dụ như nghĩ về việc phát hành Siebel ...) và có tổ chức.

Vấn đề là nếu họ kiểm tra các lỗi trên một nhánh, họ vẫn cần kiểm tra lại và hồi quy kiểm tra chúng trên thân cây sau khi chúng được hợp nhất trở lại (trừ khi chúng rất tin tưởng những người kiểm tra tốt hiếm khi). Đây không chỉ là tạo ra nhiều công việc hơn cho các nhà phát triển, nó còn tạo ra nhiều công việc hơn cho những người thử nghiệm.

Không có câu trả lời đúng ở đây nhưng một vài điều bạn nên xem xét:

• Những bản phát hành lỗi này (không có chức năng mới) có thể đến tay người dùng không? Nếu vậy thì có, nó phải được phân nhánh và thử nghiệm và mọi người cần phải chấp nhận điều đó như một chi phí chung.

• Có thể phân chia chức năng mới theo cách nó tồn tại trong các khu vực hoàn toàn riêng biệt của ứng dụng cho các phần trước đó đã được làm việc không? Nếu vậy, điều này cung cấp cho bạn các tùy chọn - người kiểm tra có thể thực hiện kiểm tra lỗi và các phần kiểm tra hồi quy của ứng dụng. Điều đó không lý tưởng nhưng đó là một sự thỏa hiệp có thể hoạt động và cung cấp cho họ một số thứ họ muốn.

• Bao nhiêu công việc thực sự là để chi nhánh họ phát hành? Nói chung đó là một nỗi đau nhưng khối lượng công việc thực tế thường không lớn như vậy. Rõ ràng là bạn cần họ để xác nhận nó không chỉ là công việc nhiều hơn cho họ (xem điều đầu tiên tôi nói) mà tôi đã thấy những nơi làm cho công việc này.

• Có cách nào tốt hơn để sử dụng kiểm soát phiên bản ở đây không? Một cái gì đó giống như Mercurial (xem http://hginit.com/ - đọc nó, nó tốt) hoặc một hệ thống kiểm soát phiên bản phân tán khác và hợp nhất theo một cách khác và có thể cho phép bạn giải quyết vấn đề. Thực sự, có một cái nhìn về nó bởi vì tôi nghĩ nó có thể là câu trả lời cho vấn đề của bạn.

Nhưng chúc may mắn, đó là một nỗi đau. Trên hết hãy nhớ rằng cách tốt nhất về phía trước sẽ phụ thuộc rất nhiều vào công ty, sản phẩm và tình huống của bạn, vì vậy hãy chắc chắn rằng bạn nghĩ về điều đó và đừng chỉ lấy thứ gì đó ra khỏi kệ và tin rằng bạn phải tuân thủ 100%.

Nếu các lỗi mà bạn mô tả là lỗi thực tế và không tối ưu hóa thiết kế , thì có, bạn thực sự nên cố gắng sửa chúng trước khi bắt đầu làm việc với các tính năng mới.

Nếu bạn xây dựng các tính năng mới trên đầu các lỗi đã biết, bạn đang tạo ra một ngôi nhà thẻ. Bạn có thể phát triển phần mềm dễ vỡ, không thể đoán trước. Tùy thuộc vào mức độ cô lập giữa mã lỗi và các tính năng mới của bạn, các lỗi cũng có thể ảnh hưởng đến các tính năng mới của bạn. Nếu vậy, làm thế nào bạn biết nếu các tính năng mới của bạn hoạt động chính xác?

Nếu bạn sửa lỗi trước, bạn sẽ có nền tảng vững chắc hơn cho bất kỳ tính năng mới nào mà bạn thêm.

Chắc chắn, có những lúc các thế lực bên ngoài gây áp lực buộc bạn phải chống lại sự phán xét tốt hơn của bạn. Cố gắng giúp những người ra quyết định đạt được một quyết định có căn cứ trong đó họ nhận thức được hậu quả của một trong hai quá trình hành động (nghĩa là các khiếm khuyết chưa được giải quyết so với ngày giao hàng tính năng bị bỏ lỡ) và cho phép họ thực hiện phán quyết. Đôi khi có những lý do pháp lý và tài chính trong đó một quá trình hành động, trong khi không thích hợp hơn, là cần thiết.

Luôn cố gắng sửa lỗi trước khi thêm các tính năng mới!

Nơi tôi làm việc, chúng tôi xử lý tình huống này trong đó mỗi dự định phát hành để sản xuất đều có chi nhánh riêng. Ví dụ: giả sử trong một giây sẽ có một bản phát hành vào cuối tháng 6 và một bản khác vào cuối tháng 7. Bản phát hành tháng 6 sẽ có chi nhánh riêng và tất cả các tính năng sẽ được thêm vào đó và gửi đến QA. Tại thời điểm này, chúng tôi sẽ bắt đầu làm việc vào ngày phát hành tháng 7 và chi nhánh từ chi nhánh của tháng sáu. Khi QA tìm thấy lỗi, chúng tôi sẽ sửa chúng trong chi nhánh của tháng 6 và một khi các bản sửa lỗi được đẩy sang QA, chúng sẽ được sáp nhập vào chi nhánh phát hành của tháng 7. Điều này không thêm một chút chi phí nào để xử lý các sự hợp nhất này, nhưng thông thường các sự hợp nhất này không gây đau đớn. Thỉnh thoảng, bạn biết điều đó là một nỗi đau lớn, nhưng điều đó chỉ xảy ra khi những thay đổi bán buôn được thực hiện và những điều đó không nên xảy ra trong chu kỳ QA (nhưng chúng xảy ra, nhiều hơn tôi muốn thừa nhận). Nhưng với một bộ kiểm tra tốt (đơn vị và tích hợp), và phạm vi bảo hiểm mã và tất cả các từ thông dụng TDD khác, các rủi ro được giảm nhẹ một chút. Để giúp đỡ, chúng tôi thường có một người xử lý sáp nhập cho mỗi dự án.