Cộng Đồng Kiểm Thử Phần Mềm

Trong cuộc sống chúng ta không quá xa lạ với những dấu hiệu. Khi ra đường chúng ta sẽ dễ dàng bắt gặp những dấu hiệu về đường một chiều, bảng báo cấm đậu xe. Khi khám bác sĩ, bác sĩ cũng hay hỏi về những dấu hiệu như hắc hơi, sổ mũi, ho v.v. Việc nhận biết những dấu hiệu đó giúp ích chúng ta rất nhiều trong cuộc sống.

Tương tự trong kiểm thử cũng có những dấu hiệu của riêng nó. Khi bạn nhận được nhiều lời phàn nàn từ khách hàng, khi số lượng bug bạn để “lọt” đến tay khách hàng ngày càng nhiều, khi tất cả các trường hợp kiểm thử có kết quả “Passed”, khi bạn không biết tài liệu kiểm thử lưu ở đâu, một lỗi được trao đổi liên tục qua lại giữa bạn và developer, khi bạn chẳng học được gì mới trong dự án v.v Tất cả những dấu hiệu đó cho thấy có thể bạn đang không làm tốt công việc của một kỹ sư kiểm thử. Việc nhận ra những dấu hiệu đó càng sớm càng tốt sẽ giúp bạn điều chỉnh, chỉnh sửa ngay lập tức hay ngăn ngừa vấn đề diễn biến xấu thêm.

Cách đây vài tuần, mình có đặt một câu hỏi tương tự về những dấu hiệu giúp nhận biết bạn không làm tốt công việc kiểm thử trên LinkedIn và nhận được gần 100 lượt bình luận và chia sẻ của cộng đồng kỹ sư kiểm thử trên thế giới. Mặc dù có nhiều dấu hiệu còn nhiều tranh cãi nhưng cũng có một số dấu hiệu nhận được sự đồng thuận cao của giới kỹ sư kiểm thử và mình cũng muốn chia sẻ với cộng đồng kỹ sư kiểm thử Việt Nam về những dấu hiệu này

*Lưu ý: Những dấu hiệu bên dưới là tập hợp của những ý kiến của các cá nhân và những dấu hiệu họ quan sát được và trong một ngữ cảnh cụ thể. Có thể đúng và có thể sai. Việc bạn đang có những dấu hiệu trên không đồng nghĩa bạn là một “tester dở” hay bạn đang gặp rắc rối mà đó chỉ đơn thuần là “dấu hiệu”, “biểu hiện” hay “triệu chứng”. Việc giải mã những dấu hiệu trên và tìm ra nguyên nhân thực sự của vấn đề đòi hỏi phân tích chi tiết hơn.

Những dấu hiệu liên quan đến Lỗi:

• Tỉ lệ lỗi đến tay người dùng tăng cao (Defect Leakage Rate)
• Lỗi được tìm thấy trễ trong các giai đoạn sau của chu kỳ kiểm thử
• Lỗi tìm thấy nhiều trong User Acceptance Test (Kiểm thử chấp nhận)
• Lỗi được đóng và mở nhiều lần, lặp đi lặp lại
• Lỗi không hợp lệ chiếm hơn 15% tổng số lỗi của dự án
• Khách hàng tìm được lỗi crash hệ thống
• Rất ít lỗi được tìm thấy và log lên hệ thống
• Chỉ tập trung tìm lỗi mà không tập trung ngăn ngừa lỗi
• Không tập trung phân tích hệ thống để tìm lỗi nghiêm trọng
• Lỗi được tìm thấy trong các trường hợp kiểm thử đã được kiểm thử và đánh dấu là “Passed”
• Bên thứ 3 tìm được lỗi trong bộ trường hợp kiểm thử “Happy path”
• Lỗi đáng ra phải được phát hiện bởi Tester nhưng lại được phát hiện bởi Developer hay được đánh dấu trong Release Note

Những dấu hiệu liên quan đến việc Thực thi kiểm thử:

• Tất cả các trường hợp kiểm thử đều Passed
• Các trường hợp kiểm thử được in nghiêng, in đậm, font chữ mà sắc khác nhau.
• Kỹ sư kiểm thử chỉ thực thi theo đúng các bước trong trường hợp kiểm thử mà không tìm cách “break” ứng dụng
• Không kiểm thử sản phẩm dưới góc nhìn người dùng cuối
• Khi bạn quá tự tin để đưa sản phẩm ra thị trường và bỏ qua “luật Murphy”
• Có 7000 trường hợp kiểm thử cho một chức năng đơn giản của hệ thống
• Tự động hóa tất cả các trường hợp kiểm thử và chỉ sử dụng một công cụ duy nhất
• Không nắm được Developer đã kiểm thử những gì rồi
• Viết nhiều trường hợp kiểm thử dư thừa và quá tập trung và một tính năng
• Dành nhiều thời gian để debug lỗi của automation hơn là kiểm thử sản phẩm
• Tập trung quá nhiều và các tài liệu kiểm thử (kế hoạch kiểm thử, trường hợp kiểm thử, v.v) hơn là mục đích chính của kiểm thử
• Không tập trung vào quá trình kiểm thử như thực thi kiểm thử sai môi trường yêu cầu, cắt bỏ các bước, hiểu sai yêu cầu/hướng dẫn kiểm thử, tài liệu kiểm thử
• Đã 12h trưa và không ai trong đội kiểm thử biết hôm nay sẽ kiểm thử cái gì, chỉ kiểm thử ngẫu nhiên vài chỗ
• Khi có ai thắc mắc về một tính năng của ứng dụng thì bạn luôn trả lời “tính năng này xưa giờ nó vậy..”
• Không hiểu được yêu cầu business đối với sản phẩm đang kiểm thử
• Kỹ sư kiểm thử đọc qua tài liệu đặc tả yêu cầu và tuyên bố “Hiểu hết, không hỏi gì thêm”

