Đã đăng vào thg 10 25, 2017 8:25 SA 10 phút đọc

233

Practical software testing tips

Bài đăng này đã không được cập nhật trong 3 năm

Trong bài viết này tôi xin phép được nêu ra một số chú ý dành cho một QA để bạn có thể đảm bảo được chất lượng sản phẩm được tốt hơn. Bạn nên cố gắng thực hiện chúng trong công việc hàng ngày, thực hiện nó như một thói quen.

1. Phân tích kết quả test

Tìm hiểu, học để phân tích kết quả test một cách triệt để. Không được bỏ qua kết quả test. Kết quả cuối cùng có thể là “pass” hoặc “ fail” nhưng quan trọng là có giải pháp cho các vấn đề, sự cố gây ra “fail”. Còn gì tốt hơn là việc bạn tìm ra lỗi, biết nguyên nhân lỗi và đưa ra được giải pháp triệt để cho các vấn đề đó.

2. Test coverage

Tìm hiểu và học để có thể thực hiện test coverage trong phạm vi lớn nhất có thể mỗi khi bạn thực hiện test bất kỳ ứng dụng nào. Mặc dù phạm vi 100% là không thể nhưng bạn vẫn có thể tiệm cận tới gần hết mức có thể.

3. Chia nhỏ chức năng

Để đảm bảo được phạm vi kiểm tra là tối đa thì bạn có thể chia nhỏ ứng dụng thành các module chức năng nhỏ hơn. Nếu module vấn lớn thì bạn vẫn có thể chia nhỏ ra nữa. Sau đó bạn hãy viết test case cho những phần đã được chia nhỏ này.

4. Thứ tự viết test case

Một cách viết test case để không bị sót đó là chúng ta nên viết các trường hợp hợp lệ trước, sau đó mới đến các trường hợp không hợp lệ. Điều này sẽ giúp bạn đảm bảo hết các trường hợp normal và abnormal của chức năng, ứng dụng đang được test.

5. Luôn nghĩ rằng: bất kỳ ứng dụng nào cũng sẽ có lỗi

Không được nghĩ rằng không có bất kỳ lỗi nào trong phần mềm. Nếu bạn hướng tới việc tìm lỗi thì chắc chắn bạn sẽ tìm được lỗi.

6. Thời điểm tham gia dự án lý tưởng

Nếu tester tham gia dự án ngay từ lúc có yêu cầu và giai đoạn thiết kế thì tốt. Vì họ có thể sẽ có hiểu biết sâu hơn, chi tiết hơn về phần mềm. Nếu bạn không được yêu cầu tham gia từ đầu thì bạn có thể đưa ra yêu cầu tham gia với cấp trên để được tham gia vào các cuộc họp này.

7. Thời điểm viết test case

Nên viết test case trong quá trình phân tích tài liệu và giai đoạn thiết kế. Bằng các này bạn có thể kiểm chứng được cả yêu cầu.

8. Gửi Deverloper test case của QA

Nếu có thể thì bạn có thể tạo test case của bạn rùi gửi cho DEV trước khi việc code bắt đầu. Không nên giữ chúng đến khi chức năng được hoàn thành rùi mới test để có thể tìm được nhiều lỗi hơn. Nếu DEV được dự báo các trường hợp kiểm thử thì DEV sẽ tạo ra sản phẩm chất lượng hơn, và khi bạn thực hiện test thì thời gian test của bạn cũng sẽ được giảm đi đáng kể

9. Regression testing

Nếu có thể hãy xác định và nhóm các test case lại, rùi thực hiện regression testing. Điều này sẽ giúp cho việc kiểm thử hồi quy thủ công nhanh và hiểu quả hơn.

10. Performance testing

Performance testing là rất quan trọng với một số ứng dụng, đặc biệt là ứng dụng yêu cầu thời gian phản hồi nhanh.
Khi test thủ công muốn kiểm tra hiểu suất thường tester cần tạo khối lượng dữ liệu lớn nên phần này thường hay bị bỏ qua. Nhưng tôi khuyên bạn nếu việc tạo dữ liệu lớn tốn thời gian và công sức, không thể hoàn thành bằng tay thì có thể nhờ sự trợ giúp của DEV để tạo dữ liệu lớn cho bạn test.

11. Unit testing

Tester chỉ kiểm thử phần mềm, còn code thì phải do chính DEV kiểm tra lại những dòng code của chính họ. Unit testing là một phần mà DEV cần phải đảm bảo và thực hiện chúng. Nếu DEV chưa thực hiện unit testing thì chúng ta không nên bỏ qua vì nghĩ rằng còn tester. => Hãy để họ tự kiểm tra và tìm lỗi trên những dòng code của họ.

12. Kiểm thử bên ngoài yêu cầu

Thực hiện kiểm tra cả những việc mà không nằm trong yêu cầu của chức năng. Rất nhiều lỗi ảnh hưởng được tìm ra khi bạn thực hiện kiểm thử này

13. Biểu đồ lỗi

Khi thực hiện regression testing thì bạn nên sử dụng biểu đồ lỗi trước đó để dự đoán được phần lỗi có thể xảy ra nhất của chức năng đó.

14. Lưu lại kinh nghiệm

Note lại các thuật ngữ mới, khái niệm mới mà bạn học được trong khi thực hiện test. Hay note lại tiến độ, trạng thái hay vấn đề trong khi bạn test. Điều này sẽ tạo 1 thói quen tốt cho bạn, và sẽ giúp ích cho bạn trong quá trình báo cáo, cũng như quản lý tiến độ rất tốt.

15. Đảm bảo môi trường test ổn định

Trong khi kiểm tra có thể gặp trường hợp thay đổi base code của ứng dụng. Lúc này cần thực hiện các bước giữ lại tất cả các thay đổi dùng cho việc test. Sau đó ở bản cuối cùng release cho khách hàng sử dụng thì bạn phải đảm bảo chắc chắn đã xóa tất cả những thay đổi này khỏi phiên bản này.

16. Giữ môi trường test là thuộc quyền của QA

Không để DEV làm việc trên môi trường test. Đây là môi trường test nên việc này là cần thiết để phát hiện bất kỳ thay đổi nào trong quá trình chỉnh sửa, thêm mới chức năng. Hoặc bạn không cần lo rằng có người động tới dữ liệu test của bạn. Nếu họ không được quyền vào môi trường test thì sẽ không thể vô tình thực hiện thay đổi bất kỳ nào trên môi trường này.

17. Test team

Các đội test nên chia sẻ các kinh nghiệm test thực tiễn giúp ích cho quá trình kiểm thử của các đội khác trong cùng 1 công ty. Biết chia sẻ và học hỏi kinh nghiệm, kỹ năng này.

18. Team work

Thực hiệc cuộc nói chuyện trực tiếp với DEV để biết nhiều hơn về sản phẩm. Nếu có thể thì hãy giải quyết mâu thuẫn bằng cách trực tiếp một cách nhanh chóng, tránh gây hiểu lầm bằng lời nói. Và khi trực tiếp giải quyết xong bạn cần phải note lại cách giải quyết lại một cách rõ ràng. Không nên dừng lại ở việc giải quyết bằng miệng.

19. Priority - Độ ưu tiên

Không dành thời gian cho việc kiểm thử những task có độ ưu tiên cao. Bạn nên sắp xếp công việc sao cho phù hợp với độ ưu tiên từ cao đến thấp. Phân tích các rủi ro để có thẻ đánh giá độ ưu tiên sao cho chính xác.

20. Report bug

Học cách mô tả lỗi rõ ràng, rành mạch. Không chỉ có triệu chứng lỗi mà cần có các bước khiến cho chức năng bị lỗi, mong muốn chức năng như thế nào. Tuy bạn không phải là người giải quyết nhưng nếu bạn có thể đưa ra giải pháp thì điều có thật tuyệt. Tất nhiên điều này còn phụ thuộc vào kỹ năng và kinh nghiệm của bạn.

Cùng tôi chia sẻ những kinh nghiệm test để giúp cho công việc của QA ngày một tốt hơn nhé.

Nguồn : http://www.softwaretestinghelp.com/practical-software-testing-tips-to-test-any-application/

Software Testing