Thực tiễn tốt nhất về chiến lược thử nghiệm cho nhóm Scrum

Scrum trừ kế hoạch thử nghiệm bằng POC trên steroid.

Ngày nay, hầu hết các dự án thành công đều bắt đầu bằng Proof of Concept (POC), một đánh giá quy mô tương đối nhỏ về một ý tưởng, trong đó công nghệ và gói tính năng được chọn sẽ được xác minh trước, được đánh giá về tác động tiềm năng đối với người dùng doanh nghiệp và sau đó, sau khi được chứng minh xứng đáng với khoản đầu tư, một nhóm dự án quy mô đầy đủ được chỉ định thiết kế và cung cấp sản phẩm đầy đủ tính năng cũng như triển khai sản xuất.

Đây là trường hợp hoàn hảo cho một nhóm Scrum. Nhóm có thể nhanh chóng phát triển nguyên mẫu, bổ sung thêm các tính năng mới quan trọng trong mỗi lần chạy nước rút, trong khi người dùng doanh nghiệp có thể xem tiến độ nhanh trong thời gian thực và cách ý tưởng được xây dựng từ đầu chỉ trong khoảng 10 lần chạy nước rút. Nó để lại ấn tượng mạnh mẽ (dù sao cũng là mục tiêu chính của POC), nhưng nó cũng có một đặc tính quan trọng – hoạt động thử nghiệm tối thiểu hoặc không có, và thậm chí nghĩ về quy trình thử nghiệm sẽ là một trò đùa.

Đó không phải là hoạt động thú vị trong nhóm Scrum và mọi người hầu hết sẽ thích ý tưởng phát triển mà không có các quy trình xung quanh để làm chậm chúng. Về cơ bản, đây là điều mà bất kỳ hoạt động thử nghiệm nào cũng sẽ ngầm thực hiện. Và ai lại muốn sự chậm chạp không cần thiết trong khoảng thời gian chúng ta cần gây ấn tượng nhất với người dùng cuối?

Trạng thái xảy ra nếu nhóm dự án tiếp tục theo cách tương tự sau khi giai đoạn POC kết thúc là thứ mà tôi dùng để gọi POC trên steroid – một hệ thống sản xuất đang phát triển về quy mô và tính năng, nhưng vẫn hoạt động như một POC – một sản phẩm hoàn chỉnh của Wannabee với những khiếm khuyết tiềm ẩn và những trường hợp góc khuất chưa được khám phá, chỉ chờ một vụ va chạm nghiêm trọng.

Nhưng trước khi nó chuyển đổi ở đó, nhóm sẽ gặp khó khăn hơn từ nước rút này sang nước rút khác để theo kịp các bản phát hành ổn định, vì việc khắc phục các sự cố luân phiên sẽ chỉ trở nên phức tạp hơn.

Dưới đây là một số kỹ thuật đã được chứng minh là có hiệu quả khi tôi giải quyết các vấn đề tương tự và tôi tin rằng có thể coi đây là các phương pháp hay nhất để triển khai các quy trình kiểm thử vững chắc mà vẫn không làm quá trình phát triển bị xáo trộn quá nhiều – bởi vì đó là điều mà tất cả chúng ta đều muốn hướng tới một nhóm Scrum.

Phân phối nỗi đau

Chúng ta sẽ bắt đầu từ đâu khi giải quyết những phiền toái không cần thiết hơn là chia cắt nỗi đau :).

Và điều tôi muốn nói ở đây là tạo ra một kế hoạch sẽ yêu cầu hoạt động bổ sung nhỏ từ các nhà phát triển ở đây và ở đó nhưng điều đó sẽ đóng góp rất nhiều cho mục tiêu chung theo thời gian, tăng dần nhưng nhất quán.

#1. Phát triển mã kiểm tra Đơn vị cho từng đoạn mã mới được tạo

Nếu bạn quản lý để thuyết phục các nhóm scrum của mình thêm vào điều khoản Definition Of Done của nó, việc phát triển các bài kiểm tra đơn vị cho mỗi mã mới được tạo trong lần chạy nước rút, thì từ góc độ dài hạn, đây sẽ là một thành tích tuyệt vời.

Những lý do khá rõ ràng:

