1. Học cách phân tích thông qua kết quả test của bạn. Đừng phớt lờ các kết quả test. Kết quả test cuối cùng có thể "pass" hoặc "fail" nhưng việc giải quyết sự cố về nguyên nhân chính của kết quả "fail" sẽ chỉ bạn cách giải quyết vấn đề. Tester sẽ được chú ý nếu họ không chỉ giải thích những thiếu sót mà cũng nên cung cấp các giải pháp cho vấn đề đó (Cái này mà các đại ka lập trình nghĩ Tester tài lanh thì chết là cái chắc-khổ thiệt).
2. Hiểu hết toàn bộ mức độ test vào mỗi lần test bất kỳ ứng dụng nào. Cho dù 100% kiểm tra hoàn toàn có thể không còn khả năng thực hiện tiếp nhưng bạn luôn luôn cố gắng với tới nó.
3. Đảm bảo toàn bộ ứng dụng đang test được chia ra thành các module nhỏ hơn có thể chạy được. Viết test case cho từng modul riêng biệt. Cũng như nếu có thể chia hoàn toàn các modul này ra các phần nhỏ hơn.
4. Trong khi viết test case, đầu tiên là viết các test case của các chức năng được dự tính trước ứng với các điều kiện hợp lệ của các yêu cầu. Sau đó mới viết các test case cho các kiều kiện không hợp lệ. Điều này sẽ bao hàm hết các hành vi được mong đợi cũng như không mong đợi của ứng dụng trong khi test.
5. Suy nghĩ chắc chắn. Bắt đầu test ứng dụng với dự định tìm ra các thiếu sót, lỗi. Đừng nghĩ trước rằng sẽ không có bất kỳ thiếu sót nào trong ứng dụng. Nếu bạn kiểm tra ứng dụng với ý định tìm ra lỗi bạn cũng sẽ tiếp tục tìm ra các thiếu sót khó thấy khác.
6. Viết các test case trong giai đoạn phân tích và thiết kế yêu cầu. Theo cách này bạn có thể đảm bảo tất cả các yêu cầu đều có thể được test.
7. Tạo sẵn test case và chuyển đến người phát triển trong khi code. Đừng giữ test case cùng với việc đợi đến khi có ứng dụng cuối cùng rồi mới đưa ra kiểm vì nghĩ rằng bạn có thể đưa ra nhiều lỗi hơn. Hãy đưa cho người phát triển phân tích test case kỹ lưỡng để phát triển trên chất lượng ứng dụng. Điều này cũng sẽ tiết kiệm được nhiều thời gian.
8. Nếu có thể đồng nhất và gom nhóm các test case của bạn cho việc test hồi quy. Điều này sẽ đảm bảo việc test hồi quy bằng thủ công nhanh và hiệu quả.
9. Về thời gian trả lời điều kiện mà các ứng dụng đạt được nên được test hoàn toàn bằng hiệu suất. Test hiệu suất là phần quyết định của các ứng dụng. Đối với việc test thủ công điều này hầu như bị bỏ qua bởi các tester thiếu dung lượng dữ liệu rộng lớn được yêu cầu trong khi test hiệu suất. Nên tìm hết các hướng để test hiệu suất cho ứng dụng của bạn. Nếu không thể tạo dữ liệu test thủ công thì nên viết một vài scrips cơ bản để tạo dữ liệu test cho test hiệu suất hoặc hỏi người lập trình để viết giúp.
10. Những người lập trình không nên test trên chính mã viết của ứng dụng. Tiêu chuẩn Test unit của ứng dụng nên đầy đủ từ người phát triển trước khi chuyển ứng dụng cho các Tester. Nhưng các tester không nên tạo áp lực cho các lập trình viên về việc chuyển sản phẩm cho test. Để họ có thời gian. Người hướng dẫn Test biết khi nào module được chuyển cho test và họ hẳn nhiên có thể ước lượng được thời gian test.
11. Về việc test yêu cầu. Kiểm tra ứng dụng cái gì nó cần làm và không được làm.
12. Trong khi test hồi quy sử dụng các phần tìm lỗi đã có trước (số lỗi được tìm thấy dựa vào các modul khác). Phần lỗi trong module đã được kiểm tra rồi có thể có lợi để dự đoán trước hầu hết các phần lỗi có thể xảy ra của ứng dụng.
13. Ghi lại các điều kiện mới, các cơ sở biết được trong khi test. Giữ các file trong khi test các ứng dụng. Ghi ra các tiến trình test, quan sát kỹ càng nó. Sử dụng các cách quan sát này khi chuẩn bị cho báo cáo hoàn tất test. Thói quen tốt này sẽ giúp cung cấp chi tiết các báo cáo hoàn tất test hoàn toàn rõ ràng.
14. Nhiều lần các tester hoặc người phát triển thay đổi chuẩn mực cơ bản trong ứng dụng đang test. Đây là bước yêu cầu trong môi trường phát triển hoặc trong môi trường test để tránh trường hợp xử lý riêng lẻ như các dự án của ngân hàng. Ghi lại các code thay đổi cho mục đích test và lúc hoàn tất cuối cùng phải chắc rằng bạn đã hoàn tất tất cả các điều thay đổi này từ tài liệu triển khai bên phía khách hàng.
15. Đừng để người phát triển tiếp cận trong môi trường test. Phần yêu cầu này là để tìm ra bất kỳ lỗi khó thấy nào bị thay đổi từ tài liệu hoặc từ môi trường triển khai. Vài lần người phát triển thay đổi một vài hệ thống hoặc cấu hình ứng dụng nhưng quên đề cập điều này trong các bước triển khai. Họ sẽ không ngẫu nhiên mà biến đổi tình hình trong môi trường test và những lỗi khó tìm thấy có thể được bắt ngay.
16. Một cách tốt để đánh giá người tester giỏi từ các cụm yêu cầu và thiết kế phần mềm. Điều này có được là từ việc các tester có thể lấy kiến thức đáng tin cậy về kết quả của ứng dụng trong việc bao quá hết được chi tiết test. Nếu bạn đang không được yêu cầu về phần chu kỳ phát triển này thì hãy yêu cầu người hướng dẫn bạn hoặc người quản lý đáp ứng cho nhóm test của bạn bằng các cuộc họp hoặc tiến trình giải quyết.
17. Nhóm test nên chia sẻ các kinh nghiệm test với các nhóm khác trong một tổ chức.
18. Tăng cường thêm các cuộc nói chuyện của bạn với người phát triển để biết nhiều hơn về sản phẩm. Bất cứ lúc nào có thể giao tiếp trực tiếp cho dù có các cuộc tranh luận để giải quyết nhanh và để tránh bất kỳ các sự hiểu nhầm. Nhưng mặc dù khi bạn đã hiểu hết các yêu cầu và các cách giải quyết từ bất kỳ các cuộc tranh luận nào cũng nên chắc rằng cuộc giao tiếp như trên được viết ra và chuyển bằng mail. Đừng giữ bất kỳ thứ gì bằng lời nói.
19. Đừng làm công việc khi không có thời gian hoặc bên ngoài kế hoạch. Ưu tiên công việc test của bạn từ cao đến thấp và phù hợp với kế hoạch công việc của bạn. Phân tích tất cả các rủi ro liên quan đến độ ưu tiên làm việc của bạn.
20. Viết toàn bộ, mô tả, báo cáo lỗi rõ ràng. Đừng chỉ cung cấp các lỗi xấu tìm được mà cũng phải cung cấp các tác động của lỗi và tất cả các giải pháp có thể. Đừng quên việc test là một công việc sáng tạo và thử thách. cuối cùng nó phụ thuộc vào kỹ năng và kinh nghiệm của bạn, vậy bạn vận dụng sự thử thách này như thế nào.
2. Hiểu hết toàn bộ mức độ test vào mỗi lần test bất kỳ ứng dụng nào. Cho dù 100% kiểm tra hoàn toàn có thể không còn khả năng thực hiện tiếp nhưng bạn luôn luôn cố gắng với tới nó.
3. Đảm bảo toàn bộ ứng dụng đang test được chia ra thành các module nhỏ hơn có thể chạy được. Viết test case cho từng modul riêng biệt. Cũng như nếu có thể chia hoàn toàn các modul này ra các phần nhỏ hơn.
4. Trong khi viết test case, đầu tiên là viết các test case của các chức năng được dự tính trước ứng với các điều kiện hợp lệ của các yêu cầu. Sau đó mới viết các test case cho các kiều kiện không hợp lệ. Điều này sẽ bao hàm hết các hành vi được mong đợi cũng như không mong đợi của ứng dụng trong khi test.
5. Suy nghĩ chắc chắn. Bắt đầu test ứng dụng với dự định tìm ra các thiếu sót, lỗi. Đừng nghĩ trước rằng sẽ không có bất kỳ thiếu sót nào trong ứng dụng. Nếu bạn kiểm tra ứng dụng với ý định tìm ra lỗi bạn cũng sẽ tiếp tục tìm ra các thiếu sót khó thấy khác.
6. Viết các test case trong giai đoạn phân tích và thiết kế yêu cầu. Theo cách này bạn có thể đảm bảo tất cả các yêu cầu đều có thể được test.
7. Tạo sẵn test case và chuyển đến người phát triển trong khi code. Đừng giữ test case cùng với việc đợi đến khi có ứng dụng cuối cùng rồi mới đưa ra kiểm vì nghĩ rằng bạn có thể đưa ra nhiều lỗi hơn. Hãy đưa cho người phát triển phân tích test case kỹ lưỡng để phát triển trên chất lượng ứng dụng. Điều này cũng sẽ tiết kiệm được nhiều thời gian.
8. Nếu có thể đồng nhất và gom nhóm các test case của bạn cho việc test hồi quy. Điều này sẽ đảm bảo việc test hồi quy bằng thủ công nhanh và hiệu quả.
9. Về thời gian trả lời điều kiện mà các ứng dụng đạt được nên được test hoàn toàn bằng hiệu suất. Test hiệu suất là phần quyết định của các ứng dụng. Đối với việc test thủ công điều này hầu như bị bỏ qua bởi các tester thiếu dung lượng dữ liệu rộng lớn được yêu cầu trong khi test hiệu suất. Nên tìm hết các hướng để test hiệu suất cho ứng dụng của bạn. Nếu không thể tạo dữ liệu test thủ công thì nên viết một vài scrips cơ bản để tạo dữ liệu test cho test hiệu suất hoặc hỏi người lập trình để viết giúp.
10. Những người lập trình không nên test trên chính mã viết của ứng dụng. Tiêu chuẩn Test unit của ứng dụng nên đầy đủ từ người phát triển trước khi chuyển ứng dụng cho các Tester. Nhưng các tester không nên tạo áp lực cho các lập trình viên về việc chuyển sản phẩm cho test. Để họ có thời gian. Người hướng dẫn Test biết khi nào module được chuyển cho test và họ hẳn nhiên có thể ước lượng được thời gian test.
11. Về việc test yêu cầu. Kiểm tra ứng dụng cái gì nó cần làm và không được làm.
12. Trong khi test hồi quy sử dụng các phần tìm lỗi đã có trước (số lỗi được tìm thấy dựa vào các modul khác). Phần lỗi trong module đã được kiểm tra rồi có thể có lợi để dự đoán trước hầu hết các phần lỗi có thể xảy ra của ứng dụng.
13. Ghi lại các điều kiện mới, các cơ sở biết được trong khi test. Giữ các file trong khi test các ứng dụng. Ghi ra các tiến trình test, quan sát kỹ càng nó. Sử dụng các cách quan sát này khi chuẩn bị cho báo cáo hoàn tất test. Thói quen tốt này sẽ giúp cung cấp chi tiết các báo cáo hoàn tất test hoàn toàn rõ ràng.
14. Nhiều lần các tester hoặc người phát triển thay đổi chuẩn mực cơ bản trong ứng dụng đang test. Đây là bước yêu cầu trong môi trường phát triển hoặc trong môi trường test để tránh trường hợp xử lý riêng lẻ như các dự án của ngân hàng. Ghi lại các code thay đổi cho mục đích test và lúc hoàn tất cuối cùng phải chắc rằng bạn đã hoàn tất tất cả các điều thay đổi này từ tài liệu triển khai bên phía khách hàng.
15. Đừng để người phát triển tiếp cận trong môi trường test. Phần yêu cầu này là để tìm ra bất kỳ lỗi khó thấy nào bị thay đổi từ tài liệu hoặc từ môi trường triển khai. Vài lần người phát triển thay đổi một vài hệ thống hoặc cấu hình ứng dụng nhưng quên đề cập điều này trong các bước triển khai. Họ sẽ không ngẫu nhiên mà biến đổi tình hình trong môi trường test và những lỗi khó tìm thấy có thể được bắt ngay.
16. Một cách tốt để đánh giá người tester giỏi từ các cụm yêu cầu và thiết kế phần mềm. Điều này có được là từ việc các tester có thể lấy kiến thức đáng tin cậy về kết quả của ứng dụng trong việc bao quá hết được chi tiết test. Nếu bạn đang không được yêu cầu về phần chu kỳ phát triển này thì hãy yêu cầu người hướng dẫn bạn hoặc người quản lý đáp ứng cho nhóm test của bạn bằng các cuộc họp hoặc tiến trình giải quyết.
17. Nhóm test nên chia sẻ các kinh nghiệm test với các nhóm khác trong một tổ chức.
18. Tăng cường thêm các cuộc nói chuyện của bạn với người phát triển để biết nhiều hơn về sản phẩm. Bất cứ lúc nào có thể giao tiếp trực tiếp cho dù có các cuộc tranh luận để giải quyết nhanh và để tránh bất kỳ các sự hiểu nhầm. Nhưng mặc dù khi bạn đã hiểu hết các yêu cầu và các cách giải quyết từ bất kỳ các cuộc tranh luận nào cũng nên chắc rằng cuộc giao tiếp như trên được viết ra và chuyển bằng mail. Đừng giữ bất kỳ thứ gì bằng lời nói.
19. Đừng làm công việc khi không có thời gian hoặc bên ngoài kế hoạch. Ưu tiên công việc test của bạn từ cao đến thấp và phù hợp với kế hoạch công việc của bạn. Phân tích tất cả các rủi ro liên quan đến độ ưu tiên làm việc của bạn.
20. Viết toàn bộ, mô tả, báo cáo lỗi rõ ràng. Đừng chỉ cung cấp các lỗi xấu tìm được mà cũng phải cung cấp các tác động của lỗi và tất cả các giải pháp có thể. Đừng quên việc test là một công việc sáng tạo và thử thách. cuối cùng nó phụ thuộc vào kỹ năng và kinh nghiệm của bạn, vậy bạn vận dụng sự thử thách này như thế nào.
Nhận xét