Một số điểm không nên viết trong Test case

Viết các trường hợp kiểm thử hoàn hảo và bao gồm tất cả các mục kiểm thử cần thiết sẽ xây dựng được lòng tin với khách hàng , nhưng viết như thế nào , cần tránh những điểm gì để test case được tốt hơn là điều tất cả người kiểm thử cần quan tâm. Vì vậy trong bài viết này mình sẽ giới thiệu một vài điểm không nên viết trong khi tạo test case.

1. Không viết một Test Case bao gồm nhiều hơn một chức năng nhỏ độc lập

Nhiều người kiểm thử cảm thấy không thích hợp để viết nhiều trường hợp kiểm thử, thay vào đó họ viết vài chi tiết cho một yêu cầu trong một trường hợp kiểm thử và sẽ tiết kiệm rất nhiều công sức.

Họ không nhận ra tại thời điểm đó bằng cách làm này, họ đang gia tăng việc kiểm thử. Bởi vì trong khi kiểm tra hồi quy,người kiểm thử sẽ phải lựa chọn trường hợp kiểm thử và thực hiện tất cả các chức năng nhỏ ngay cả khi các bug không ảnh hưởng đến bất kỳ khu vực nào. Điều này sẽ giảm những nỗ lực không cần thiết mà có thể tránh được bằng cách chia nhỏ yêu cầu thành các đơn vị có thể kiểm thử độc lập.

2. Không ăn cắp các bước

Trong khi viết các trường hợp kiểm thử, nhiều người kiểm thử đã ăn cắp các bước cái mà họ coi là quá rõ ràng để viết, đặc biệt những bước đầu, nơi người dùng được đưa đến màn hình có liên quan khi bắt đầu ứng dụng.

Với những người kiểm thử mới bắt đầu vào dự án khi họ kiểm thử lại các lỗi được sửa hoặc thực hiện kiểm thử hồi quy. Họ sẽ khó biết được cách đi đến màn hình cụ thể.

3. Không chỉ viết Test Cases đối với các kịch bản đúng

Trong kiểm thử một ứng dụng ở giai đoạn nào, nên có đủ số lượng các trường hợp kiểm thử tiêu cực.

Điều này sẽ chứng minh rằng ứng dụng làm việc như mong đợi.

Các trường hợp kiểm thử tiêu cực là những hành vi được theo dõi và kiểm tra ok khi người dùng nhập vào các giá trị mà ứng dụng không bao giờ mong đợi hoặc không được thực hiện.

4. Không viết các bước kiểm thử bằng ngôn ngữ khó hiểu và dể hiểu lầm cho người kiểm thử khác

Viết các trường hợp kiểm thử bằng ngôn ngữ đơn giản và trong sáng nhất. Sử dụng ngôn ngữ khó hiểu sẽ gây khó khắn cho người kiểm thử khác.

5. Không sử dụng giọng bị động

Sử dụng giọng chủ động 'Làm điều này' hoặc 'chạy lệnh xyz' được đề nghị trong khi viết một trường hợp kiểm thử.

6. Không nhập nhằng trong khi viết các Test case

Một trong những yếu tố phân biệt một trường hợp kiểm thử tốt là sử dụng tên công việc, vị trí tập tin chính xác vv.. Nếu người kiểm thử sử dụng các thuộc tính chính xác thì ngay cả một người mới cũng có thể thực hiện nó mà không cần bất kỳ sự giúp đỡ.

7. Không bao gồm các bước không cần thiết

Nếu một trường hợp kiểm thử có thể được hoàn thành trong hai bước. Nhưng người kiểm thử không nghĩ rằng nó sẽ làm giảm sự phức tạp của các trường hợp kiểm thử nghiệm và tự bổ sung các bước phù hợp hơn.

8. Đừng viết các trường hợp kiểm thử không thể được tái sử dụng

9. Không viết các trường hợp kiểm thử không thể truy xuất nguồn gốc

Truy xuất nguồn gốc là một trách nhiệm rất lớn đối với nhóm kiểm thử. Không ai giúp bạn trong việc lựa chọn các trường hợp kiểm thử cần được thực hiện xung quanh việc sửa chữa một lỗi.

Truy xuất nguồn gốc là một bản đồ rất dễ dàng để các trường hợp kiểm thử quay lại các yêu cầu.

Một số công cụ quản lý kiểm thử việc lập bản đồ này có thể được thực hiện mặc định. Có thể phải tự thiết lập truy xuất nguồn gốc, trong trường hợp, không sử dụng bất kỳ công cụ quản lý kiểm thử nào, một bảng tính excel đơn giản có thể được sử dụng để thiết lập truy xuất nguồn gốc.

10. Không viết các trường hợp kiểm thử không có bất kỳ tiêu điểm nào

Một bản tóm tắt các trường hợp kiểm thử nên nói với những người kiểm thử những gì được dự định trong các kiểm thử.Người kiểm thử nên viết bản tóm tắt các trường hợp kiểm thử dựa trên mục đích kiểm thử. Ví dụ một test case để kiểm thử việc đăng nhập đúng không nên có một bản tóm tắt các trường hợp kiểm thử như "Để kiểm tra chức năng đăng nhập của ứng dụng xyz '. Đồng ý rằng mục đích chính là để kiểm tra chức năng đăng nhập và bản tóm tắt các trường hợp kiểm thử nên ngắn gọn. Nhưng, chỉ viết kiểm thử chức năng đăng nhập của xyz sẽ là quá chung chung. Có thể có nhiều vai trò của người sử dụng đăng nhập vào ứng dụng. Có thể có các loại khác nhau đăng nhập vào ứng dụng. Ví dụ. trong một ứng dụng Ecom có màn hình đăng nhập riêng cho các khách hàng tiềm năng, người quản trị và những người bán hàng cần truy cập vào đăng ký sản phẩm của họ, theo dõi cổ phiếu. Vì vậy,bản tóm tắt các trường hợp kiểm thử nên được viêt ' Để xác minh đăng nhập cho một khách hàng trong ứng dụng xyz 'hoặc' Để xác minh đăng nhập của một người bán trong ứng dụng xyz '.

11. Không viết các trường hợp kiểm thử không thể bảo trì

Xem xét một kịch bản mà các yêu cầu thay đổi sau khi hoàn thành viết các trường hợp kiểm thử. Người kiểm thử nên có thể dễ dàng sửa đổi các trường hợp kiểm thử ảnh hưởng. Các yêu cầu thay đổi có thể sẽ có những điều kiện bị ảnh hưởng và người kiểm thử nên theo dõi lại các yêu cầu với các trường hợp kiểm thử.

12. Không chỉ viết các trường hợp kiểm thử, suy nghĩ nếu có bất kỳ yêu cầu nào đối với việc thực hiện

Test case thường được viết trong giai đoạn đầu khi ứng dụng vẫn chưa sẵn sàng và người kiểm thử có tài liệu đặc tả chức năng.

Nhiều đội kiểm thử chỉ viết các trường hợp kiểm thử một cách mù quáng chỉ tìm thấy tại thời điểm thực hiện, các dữ liệu kiểm thử có liên quan làm test case không tồn tại trong hệ thống và cần được tạo mới ra. Để tránh lộn xộn này, khuyến khích nhóm kiểm thử dựa trên các khía cạnh thực tế và những dữ liệu / điều kiện sẽ được yêu cầu để chạy test case trong khi thực hiện.

13. Không chỉ tạo bộ kiểm thử mà nên tạo phiên bản và đánh dấu chỗ thay đổi

Cần phiên bản của bộ kiểm thử và đường cơ sở cho một phiên bản của ứng dụng được kiểm thử. Thay đổi là hằng số duy nhất. Ngày mai trong trường hợp ứng dụng của bạn phải trải qua bất kỳ thay đổi nào, dù lớn hay nhỏ, thay vì cập nhật bộ kiểm thử, cập nhật phiên bản và lấy đường cơ sở cho phiên bản của ứng dụng. Giữ tất cả các phiên bản test case trước.

Kết luận : Viết test case là công việc thường ngày của một người kiểm thử, để viết test case hiệu quả , đáp ứng được mong đợi của khách hàng các bạn hãy lưu ý các điểm trên nhé . Hy vọng qua bài viết này các bạn có thể viết test case tốt hơn .

Link tham khảo http://www.softwaretestingclass.com/how-not-to-write-test-cases/