🐞 Mặc dù bất kỳ sản phẩm hay một chức năng nào cũng sẽ được kiểm thử kỹ lưỡng qua nhiều mức khác nhau, trong suốt quá trình phát triển, từ lúc phân tích yêu cầu, thiết kế, lập trình, cho đến kiểm thử. Tuy nhiên, người dùng vẫn gặp lỗi khi sử dụng sản phẩm là điều khó tránh khỏi.
Lỗi trong quá trình sử dụng phần mềm, cũng có nhiều mức độ nghiêm trọng khác nhau. Lỗi nhẹ thì khách hàng khó chịu vì khó sử dụng, mất thời gian để thao tác lại. Lỗi nặng thì gây tổn thất lớn về doanh số, ảnh hưởng đến uy tín của công ty làm ra sản phẩm và công ty khách hàng sử dụng sản phẩm. Hoặc thậm chí, như trên xe ô tô tự lái, thì lỗi phần mềm có thể ảnh hưởng đến tính mạng của người dùng.
Sót bug là gì?
Sót bug (Bug leakage) là khi một bug được phát hiện bởi khách hàng hoặc người dùng cuối khi sử dụng sản phẩm, mà lỗi này không được phát hiện bởi nhóm phát triển phần mềm trong quá trình phát triển. Tỉ lệ sót bug càng cao nghĩa là số lượng bug bị bỏ sót trong quá trình làm việc càng nhiều, ngược lại thì tỉ lệ sót bug thấp có nghĩa là nhóm của bạn đã kiểm soát chất lượng tốt hơn.
Một trong những thước đo được nhiều công ty sử dụng là Bug Leakage hay Defect Leakage Rate.
Defect Leakage Rate = [số bug khách hàng phát hiện trên môi trường thực tế] x 100 / [tổng số bug hiện có]
Ví dụ, tổng số bug hiện có của dự án này là 300. Khách hàng phát hiện được 45 bug, thì Defect Leakage Rate là 45 x 100 / 300 = 15%
Tester nên làm gì khi sót bug?
Anh Sơn đã thực hiện một khảo sát về chủ đề này trên nhóm facebook Testing VN.
Trong hơn 180 bình luận, một số bạn bình luận vui rằng khi sót bug chúng ta có thể thực hiện một số điều sau đây:
- Thực hiện phân tích nguyên nhân gốc rễ của vấn đề (Root cause analysis – RCA) >> rút kinh nghiệm >> xin lỗi nếu cần hoặc có yêu cầu >> bỏ trốn nếu hậu quả nghiêm trọng ạ 😂
- Có bạn thì “Cập nhật CV và chuyển sang chế độ ‘Open to work’ trên LinkedIn”
- Mua cafe mời anh Dev uống và fix (sửa lỗi) hộ em nhé anh
- Nở một nụ cười thật tự tin
- V.v…
Nếu khóc hay bỏ trốn mà giải quyết được vấn đề thì cũng nên làm. Tuy nhiên, chắc chắn điều ấy không thể giúp được gì.
Thay vì trách móc bản thân, tìm cách biện minh, hay đổ lỗi cho nhau, tester cần hành động một cách chuyên nghiệp để giải quyết vấn đề và rút kinh nghiệm cho những lần sau. Nếu lỗi nghiêm trọng, sau khi cả nhóm đã cùng nhau xử lý lỗi xong, thì chúng ta cần kiểm thử lại kỹ càng. Đừng quên thực hiện regression testing (kiểm thử hồi quy) để bảo đảm việc sửa lỗi không làm phát sinh lỗi ở những chức năng/màn hình khác.
Khi phát hiện lỗi trên môi trường thực tế (dù là do khách hàng, bạn hay người trong nhóm phát triển phần mềm) thì tester nên:
- Báo cáo vấn đề – Tạo ticket trên hệ thống quản lý lỗi như Jira
- Nếu lỗi nghiêm trọng, thì báo ngay cho nhóm – Có thể là trao đổi trên Slack
- Kiểm tra trên hệ thống theo dõi hành vi người dùng như FullStory (nếu công ty có sử dụng)
- Kiểm tra nhật ký của hệ thống (server logs) xem có lỗi gì xảy ra trong khoảng thời gian lỗi được phát hiện
- Cố gắng tái hiện lỗi trên môi trường thực tế (nếu được)
- Cố gắng tái hiện lỗi trên môi trường kiểm thử (như UAT hoặc Staging)
Một trong những lợi ích của việc cập nhật tình hình, báo cáo ngay cho nhóm của mình bao gồm developer, PM, QA Manager,… bạn đã giúp nhóm nắm được tình hình sớm. Điều này giúp nhóm, cụ thể là PM, trao đổi với khách hàng hiệu quả và chủ động hơn. Nó cũng giúp tạo niềm tin và sự gắn kết trong nhóm, từ đó thúc đẩy tinh thần hợp tác cùng nhau giải quyết vấn đề.
Tester có thể giúp nhóm mình thế nào?
Đối với những lỗi hay sự cố nghiêm trọng, điều quan trọng nhất là tester cần phối hợp với nhóm để tìm hiểu nguyên nhân lỗi đó bị bỏ sót trong quá trình kiểm thử.
Thực hiện phân tích nguyên nhân gốc rễ (Root cause analysis – RCA) là một cách để giúp phát hiện nguyên nhân dẫn đến lỗi, từ đó giúp nhóm phát triển phần mềm tránh được những lỗi tương tự trong tương lai. Phương pháp 5 Whys (5 câu hỏi tại sao) và mô hình xương cá (fish born) là hai phương pháp phân tích nguyên nhân gốc rễ phổ biến nhất.
Một số nguyên nhân sót lỗi thường gặp:
- Tester thiếu kinh nghiệm hoặc/và kiến thức về lĩnh của của phần mềm mình đang kiểm thử. Nhiều công ty, dự án không có chương trình đào tạo bài bản cho các bạn tester trước khi tham gia dự án. Hoặc do vấn đề “thời gian không cho phép.” Điều này làm cho các bạn khó nắm bắt và hiểu hết được hệ thống cũng như yêu cầu, dễ xảy ra thiếu sót trong quá trình kiểm thử. Hoặc bản thân tester không chịu tự học hỏi thêm khi gặp lĩnh vực mới.
- Chất lượng tài liệu yêu cầu, thiết kế không được tốt. Product Manager (quản lý sản phẩm) hoặc BA (Business Analyst – nhân viên phân tích nghiệp vụ) thiếu kinh nghiệm và kiến thức liên quan đến lĩnh vực của phần mềm (domain knowledge) dễ dẫn đến việc mô tả yêu cầu không rõ ràng hoặc thiếu chức năng.
- Trong quá trình kiểm thử, chúng ta không bao quát được mọi trường hợp. Nên áp dụng các kỹ thuật kiểm thử để giúp nâng cao khả năng bao phủ của bộ test case.
- Thời gian phát triển và kiểm thử phần mềm bị hạn chế cũng là một nguyên nhân phổ biến. Làm gì cũng gấp! Áp lực về thời gian làm cho lập trình viên chỉ nghĩ đến các trường hợp đúng (positive case), mà quên đi các trường hợp lỗi. Dẫn đến thiếu xử lý các trường hợp lỗi xảy ra từ chính bản thân chương trình, máy chủ, hoặc phần mềm/dịch vụ của bên thứ ba. Tester thì, do áp lực thời gian nên sẽ chỉ tập trung kiểm thử các trường hợp chính, happy case, thường sẽ bỏ qua các trường hợp negative case (trường hợp nhập dữ liệu không đúng) – Mà thường những trường hợp này mới dẫn đến lỗi. Hơn thế nữa thì không có thời gian để thực hiện các trường hợp edge case.
- Nhiều lỗi chỉ xảy ra trên môi trường thực tế hoặc trên một số thiết bị cụ thể mà không thể tái hiện được trên môi trường kiểm thử như UAT hay Staging.
Và nhiều nguyên nhân khác.
Tester nên làm gì để cải thiện?
Thật ra, chỉ tester hay developer (lập trình viên) thay đổi cũng không thể giúp giảm số lượng lỗi bị sót. Tuỳ nguyên nhân sót lỗi, mà sẽ có hành động khác nhau để cải tiến. Có khi phải cải tiến quy trình phát triển phần mềm, thêm các hoạt động kiểm thử, bao gồm review tài liệu, các bản thiết kế trước khi tiến hành lập trình.
Việc sót bug không chỉ liên quan đến lỗi cá nhân mà còn quy trình làm việc. Điều quan trọng là tester cần phối hợp với nhóm để tìm cách cải thiện. Tuỳ nguyên nhân phổ biến là gì sẽ có các cải tiến trực tiếp trong các hoạt động kiểm thử và các hoạt động khác như đánh giá lại danh sách test case hiện có hay đào tạo nghiệp vụ cho PM, BA, hoặc cả nhóm – bao gồm developer và tester nữa.
Tester có thể hỗ trợ cải tiến các khía cạnh sau đây, giúp nâng cao chất lượng phần mềm do mình tham gia phát triển.
Về quy trình làm việc
Không chỉ riêng tester hay QA, tất cả mọi vị trí từ Product Manager, developer, và cả khách hàng đều liên quan đến quy trình làm việc. Tester hay QA có thể đề xuất cách để thực hiện các hoạt động kiểm thử càng sớm càng tốt. Ví dụ phương pháp shift-left testing – dịch chuyển các hoạt động về bên trái – Nghĩa là áp dụng các hoạt động từ những giai đoạn sớm như review (rà soát) tài liệu mô tả yêu cầu, các bản thiết kế, và mã nguồn (source code). Có thể áp dụng quy định như “tài liệu phải được khách hàng duyệt trước khi tiến hành lập trình”
Phân tích kết quả kiểm thử, chất lượng của sản phẩm để cải tiến quy trình làm việc ngày càng hiệu quả hơn trong việc ngăn ngừa lỗi.
Về chất lượng test case
Trong quá trình phân tích yêu cầu hệ thống, tester nên áp dụng các kỹ thuật hộp đen, dựa vào kinh nghiệm để thiết kế test case bao quát hiệu quả và đầy đủ các khía cạnh cần kiểm thử như chức năng, phi chức năng (hiệu năng, tính khả dụng, bảo mật, v.v…) và UI hiển thị tốt trên các trình duyệt phổ biến như Chrome, Firefox, Safari, MS Edge.
Ngoài ra, tester nên sử dụng checklist để giúp thiết kế test case hiệu quả hơn. Ví dụ một số gạch đầu dòng trong một checklist dành cho kiểm thử web
- Accessibility testing
- Functional testing
- Performance testing
- Security testing
- Check browser compatibility
- UI testing
- Cookie testing
Về kiến thức chuyên ngành (domain knowledge)
Ngoài kiến thức nền tảng về kiểm thử phần mềm và kỹ thuật thiết kế test case, tester cần phải nắm vững nghiệp vụ của hệ thống mà mình đang kiểm thử. Để dễ dàng hiểu rõ nghiệp vụ, tester cần được trang bị kiến thức chuyên ngành về lĩnh vực đó, hay được gọi là “domain knowledge.”
Chỉ khi nắm vững nghiệp vụ, tester mới có thể đưa ra danh sách test case hiệu quả nhằm đánh giá phần mềm có đáp ứng yêu cầu của người dùng, và thực sự giúp giải quyết các vấn đề mà người dùng/khách hàng đang gặp phải. Ví dụ một số lĩnh vực phổ biến như hệ thống thương mại điện tử, phần mềm phục vụ trong ngành tài chính ngân hàng, bảo hiểm, chứng khoán, v.v… Hay một số nghiệp vụ phức tạp liên quan đến quản lý bệnh viện/phòng khám, hoặc phần mềm quản lý và điều khiển trên xe ô tô tự lái.
Tóm lại, tuy việc sót bug là không thể tránh khỏi trong quá trình phát triển phần mềm, nhưng điều quan trọng nhất là những bài học kinh nghiệm mà chúng ta rút ra được từ những lần sót bug này. Từ đó, giúp nhóm (hay lớn hơn là cả công ty) nhìn nhận, thay đổi quy trình và cách làm việc để tránh bỏ sót những lỗi tương tự như vậy trong tương lai.
Happy testing!