Nó sẽ buộc các nhà phát triển phải suy nghĩ về các đường dẫn mã không chuẩn khác nhau. –

• Các thử nghiệm đơn vị như vậy có thể được cắm vào quy trình DevOps tự động và được thực thi với mỗi lần triển khai đơn lẻ cho môi trường thử nghiệm hoặc nhà phát triển. Ngoài ra, các số liệu từ quy trình có thể dễ dàng xuất và sau đó được sử dụng để minh họa cho người dùng doanh nghiệp về mức độ bao phủ phần trăm của các trường hợp thử nghiệm được liên kết trực tiếp với mã nguồn.

Điều quan trọng nhất là bắt đầu rất sớm. Các bài kiểm tra đơn vị sẽ bắt đầu được phát triển càng muộn, các nhà phát triển sẽ càng mất tập trung khi thêm chúng trong một lần chạy nước rút.

• Sẽ cần nỗ lực đáng kể để phát triển ngược các bài kiểm tra đơn vị cho mã hiện có. Một số phần của mã có thể được tạo bởi một nhà phát triển khác và kiến ​​thức chính xác về cách thức hoạt động của nó trong từng phần mã đơn lẻ không chính xác rõ ràng đối với nhà phát triển hiện tại. Trong một số trường hợp, có thể tiến xa đến mức việc thêm một bài kiểm tra đơn vị vào mã đã sửa đổi sẽ mất nhiều thời gian hơn so với việc phát triển thay đổi tính năng cho lần chạy nước rút (chắc chắn đây là trạng thái không ai được tính toán trong quá trình lập kế hoạch chạy nước rút).

#2. Tạo thói quen thực hiện tất cả các phần của Bài kiểm tra đơn vị trên môi trường Phát triển

Ngay cả trước khi tạo yêu cầu kéo để hợp nhất mã mới vào nhánh Chính, hoạt động tiêu chuẩn phải là kiểm tra cả mã tính năng và mã kiểm tra đơn vị trên môi trường nhà phát triển. Bằng cách này, nó sẽ được đảm bảo rằng:

• Mã kiểm tra đơn vị thực sự hoạt động cho từng phần (cuối cùng, đó chỉ là một mã khác phải được xác minh). Bước này thường bị bỏ qua hoàn toàn. Bằng cách nào đó, giả định rằng nếu thử nghiệm đơn vị vẫn được cắm vào đường dẫn DevOps, thì cuối cùng nó sẽ được thực thi và thử nghiệm ở đâu đó theo mặc định. Tuy nhiên, điều này không có gì khác ngoài việc đẩy các vấn đề lên cấp độ cao hơn của các hoạt động chạy nước rút, nơi nhóm thường có ít thời gian hơn và nhiều căng thẳng hơn để hoàn thành mọi câu chuyện đã cam kết.
• Mã tính năng mới được nhà phát triển kiểm tra chức năng cơ bản. Rõ ràng, không thể mong đợi từ thử nghiệm này rằng chức năng kinh doanh sẽ được xác minh đầy đủ, nhưng ít nhất thử nghiệm này sẽ xác nhận mã hoạt động theo cách mà nhà phát triển dự định (hiện tại, bỏ qua thực tế là logic kinh doanh có thể được hiểu sai trong khi phát triển).

#3. Yêu cầu thực thi kiểm tra đơn vị sau khi hợp nhất mã vào nhánh chính

Việc có mã chức năng trên nhánh cục bộ (nơi không ai ngoài chủ sở hữu nhánh đang phát triển một tính năng mới) là một chuyện, nhưng việc có cùng một mã hoạt động sau yêu cầu kéo và hợp nhất vào nhánh chính lại là một chuyện hoàn toàn khác.

Nhánh chính chứa các thay đổi từ các thành viên nhóm Scrum khác và ngay cả khi các xung đột được giải quyết và mọi thứ đều ổn, thì mã sau khi hợp nhất và giải quyết xung đột về cơ bản vẫn là một đoạn mã chưa được kiểm tra và sẽ rất rủi ro nếu gửi tiếp mà không xác minh trước nó vẫn hoạt động tốt.

