Vào năm 2012, Knight Capital Americas, một công ty tài chính toàn cầu, đã gặp lỗi trong hệ thống định tuyến tự động cho các đơn đặt hàng vốn (equity order) khi team dự án đã triển khai một phần mềm chưa được kiểm thử vào môi trường sản xuất. Kết quả là công ty đã mất hơn 460 triệu đô la chỉ trong 45 phút, và cơ bản đã dẫn đến sự phá sản của công ty. Lịch sử biết thêm nhiều ví dụ về các sự cố phần mềm gây ra thiệt hại tương tự. Tuy nhiên, kiểm thử vẫn là một trong những chủ đề gây tranh cãi nhất trong phát triển phần mềm. Nhiều product owner, do xem nhẹ giá trị của kiểm thử như một quy trình chuyên biệt, đã đặt các doanh nghiệp và sản phẩm phần mềm của họ vào nguy cơ thất bại trong khi bản thân họ cố gắng tiết kiệm từng đồng xu chi phí.

Mặc dù có một sự hiểu lầm phổ biến rằng nhiệm vụ duy nhất của người kiểm thử là tìm lỗi, hoạt động kiểm thử và QA (quality assurance) có tác động to lớn đến thành công của sản phẩm cuối cùng. Có hiểu biết sâu sắc về doanh nghiệp, khách hàng và bản thân sản phẩm, các kỹ sư kiểm thử làm tăng thêm giá trị cho phần mềm và đảm bảo chất lượng của phần mềm. Nhờ áp dụng kiến ​​thức sâu rộng của họ về sản phẩm, người kiểm thử có thể mang lại giá trị gia tăng cho khách hàng thông qua việc đóng góp thêm kinh nghiệm vào qui trình kiểm thử và hướng dẫn sử dụng sản phẩm. Điều này dẫn đến giảm chi phí sở hữu và nâng cao hiệu quả kinh doanh.

Khái niệm về chất lượng phần mềm: Quality Assurance (QA), Quality Control (QC) & Testing

Lịch sử biết nhiều ví dụ về các tình huống khi lỗ hổng phần mềm gây lãng phí hàng tỷ đô la hoặc thậm chí dẫn đến thương vong: từ việc các cửa hàng cà phê Starbucks bị buộc phải tặng đồ uống miễn phí vì trục trặc đăng ký, cho đến việc máy bay quân sự F-35 không thể phát hiện các mục tiêu chính xác vì một sự cố radar. Để đảm bảo phần mềm được phát hành an toàn và hoạt động như mong đợi, khái niệm chất lượng phần mềm đã được đưa ra. Chất lượng thường được định nghĩa là mức độ phù hợp với các yêu cầu rõ ràng và các yêu cầu tiềm ẩn, hay kỳ vọng. Những kỳ vọng được gọi là rõ ràng (explicit) và tiềm ẩn (implicit) này tương ứng với hai mức chất lượng phần mềm cơ bản:

• Functional (Chức năng) – sự tuân thủ của sản phẩm với các yêu cầu chức năng (explicit) và thông số kỹ thuật thiết kế. Khía cạnh này tập trung vào việc sử dụng phần mềm thực tế, từ quan điểm của người dùng: tính năng, hiệu suất, dễ sử dụng, không có lỗi.
• Non-Functional (Phi chức năng) – đặc điểm bên trong hệ thống và kiến ​​trúc, tức là các yêu cầu về cấu trúc. Điều này bao gồm khả năng dễ bảo dưỡng code, dễ hiểu, hiệu quả và bảo mật. Chất lượng cấu trúc của phần mềm thường khó quản lý: Nó chủ yếu dựa vào chuyên môn của đội ngũ kỹ thuật và có thể được đảm bảo thông qua code review, code analysis và refactoring.

Đồng thời, khía cạnh chức năng có thể được đảm bảo thông qua các hoạt động quản lý chất lượng đặc thù, bao gồm đảm bảo chất lượng (QA), kiểm soát chất lượng (QC) và kiểm thử (Testing).

Đôi khi 3 khái niệm này được sử dụng lẫn lộn với nhau nhưng chúng đề cập đến các khía cạnh có phần khác nhau của quản lý chất lượng phần mềm. Mặc dù có một mục tiêu là cung cấp một sản phẩm có chất lượng tốt nhất có thể, cả về cấu trúc và chức năng, các khái niệm nói trên sử dụng các phương pháp khác nhau cho nhiệm vụ này.

Theo Altexsoft