Scrum trừ kế hoạch kiểm tra là 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 Bằng chứng về khái niệm (POC), một đánh giá ý tưởng tương đối nhỏ trong đó công nghệ và bộ tính năng đã chọn trước tiên sẽ được xác thực, đánh giá về tác động tiềm tàng đối với người dùng doanh nghiệp và sau đó, sau khi được chứng minh là đáng đầu tư, Ở quy mô đầy đủ, nhóm thiết kế được giao nhiệm vụ thiết kế và cung cấp một sản phẩm có đầy đủ chức năng và triển khai nó vào 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 tạo nguyên mẫu, bổ sung 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ể thấy tiến độ nhanh chóng trong thời gian thực và cách xây dựng ý tưởng ngay 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 – tối thiểu hoặc không có hoạt động thử nghiệm và chỉ nghĩ về quá trình thử nghiệm sẽ là một trò đùa.
Trong nhóm Scrum, đây không phải là một hoạt động thú vị và mọi người hầu như sẽ thích ý tưởng phát triển mà không có các quy trình có thể làm họ chậm lại. Về cơ bản đây là điều mà bất kỳ hoạt động thử nghiệm nào cũng sẽ thực hiện ngầm. Và ai lại không muốn sự chậm lại không cần thiết mà chúng ta cần để tạo ấn tượng lớn nhất cho người dùng cuối?
Trạng thái xảy ra khi nhóm dự án tiếp tục theo cách tương tự sau khi kết thúc giai đoạn POC, tôi gọi POC là steroid – hệ thống sản xuất phát triển về quy mô và tính năng, nhưng vẫn hoạt động giống như POC – một sản phẩm sẽ hoàn chỉnh có ẩn góc sai sót và trường hợp chưa được khám phá, chỉ chờ đợi một thất bại nghiêm trọng.
Nhưng vào thời điểm nó biến đổi ở đó, nhóm sẽ khó chạy nước rút hơn để theo kịp các bản phát hành ổn định vì việc khắc phục các vấn đề liên tục sẽ chỉ trở nên phức tạp hơn.
Dưới đây là một số kỹ thuật đã giúp ích cho tôi khi tôi gặp phải các vấn đề tương tự và tôi tin rằng có thể gọi là các phương pháp thực hành tốt nhất để triển khai các quy trình thử nghiệm mạnh mẽ mà vẫn không làm xáo trộn quá nhiều tiến trình phát triển – bởi vì tất cả chúng ta đều muốn trở thành một nhóm Scrum.
Lan tỏa nỗi đau
Bắt đầu từ đâu khi chúng ta đang phải đối mặt với những phiền toái không cần thiết, nếu không phải là chia sẻ nỗi đau :).
Ý tôi là việc tạo ra một kế hoạch sẽ yêu cầu nhà phát triển thực hiện thêm một chút hoạt động ở chỗ này chỗ kia, nhưng sẽ bổ sung rất nhiều vào mục tiêu chung theo thời gian, dần 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 mà bạn tạo
Nếu bạn có thể thuyết phục các nhóm scrum của mình thêm vào mệnh đề Định nghĩa hoàn thành của họ để tạo các bài kiểm tra đơn vị cho mỗi mã mới mà họ tạo như một phần của chạy nước rút, thì đó sẽ là một thành tựu tuyệt vời từ góc độ dài hạn.
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ã tùy chỉnh khác nhau. –
- Các thử nghiệm đơn vị này có thể được kết nối với quy trình DevOps tự động và chạy mỗi khi bạn triển khai vào môi trường phát triển hoặc thử nghiệm. Ngoài ra, số liệu quy trình có thể được xuất dễ dàng và sau đó được sử dụng để chứng minh cho người dùng doanh nghiệp 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 nhanh. Công việc kiểm thử đơn vị càng bắt đầu muộn thì các nhà phát triển sẽ càng mất tập trung khi thêm chúng vào như một phần của chạy nước rút.
- Việc phát triển các bài kiểm tra đơn vị cho mã hiện có sẽ đòi hỏi nỗ lực đáng kể. Một số phần của mã có thể được tạo bởi một lập trình viên khác và việc biết chính xác từng phần mã sẽ hoạt động như thế nào không hoàn toàn rõ ràng đối với lập trình viên hiện tại. Trong một số trường hợp, việc thêm một bài kiểm tra đơn vị vào mã đã sửa đổi có thể 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 (điều mà tôi chắc chắn rằng không ai 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ị trong môi trường phát triển của bạ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, thông lệ tiêu chuẩn là phải kiểm tra cả mã chức năng và mã kiểm tra đơn vị trong môi trường phát triển của bạn. Điều này sẽ đảm bảo rằng:
- Mã kiểm tra đơn vị thực sự hoạt động cho mọi bộ phận (xét cho cùng, đó chỉ là một mã khác cần được xác minh). Bước này rất thường xuyên bị bỏ qua hoàn toàn. Bằng cách nào đó, người ta giả định rằng nếu một bài kiểm thử đơn vị vẫn được đưa vào quy trình DevOps thì cuối cùng nó sẽ được thực thi và kiểm thử ở đâu đó theo mặc định. Tuy nhiên, điều này không gì khác hơn là đẩy vấn đề lên cấp độ cao hơn trong các hoạt động chạy nước rút, nơi mà nhóm thường có ít thời gian hơn và căng thẳng hơn để hoàn thành từng câu chuyện liên quan.
- Mã chức năng mới được nhà phát triển kiểm tra chức năng cơ bản. Tất nhiên, thử nghiệm này không thể được kỳ vọng sẽ xác thực đầy đủ chức năng kinh doanh, nhưng ít nhất thử nghiệm này sẽ xác nhận rằng mã hoạt động như dự định của nhà phát triển (bỏ qua thực tế là logic nghiệp vụ có thể bị hiểu sai trong quá trình phát triển).
#3. Dự kiến sẽ chạy thử nghiệm đơn vị sau khi hợp nhất mã của bạn với nhánh chính
Việc có mã chức năng trong một nhánh địa phương là một chuyện (nơi không có ai ngoài chủ sở hữu chi nhánh đang phát triển một tính năng mới), nhưng việc có cùng một mã chạy sau một yêu cầu kéo và sáp nhập 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 khác của nhóm Scrum và ngay cả khi xung đột được giải quyết và mọi thứ đều ổn, mã sau khi hợp nhất và giải quyết xung đột về cơ bản vẫn là mã chưa được kiểm tra và sẽ rất nguy hiểm khi đẩy nó về phía trước mà không xác minh trước. hoạt động tốt
Vì vậy, điều tôi thấy hiệu quả ở đây chỉ đơn giản là yêu cầu chạy các bài kiểm tra đơn vị tương tự – đã đượ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 nhánh chính của mã.
Đối với các lập trình viên, đây có thể là một bước bổ sung mà họ cần áp dụng 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 bạn không cần phải phát minh ra bất cứ điều gì mới – chỉ cần làm lại những gì đã được thực hiện.
Bây giờ bước này có thể được bỏ qua trong một trường hợp cụ thể:
- Kiểm thử đơn vị tự động trong quy trình DevOps linh hoạt đến mức chúng đã bao gồm toàn bộ kiểm thử thủ công dựa trên chúng.
Mặc dù hoàn toàn có thể đạt được trạng thái này nhưng tôi chưa bao giờ trải qua trạng thái như vậy trong đời thực. Việc tạo các bài kiểm tra đơn vị tự động chi tiết như vậy có lẽ sẽ tốn quá nhiều thời gian đối với các nhà phát triển. Chủ sở hữu sản phẩm có thể dễ dàng không thể chấp nhận được việc cho phép 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, việc ưu tiên nội dung chạy nước rút không bao giờ là lý do để không thực hiện kiểm thử đơn vị hoặc thậm chí giảm thiểu nó. Bằng cách này, nhóm sẽ chuyển đổi lại sang trạng thái mà mã thiếu quá nhiều phạm vi kiểm thử đơn vị và sau đó có thể đã quá muộn để bắt kịp (một lần nữa, cần nhiều nỗ lực hơn để hoàn thành các bài kiểm thử đơn vị so với thay đổi mã thực tế cho lần chạy nước rút). ).
Vì tất cả những lý do này, tôi sẽ không ngần ngại khuyên bạn nên thực hiện lại các bài kiểm tra đơn vị của mình trên một phiên bản của mã chính. Đó là một nỗ lực rất nhỏ so với giá trị mà nó sẽ mang lại.
Sẽ thực hiện kiểm tra lần cuối về mức độ sẵn sàng của nhánh chính cho giai đoạn thử nghiệm phát hành. Nó cũng sẽ giúp bạn tìm ra hầu hết các lỗi kỹ thuật (ví dụ: lỗi ngăn mã nguồn thực thi thành công đến hoàn thành 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 các bài kiểm tra chức năng
Tất cả các hoạt động thử nghiệm cho đến nay đều 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 vấn đề gì đối với các luồng chức năng đầu cuối.
Đây là giai đoạn mà một người có thể dễ dàng vượt qua 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 nó được thực hiện bởi một người nào đó không kết nối với các nhà phát triển, nhưng có nhận thức chức năng về cách người dùng doanh nghiệp mong đợi mã hoạt động. Có hai bước chính để thực hiện:
# 1. Kiểm tra chức năng mục tiêu của các câu chuyện chạy nước rút mới
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), chưa có trước đó và do đó phải được xác minh. Điều quan trọng là 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ó, vì tất nhiên họ đã chờ đợi nó ít nhất trong toàn bộ lần chạy 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 (từ lâu) cuối cùng cũng được công bố phát hành, chỉ để rồi một ngày nọ, nó thực sự hoạt động không tốt.
Vì vậy, điều quan trọng là phải kiểm tra đúng chức năng chạy nước rút mới. Để điều này thành công, cách tốt nhất là thu thập trước các trường hợp kiểm thử 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à liệt kê tất cả các trường hợp kiểm thử đó cần thiết cho nội dung trong giai đoạn 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ó hoàn toàn có thể thực hiện được đối với một người. Vì các lần chạy nước rút hầu hết khá ngắn (chẳng hạn như khoảng thời gian 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 bao gồm 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ế/bước nhảy, v.v.
Sau đó, các trường hợp thử nghiệm được thực hiện, mục đích chủ yếu là để xác minh chức năng mong muốn. Nếu có bất kỳ vấn đề nào với kết quả, nó chỉ chuyển sang nhà phát triển có liên quan (người sở hữu các thay đổi cho lỗi cụ thể đó) để khắc phục vấn đề, hy vọng là nhanh chóng.
Bằng cách này, các nhà phát triển sẽ dành tối thiểu thời gian thử nghiệm chức năng mà vẫn có thể tập trung vào các hoạt động mà họ yêu thích nhất.
#2. Thực hiện các trường hợp kiểm thử hồi quy
Một phần khác của kiểm thử chức năng là đảm bảo rằng mọi thứ đã hoạt động cho đến nay cũng sẽ hoạt động trong bản phát hành tiếp theo. Đây là mục đích của các bài kiểm tra hồi quy.
Các trường hợp thử nghiệm để kiểm tra hồi quy là tốt nhất nếu chúng được duy trì và xem xét 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 bạn nên giữ chúng đơn giản nhưng bao gồm hầu hết các chức năng rất cơ bản 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 đều có các quy trình như thế này liên quan đến nhiều lĩnh vực khác nhau, đây là những ứng cử viên tốt nhất cho các trường hợp kiểm thử hồi quy.
Trong một số trường hợp, kiểm tra hồi quy cũng bao gồm các tính năng mới trong một lần chạy nước rút theo mặc định, chẳng hạn như nếu một câu chuyện mới trong lần chạy nước rút làm thay đổi một phần cụ thể của luồng hiện có.
Vì vậy, trong hầu hết các trường hợp, việc chạy thử nghiệm hồi quy cùng với thử nghiệm chức năng của các 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 lần phát hành sản phẩm và chu kỳ phát hành sản phẩm không quá nhỏ.
Nhấn mạnh vào việc kiểm tra QC trước mỗi phiên bản sản xuất
Kiểm tra đảm bảo chất lượng (QA) là bước cuối cùng trước khi đi vào sản xuất và thường kiểm tra này bị bỏ qua vì không hợp lệ. Đặ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 chứ không phải việc duy trì chức năng hoặc giữ số lượng lỗi ở mức thấp. Nhưng mặt khác – theo thời gian, đây là lý do chính khiến nhóm phát triển cuối cùng sẽ phải chậm lại và khi đó 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 chỉ nên được thực hiện bởi những người bên ngoài nhóm Scrum, tốt 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ế người dùng cuối.
Trong mọi trường hợp, nó phải là một thử nghiệm chức năng thuần túy theo quan điểm của người dùng cuối, không liên quan đến nhóm phát triển Scrum. Nó sẽ đưa ra cái nhìn cuối cùng về sản phẩm và sẽ được sử dụng theo cách mà có lẽ không ai trong nhóm scrum mong đợi (không phải là một trường hợp lý tưởng chút nào, 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, nhóm scrum có thể không hiểu rõ kỳ vọng, trong trường hợp đó ít nhất chúng ta có thể đồng ý về một kế hoạch tiếp theo trước khi quá trình sản xuất thực sự đi vào hoạt động. Một lần nữa, đây không phải là một trường hợp hoàn hảo, nhưng vẫn tốt hơn nhiều so với việc thừa nhận thất bại ngay sau khi báo cáo quá trình xây dựng sản xuất thành công.
Tiếp theo là ở đâu?
Việc áp dụng những phương pháp này vào công việc scrum hàng ngày của bạn có thể dẫn đến 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 phẩm hoặc dành toàn bộ sprint để chuẩn bị cho bản phát hành tiếp theo hoặc thậm chí buộc tất cả các thành viên của nhóm scrum phải làm điều gì đó mà họ không làm’ Tức là tôi không thực sự thích hoặc không biết làm thế nào cho hiệu quả trong hầu hết các sprint.
Nhưng bạn chắc chắn không phải dừng lại ở đây.
Một chủ đề cần đề cập là việc đưa vào bài kiểm tra hiệu suất. Chúng thường bị bỏ qua hoặc bị coi là không cần thiết, bị loại bỏ ngay trong vòng đầu tiên của quá trình “tối ưu hóa hoạt động scrum”. Tuy nhiên, tôi luôn nghi ngờ về việc làm thế nào một hệ thống sản xuất có thể phát triển theo thời gian nếu nó không được kiểm tra hiệu suất thường xuyên.
Tăng 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 toàn diện 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ảm bớt áp lực cho nhóm phát triển scrum nhiều hơn, nhưng đòi hỏi một nhóm tận tâm để phát triển và duy trì các thử nghiệm tự động như vậy. Điều này sẽ trở thành một công việc liên tục vì mỗi khi 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ệ nên chúng cần đượ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, nhưng lợi ích dành cho nhóm phát triển scrum sẽ rất lớn.
Đây là những chủ đề vượt xa phạm vi của bài viết này và việc đặt lịch trình cũng như thời gian thích hợp cho từng loại thử nghiệm được liệt kê ở đây để bạn có thể thực hiện nó trong giai đoạn chạy nước rút. Tôi sẽ rất vui khi được lặn lần sau!
