Sơ lược về biểu đồ xương cá và sử dụng biểu đồ xương cá trong quản lý chất lượng dự án test.

I. Giới thiệu về biểu đồ xương cá

1. Biểu đồ xương cá là gì

・Biểu đồ xương cá, hay còn gọi là biểu đồ Ishikawa hay biểu đồ nguyên nhân - kết quả ( Fishbone diagram, Ishikawa diagram, Cause-and-effect diagram ) là 1 trong 7 công cụ kiểm soát chất lượng cơ bản như liệt kê dưới đây, là một phương pháp nhằm nhận diện vấn đề và đưa ra giải pháp, một trong những yếu tố cốt lõi để xây dựng - đảm bảo - nâng cao chất lượng.

a. Fishbone diagram (Cause-and-effect diagram, Ishikawa diagram): biểu đồ xương cá

b. Check sheet: phiếu (biểu) kiểm tra

c. Control charts: biểu đồ kiểm soát

d. Histogram: biểu đồ phân bố

e. Pareto chart: biểu đồ Pareto

f. Scatter diagram: biểu đồ phân tán

g. Flow charts: biểu đồ dòng chảy

・Công cụ này do giáo sư Kaoru Ishikawa - một giáo sư chuyên ngành kỹ thuật của trường đại học Tokyo sáng chế vào thập niên 50.

・Đây là một biểu kỹ thuật đồ họa, có hình dạng giống xương cá, lấy cơ sở là lý thuyết thống kê, thu thập các dữ liệu theo mục đích đã định, phân tích các dữ liệu để giải quyết hoặc cải tiến vấn đề. Nó được gọi là cơ bản vì 1. ngay cả những người ít được đào tạo về thống kê cũng có thể sử dụng được và 2. nó có thể được sử dụng để giải quyết phần lớn các vấn đề liên quan đến chất lượng.

・Công cụ này đã được áp dụng hiệu quả từ những năm 1960s và đã được người Nhật sử dụng rất thành công.

2. Tác dụng của việc sử dụng biểu đồ xương cá

• Đưa ra một cấu trúc, định hướng cho việc xác định nguyên nhân. -> Giúp cho việc xác định nguyên nhân nhanh chóng và hiệu quả.

• Khi áp dụng biểu đồ này, người dùng sẽ có khả năng tìm ra các nguyên nhân tiềm tàng và nguyên nhân cốt lõi gây nên vấn đề.

• Nhìn vào biểu đồ xương cá này, người đọc sẽ cóhình dung đầy đủ nguyên nhân của một vấn đề . Việc lập biểu đồ sẽ chỉ rõ từng nguyên nhân, từ đó có thể đưa ra hướng giải pháp cụ thể cho từng nguyên nhân một.

3. Cách tạo một biểu đồ xương cá

Bước 1: Xác định vấn đề. Vấn đề này chính là hệ quả của nguyên nhân sẽ xác định.

Bước 2 và bước 3 là xác định nguyên nhân chính và nguyên nhân phụ. Có thể thực hiện theo 1 trong 2 cách sau.

Cách 1:

• Bước 2: Động não, suy nghĩ tỷ mỉ kỹ lưỡng để tìm ra tất cả các nguyên nhân có thể có của vấn đề. Ở bước này chưa phân biệt nguyên nhân chính và nguyên nhân phụ.

• Bước 3: Sắp xếp, tổ chức lại tất cả những kết quả đã động não được. Nhóm các nguyên nhân phụ lại vào trong 1 nguyên nhân chính.

Cách 2:

• Bước 2: Liệt kê danh sách tất cả các nguyên nhân chính của vấn đề. Có thể áp dụng 5W 1H, trả lời cho các câu hỏi What: vấn đề gì, Who: những ai liên quan, When: xảy ra khi nào, Where: Xảy ra ở đâu, Why: Tại sao xảy ra, How: xảy ra như thế nào... để đưa ra nguyên nhân chính

• Bước 3: Tiếp tục động não suy nghĩ những nguyên nhân cụ thể hơn, trực tiếp gây ra nguyên nhân chính (Nguyên nhân cấp 1). Nếu cần phân tích sâu hơn thì tiếp tục tìm ra những nguyên nhân khác nhỏ hơn, trực tiếp gây ra nguyên nhân cấp 1.

Bước 4: Xây dựng một biểu đồ xương cá, hiển thị chính xác mối quan hệ giữa các data trong mỗi category như các bước dưới đây

+Vẽ 1 ô vuông ở ngoài cùng bên tay phải của tờ giấy

+Vẽ 1 mũi tên nằm ngang , hướng đầu mũi tên về phía ô vuông ở trên

+Bên trong ô vuông trên, viết mô tả vấn đề đang cố gắng giải quyết

