Chào bạn!  Tôi rất vui được chia sẻ cách tôi quản lý để cải thiện 20% quy trình phát hành thông qua việc triển khai vai trò QA hệ thống.  Cho rằng công ty của tôi là một công ty sản phẩm điển hình, các nhóm không được phân chia theo sản phẩm mà theo thành phần. Nhờ vậy, một mặt, chúng tôi đã thành lập được những đội mạnh với những "người nắm giữ" kiến thức. Nhưng mặt khác, các vai trò trong các đơn vị tương đối biệt lập và các nhóm kỹ năng cứng và chuyên môn khác nhau áp đặt những hạn chế của chúng. Ví dụ: đôi khi tôi cần chuyển một người thử nghiệm từ nhóm phụ trợ sang nhóm giao diện người dùng hoặc ngược lại.  Điều này dẫn đến thực tế là có một câu hỏi về sự phối hợp hiệu quả trong các nhóm QA và quản lý tương tác giữa các nhóm. Tất nhiên, điều này cuối cùng đã ảnh hưởng đến dòng phát hành.   Giải phóng luồng trước khi thay đổi  Trước khi có thay đổi, quy trình phát hành của chúng tôi trông như thế này:     là một tài liệu phác thảo các nhu cầu, kỳ vọng và thông số kỹ thuật chi tiết cho một tính năng, hệ thống, sản phẩm hoặc dự án cụ thể trong một doanh nghiệp. Nó đóng vai trò là cầu nối giữa các bên liên quan trong kinh doanh và nhóm phát triển hoặc triển khai, đảm bảo hiểu rõ những gì cần đạt được và cách nó phù hợp với   kinh doanh tổng thể. Nó phải chứa các kịch bản chi tiết mô tả cách người dùng sẽ tương tác với tính năng này. Chủ sở hữu tính năng (FO) được giao nhiệm vụ xây dựng các yêu cầu kinh doanh. Đặc tả yêu cầu kinh doanh (BRS) các mục tiêu    là một tài liệu toàn diện phác thảo mô tả chi tiết về những gì một hệ thống phần mềm dự kiến sẽ hoàn thành. Ví dụ, cách thức và lệnh nào tương tác, theo giao thức nào và dữ liệu nào sẽ được truyền đi. Nếu nhóm làm việc trên tính năng này sử dụng giao diện đồ họa, thì SRS nên bao gồm các bố cục của tính năng đang được phát triển. Feature Architect chịu trách nhiệm viết SRS. Đặc tả yêu cầu phần mềm (SRS)    – một tập hợp các trường hợp mà chủ sở hữu tính năng kiểm tra trước khi chấp nhận một tính năng. Sau khi các tài liệu được mô tả, chúng tôi tiến hành triển khai tính năng. Khi nhóm đầu tiên hoàn thành việc phát triển và thử nghiệm một phần tính năng của mình, nó sẽ được chuyển sang nhóm thứ hai. Nhóm thứ hai thực hiện tích hợp/phát triển/thử nghiệm và chuyển nó cho đơn vị tiếp theo. Và cứ tiếp tục như vậy cho đến khi tất cả các nhóm thành phần tham gia phát triển tính năng vượt qua quy trình này. FO xác thực tính năng này và tính năng này được gửi đến bản phát hành. Kế hoạch hành động chất lượng (QAP)   Phát hành các vấn đề về dòng chảy  Vì vậy, mọi thứ dường như đều ổn – tài liệu, đơn đăng ký, trường hợp chấp nhận. Tuy nhiên, chúng tôi gặp phải những khó khăn sau trong quá trình này:   Các vấn đề về phía QA:  Kiểm tra yêu cầu chỉ bắt đầu sau khi phát triển. Các nhiệm vụ đã được các nhà phát triển thực hiện cùng với các yêu cầu của họ sẽ được bàn giao cho nhóm QA. Tuy nhiên, như chúng ta biết, có thể có lỗi trong các yêu cầu.  Việc tìm ra nhóm chịu trách nhiệm về lỗi mất khá nhiều thời gian vì không phải lúc nào cũng rõ trường hợp nào đã được kiểm tra bởi các nhóm khác.  Không sử dụng lại các vật phẩm thử nghiệm. Là một phần của thử nghiệm một tính năng, các nhóm QA chuẩn bị các bộ dữ liệu thử nghiệm tương tự. Nhưng do sự cô lập và chuyên môn hóa hẹp của các đội, họ không thể truyền dữ liệu này cho nhau.   Các vấn đề về phía FO:  Do có nhiều tính năng nên viết QAP mất khá nhiều thời gian.  Việc xác thực tính năng diễn ra sau khi tất cả các nhóm phát triển. Trong trường hợp của chúng tôi, điều này kéo dài đáng kể quy trình phát hành do nhiều vấn đề về tích hợp.  Việc chuẩn bị môi trường thử nghiệm cũng chính xác do tính phức tạp của sản phẩm và khối lượng tích hợp giữa các nhóm. Các nhóm khác nhau đang kiểm tra các thành phần của họ đồng thời, làm tăng rủi ro trộn, thay đổi hoặc xóa dữ liệu.   Đảm bảo chất lượng hệ thống trong quy trình phát hành cập nhật  Để tạo điều kiện tương tác giữa các nhóm hiệu quả giữa các nhóm QA và giảm quy trình phát hành, chúng tôi đã giới thiệu vai trò của QA hệ thống.  Điều này giúp giảm bớt khối lượng công việc dưới dạng viết các trường hợp chấp nhận bằng FO và tăng tốc độ viết các kịch bản thử nghiệm, giới thiệu thử nghiệm trung gian của thành phần tính năng trước khi chuyển cho nhóm tiếp theo, đồng thời chuyển công việc chuẩn bị thử nghiệm tốn nhiều thời gian môi trường cho QA hệ thống, có tính đến tất cả các sắc thái và yêu cầu của các nhóm đối với dữ liệu tích hợp và thử nghiệm.  QA hệ thống đã trở thành mối liên kết giữa các yêu cầu kỹ thuật và nghiệp vụ đối với từng tính năng và toàn bộ sản phẩm.  Lên tàu cho QA hệ thống  Để hiểu toàn bộ chu kỳ phát hành, các QA hệ thống cần hiểu cách thức hoạt động của một chu kỳ phát hành cụ thể trong mỗi nhóm. Quá trình giới thiệu thường kéo dài khoảng ba tháng vì QA hệ thống dành 2-3 tuần cho mỗi nhóm để hiểu các chu kỳ phát hành cụ thể của họ.  Kết quả của quy trình mới  Chúng tôi hiện đang thử nghiệm các yêu cầu BRS/SRS từ chủ sở hữu tính năng và kiến trúc sư. Phát hiện lỗi sớm giúp tiết kiệm chi phí cho doanh nghiệp.  Chúng tôi đã thiết lập một không gian QA giữa các nhóm, nơi các tạo phẩm thử nghiệm được đính kèm với từng tính năng – yêu cầu kinh doanh, yêu cầu kỹ thuật, trường hợp chấp nhận, trường hợp của các nhóm khác, dữ liệu thử nghiệm. Điều này giúp ích đáng kể cho tất cả các nhóm QA ở trong một bối cảnh duy nhất và tái sử dụng dữ liệu một cách hiệu quả.  Đẩy nhanh quá trình bản địa hóa các lỗi vì QA hệ thống có các bộ trường hợp thử nghiệm từ tất cả các nhóm.  Vì QA hệ thống đang viết các trường hợp chấp nhận cho mỗi nhóm nên đây là một gợi ý tuyệt vời để tăng tốc và cải thiện chất lượng thử nghiệm.  Quá trình tích hợp trở nên dễ dàng hơn vì tính năng này được xác thực bằng các trường hợp chấp nhận sau mỗi lệnh.  Sau khi loại bỏ một phần đáng kể tải khỏi FO, việc chấp nhận các tính năng và chuẩn bị giá đỡ tích hợp với dữ liệu thử nghiệm được tăng tốc.  Nhìn chung, đã tăng tốc quy trình phát hành lên 15-20% và giảm gần một nửa số lỗi tích hợp kể từ bây giờ, chúng tôi phát hiện ra chúng ở cả giai đoạn viết yêu cầu BRS và SRS cũng như trong quá trình tích hợp nhóm trong khuôn khổ phát triển tính năng.  Thử nghiệm vui vẻ và hiệu quả!

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

Read My Stories

QA Head

Nghe bài viết này bằng Tiếng Anh, đọc bởi robot thông minh của HackerNoon

Tăng năng suất: Hướng dẫn triển khai vai trò QA mới để phát hành nhanh hơn

About Author

BÌNH LUẬN

chuyên mục

BÀI VIẾT NÀY CŨNG CÓ MẶT TẠI

Related Stories

72 Stories To Learn About The Essays Of Adam Smith

287 Stories To Learn About Blockchain Development

223 Stories To Learn About Science

178 Stories To Learn About Essay

72 Stories To Learn About The Essays Of Adam Smith

287 Stories To Learn About Blockchain Development

223 Stories To Learn About Science

178 Stories To Learn About Essay

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps