Top 20 mẹo thực tế kiểm thử phần mềm, bạn nên đọc trước khi kiểm thử các ứng dụng

Tất cả các nhân viên kiểm thử nên đọc những phần mềm kiểm thử nghiệm thực tiễn tốt. Đọc tất cả các điểm cẩn thận và cố triển khai chúng trong hoạt động kiểm thử hàng ngày của bạn. Đây là những gì tôi mong đợi từ bài viết này. Nếu bạn không hiểu cách thực hiện bất cứ kiểm thử nào, yêu cầu làm rõ hơn trong các ý kiến dưới đây. Sau khi tất cả các bạn sẽ tìm hiểu tất cả những kiểm thử thực tiễn bằng kinh nghiệm. Nhưng sau đó tại sao lại không tìm hiểu tất cả những điều này trước khi phạm sai lầm?

Dưới đây là một số hoạt động thử nghiệm tốt nhất mà tôi học được bằng kinh nghiệm:

1) Tìm hiểu để phân tích kết quả kiểm tra một cách kỹ lưỡng. Đừng lờ đi kết quả kiểm tra. Kết quả kiểm tra cuối cùng có thể “Pass” hoặc “Fail” nhưng xử lý sự cố là nguyên nhân gốc rễ của “Fail” sẽ đưa bạn đến các giải pháp của vấn đề. Kiểm thử viên sẽ được tôn trọng nếu họ không chỉ ghi lại những lỗi mà còn cung cấp các giải pháp.

2) Tìm hiểu để tối đa hóa test coverage mỗi khi bạn kiểm tra bất kỳ ứng dụng nào. Mặc dù 100% kiểm thử bao phủ có thể không có khả năng nhưng bạn vẫn có thể luôn luôn cố gắng để đạt đến gần nó.

3) Để đảm bảo mức độ kiểm thử bao phủ tối đa chúng ta phải chia nhỏ ứng dụng đang được kiểm thử (AUT) thành các module chức năng nhỏ hơn. Viết các trường hợp kiểm thử trên từng module đó. Ngoài ra nếu có thể chia nhỏ các module này thành các phần nhỏ hơn. Ví dụ: Cho phép giả sử bạn đã chia ứng dụng trang web của bạn thành các module và “chấp nhận thông tin của người sử dụng” là một trong những module đó. Bạn có thể chia nhỏ màn hình này 'thông tin của người sử dụng thành các phần nhỏ hơn để viết các trường hợp kiểm thử : Các bộ phận như kiểm thử giao diện người dùng (UI), kiểm thử bảo mật, kiểm thử chức năng của của form “User information”, vv… Áp dụng tất cả các loại field và size test, kiểm tra nagiative và validation cho từng trường đầu vào và viết tất cả các trường hợp kiểm thử như vậy cho mức độ bao phủ tối đa.

4) Trong khi viết các trường hợp kiểm thử, viết các trường hợp kiểm thử cho chức năng dự định đầu tiên, có nghĩa cho các điều kiện hợp lệ theo yêu cầu. Sau đó viết các trường hợp các điều kiện hợp lệ. Điều này sẽ cover hành vi được expect cũng như unexpect của ứng đụng đang kiểm thử.

5) Suy nghĩ tích cực. Bắt đầu kiểm thử các ứng dụng với ý định tìm lỗi / sai sót. Đừng nghĩ trước rằng sẽ không có bất kỳ lỗi nào trong ứng dụng. Nếu bạn kiểm tra các ứng dụng bằng cách có ý định tìm kiếm lỗi bạn chắc chắn sẽ thành công để tìm những lỗi rất khó để tìm thấy.

6) Viết các trường hợp kiểm thử của bạn dựa vào việc phân tích các yêu cầu và giai đoạn thiết kế. Bằng cách này bạn có thể đảm bảo tất cả các yêu cầu có thể được kiểm thử.

7) Hãy đảm bảo rằng những test case của bạn đã sẵn sàng để các lập trình viên trước khi code. Đừng giữ các test case với bạn cho đến khi ứng dụng cuối cùng được release cho việc kiểm thử, nghĩ rằng bạn có thể tìm được nhiều lỗi hơn. Hãy để các lập trình viên phân tích các trường hợp kiểm thử kỹ lưỡng để phát triển các ứng dụng có chất lượng hơn. Điều này cũng sẽ tiết kiệm thời gian làm việc.

8) Nếu có thể xác định và nhóm các Test case của bạn lại với nhau để kiểm thử hồi quy. Điều này sẽ đảm bảo kiểm thử hồi quy bằng tay nhanh chóng và hiệu quả.

9) Ứng dụng đòi hỏi thời gian đáp ứng ngay lập tưc thì cần phải được kiểm tra kỹ lưỡng hiệu năng. Kiểm thử hiệu năng là một phần quan trọng của rất nhiều ứng dụng. Trong kiểm thử bằng tay điều này hầu hết được bỏ qua bởi kiểm thử viên bởi vì thiếu yêu cầu kiểm thử hiệu năng lượn dữ liệu lớn. Tìm ra cách để kiểm thử hiệu năng với ứng dụng của bạn. Nếu không thể để tạo ra dữ liệu kiểm thử bằng tay vậy thì bạn có thể viết một số script cơ bản để tạo ra dữ liệu để kiểm thử hiệu năng hoặc có thể nhờ các lập trình viên viết cho bạn.

10) Các lập trình viên không nên kiểm tra code của họ. Như đã thảo luận trong bài viết này : http://www.softwaretestinghelp.com/developers-are-not-good-testers/, các lập trình viên nên có đủ thời gian làm unit test trước khi đưa sản phẩm tới tay. Nhưng tester cũng không nên ép buộc các lập trình viên phải release product để test. Hãy để họ dành thời gian riêng của họ cho việc làm Unit test trước khi đưa sản phẩm cho tester. Mọi người từ lead đến manager đều biết khi nào module / update được phát hành để kiểm thử và họ có thể ước tính thời gian kiểm thử phù hợp. Đây là một tình huống điển hình trong môi trường dự án Agile.

11) Vượt ra ngoài yêu cầu kiểm thử. Ứng dụng kiểm thử cho những gì nó không được chỉ định để làm.

12) Trong khi làm kiểm thử hồi quy sử dụng đồ thị lỗi từ các phase trước (Bug đồ thị - số lỗi được tìm thấy với thời gian cho các module khác nhau). Bug đồ thị này có thể hữu ích để dự đoán một phần lỗi có thể xảy ra của ứng dụng.

**13)**Ghi chép lại đối với các thuật ngữ mới, khái niệm bạn tìm hiểu trong khi tiến hành kiểm thử. Luôn mở một tập tin văn bản trong khi tiến hành kiểm thử một ứng dụng. Ghi chú tiến độ kiểm thử, theo dõi tiến độ. Sử dụng những mẩu giấy ghi nhớ trong khi chuẩn bị báo cáo kiểm tra phiên bản cuối cùng. Thói quen tốt này sẽ giúp bạn cung cấp hoàn toàn rõ ràng báo cáo kiểm thử và chi tiết release.

14) Trong một dự án có rất nhiều lần tester hoặc các lập trình viên thực hiện những thay đổi trong code cơ sở mã cho ứng dụng đang kiểm thử. Điều này được yêu cầu trong quá trình phát triển môi trường kiểm thử để tránh thực hiện các xử lý giao dịch trực tiếp như trong các dự án ngân hàng. Ghi lại tất cả code đã được thay đổi cho mục đích kiểm thử và trong thời điểm release sảm phảm phải chắc chắn rằng bạn đã gỡ bỏ tất cả những thay đổi trong sản phẩm release cuối cùng cho khách hàng.

15) Các lập trình viên tránh xa môi trường test. Đây là bước được yêu cầu để phát hiện bất kỳ sự thiếu sót nào khi thay đổi cấu hình trong tài liệu release hoặc tài liệu triển khai. Một lúc nào đó khi lập trình viên thay đổi một số hệ thống hoặc cấu hình ứng dụng nhưng quên đề cập đến chúng trong các bước triển khai. Nếu lập trình viên không có quyền sử dụng môi trường kiểm thử họ sẽ không vô tình làm bất kỳ thay đổi nào trên đó và những lỗi này có thể được phát hiện ở đúng vị trí.

16) Một thực hành tốt là để tester tham gia ngay từ giai đoạn yêu cầu phần mềm và giai đoạn thiết kế. Những cách này giúp tester có thể có được kiến thức về mức độ tin cậy của ứng dụng kết quả trong phạm vi kiểm tra chi tiết. Nếu bạn không được yêu cầu để trở thành một phần của chu kỳ phát triển này sau đó hãy yêu cầu leader hoặc quản lý của mình để nhóm kiểm thử nghiệm được tham gia vào tất cả quá trình quyết định hay các cuộc họp.

17) Team test nên chia sẻ những thực hành và kinh nghiệm kiểm thử tốt nhất với các nhóm khác trong tổ chức của họ.

18) Tăng cường trao đổi với các lập trình viên để biết thêm chi tiết về sản phẩm. Bất cứ khi nào có thể hãy gặp mặt và giải quyết trưc tiếp để giải quyết những tranh cãi một cách nhanh chóng và để tránh bất cứ hiểu lầm nào. Nhưng cũng có khi bạn hiểu các yêu cầu hoặc giải quyết mọi cuộc tranh luận - hãy chắc chắn rằng có thể có những cách giao tiếp khác thông qua văn bản tương tự như email. Không giữ bất cứ điều gì bằng lời nói.

19) Đừng để bạn không có đủ thời gian để làm những task có độ ưu tiên cao. Mức độ ưu tiên trong công việc kiểm thử là từ cao đến thấp và kế hoạch làm việc cho phù hợp. Phân tích tất cả các rủi ro liên quan đến ưu tiên công việc.

20) Viết, mô tả, báo cáo lỗi rõ ràng rõ ràng. Không chỉ cung cấp cách tái hiện lỗi mà còn phải cung cấp mức độ ảnh hưởng của các lỗi và tất cả các giải pháp có thể.

Lời kết: Chia sẻ kinh nghiệm kiểm thử của riêng bạn, thủ thuật hoặc thử nghiệm bí mật trong ý kiến dưới đây chắc chắn sẽ làm cho bài viết này thú vị hơn và hữu ích !!

Nguồn: viblo