Vì vậy, điều được chứng minh là hiệu quả ở đây chỉ đơn giản là yêu cầu thực hiện cùng một thử nghiệm đơn vị – đã được thực hiện trước đó trên môi trường nhà phát triển – cũng như trên môi trường, được xây dựng từ phiên bản mã nhánh chính.

Đối với các nhà phát triển, đó có thể là một bước bổ sung mà họ cần đưa vào cuộc sống của mình, nhưng đó không phải là một nỗ lực quá lớn vì trong trường hợp này, không cần phải phát minh ra điều gì mới – chỉ cần thực hiện lại những gì đã được thực hiện một lần.

Bây giờ, bước này có thể được bỏ qua trong một trường hợp cụ thể:

• Các thử nghiệm đơn vị tự động trong quy trình DevOps toàn diện đến mức chúng đã bao gồm toàn bộ thử nghiệm thủ công được thực hiện trên đó.

Mặc dù đạt được trạng thái này chắc chắn là khả thi, nhưng tôi chưa bao giờ trải qua trạng thái như vậy trong đời thực. Các nhà phát triển thậm chí có thể sẽ tốn quá nhiều thời gian để tạo các bài kiểm tra Đơn vị tự động chi tiết sâu sắc như vậy. Chủ sở hữu sản phẩm có thể dễ dàng không chấp nhận được việc để nhóm dành quá nhiều thời gian cho hoạt động này, vì nó sẽ có tác động rõ ràng đến số lượng câu chuyện được phân phối trong một lần chạy nước rút.

Tuy nhiên, ưu tiên cho nội dung chạy nước rút sẽ không bao giờ là cái cớ để không thực hiện các bài kiểm tra đơn vị hoặc thậm chí giảm thiểu chúng. Bằng cách này, nhóm sẽ chuyển đổi lại sang trạng thái như vậy mà mã thiếu quá nhiều phạm vi kiểm tra đơn vị và sau đó để bắt kịp, có thể đã quá muộn (một lần nữa, nỗ lực hoàn thành kiểm tra đơn vị cao hơn so với thực tế thay đổi mã cho một lần chạy nước rút).

Vì tất cả những lý do đó, tôi khuyên bạn nên thực hiện lại các bài kiểm tra đơn vị trên phiên bản mã chính mà không do dự. Đó là một nỗ lực thấp so với giá trị mà nó sẽ mang lại.

Nó sẽ thực hiện kiểm tra cuối cùng về sự sẵn sàng của nhánh chính cho giai đoạn thử nghiệm phát hành. Ngoài ra, nó sẽ giúp tìm ra hầu hết các lỗi kỹ thuật (ví dụ: lỗi ngăn mã nguồn được thực thi thành công cho đến khi kết thúc thành công), để giai đoạn tiếp theo chỉ tập trung vào việc xác minh chức năng kinh doanh.

Chuẩn bị cho kiểm thử chức năng

Tất cả các hoạt động thử nghiệm trước đó sẽ dẫn đến một kết luận cụ thể – mã nhánh chính không có lỗi kỹ thuật và có thể thực thi được mà không gặp sự cố đối với các luồng chức năng từ đầu đến cuối.

Đây là một giai đoạn có thể dễ dàng được thực hiện chỉ bởi một người duy nhất và người này thậm chí không cần phải có nền tảng kỹ thuật.

Trên thực tế, sẽ tốt hơn nhiều nếu điều này được thực thi bởi một người nào đó không liên quan đến các nhà phát triển nhưng có nhận thức về chức năng về những gì người dùng doanh nghiệp mong đợi mã sẽ hoạt động như thế nào. Có hai hoạt động chính cần hoàn thành:

#1. Câu chuyện chạy nước rút mới được nhắm mục tiêu thử nghiệm chức năng

Lý tưởng nhất là mỗi lần chạy nước rút sẽ mang lại một số chức năng mới (tăng mục tiêu chạy nước rút) mà trước đây không tồn tại và do đó, chức năng này sẽ được xác minh. Điều quan trọng là phải đảm bảo phần mềm mới hoạt động ở mức độ mà người dùng doanh nghiệp hài lòng khi có nó ngay bây giờ, vì rõ ràng họ đã mong đợi nó ít nhất là trong toàn bộ nước rút cuối cùng :).