+Từ trục chính nằm ngang này, vẽ các nhánh chính và viết tên của các category ở phía trên và phía dưới của đường mũi tên nằm ngang trên (Đây như là các cành to của một thân cây chính)

+Từ các nhánh chính này, vẽ các nhánh phụ và viết nguyên nhân chi tiết cho mỗi category (Đây như là các cành nhỏ và các nhánh con)

Mỗi biểu đồ xương cá sẽ có rất nhiều nhánh con. Nếu biểu đồ không có nhiều nhánh con thì nó thể hiện rằng việc hiểu vấn đề còn đang rất hời hợt, chưa hiểu rõ bản chất của vấn đề. Có thể phải cần có sự giúp đỡ của người khác hỗ trợ để hiểu vấn đề, ví dụ như người mà liên quan trực tiếp đến vấn đề.

4. Khi lập biểu đồ xương cá thì cần chú ý các vấn đề sau

• Cần có sự tham gia của tất cả những người có liên quan đến vấn đề, từ người quản lý đến người liên quan trực tiếp và liên quan gián tiếp đến vấn đề. Vấn đề cần được xem xét, phân tích, cần có sự trao đổi ý kiến giữa các bên liên quan trực tiếp và gián tiếp.

• Cần nhìn vấn đề một cách tổng thể toàn diện để có thể tìm ra đầy đủ tất cả các nguyên nhân có thể có.

• Người xây dựng biểu đồ cần biết lắng nghe, tiếp thu ý kiến mà những người có liên quan trực tiếp cũng như gián tiếp đến vấn đề đã đưa ra, tổng hợp, tóm gọn các ý kiến lại.

• Sau khi xây dựng , cần đưa biểu đồ ra để toàn bộ các thành viên review lại, bổ sung và chỉnh sửa nếu cần. Ngoài ra có thể hỏi thêm ý kiến của một vài người khác có kiến thức về hoạt động của quá trình.

II. Sử dụng biểu đồ xương cá trong quản lý chất lượng dự án test

Đối với 1 dự án phần mềm, việc đảm bảo chất lượng của đợt test, không để bỏ sót bug là hết sức quan trọng. Ngay khi phát hiện ra tester đã để lọt bug (kể cả giai đoạn đang test và giai đoạn đã release cho khách hàng) thì chúng ta cần phải tìm ra nguyên nhân vì sao để sót lỗi để có hướng ngăn chặn cho những lần test sau.

Khi điều tra nguyên nhân vì sao để sót lỗi, tôi thấy có thể xảy ra các trường hợp sau:

1. Đã có testcase để check cho trường hợp đó. => Ở đây chúng ta cần phải tìm nguyên nhân Vì sao bug đó đã không được raise lên cho khách hàng ?

1.1 Đã làm đúng toàn bộ các điều kiện phát sinh bug: môi trường, thao tác v.v, bug có xảy ra nhưng lại không report cho khách hàng do:

• Tester không nhận thức đó là bug nên đã không report lên.

• Tester nhận thức đó là bug nhưng lại lack không report lên. Ví dụ tester note lại trong testcase bản cứng hoặc bản mềm, sau đó quên không log trong file defect gửi cho khách hàng.

• Bug đã chỉ phát sinh đúng 1, 2 lần. Sau đó làm lại thì bug không xảy ra nên Tester đã không report. Hoặc để tái hiện, điều tra thì mất thời gian chuẩn bị môi trường, thời gian test không còn nhiều nên đã không có đủ thời gian tìm hiểu lại, nên không report.

• Tester nhận thức là bug, có report lên nhưng bị team leader reject.

• Tester nhận thức là bug, có report lên nhưng team leader đã để sót bug này khi tổng hợp để report cho khách hàng.

1.2 Đã không có đầy đủ các điều kiện phát sinh bug nên khi test, bug đã không xảy ra. Vì thế không phát hiện ra được. TH1：Thao tác test đúng, nhưng môi trường test không đúng (Trường hợp lỗi chỉ xảy ra trên 1 môi trường đặc định).

• Khách hàng có require test trên môi trường đó nhưng lại để sót môi trường.

• Khách hàng có require test trên môi trường đó nhưng khi dựng môi trường lại làm không đúng theo require.

• Windows không được update theo đúng require của khách hàng.
• Môi trường không sạch: ví dụ như trước đó đã thực hiện install, uninstall nhiều lần rồi.
• Thiếu không cài 1 số phần mềm mà khách hàng đã yêu cầu.
• Cài sai version của 1 số phần mềm mà khách hàng đã yêu cầu.

• Khách hàng không require cụ thể mà cho chọn môi trường, và khi test testcase đó thì đã test trên môi trường khác.

• Khách hàng không chỉ định test trên môi trường đó.

