Thực hành tốt nhất QA hiệu quả

Làm việc tại hiệu quả Tôi đã tham gia vào hơn 30 dự án khác nhau. Tất cả đều hoàn toàn khác nhau: web và di động, lớn và nhỏ, phức tạp và đơn giản. Chúng tôi đã xây dựng các dự án từ đầu, thêm các tính năng mới và duy trì các dự án hiện có.

Có rất nhiều trường hợp khó khăn trong quy trình đảm bảo chất lượng, thử nghiệm, quản lý và phát triển và bây giờ có cảm giác như nhóm của chúng tôi đã vượt qua Per Aspera ad Astra.

Hiện tại, có vẻ như không có gì đặc biệt được thực hiện, nhưng so sánh Hiệu quả bây giờ và sau đó tôi có thể nói rằng chúng tôi đã thực hiện một bước tiến rất lớn. Phân tích sai lầm đã được thực hiện, mong muốn và đề xuất của nhóm, tôi đã chuẩn bị danh sách thực hành tốt nhất sau đây để đảm bảo chất lượng. Mục đích của danh sách này là giúp các đội trẻ hiểu những gì có thể hữu ích cho họ mà không dành nhiều thời gian cho nghiên cứu. Đối với một số người có kinh nghiệm, điều này có thể trông giống như phát minh lại xe đạp :) Ở đây chúng tôi đi!

Hiểu mục tiêu kinh doanh và làm rõ Tiêu chí chấp nhận

Đây là nền tảng của một dự án và cần được làm rõ trước khi bắt đầu phát triển. Một nhóm dự án phải hiểu những gì nên được thực hiện, ai là đối tượng mục tiêu / người tiêu dùng tính năng và làm thế nào để hiểu không còn gì để làm.

Hiểu các mục tiêu kinh doanh sẽ giúp bạn trả lời các câu hỏi như Chúng ta cần làm gì và ai sẽ sử dụng nó? Tiêu chí chấp nhận sẽ giúp bạn hiểu một tính năng có đáp ứng mục tiêu kinh doanh hay không. Từ kinh nghiệm của tôi, tôi có thể nói rằng các mục tiêu kinh doanh và tiêu chí chấp nhận nên được xác nhận bởi một đại diện khách hàng hoặc khách hàng. Ngoài ra, dựa trên các mục tiêu kinh doanh rõ ràng và minh bạch và các tiêu chí chấp nhận, các công ty phát triển phần mềm gia công lành nghề có thể nâng cấp ý tưởng kinh doanh hoặc đề xuất một giải pháp tốt hơn.

CI / CD - Tích hợp liên tục / Triển khai liên tục

Nghe có vẻ quen thuộc Một trong những xu hướng trong phát triển phần mềm hiện tại, lợi thế chính của quan điểm nhóm QA là chúng ta có thể dễ dàng có được bản dựng với các tính năng hoặc bản sửa lỗi mới nhất.

Trong chu kỳ phát triển, nhóm phát triển của chúng tôi có thể có rất nhiều nhánh git liên quan đến các tính năng khác nhau nhưng chỉ có một nhánh chứa mã được cập nhật nhất. Công cụ CI kiểm tra nhánh này và khi mã được thay đổi, nó tạo ra một bản dựng mới và chia sẻ nó với dịch vụ phân phối được chỉ định.

Chúng tôi đã thử TeamCity và Jenkins. Cả hai đều là những công cụ tuyệt vời. TeamCity có giao diện người dùng đẹp hơn, nhưng Jenkins hoàn toàn miễn phí, vì vậy chúng tôi đã chọn Jenkins.

Dịch vụ phân phối ứng dụng

Nhìn chung, có vẻ như không có gì đặc biệt nhưng dưới vỏ bọc, việc tích hợp liên tục với các dịch vụ triển khai ứng dụng được điều chỉnh cho bạn cách dễ nhất và nhanh nhất để có bản dựng mới nhất trên bất kỳ thiết bị hoặc môi trường thử nghiệm nào bạn muốn. Nó có thể tải lên bản dựng qua USB cho một thiết bị. Nhưng nếu bạn cần kiểm tra bản dựng bằng 10 thiết bị khác nhau thì sao? Đó là điểm.