Thật là một trải nghiệm đáng buồn khi chức năng được hứa hẹn (lâu nay) cuối cùng được thông báo sẽ phát hành, chỉ để phát hiện ra vào một ngày khác, nó thực sự không hoạt động tốt.

Do đó, kiểm tra đúng chức năng chạy nước rút mới là rất quan trọng. Để làm cho điều này thành công, tốt nhất là thu thập trước các trường hợp thử nghiệm quan trọng và từ các bên liên quan (từ chủ sở hữu sản phẩm hoặc thậm chí từ người dùng cuối) và lập danh sách tất cả các trường hợp thử nghiệm cần thiết cho nội dung bên trong nước rút.

Điều này thoạt nhìn có vẻ choáng ngợp, nhưng theo kinh nghiệm của tôi, nó lại hoàn toàn có thể quản lý được bởi một người. Vì các lần chạy nước rút hầu hết đều khá ngắn (chẳng hạn như khoảng thời gian ngắn hai tuần), nên hầu như không bao giờ có quá nhiều nội dung mới, vì chạy nước rút cũng chứa các hoạt động bổ sung như câu chuyện nợ kỹ thuật, tài liệu, câu chuyện thiết kế/tăng đột biến, v.v.

Các trường hợp thử nghiệm sau đó được thực hiện với mục đích trước hết là xác minh chức năng mong muốn. Nếu có bất kỳ vấn đề nào xảy ra với kết quả, chỉ nhà phát triển có liên quan mới được tiếp cận (người sở hữu các thay đổi liên quan đến lỗi cụ thể này) để giải quyết vấn đề một cách nhanh chóng với hy vọng.

Bằng cách này, các nhà phát triển sẽ dành thời gian tối thiểu liên quan đến thử nghiệm chức năng và vẫn có thể tập trung vào các hoạt động mà họ thích nhất.

#2. Thực hiện các trường hợp kiểm tra hồi quy

Phần khác của thử nghiệm chức năng là đảm bảo mọi thứ hoạt động cho đến bây giờ cũng sẽ hoạt động sau bản phát hành tiếp theo. Đây là những gì các bài kiểm tra hồi quy dành cho.

Các trường hợp kiểm thử cho kiểm thử hồi quy là tốt nhất nếu chúng được duy trì và xem lại thường xuyên trước mỗi lần phát hành. Dựa trên các chi tiết cụ thể của dự án, tốt nhất là giữ cho chúng đơn giản nhưng bao gồm phần lớn các chức năng cốt lõi và các luồng đầu cuối quan trọng chạy qua toàn bộ hệ thống.

Thông thường, mỗi hệ thống có các quy trình liên quan đến nhiều lĩnh vực khác nhau, đó là những ứng cử viên tốt nhất cho các trường hợp kiểm tra hồi quy.

Trong một số trường hợp, các thử nghiệm hồi quy thậm chí còn bao gồm cả các tính năng mới trong lần chạy nước rút, chẳng hạn như nếu câu chuyện mới trong lần chạy nước rút đang thay đổi một số phần cụ thể của quy trình hiện có.

Vì vậy, trong hầu hết các trường hợp, việc hoàn thành các bài kiểm tra hồi quy cùng với các bài kiểm tra chức năng câu chuyện chạy nước rút mới không quá phức tạp, đặc biệt nếu việc này được thực hiện thường xuyên trước mỗi bản phát hành sản xuất và tính định kỳ của các bản phát hành sản xuất không quá nhỏ.

Kiên quyết thực hiện các bài kiểm tra Đảm bảo chất lượng trước mỗi lần phát hành sản phẩm

Thử nghiệm Đảm bảo chất lượng (QA) là bước cuối cùng trước khi đưa vào sản xuất và thường thì thử nghiệm này bị bỏ qua vì không quan trọng. Đặc biệt nếu nhóm scrum được quản lý tích cực cho nội dung mới.

Ngay cả người dùng doanh nghiệp cũng sẽ nói rằng họ quan tâm đến các tính năng mới và không quan tâm nhiều đến việc duy trì chức năng hoặc giữ cho số lượng lỗi ở mức thấp. Nhưng một lần nữa – theo thời gian, đây là lý do chính khiến nhóm nhà phát triển cuối cùng sẽ phải chậm lại, và sau đó người dùng doanh nghiệp sẽ không nhận được những gì họ yêu cầu.

