TESTING FUNDAMENTALS
TYPES OF TESTING
TESTCASE DEVELOPMENT
TESTING TECHNIQUES
TEST MANAGEMENT & CONTROL
DEFECTS
AGILE
TESTING DIFFERENT DOMAINS
WHITEBOX TESTING
PERFORMANCE TESTING
ADVANCE TESTING TOPICS
FAQ
TESTING TYPES - MEGA LIST
TOOLS
CHECK!
CERTIFICATION
LIVE TESTING PROJECT
CÁC CHỦ ĐỀ
BÀI MỚI NHẤT
MỚI CẬP NHẬT

10 sai lầm trong kiểm thử phần mềm

Kiểm thử phần mềm (Testing) là một công việc quan trọng và không thể thiếu trong quá trình phát triển phần mềm, đang ngày càng được quan tâm và phát triển tại Việt Nam. Có rất nhiều vấn đề khiến chúng ta hiểu không chính xác về công việc này. Trong bài này viết này, mình sẽ giới thiệu một số suy nghĩ sai lệch phổ biến nhất trong kiểm thử phần mềm mà nhiều người thường mắc phải.

1/ Kiểm thử là tốn kém

Thực tế - Trả ít hơn cho việc kiểm thử trong quá trình phát triển phần mềm hoặc trả nhiều hơn cho việc bảo trì hoặc sửa chữa sau này. Kiểm thử sớm sẽ tiết kiệm cả thời gian và chi phí ở nhiều khía cạnh, tuy nhiên việc giảm chi phí thay vì không thực hiện kiểm thử có thể dẫn đến việc thiết kế phần mềm không đúng yêu cầu, khiến sản phẩm phần mềm trở nên vô ích.

banquyen png
Bài viết này được đăng tại freetuts.net, không được copy dưới mọi hình thức.

2/ Kiểm thử là tốn nhiều thời gian

Thực tế - Trong giai đoạn phát triển phần mềm, kiểm thử không bao giờ là một quá trình tốn thời gian. Viêc đoán lỗi và sửa các lỗi được tìm thấy trong quá trình kiểm thử là một hoạt động tốn thời gian nhưng hiệu quả.

3/ Chỉ khi sản phẩm được phát triển hoàn thiện mới cần kiểm thử

Thực tế - Việc kiểm thử phụ thuộc vào mã nguồn nhưng việc rà soát các yêu cầu và xây dựng các testcase là độc lập với mã nguồn đã được phát triển. Tuy nhiên việc lặp lại hay tiếp cận gia tăng giống như một vòng đời phát triển phần mềm, có thể làm giảm sự phụ thuộc của việc kiểm thử với một phần mềm đã được phát triển hoàn thiện.

4/ Kiểm thử toàn bộ là có thể

Thực tế - Khi khách hàng hoặc người kiểm thử (tester) nghĩ rằng test toàn bộ là có thể, điều này khả thi khi các kịch bản được thực thi bởi nhóm nhân viên kiển thử. Nhưng kiểm thử toàn bộ là không thể. Có thể có một số kịch bản không được người kiểm thử hoặc khách hàng thực thi trong suốt vòng đời phát triển nhưng lại được thực thi khi dự án đã được triển khai.

5/ Phần mềm đã được test là không có lỗi

Thực tế - Đây là một sai lầm rất phổ biến mà khách hàng, người quản lý dự án và nhóm quản lý thường tin. Không ai có thể khẳng định chắc chắn rằng phần mềm 100% không có lỗi ngay cả khi người kiểm thử có kỹ năng kiểm thử tốt đã test phần mềm đó.

6/ Các lỗi không được phát hiện là do người kiểm thử

Thực tế - Đây không phải là hướng tiếp cận chính xác để đổ lỗi cho người kiểm thử khi các lỗi vẫn còn trong ứng dụng ngay cả sau khi đã được thực hiện test. Sai lầm này liên quan đến Thời gian, Chi phí và Yêu cầu thay đổi Ràng buộc. Tuy nhiên, chiến lược kiểm thử cũng có thể dẫn đến lỗi do nhóm kiểm thử bỏ qua.

7/ Người kiểm thử chịu trách nhiệm về chất lượng sản phẩm

Thực tế - Một sai lầm rất phổ biến là chỉ những người kiểm thử hoặc nhóm kiểm thử phải chịu trách nhiệm về chất lượng sản phẩm. Trách nhiệm của người kiểm thử bao gồm việc xác định lỗi cho các bên liên quan, sau đó quyết định xem có sửa lỗi hay phát hành phần mềm. Việc phát hành phần mềm vào thời điểm đó sẽ gây thêm áp lực cho tester, vì họ sẽ bị đổ lỗi khi có bất kỳ lỗi nào xảy ra.

8/ Test tự động (Test Automation) nên được sử dụng bất cứ khi nào có thể để giảm thời gian

Thực tế - Đúng là Test Automation giảm thời gian kiểm thử, nhưng không thể bắt đầu Test Automation bất cứ lúc nào trong quá trình phát triển phần mềm. Automaton test nên được bắt đầu khi phần mềm đã được kiểm tra bằng tay và ổn định ở một mức độ nào đó. Hơn nữa Test Automation không thể được sử dụng nếu yêu cầu liên tục thay đổi.

9/ Bất cứ ai cũng có thể test một ứng dụng phần mềm

