Kiểm thử - Trách nhiệm thuộc về ai?

QA (viết tắt của Quality Assurance) là người chịu trách nhiệm đảm bảo chất lượng sản phẩm thông qua việc đưa ra quy trình làm việc giữa các bên liên quan. Nhiệm vụ chủ yếu của QA là: đề xuất, đưa ra quy trình phát triển (development process) sản phẩm phù hợp với yêu cầu cụ thể của từng dự án.

Phải đến quá nửa những cuộc tranh cãi của lập trình viên là về kiểm thử và bug. Mỗi khi gặp lỗi nghiêm trọng, hoặc khi mọi thứ trở nên rắc rồi, điều mà rất nhiều lập trình viên nghĩ đến thường là trách QA (Quality Assurance):

• Tại sao lại không test kỹ, không hiểu độ cần thiết của tính năng này sao?
• Tại sao lại có thể sai ngớ ngẩn thế này? Cái này rất cơ bản?
• Tại sao QA không phát hiện ra lỗi?
• Hoặc, ở công ty nhỏ lại còn có câu hỏi: tại sao không có team QA? Và những câu hỏi tại sao không bao giờ chấm dứt… Những lập trình viên bắt đầu tìm người để “hỏi tội”.

Đứng về vai trò, rõ ràng là QA sẽ chịu trách nhiệm về chất lượng cuối cùng của sản phẩm. Nhưng thực tế trong ngành phần mềm đó là: không có một chương trình nào không có bug. Chương trình tiềm ẩn nhiều bug hay không, dễ nâng cấp, bảo trì, kiểm thử hay không là do ý thức cũng như trình độ của người thiết kế hệ thống cũng như người lập trình.

Vậy trách nhiệm kiểm thử thuộc về ai?

Hãy xem lại một chút vấn đề của kiểm thử phần mềm:

1. Các phần mềm luôn có lỗi.
2. Các phương pháp kiểm thử luôn là vấn đề làm đau đầu những người làm phần mềm.
3. Muốn giảm thiểu lỗi, phải kiểm thử rất nhiều, và luôn tiêu tốn thời gian.
4. Trong trường hợp manual testing, QA thường không có kiến thức về lâp trình.
5. Với auto-test, việc test diễn ra nhanh chóng, đảm bảo nhưng hạn chế trong phạm vi của testing framework.
6. Các QA trong mảng này cần có kiến thức rất tốt về phát triển và kiểm thử phần mềm.
7. Kiểm thử rất nhàm chán.

Câu hỏi "Trách nhiệm thuộc về ai?" thật vô nghĩa và kéo theo nhiều rắc rối bởi: Câu hỏi đó đủ để phá vỡ tinh thần hợp tác của mọi người trong nhóm. Cách suy nghĩ đó sẽ đưa bài toán đến chỗ không có lời giải. Câu hỏi phải là “Giải quyết như thế nào?” Với nghề QA, chữ “Q”-Quality trong QA là quan trọng nhất. Một Q hợp lý cần phải đạt được với ngân sách, thời gian và chiến lược hợp lý. Vậy bạn hiểu CHẤT LƯỢNG LÀ GÌ? Theo quan điểm của tôi chất lượng sản phẩm bao gồm hai yếu tố :

• Tạo ra giá trị cho Stakeholders - Những người/nhóm người có quyền lợi nhất định đối với việc thực thi dự án. Họ có ảnh hưởng tới dự án và phạm vi ảnh hưởng của những người khác nhau sẽ khác nhau.
• Đáp ứng được yêu cầu của các Owners cả về mặt tính năng, tài chính, thời gian và kỹ thuật.

Thực tế, người hiểu Stakeholders nhất chính là các Owner và Project Manager. Nếu bạn là một Developer, hay một QA và bạn thực sự lo lắng cho chất lượng sản phẩm, hãy thường xuyên nói chuyện, trao đổi với họ về sản phẩm, dù bạn không phải là dân Phân tích nghiệp vụ (Business Analyst).

Chiến thuật kiểm thử

Vậy khi đã hiểu rõ các tính năng trên quan điểm là quyền lợi của Stakeholders, việc xây dựng chiến thuật kiểm thử trở nên rõ ràng hơn. Hiển nhiên, những tính năng đem lại nhiều giá trị cho Stakeholders sẽ phải được kiểm thử kỹ lưỡng hơn những tính năng ít gây ảnh hưởng đến họ. Việc xây dựng chiến thuật xây dựng sản phẩm và kiểm thử rất cần phải linh hoạt. Có ba câu hỏi tôi luôn nghĩ đến khi tiến hành kiểm thử:

• Các Stakeholders sẽ nghĩ thế nào nếu tính năng này có lỗi?
• Việc kiểm thử tốn bao nhiêu thời gian là chấp nhận được?
• Technical debt sẽ là gì? (Technical debt (Nợ kỹ thuật): những rủi ro về mặt kỹ thuật tồn tại trong tương lai, ở bất kỳ một hệ thống phần mềm nào.)

Hãy cân đo đong đếm để từ đó đưa ra cách kiểm thử hợp lý. Tuy vậy, đó không hề là một vấn đề đơn giản. Để giải thích về chiến thuật kiểm thử tôi sẽ phân tích chiến thuật trên hai yếu tố:

1. Testing level: Tôi sẽ lấy ví dụ về 3 level: Unit level, Integration level và Behavior level.
2. Testing method: Tôi sẽ lấy ví dụ về kiểm thử tự động và thủ công.

Trước hết, các testing level là như thế nào? Để dễ hiểu hơn, thay vì dùng phần mềm, hãy dùng một chú robot làm ví dụ. Unit test tức là bạn đang kiểm tra chất lượng từng linh kiện như dây điện, con ốc, bảng mạch, mô tơ,…. Sau khi bạn lắp ráp thành công từng bộ phận như chân, tay, đầu,… bạn sẽ kiểm tra hoạt động của từng phần, đó là Integration test. Sau khi hoàn tất rô-bốt, bạn sẽ điều khiển nó đi lại, vượt chướng ngại vật, khuân vác,… đó là Behaviour Test.

So sánh phương pháp kiểm thử tự động và thủ công:

So sánh các Testing level ở trên với phương pháp kiểm thử tự động và thủ công: Với Unit test:

Với Integration test (Tính đảm bảo sẽ giảm khi Unit test không được thực hiện):

Với Behavior test (Tính đảm bảo sẽ giảm khi Unit test và Integration test không được đảm bảo):

Lời kết:

• Nếu như bạn là một Developer và cảm thấy QA không tốt. Khả năng cao, QA công ty bạn chỉ đang làm thủ công ở level Behavior test, hoặc đang test không đủ ở những level thấp (do vấn đề chi phí công ty chấp nhận Technical Debt). Hãy hiểu rằng người sai trước hết luôn là Developer đã không thực hiện tốt khâu Unit Test và Integration Test nên mới khiến QA trở nên khó khăn. Hãy trao đổi tích cực và giúp QA làm việc năng suất, hiệu quả hơn.
• Ngược lại, nếu bạn là một QA và cảm thấy Developer không tốt, hãy kiểm tra lại xem là do Developer không tốt hay quy trình test chưa đảm bảo. Hãy suy nghĩ về bản thân mình trước khi trách cứ một ai. Và hãy tích cực trau dồi kỹ năng test, kiến thức chuyên ngành để có thể ngày càng hoàn thiện bản thân hơn, giúp công việc suôn sẻ và tốt hơn.

Nguồn tham khảo: http://www.softwaretestinghelp.com/who-is-responsible-for-software-quality/