Những dấu hiệu liên quan đến Quản lí kiểm thử:

• Hoãn đưa sản phẩm ra thị trường chỉ để tìm câu trả lời cho câu hỏi “Làm sao con bug này có thể sót được”
• Điều chỉnh công việc kiểm thử chỉ để cho khớp với ước tính ban đầu
• Không biết nơi lưu trữ các tài liệu, trường hợp hay kết quả kiểm thử khi người phụ trách vắng mặt
• Tài liệu kiểm thử chỉ có một version duy nhất
• Tài liệu, các trường hợp kiểm thử không được cập nhật các tính năng mới của sản phẩm kiểm thử
• Khi việc kiểm thử vượt quá ngân quỹ, thời gian và chất lượng kém
• Khi bạn phải làm việc nhiều thời gian hơn bình thường
• Khi ai đó đánh thức bạn khi bạn đang ngủ (đặc biệt là trong giờ làm :-))
• Sếp tự động thêm tính năng vào sprint và không thông báo cho đội kiểm thử
• Khi bạn không rõ milestone kế tiếp của dự án là khi nào
• Bạn không trả lời được câu hỏi “Bạn test tới đâu rồi”
• Bạn không có sẵn các kế hoạch hay chiến lược kiểm thử cho việc kiểm thử phần nào, kiểm thử nhiều ít, cách tiếp cận, rủi ro v.v

Những dấu hiệu liên quan đến Giao tiếp:

• Đội kỹ sư kiểm thử tách biệt với các đội khác
• Kỹ sư kiểm thử ngồi trước máy tính nhiều giờ, tai đeo headphone
• Kỹ sư kiểm thử không nói chuyện với Dev và ngược lại
• Kỹ sư kiểm thử không nói chuyện với Chủ sản phẩm và ngược lại
• Kỹ sư kiểm thử không nói chuyện với Khách hàng và ngược lại
• Không ai tìm bạn để hỏi hay xin ý kiến
• Kênh giao tiếp chủ yếu thông qua e-mail và bảng báo bug
• Khi mọi người quyết định mà không thông qua kỹ sư kiểm thử
• Khi bạn cảm thấy dường như bạn đứng ngoài lề trong các cuộc thảo luận về công nghệ, công cụ, qui trình
• Quản lí dự án dường như “tránh né” bạn. Không cung cấp đủ nguồn lực cho công việc kiểm thử và xếp kiểm thử của bạn vào độ ưu tiên thấp
• Kỹ sư kiểm thử ít khi đặt câu hỏi cho bạn đồng nghiệp, Dev, quản lí dự án, chủ sản phẩm, khách hàng v.v
• Khi bạn không rõ phần nào đã kiểm thử rồi, phần nào chưa
• Không tham gia hoặc nhận được báo cáo hàng ngày từ Dev, BA, Scrum Master, quản lí dự án
• Bạn có những phát kiến, tìm hiểu thú vị…và bạn không chia sẻ cho team
• Bạn không nói cho mọi người biết sai lầm/lỗi của bạn để giúp mọi người nhận biết và phòng tránh nó
• Bạn không thường xuyên hỏi “Tại sao…”
• Bạn và Developer thường xuyên phải hỏi qua hỏi lại một con bug vì mọi người không hiểu bạn đang mô tả vấn đề gì
• Bạn yêu cầu về thiết bị và nguồn lực chỉ 1 ngày trước khi bạn tiến hành kiểm thử
• Bạn phớt lờ lỗi
• Bạn không chỉ ra được phần thiếu sót trong đặc tả yêu cầu. Không hiểu và sử dụng công cụ phù hợp cho từng giai đoạn của dự án
• Khi bạn quan sát thấy một kỹ sư kiểm thử ngồi “yên lặng” và không có ý kiến suốt buổi họp

Những dấu hiệu liên quan đến Liên tục cải tiến:

• Không thường xuyên thử học những kỹ năng mới để làm công việc tốt hơn
• Nhận việc một cách cam chịu cũng như phớt lờ học hỏi những điều mới mẻ hay triển khai những ý tưởng mới
• Không thường xuyên tự đánh giá bản thân để cải hoàn thiện mình
• Không học thêm điều gì mới hay thấy thử thách trong cả tuần làm việc

Những dấu hiệu khác (nhưng không kém phần quan trọng):

• Nhận được nhiều phàn nàn từ khách hàng
• Luôn mặc định áp dụng một qui trình (đã từng chạy tốt trong quá khứ) cho những dự án khác nhau
• Bị sa thải
• Bạn thức dậy và thấy mệt mỏi
• Bạn có cùng cách tiếp cận cho các dự án kiểm thử
• Bạn cho rằng từ khách hàng, Developer đến Quản lí là những tên ngốc
• Bạn/những lỗi bạn tìm thấy không nhận được sự tôn trọng cần thiết từ các phòng ban khác.

Bên trên là những dấu hiệu mình tổng hợp từ diễn đàn LinkedIn và dĩ nhiên không phải là một danh sách của tất cả các dấu hiệu. Nếu bạn phát hiện thêm những dấu hiệu khác, bạn có thể chia sẻ bằng cách comment bên dưới bài viết. Ngoài ra bài viết chỉ tập trung liệt kê các dấu hiệu chứ không đi sâu vào phân tích cũng như đưa ra giải pháp. Nếu mọi người có hứng thú thì có thể tìm đọc quyển “Common System and Software Testing Pitfalls” của Donald G. Firesmith để có cái nhìn chi tiết và sâu hơn những vấn đề nêu trên.

Kiểm thử phần mềm