Phân tích nguyên nhân gốc rễ là gì?
Khi phát hiện ra lỗi, chúng ta có thể cố gắng tìm ra nguyên nhân gốc rễ của chúng, nguyên nhân thực sự mà chúng đã xảy ra.
Có một số cách để thực hiện phân tích nguyên nhân gốc rễ, ví dụ brainstorming (động não) các ý tưởng và thảo luận về chúng.
Ví dụ: giả sử một tổ chức gặp sự cố với việc in ấn liên tục bị lỗi. Một số người bảo trì CNTT họp lại với nhau để xem xét vấn đề và họ bắt đầu bằng cách suy nghĩ về tất cả các nguyên nhân có thể gây ra lỗi. Sau đó, họ nhóm chúng thành các danh mục và xem có nguyên nhân cơ bản hay nguyên nhân gốc rễ phổ biến hay không. Một số nguyên nhân rõ ràng mà họ phát hiện ra có thể là:
- Máy in hết nguồn cung cấp (mực hoặc giấy).
- Phần mềm trình điều khiển máy in bị lỗi.
- Phòng máy in quá nóng đối với máy in và máy in bị kẹt.
Phân tích nguyên nhân trước mắt?
Đây là những nguyên nhân trước mắt. Nếu chúng ta nhìn vào một trong số những nguyên nhân: “Máy in hết nguồn cung cấp (mực hoặc giấy)”, điều này có thể xảy ra vì:
- Không ai chịu trách nhiệm kiểm tra mức giấy và mực trong máy in; Nguyên nhân gốc rễ có thể: không có quy trình kiểm tra mực / giấy máy in trước khi sử dụng.
- Một số nhân viên không biết cách thay hộp mực; nguyên nhân gốc rễ có thể: nhân viên không được đào tạo hoặc hướng dẫn chăm sóc máy in.
- Không có nguồn cung cấp hộp mực hoặc giấy thay thế; nguyên nhân gốc rễ có thể: không có quy trình kiểm soát và đặt hàng.
Nếu thử nghiệm của bạn chỉ giới hạn trong phần mềm, bạn có thể nhìn vào chúng và nói “Đây không phải là vấn đề phần mềm, vì vậy chúng không liên quan đến chúng tôi!”. Vì vậy, với tư cách là người kiểm tra phần mềm, chúng ta có thể tự giới hạn mình trong việc báo cáo lỗi driver của máy in.
Nhiệm vụ của tester chỉ nằm ở phần mềm?
Tuy nhiên, nhiệm vụ của tester có thể nằm ngoài cả phần mềm; họ có thể phải xem xét toàn bộ hệ thống bao gồm cả phần cứng và firmware. Ngoài ra, ngay cả khi nhiệm vụ của họ là phần mềm, thì tester cũng muốn xem xét cách phần mềm có thể giúp người dùng ngăn chặn hoặc giải quyết sự cố.
Phần mềm có thể cung cấp giao diện (UI) giúp người dùng dự đoán khi nào giấy hoặc mực sắp hết, hướng dẫn từng bước đơn giản để giúp người dùng thay đổi hộp mực hoặc bổ sung giấy. Hay phần mềm cũng có thể đưa ra cảnh báo nhiệt độ cao do đó yếu tố môi trường có thể quản lí được.
Là một tester, ngoài việc suy nghĩ về các defect, hãy suy nghĩ về bất kì nguyên nhân tiềm ẩn nào dẫn đến failure.
Chúng ta sử dụng kiểm thử để giúp tìm ra các fault và các lỗi tiềm ẩn trong quá trình phát triển, bảo trì và vận hành phần mềm. Giúp giảm nguy cơ lỗi xảy ra trong môi trường vận hành và góp phần vào chất lượng của hệ thống phần mềm.
Mọi defect đều phải được sửa chữa?
Không phải tất cả các defect và failure đều được sửa chữa. Các lập trình viên và những người khác có thể sửa chữa các defect trước khi đưa hệ thống vào vận hành, nhưng cũng có thể sẽ làm việc song song với các failure đó.
Việc sửa chữa một defect có khả năng đưa ra một defect. Điều này đặc biệt đúng nếu chúng ta đang sửa chữa một defect dưới áp lực. Vì lý do này, các dự án sẽ đôi khi quan điểm rằng họ sẽ trì hoãn việc sửa lỗi. Điều này không có nghĩa là việc người kiểm thử làm là đã lãng phí thời gian. Sẽ rất hữu ích khi biết rằng có vấn đề và chúng ta có thể giúp người dùng khắc phục và phòng tránh nó.
Có cần kiểm thử nghiêm ngặt?
Kiểm thử càng nghiêm ngặt, càng tìm thấy nhiều lỗi. Kiểm thử nghiêm ngặt không nhất thiết có nghĩa là kiểm thử nhiều hơn; mục đích của kiểm thử là để tìm ra defect – có thể đưa ra một số lượng bài kiểm thử nhỏ nhưng đủ tính khắt khe, thì còn tốt hơn số lượng lớn nhưng lại không đảm bảo tính này.
Chiến lược để đối phó với error, fault và failure là cố gắng ngăn chặn chúng, và ta đã xem xét việc xác định nguyên nhân của các defect và failure.
Khi bắt đầu một dự án mới, ta học hỏi từ những vấn đề gặp phải trong các dự án trước đó. Hiểu được nguyên nhân gốc rễ của các defect là một khía cạnh quan trọng của hoạt động đảm bảo chất lượng, và việc kiểm thử góp phần giúp xác định các defect càng sớm càng tốt trước khi phần mềm được sử dụng.
Tester quan tâm đến việc xem xét các defect được tìm thấy trong các dự án, để có thể cải thiện quy trình. Cải tiến quy trình phải ngăn ngừa những defect đó tái diễn và do đó, cải thiện chất lượng của các hệ thống trong tương lai. Các tổ chức nên coi kiểm thử là một phần của chiến lược đảm bảo chất lượng, bao gồm các hoạt động khác (ví dụ: tiêu chuẩn phát triển, đào tạo và phân tích nguyên nhân gốc rễ).
Ở phần tiếp theo, chúng ta sẽ cùng tìm hiểu về một số nguyên lý kiểm thử khác. Hãy cùng đón đọc nhé!
Bản gốc Tiếng Anh các bạn có thể Tải về Tại đây.