Đối với các dự án di động, chúng tôi đã thử một vài dịch vụ khác nhau như HockeyApp, Beta bằng vải (ví dụ như Crashlytics), Chuyến bay thử của Apple, Play Console của Google. Tất nhiên, có nhiều dịch vụ hơn nhưng những dịch vụ này đã được chọn là phổ biến nhất. Bây giờ tôi đã bỏ phiếu cho Test Flight và Play Console vì các dịch vụ này rất linh hoạt, hỗ trợ các tính năng của người kiểm tra nội bộ và bên ngoài và các dịch vụ chính thức từ Apple và Google và chỉ yêu cầu email của người kiểm tra. Hạn chế duy nhất ở đây là bạn cần có tài khoản nhà phát triển của Apple và Google có giá 25 đô la cho Google (thanh toán một lần) và 99 đô la cho Apple (hàng năm).

Các dịch vụ khác như HockeyApp hoặc Beta có một số khó khăn khi thêm người thử nghiệm mới vào dự án, đặc biệt là trên iOS. Do sự chăm sóc bảo mật của Apple, từ những người thử nghiệm, nó yêu cầu phải cung cấp UDID cho các thiết bị của họ cho nhà phát triển và nhà phát triển phải thêm các UDID này vào dự án. Vì chúng tôi chia sẻ các bản dựng dev với khách hàng của chúng tôi (những người thường có nhiều thiết bị khác nhau và thay đổi chúng thường xuyên), tất cả chúng tôi đều cảm thấy mệt mỏi với các hoạt động thu thập UDID này. Đó là lý do tại sao chúng tôi đã chọn Test Flight và Play Console.

Đối với các dự án web, mọi thứ đơn giản hơn một chút vì chúng tôi sử dụng môi trường thử nghiệm đặc biệt được cập nhật bởi công cụ CI khi nhánh phát triển được thay đổi.

Tài liệu kiểm tra

Qua nhiều năm, nhóm QA của chúng tôi đã tìm ra bốn tài liệu có giá trị nhất có thể được chia sẻ với khách hàng hoặc các bên liên quan:

  • Nền tảng được hỗ trợ
  • Kế hoạch kiểm tra
  • Các trường hợp kiểm tra / Danh sách kiểm tra
  • Ghi chú phát hành

Tài liệu nền tảng được hỗ trợ nên được chuẩn bị càng sớm càng tốt khi dự án bắt đầu và ký với khách hàng. Nó nên chứa thông tin về cấu hình phần cứng và phần mềm được hỗ trợ, các hạn chế và hạn chế đã biết. Nó cũng dựa trên các thiết bị đối tượng mục tiêu vì thị trường thiết bị khác nhau ở các quốc gia khác nhau.

Ký kết điều này với khách hàng của chúng tôi, chúng tôi đảm bảo rằng phiên bản đầu tiên của sản phẩm hoạt động hoàn hảo trên các cấu hình được liệt kê, bên cạnh đó chúng tôi cho khách hàng biết rằng sản phẩm đó có thể hoạt động trên các cấu hình khác nhưng một số vấn đề có thể xuất hiện. Và nếu sản phẩm và đối tượng mục tiêu sẽ phát triển, chúng tôi sẽ có thể phân tích và triển khai hỗ trợ nền tảng bổ sung. Trong tương lai, tài liệu này sẽ cho phép chúng tôi tập trung vào các nền tảng được chỉ định trong phát triển và sửa lỗi.

Kế hoạch kiểm tra cũng nên được chuẩn bị ngay từ đầu và chia sẻ với khách hàng. Tài liệu này nên chứa tất cả các loại thử nghiệm sẽ được sử dụng trong quá trình phát triển sản phẩm với mục đích được mô tả cho từng loại. Trong kế hoạch kiểm tra, nhóm QA nên quyết định những gì họ sử dụng để kiểm tra, trường hợp kiểm tra hoặc danh sách kiểm tra. Thông thường, nó phụ thuộc vào thời gian dự án và độ phức tạp chức năng. Các nền tảng được hỗ trợ nên được liên kết với kế hoạch kiểm tra là tốt. Và cuối cùng, kế hoạch kiểm thử nên chứa thông tin về các hoạt động kiểm tra theo kế hoạch theo ngày theo thời gian phát triển và phát hành dự án.