TH2： Môi trường test đúng, nhưng thao tác test chưa đúng　(Trường hợp lỗi chỉ xảy ra khi thực hiện đúng theo các bước XYZ).

• Testcase đã ghi thao tác cụ thể và nếu thực hiện theo đúng testcase thì sẽ ra bug. Tuy nhiên tester đã đọc sót testcase, dẫn đến sót thao tác.

• Testcase đã ghi thao tác cụ thể và nếu thực hiện theo đúng testcase thì sẽ ra bug. Tuy nhiên tester đã hiểu sai 1 số thao tác nên đã thực hiện thao tác khác.

• Testcase đã ghi thao tác cụ thể và nếu thực hiện theo đúng testcase thì sẽ ra bug. Tuy nhiên tester đã thực hiện không theo đúng tuần tự các bước đã ghi, ví dụ như thực hiện bước 3 -> bước 2

• Testcase đã ghi thao tác cụ thể và nếu thực hiện theo đúng testcase thì sẽ ra bug. Tuy nhiên trong quá trình thực hiện các bước theo testcase, tester đã thực hiện thêm 1 bước nào đó không ghi trong testcase. Tuy nhiên tester lại nhận thức rằng đáng lẽ phải có thêm bước đó, và cũng không confirm lại với khách hàng khi thấy testcase không ghi bước đó.

• Testcase đã ghi thao tác cụ thể và nếu thực hiện theo đúng testcase thì sẽ ra bug. Tuy nhiên trong quá trình thực hiện các bước theo testcase, tester đã vô tình thực hiện thêm 1 bước nào đó không ghi trong testcase.

• Testcase không ghi thao tác cụ thể, và tester có thể thao tác theo nhiều kiểu khác nhau đều sẽ ra kết quả xác nhận. Và thực tế thì thao tác mà tester đã thực hiện không đúng với thao tác để có thể sinh ra bug.

1.3 Tester đã không test testcase đó

• Khách hàng có require test testcase đó nhưng do leader hiểu sai requirement nên đã không giao cho tester test

• Khách hàng có require test testcase đó nhưng trong quá trình giao testcase cho tester, leader đã bị giao sót testcase đó: ví dụ in sót, hoặc in bị lỗi, hoặc testcase đó vô tình bị bôi đen đi.

• Leader có giao testcase đó nhưng Tester đã bị bỏ sót không test testcase đó.

• Khách hàng cho phép chọn testcase random và leader đã không chọn testcase đó.

• Khách hàng cho phép chọn testcase random và leader để cho tester tự chọn. Bản thân tester đã không chọn testcase đó.

• Khách hàng đã không yêu cầu test testcase đó

2. Đã không có testcase check cho trường hợp đó => Ở đây chúng ta cần phải trả lời cho câu hỏi Vì sao testcase đó đã không được add vào ?

• Testcase do khách hàng cung cấp, khách hàng đã không tạo testcase đó.
• Testcase do dự án viết theo những chỉ định của khách hàng. Trong nội dung chỉ định thì đã không có nội dung đó.
• Testcase do dự án viết theo chỉ định của khách hàng. Trong nội dung chỉ định có trường hợp đó nhưng người viết đã bị bỏ sót.
• Testcase do dự án viết theo chỉ định của khách hàng. Trong nội dung chỉ định thì có nội dung đó, nhưng khi viết testcase đã không cover được hết các trường hợp thao tác.

=>=>Từ việc tìm hiểu các nguyên nhân như trên chúng ta có thể đưa ra biểu đồ xương cá với các nguyên nhân chính và nguyên nhân phụ như sau.

Nhìn vào biểu đồ trên, ta có thể thấy ở tất cả các giai đoạn của quá trình test, nếu chúng ta không làm tốt từng giai đoạn, không kiểm soát chặt chẽ chất lượng từng giai đoạn thì giai đoạn nào cũng có thể là nguyên nhân dẫn đến bị bỏ sót bug. Ví dụ như ngay từ bước tạo file requirement chỉ thị nội dung test, nếu bản requirement có format khó đọc, khó nhìn, dễ gây hiểu lầm, hay nội dung liên tục bị update lại thì sẽ làm cho người được chỉ thị dễ bị hiểu sai, sót requirement -> bỏ sót nội dung cần test -> để sót bug (test lead hay tester). Hoặc giai đoạn report cuối cùng, nếu việc quản lý file log bug không tốt, thì cũng dễ dẫn đến leader report sót bug cho khách hàng.

Trên đây mình đã đưa ra những nguyên nhân có thể dẫn đến bỏ sót bug. Hi vọng nó sẽ giúp các bạn đang quản lý dự án test cũng như các bạn đang thực hiện việc test có cái nhìn đầy đủ về tổng thể dự án, có biện pháp quản lý chất lượng cho từng giai đoạn để đảm bảo chất lượng chung của cả dự án.