Tips to Apply Root Cause Analysis for Software Quality
Bài viết được dịch từ: http://www.softwaretestingmagazine.com/knowledge/tips-to-apply-root-cause-analysis-for-software-quality/ Phân tích nguồn gốc nguyên nhân (RCA) là một phương pháp được sử dụng trong chất lượng phần mềm để xác định nguồn gốc nguyên nhân của lỗi hoặc vấn đề và đề xuất phương ...
Bài viết được dịch từ: http://www.softwaretestingmagazine.com/knowledge/tips-to-apply-root-cause-analysis-for-software-quality/
Phân tích nguồn gốc nguyên nhân (RCA) là một phương pháp được sử dụng trong chất lượng phần mềm để xác định nguồn gốc nguyên nhân của lỗi hoặc vấn đề và đề xuất phương pháp thay thế khi xem xét các dấu hiệu. Trong bài báo này, tác giả Mush Honda giải thích rằng RCA có thể được dùng để người dùng cuối phản hồi đánh giá giống như phần mềm bị sai lệch trong khâu kiểm thử và cung cấp một vài lời khuyên hữu ích trong việc làm thế nào để ứng dụng RCA.
Khi một phần mềm sai lệch được xác định trong sản xuất hoặc trong môi trường sống, thì tình huống đó luôn luôn nhanh chóng được fix và cung cấp môi trường làm việc hoàn hảo như mong đợi. Mọi người quá tập trung vào việc giải quyết vấn đề (issue) đến nỗi họ thường quên việc tìm kiếm nguyên nhân. Bởi vậy bằng việc ứng dụng Phân tích nguồn gốc nguyên nhân (RCA) với các lỗi phần mềm, bạn có thể đi từ những dấu hiệu trực quan đơn giản và không thể phát hiện ra nguyên nhân sâu xa vấn đề của bạn. Nếu bạn sai trong việc xác định nguồn gốc nguyên nhân, đó sẽ là cơ hội tốt mà bạn sẽ tìm kiếm nguyên do trong quá trình thao tác kiểm thử, gắn dấu hiệu sử lý nhưng không bao giờ tìm kiếm nguồn gốc.
Một người ứng dụng phân tích nguồn gốc nguyên nhân thành công sẽ phát hiện ra tại sao những dấu hiệu hoặc vấn đề đang xảy ra, đang có thể, bạn cần định hình một chiến lược giảm nhẹ. Đó là một cơ hội cho đội nhóm của bạn cùng tham gia, học hỏi và nhận được kết quả tốt hơn với những phần mềm tương tự. Gắn lỗi (Fix) nguồn có thể cũng giảm bớt những dấu hiệu khác mà bạn đã không thông báo mà được đưa ra trong các liên kết, sau cùng, nó là kết quả trong một quy trình vận chuyển hiệu quả với chất lượng cao. Nhưng nên ứng dụng nó ở đâu và như thế nào?
Khi gặp một vấn đề mà nguyên nhân theo một sơ đồ kín hoặc hiệu ứng tác động phát sinh, bạn cần 1 hệ thống thay thế để thay thế nhanh và hiệu quả. Bạn có thể ứng dụng phương pháp dịch vụ thỏa thuận mức dịch vụ cao để thẩm định và phân tích nguồn gốc nguyên nhân. Bất cứ khi nào một sự chệch hướng nghiêm trọng được xác định, bạn phải đánh giá mức độ trầm trọng và có kế hoạch giảm nhẹ nguyên nhân, tương tự khi bạn fix lỗi với các dấu hiệu được xác định trong thời gian ngắn.
Bạn cần thực hiện việc fix các dấu hiệu tương đồng với kết quả phân tích nguyên nhân để giảm thiểu tối đa hiệu ứng không mong muốn. Chuyển tới sự đồng bộ trong chu trình thời gian và nhắm tới việc hoàn thành việc fix lỗi và đánh giá trong vài giờ (dĩ nhiên trong 24h) của mức độ trầm trọng cao gửi phản hồi về lỗi. Có những lỗi được phân tán cho các đội ngũ hoặc đội hỗ trợ có thể sẵn sàng giúp đỡ, hoặc đội ngũ của bạn có thể làm thêm giờ.
Phần mềm, các mẫu tài liệu như TestPlan, test case hay test report… hoặc thậm chí là định dạnh các file mà bạn sử dụng để capture dữ liệu thích hợp hoặc là bất cứ thứ gì trong quá trình làm việc của bạn để tạo hiệu quả tốt nhất cho team bạn đang làm. Nó có thể là 1 file: Excel spreadsheet, tài liệu Word hoặc một tool đặc biệt nào đó. Nhưng tối thiểu bạn phải có định hướng suy nghĩ về những vấn đề sau đây:
1. Đưa ra vấn đề - Triệu trứng của vấn đề là gì? Bạn đã tham gia vào việc giải quyết vấn đề đó như thế nào? Tác động của tài chính và nghiệp vụ là gì? Điều chính xác đã xảy ra là gì?
2. Root cause - Nguyên chính của issue là gì? Bạn đã làm như thế nào mà đã thiếu nó trong suốt quá trình test? Có phải khoảng cách là do sự thay đổi ở đâu đó không được đánh giá chính xác giữa quá trình test và quá trình implement? Bạn có thể xác định được khoảng trống đó trong effort test của bạn hay không?
3. Chiền lược giảm nhẹ - Bạn đã làm gì để giải quyết vấn đề? Triệu trứng của vấn đề được giải quyết như thế nào? Bạn có thể cải tiến nó thông qua giao tiếp hoặc quy trình để tránh issue tương tự sẽ xảy ra sau này không? Bạn đã thực hiện thẩm định đánh giá để đảm bảo rằng bất kỳ sửa chữa không thực sự gây ra một vấn đề?
4. Xu hướng chung - Đảm bảo rằng issue của bạn được phân loại, sao cho tất cả những vấn đề của bạn được tập hợp và phân tích mà không vượt quá thời gian để có thể đưa ra xu hương chung. Loại vấn đề thường gặp nhất là gì? Những gì có thể được thực hiện, chiến lược chung thu thập được để giảm thiểu những vấn đề đó là gì? Hãy nhớ rằng tất cả mọi người nên làm việc chung để xác định những ý tưởng sẽ được cải thiện theo cách deliver phần mềm của bạn.
Điều quan trọng về phản hồi của người sử dụng cuối được chấp nhận rộng rãi, nhưng nó không phải luôn luôn được bao gồm trong cách tiếp cận RCA. Nếu bạn đang thu thập rất nhiều dữ liệu về cách người dùng tương tác với phần mềm của bạn, yêu cầu họ thực hiện khảo sát và báo cáo thêm chi tiết về các vấn đề và lỗi mà họ gặp phải, thì bạn cũng trộn nó vào hỗn hợp.
Sắp xếp phản hồi của người dùng để xác định các vấn đề phổ biến. Nhóm hỗ trợ IT/ khách hàng có thể xem lại dữ liệu này và đảm bảo rằng các triệu chứng ngay lập tức được giải quyết, trong khi nhóm QA thu thập phản hồi và đánh giá các vấn đề, giống như bạn sẽ làm trong RCA thông thường.
Ý tưởng là cung cấp đầu vào hữu ích cho các nhóm kinh doanh và các bên liên quan về cách ngăn chặn những vấn đề tương tự như cắt xén nhiều lần. Đây là thông tin phản hồi có giá trị cho các bên liên quan để hiểu cách ứng dụng của họ đang được sử dụng trong thế giới thực, nhưng nó cũng có thể chứng minh rất hữu ích cho người kiểm tra, vì nó giúp họ hiểu ngữ cảnh miền một cách chi tiết hơn.
Nếu phản hồi của người dùng được nhóm lại cùng với tất cả các RCA khác dựa trên các defect, sau đó bạn bắt đầu tạo ra một cái nhìn tổng quan rõ ràng về những xu hướng cho mặt kinh doanh thực tế. Đó là một lộ trình để bao phủ tốt hơn, và nó báo cho các phương pháp tiếp cận trong tương lai của cả nhóm, cho họ những hiểu biết có giá trị. Bằng cách sử dụng Phân tích Nguyên nhân Bằng cách này, bạn có thể tập trung vào những gì sẽ mang lại những lợi ích kinh doanh lớn nhất và nâng cao chất lượng phần mềm của bạn cho người dùng cuối.
Giới thiệu về tác giả
Mush Honda là Phó Giám đốc Thử nghiệm cho KMS Technology, nhà cung cấp các dịch vụ CNTT trong toàn bộ vòng đời phát triển phần mềm với các văn phòng tại Atlanta, GA và Thành phố Hồ Chí Minh, Việt Nam. Trước đây ông từng là người thử nghiệm tại Ernst & Young, Nexidia, Colibrium Partners và Connecture. Các dịch vụ KMS bao gồm quản lý ứng dụng, kiểm tra, hỗ trợ, dịch vụ chuyên nghiệp và tăng cường đội ngũ nhân viên.