Kiểm tra QA sẽ chỉ được thực hiện bởi những người bên ngoài nhóm Scrum, lý tưởng nhất là bởi chính người dùng doanh nghiệp trong một môi trường chuyên dụng, càng gần với quá trình sản xuất trong tương lai càng tốt. Ngoài ra, chủ sở hữu sản phẩm có thể thay thế ở đây người dùng cuối.

Trong mọi trường hợp, đây phải là một thử nghiệm chức năng rõ ràng từ quan điểm của người dùng cuối, không có bất kỳ kết nối nào với nhóm nhà phát triển Scrum. Nó sẽ trình bày một cái nhìn cuối cùng về sản phẩm và được sử dụng theo cách mà có thể không ai trong nhóm scrum dự đoán được (hoàn toàn không phải là một trường hợp lý tưởng, nhưng nó chắc chắn có thể xảy ra). Vẫn còn thời gian cho những điều chỉnh vào phút cuối.

Ngoài ra, có thể rõ ràng là nhóm scrum không hiểu rõ các kỳ vọng và trong trường hợp như vậy, ít nhất chúng ta có thể đồng ý về một kế hoạch tiếp theo, vẫn còn trước khi phát hành sản phẩm thực tế. Một lần nữa, đây không phải là một trường hợp lý tưởng, nhưng vẫn tốt hơn nhiều so với việc thừa nhận lỗi ngay sau khi báo cáo một bản phát hành sản xuất thành công.

Đi đâu tiếp theo từ đây?

Áp dụng những thực tiễn đó vào công việc scrum hàng ngày có thể giúp bạn có thói quen phát hành sprint ổn định hơn và có thể dự đoán được, mà không làm trì hoãn các bản phát hành sản xuất hoặc dành toàn bộ Sprint chỉ để chuẩn bị cho lần phát hành tiếp theo hoặc thậm chí không buộc mọi người trong nhóm scrum phải làm điều gì đó mà họ không làm. Dù sao thì tôi cũng không thực sự thích hoặc không biết cách thực hiện hiệu quả trong phần lớn thời gian chạy nước rút.

Nhưng chắc chắn bạn không cần phải dừng lại ở đây.

Bao gồm kiểm tra hiệu suất là một chủ đề để đặt tên ở đây. Những thứ đó thường bị bỏ qua hoặc được coi là không cần thiết, được loại bỏ trong vòng đầu tiên của “tối ưu hóa các hoạt động scrum”. Tuy nhiên, tôi luôn nghi ngờ về việc người ta có thể mong đợi hệ thống sản xuất phát triển theo thời gian như thế nào nếu nó không được kiểm tra hiệu suất thường xuyên.

Lên một cấp cũng có nghĩa là giới thiệu các bài kiểm tra tự động.

Tôi đã đề cập đến một nhóm thử nghiệm tự động (kiểm tra đơn vị trong đường ống). Tuy nhiên, bạn có thể phát triển các thử nghiệm hồi quy từ đầu đến cuối hoàn toàn tự động và tự thực hiện sau mỗi lần triển khai vào môi trường thử nghiệm. Điều này sẽ giải phóng nhóm scrum phát triển nhiều hơn, nhưng nó yêu cầu một nhóm chuyên dụng để phát triển và duy trì các thử nghiệm tự động như vậy. Nó sẽ trở thành công việc liên tục, vì bất cứ khi nào mã sản xuất thay đổi, một số thử nghiệm tự động hiện có có thể trở nên không hợp lệ và do đó chúng phải được cập nhật để tiếp tục hoạt động trong quy trình. Đó là một nỗ lực mà chỉ một số ít sẵn sàng trả tiền, tuy nhiên, lợi ích cho nhóm phát triển scrum sẽ rất tuyệt vời.

Đó là những chủ đề vượt xa phạm vi của bài viết này và tìm ra lịch trình và thời gian phù hợp cho từng loại thử nghiệm được đề cập ở đây – để bạn có thể thực hiện nó trong khoảng thời gian chạy nước rút. Tôi sẽ rất vui khi được lặn vào lần tới!