Agile Test Case Management - Giữ cho test case của bạn gọn gàng

Bằng cách chủ động quản lý trường hợp thử nghiệm nhanh trong mỗi lần chạy nước rút, nhóm QA sẽ tránh vô tình thực hiện các trường hợp thử nghiệm lỗi thời và tránh gửi các lỗi không hợp lệ, do đó tạo ra một quy trình hiệu quả hơn để đảm bảo phạm vi thử nghiệm.

Giải pháp để quản lý các trường hợp thử nghiệm Agile

Giải pháp thực sự đơn giản, nó chỉ yêu cầu một mức độ chủ động, để ngăn nhóm tranh giành cập nhật các bài kiểm tra hồi quy tại thời điểm hồi quy. Lên lịch thời gian trong mỗi lần chạy nước rút để quản lý các trường hợp kiểm thử hồi quy. Các thay đổi đối với mỗi câu chuyện của người dùng sẽ thuộc một hoặc nhiều trong bốn loại sau. Đánh giá từng câu chuyện của người dùng và các thử nghiệm đã tạo, sau đó quyết định bộ hoặc danh mục hoặc danh mục nào sẽ thuộc các thử nghiệm cho câu chuyện của người dùng. Có thể một câu chuyện của người dùng sẽ yêu cầu thêm, cập nhật và xóa các thử nghiệm cùng một lúc.

• Thêm thử nghiệm – Nếu chức năng chính được giới thiệu, các thử nghiệm được tạo cho thử nghiệm chạy nước rút sẽ được thêm vào bộ hồi quy. Điều này có thể bao gồm cả việc thêm bài kiểm tra vào bài kiểm tra khói hoặc độ tỉnh táo. Trường hợp thử nghiệm được thêm vào sẽ được xác định bởi tầm quan trọng của chức năng hoặc tính năng. Nếu đó là một tính năng cấp cao mà phần lớn người dùng sẽ sử dụng, thì nó nên được thêm vào cả hồi quy vàKhói/kiểm tra sự tỉnh táo. Việc thêm kiểm tra thường được thực hiện theo mặc định, điều này sẽ gây ra các vấn đề tôi đã đề cập ở trên. Hãy chắc chắn rằng bài kiểm tra là bài kiểm tra nên được thêm vào hồi quy để tránh trùng lặp. Điều này dẫn chúng ta đến tùy chọn tiếp theo; cập nhật các bài kiểm tra.
• Cập nhật kiểm tra – Trong trường hợp quy trình công việc được cập nhật nhưng, chẳng hạn như không có thay đổi đáng kể nào đối với chức năng, thì không cần thiết phải tạo kiểm tra mới. Chỉ cần chỉnh sửa các thử nghiệm để phù hợp với quy trình công việc mới là đủ và trong trường hợp này, các thử nghiệm cho chức năng này trong bộ hồi quy sẽ được đưa vào chạy nước rút và cập nhật để phù hợp với quy trình hoặc hành vi mới. Nếu tác giả ca kiểm thử chỉ đơn giản là viết một ca kiểm thử mới thay vì cập nhật ca kiểm thử trước đó, thì bạn có một ca kiểm thử trùng lặp/lỗi thời trong hồi quy. Nếu điều này xảy ra lặp đi lặp lại, bạn đột nhiên cảm thấy đau đầu khi bắt đầu kiểm thử hồi quy. Hãy nhớ cập nhật trường hợp thử nghiệm hiện có trước khi kéo nó vào giai đoạn nước rútkế hoạch kiểm travà thử nghiệm ban đầu phải được cập nhật tại nguồn và sau đó được đưa vào chạy nước rút.
• Xóa bài kiểm tra– Một số câu chuyện của người dùng chỉ yêu cầu xóa một tính năng không còn được sử dụng. Điều này có thể là do nhà cung cấp đã bị xóa và nội dung đã được thử nghiệm trước đó không còn phù hợp nữa. Khi nói đến việc cập nhật các trường hợp thử nghiệm, việc loại bỏ các chi tiết không cần thiết cũng quan trọng như việc thêm các chi tiết mới có liên quan. Nếu một người thử nghiệm mới được thuê, họ sẽ không có kiến ​​thức trước đó về lịch sử của sản phẩm. Khi người kiểm tra được chỉ định một tập hợp các trường hợp kiểm tra hồi quy đã lỗi thời, họ sẽ nhập các lỗi không hợp lệ. Điều này làm lãng phí thời gian của người thử nghiệm nhập chúng, nhóm sản phẩm đọc và nhận xét về chúng cũng như người thử nghiệm cấp cao phải thông báo lý do khiến lỗi không hợp lệ. Một lỗi không hợp lệ biến thành một sự lãng phí tài nguyên không cần thiết. Tất cả đều có thể tránh được bằng cách loại bỏ test case khi nó không còn hiệu lực.
• Không làm gì cả – Các câu chuyện của người dùng chỉ cần điều chỉnh hình ảnh, bảng màu hoặc văn bản sẽ có các trường hợp thử nghiệm được tạo trong thử nghiệm nước rút. Những thử nghiệm này không thuộc về bộ hồi quy. Chúng là các thử nghiệm hợp lệ và có thể cần được thực thi mỗi khi phần mềm được triển khai sang một môi trường mới, nhưng sau đó chúng nên được đặt sang một bên. Các phần tử thay đổi thường xuyên và rất khó có thể được chạm vào trừ khi một câu chuyện người dùng khác được tạo, không hữu ích trong thử nghiệm hồi quy hoặc thử nghiệm khói/tinh thần. Trong trường hợp này, sau khi hoàn thành chạy nước rút và thay đổi đang được sản xuất, hãy để các thử nghiệm này trong thư mục chạy nước rút cho các mục đích lịch sử.

Phần kết luận

Chìa khóa để có kho lưu trữ trường hợp thử nghiệm cập nhật là tính chủ động. Cập nhật nó thường xuyên khi các câu chuyện của người dùng được giải quyết. Với kho lưu trữ trường hợp thử nghiệm được sắp xếp hợp lý, người thử nghiệm có thể dễ dàng được thêm vào dự án. Bạn đã bao giờ muốn mời một người thử nghiệm từ một dự án khác nhưng không muốn dành thời gian đào tạo họ chưa? Các trường hợp thử nghiệm cập nhật sẽ đào tạo cho bạn. Chỉ định một thành viên mới trong nhóm cho một tập hợp các trường hợp thử nghiệm hợp lệ và họ sẽ biết sản phẩm ngay lập tức. Mặt khác, nếu bạn chỉ định nhầm một thành viên mới cho các trường hợp thử nghiệm lỗi thời với kết quả không như mong đợi, sẽ không có gì ngoài sự nhầm lẫn và lãng phí thời gian. Khi nói đến các trường hợp thử nghiệm, một công việc nhỏ trong mỗi lần chạy nước rút sẽ giúp tiết kiệm rất nhiều công việc trong tương lai.