Các trường hợp kiểm tra / danh sách kiểm tra là một điều bắt buộc cho mọi dự án. Tất nhiên, phải mất một thời gian để chuẩn bị các sản phẩm này và có thể mất thêm thời gian để hỗ trợ tài liệu này, nhưng nó cung cấp cho bạn một số loại thân cây và sử dụng thân cây này, bạn có thể dễ dàng tưởng tượng và tạo các kịch bản thử nghiệm mới chỉ bằng cách thêm các nhánh vào thân cây của bạn. Sau đó, bạn có thể chia sẻ các trường hợp thử nghiệm đã chuẩn bị với nhóm UAT ở phía máy khách hoặc với những người thử nghiệm beta hoặc thậm chí hiển thị các trường hợp thử nghiệm cho nhóm phát triển dự án. Nhóm phát triển có thể sử dụng các trường hợp thử nghiệm như một phần của yêu cầu và nó thực sự có thể giúp họ tránh một số vấn đề.

Tại hiệu quả, chúng tôi đã thử rất nhiều TMS (Hệ thống quản lý kiểm tra) và chọn TestRail là một trong những công cụ phổ biến nhất, có thể tùy chỉnh, nhanh chóng và thuận tiện để quản lý trường hợp kiểm tra và quản lý kiểm tra. Sử dụng TestRail cho phép chúng tôi dễ dàng cập nhật các trường hợp kiểm tra và danh sách kiểm tra. Đối với chúng tôi, bộ công cụ này tuyệt vời, nhưng vẫn còn rất nhiều lựa chọn thay thế. Mẹo chính ở đây là sử dụng TMS thích hợp và không nên sử dụng Google Docs và Bảng tính cho các trường hợp thử nghiệm và nhật ký kiểm tra :)

Ghi chú phát hành là tài liệu được chuẩn bị bởi nhóm QA của chúng tôi cho khách hàng và chứa thông tin thực tế về dự án. Những tính năng nào đã được hoàn thành trong lần chạy nước rút cụ thể, những gì vẫn đang được tiến hành, những vấn đề đã biết, nơi và cách xây dựng bản demo có thể được tải xuống. Chúng tôi luôn chuẩn bị ghi chú phát hành bằng cách chạy nước rút và phát hành. Nó cung cấp cho khách hàng của chúng tôi minh bạch thêm về tiến trình phát triển.

Thử nghiệm thăm dò

Điều cuối cùng không bao giờ nên quên là Thử nghiệm thăm dò. Mục đích chính của thử nghiệm này là để hiểu rõ hơn về sản phẩm của bạn và xem xét nó từ góc độ người dùng. Kết hợp thử nghiệm thăm dò và thử nghiệm theo kịch bản (bằng thử nghiệm theo kịch bản, ý tôi là sử dụng các trường hợp thử nghiệm hoặc sử dụng danh sách kiểm tra), kết hợp người dùng thử nghiệm và nhận thức của người dùng về sản phẩm và ghi nhớ các mục tiêu kinh doanh bạn có thể làm cho sản phẩm bạn làm việc hoàn hảo nhất có thể.

Là một phần của thử nghiệm thăm dò, chúng tôi cũng sử dụng phương pháp thử nghiệm bầy đàn. Sử dụng Test Flight và Play Console, chúng tôi mời những người thử nghiệm bên ngoài thường là nhân viên hiệu quả, những người không tham gia dự án và có thể đóng vai trò là người thử nghiệm beta. Điều này cho phép chúng tôi có được một cái nhìn tổng quan về sản phẩm từ góc độ người dùng và chú ý đến khả năng sử dụng.

Tóm tắt thực tiễn tốt nhất về QA hiệu quả:

  • Hiểu các mục tiêu kinh doanh
  • Làm rõ tiêu chí chấp nhận
  • Biết các nền tảng được hỗ trợ của bạn
  • Chuẩn bị kế hoạch kiểm tra
  • Sử dụng Test Case / Danh sách kiểm tra
  • Sử dụng tích hợp liên tục + Triển khai liên tục
  • Giữ các trường hợp kiểm tra / Danh sách kiểm tra được cập nhật
  • Chia sẻ ghi chú phát hành với khách hàng của bạn
  • Không bao giờ quên về thử nghiệm thăm dò

Cảm ơn vì đã đọc! Hãy bình luận nếu bạn muốn biết thêm, không đồng ý hoặc có bất kỳ câu hỏi nào :)