Cách đây không lâu tác giả VNTesters có đăng một bài viết với chủ đề “Cần chuẩn bị gì khi phỏng vấn vị trí kỹ sư kiểm thử phần mềm?” và được nhiều bạn đọc quan tâm và thắc mắc sao không có câu trả lời kèm theo. Hôm nay mình xin trích lọc một số câu hỏi thú vị và đưa ra câu trả lời. Những câu hỏi khác không phải là không hay nhưng các bạn hoàn toàn có thể tìm hiểu trên Google. Các bạn có thể đọc toàn bộ câu hỏi ở đây.
Làm thế nào để đảm bảo chất lượng của sản phẩm phần mềm?
Một câu hỏi thuộc dạng khó và rộng tuy nhiên để tóm gọn thì mình xin trả lời như sau. Để đảm bảo chất lượng của phần mềm theo mình có 2 yếu tố quan trọng: qui trình tốt và nhân lực tốt. Qui trình chỉ những bước, cách thức để làm ra một sản phẩm có chất lượng. Nhân lực chỉ yếu tố con người để thực hiện qui trình đó. Nhân lực bao gồm đội phát triển, đội kiểm thử, phân tích yêu cầu, quản lý dự án, quản lý qui trình, v.v. (tùy theo mô hình có thể sẽ có thêm hoặc bớt). Điều đó có nghĩa là tất cả những bộ phận liên quan trong dự án đều tham gia, đóng góp và chịu trách nhiệm về chất lượng của sản phẩm. Đội kiểm thử đóng vai trò quan trọng trong đảm bảo chất lượng sản phẩm nhưng không phải duy nhất.
Bạn sẽ làm gì nếu bạn không có đủ thời gian để kiểm thử?
Ngày nay việc đội kiểm thử không có đủ thời gian để kiểm thử cũng không có gì là lạ. Không chỉ riêng đội kiểm thử mà cả đội phát triển, đội phân tích đều bị đặt dưới áp lực thời gian do áp lực cạnh tranh, chi phí. Dĩ nhiên khi chúng ta có ít thời gian hơn chúng ta sẽ phải kiểm thử ít hơn đều đó cũng đồng nghĩa rủi ro chất lượng sản phẩm sẽ bị ảnh hưởng lớn hơn. Để giảm thiểu rủi ro, chúng ta sẽ phải sắp xếp độ ưu tiên cho việc kiểm thử (Risk-based testing). Những trường hợp kiểm thử, thành phần nào quan trọng được kiểm thử trước, cái nào không quan trọng ít rủi ro có thể thực thi sau hoặc có thể cắt bỏ. Chúng ta cũng có thể tận dụng kiểm thử tự động để rút ngắn thời gian thực thi cũng như tăng độ bao phủ cho công việc kiểm thử.
Khi nào bạn nói dự án kiểm thử của bạn hoàn thành? Nêu tên các yếu tố.
Các bạn có thể tìm hiểu thêm về Exit criteria. Tuy nhiên, theo quan điểm của mình thì việc kiểm thử không bao giờ có khái niệm xong (Các bạn có thể tìm đọc “You are not done yet” của Michael Hunter). Luôn có thứ để chúng ta kiểm thử và mình sẽ dừng việc kiểm thử khi dự án hết tiền hoặc sếp bảo dừng.
Làm thế nào để bạn biết rằng tất cả các kịch bản thử nghiệm được bao phủ (covered)?
Mình cũng không rõ kịch bản thử nghiệm trong ngữ cảnh câu hỏi là gì. Tuy nhiên theo mình hiểu câu hỏi đề cập đến độ bao phủ trong kiểm thử. Độ bao phủ đóng vai trò quan trọng trong kiểm thử đặc biệt là trong quản lý kiểm thử. Tuy nhiên khi nói đến độ bao phủ, chúng ta phải nói độ bao phủ đó được đo dựa trên đơn vị nào. Độ bao phủ của yêu cầu, độ bao phủ của chức năng, độ bao phủ của các loại kiểm thử, độ bao phủ của kỹ thuật kiểm thử, độ bao phủ của trình duyệt v.v. Chúng ta cũng nên lưu ý thông tin về độ bao phủ cũng rất dễ gây nhầm lẫn. Bạn có 100 yêu cầu và bạn đã kiểm thử được 90 yêu cầu vậy độ bao phủ là 90% đối với yêu cầu. Con số 90% nói lên điều gì về chất lượng công việc kiểm thử cũng như chất lượng sản phẩm. Chẳng nói lên điều gì cả. 90% đó sẽ có nghĩa hơn nếu được kết hợp với những thông tin khác như bao nhiêu yêu cầu quan trọng đã được bao phủ, bao nhiêu lỗi đã tìm được trong 90% đó.
Ý kiến của bạn về quan điểm “kiểm thử tự động nâng cao hiệu quả kiểm thử phần mềm”.
Theo quan điểm của mình thì kiểm thử tự động sẽ hỗ trợ trong việc tăng độ bao phủ, giảm thời gian thực thi cũng như giảm thiểu chi phí cho công việc kiểm thử….nếu làm đúng cách.
Bạn có nghĩ rằng kiểm thử tự động có thể thay thế kiểm thử thủ công?
Có và không. Kiểm thử tự động có thể thay thế kiểm thử thủ công ở những công việc mang tính lặp đi lặp lại hay không thể thực thi bằng kiểm thử thủ công. Tuy nhiên, kiểm thử tự động không thể thay thế kiểm thử thủ công chẳng hạn như việc tìm bug hay hỏi những câu hỏi hay.
Mô tả những vấn đề chung của kiểm thử tự động
Kiểm thử tự động mang lại nhiều giá trị cho công việc kiểm thử. Tuy nhiên, cũng như kiểm thử thủ công, kiểm thử tự động cũng có những vấn đề riêng của nó.
1) Chi phí cao. Chi phí này bao gồm chi phí mua công cụ, chi phí đào tạo hoặc thuê kỹ sư triển khai, chi phí bảo trì.
2) Kỹ thuật. Việc tương tác giữa công cụ kiểm thử và sản phẩm là một thách thức lớn đối với kiểm thử tự động do sự phát triển nhanh chóng của công nghệ nói chung và công nghệ phát triển phần mềm nói riêng.
3) Đòi hỏi một nền tảng kiến thức nhất định về coding cũng như phát triển phần mềm. Thực chất, kiểm thử tự động cũng không khác việc phát triển phần mềm là mấy. Chúng tai phải viết thiết kế framework, viết code, thực thi, debug, sửa lỗi v.v. Nhiều công cụ ngày nay với những mô hình tiên tiến hỗ trợ kỹ sư kiểm thử có thể triển khai kiểm thử tự động mà không phải “động” đến code nhiều nhưng vẫn còn nhiều hạn chế.
Có lỗi nào có mức độ nghiêm trọng cao nhưng ưu tiên thấp không (và ngược lại, mức độ nghiêm trọng thấp nhưng độ ưu tiên lại cao)?
Câu trả lời là có. Mình có viết 1 bài về độ ưu tiên, độ nghiêm trọng. Các bạn có thể đọc thêm ở đây.
Đây chỉ là những câu trả lời tham khảo không phải là câu trả lời đúng nhất cũng không chắc đúng. Các bạn có thể chia sẻ câu trả lời của mình bằng cách comment bên dưới để cùng trao đổi.