Thực tế - Những người ngoài ngành công nghiệp CNTT đều nghĩ và thậm chí tin rằng bất cứ ai cũng có thể kiểm thử một phần mềm và kiểm thử không phải là một công việc sáng tạo. Tuy nhiên những tester biết rất rõ rằng đây là một sai lầm. Suy nghĩ về các kịch bản thay thế, cố gắng phá vỡ một phần mềm với mục đích tìm lỗi tiềm ẩn không thể là người đã phát triển phần mềm đó.

10/ Nhiệm vụ duy nhất của Tester là tìm lỗi

Thực tế - Tìm lỗi trong phần mềm là nhiệm vụ của người kiểm thử, nhưng đồng thời, họ là những chuyên gia của phần mềm đó. Developers chỉ chịu trách nhiệm cho một phần cụ thể hoặc chức năng đã được giao cho họ, nhưng Tester sẽ hiểu rõ hoạt động tổng thể của phần mềm, những gì phụ thuộc và tác động của một mô-đun lên một mô-đun khác.

Trên là tổng hợp 10 sai lầm mà người ta hay nghĩ tới khi nhắc đến testing, hiểu rõ 10 vấn đề đó thì bạn sẽ thấy làm tester cũng không hề đơn giản, phải chịu nhiều áp lực khi bị những hiểu nhầm không đáng có như: Tại sao test rồi mà vẫn xuất hiện lỗi :) câu hỏi muôn thuở dành cho tester.

Cùng chuyên mục:

Giám sát và kiểm soát kiểm thử

Giám sát và kiểm soát kiểm thử

Trong khi nhóm thực hiện các nhiệm vụ được giao, Test Manager cần giám sát…

Tài liệu kiểm thử

Tài liệu kiểm thử

Tài liệu kiểm thử giúp nhóm kiểm thử ước tính effort kiểm thử cần thiết,…

Cách tạo Test Plan

Cách tạo Test Plan

Test Plan là một tài liệu chi tiết mô tả chiến lược kiểm thử, Mục…

Tổ chức nhóm kiểm thử

Tổ chức nhóm kiểm thử

Tổ chức nhóm kiểm thử là một trong những nhiệm vụ phức tạp nhất trong…

Phân tích rủi ro dự án và giải pháp trong quản lý kiểm thử

Phân tích rủi ro dự án và giải pháp trong quản lý kiểm thử

Khi thực hiện dự án, luôn có những rủi ro tiềm ẩn. Để giảm thiểu…

Quy trình quản lý kiểm thử

Quy trình quản lý kiểm thử

Quản lý kiểm thử (Test Management) bao gồm chuỗi nhiều hoạt động. Có hai phần…

Vai trò và Trách nhiệm của Test Manager

Vai trò và Trách nhiệm của Test Manager

Trước khi bắt đầu kiểm thử một dự án, bạn nên biết vai trò của…

Kiểm thử Use Case

Kiểm thử Use Case

Là một tester, bạn đã hiểu rõ về Use Case hay Kiểm thử Use Case…

Kỹ thuật kiểm thử chuyển đổi trạng thái

Kỹ thuật kiểm thử chuyển đổi trạng thái

Chuyển đổi trạng thái (State Transition) trong kiểm thử là gì? Khi nào sử dụng…

Kỹ thuật kiểm thử bảng quyết định

Kỹ thuật kiểm thử bảng quyết định

Bảng quyết định là một trong những kỹ thuật kiểm thử phầm mềm. Vậy Kiểm…

Kỹ thuật Phân tích giá trị biên và phân vùng tương đương

Kỹ thuật Phân tích giá trị biên và phân vùng tương đương

Chúng ta cần sử dụng các kỹ thuật đặc biệt để lựa chọn test cases…

Kỹ thuật kiểm thử phần mềm

Kỹ thuật kiểm thử phần mềm

Kỹ thuật kiểm thử giúp giảm số lượng các test cases được thực hiện trong…

Test Case Template

Test Case Template

Test cases là đơn vị nhỏ nhất trong kế hoạch kểm thử, mô tả các…

Thủ thuật để tạo dữ liệu kiểm thử

Thủ thuật để tạo dữ liệu kiểm thử

Data được sử dụng trong kiểm thử mô tả các điều kiện tiền đề của…

Cách tạo Requirements Traceability Matrix - RTM

Cách tạo Requirements Traceability Matrix - RTM

Requirements Traceability Matrix - RTM là gì? Traceability Test Matrix bao gồm những loại nào?…

Cơ sở kiểm thử - Test basis

Cơ sở kiểm thử - Test basis

Cơ sở kiểm thử - Test Basis là nguồn để tạo ra các test cases.…

Cách viết Test Cases

Cách viết Test Cases

Test Case là tập hợp các hành động được thực thi để xác minh một…

Kịch bản kiểm thử - Test Scenario

Kịch bản kiểm thử - Test Scenario

Test Scenario tuy không còn mới mẻ nhưng không ít người còn mơ hồ về…

Kiểm thử phi chức năng

Kiểm thử phi chức năng

Kiểm thử phi chức năng liên quan đến việc kiểm thử phần mềm từ những…

Kiểm thử hồi quy

Kiểm thử hồi quy

Kiểm thử hồi quy - Regression Testing rất quan trọng, đặc biệt là trong những…

Top