Bài viết chuyên sâu

[Software Testing] Log bug sao cho hiệu quả

[Software Testing] Log bug sao cho hiệu quả

by Admin Dathoc -
Number of replies: 0

#koolj_softwaretesting

#buglogging

#chiase


Về công việc: Tìm kiếm bắt lỗi, và ngăn ngừa LỖI PHẦN MỀM sao cho hiệu quả.


Đây gần như là công việc hàng ngày của Tester, xong mình rất thấy ÍT KHI các bạn chia sẻ và các ĐÚC KẾT từ những gì các bạn làm. Có thể các bạn ngại viết hay vì dự án bảo mật không chia sẻ được.


(Mình không rõ cái này có phù hợp với group không nếu OK admin approve, nếu NOT OK admin có thể xoá bài nhé, thanks)


Mình bắt đầu học bắt LỖI PHẦN MỀM - LPM, là một phần công việc của Software Tester, bắt đầu từ 1996, lúc đó tại một công ty gia công phần mềm nhỏ, tên là 24MB, tại Khách sạn Phương Nam II ở Láng Hạ Hà Nội, nền tảng bắt lỗi mình học từ sách The Art of Software Testing (trong phần chia sẻ dathoc.net/booktest), tới 1998 anh em team yêu cầu mình dịch lại sang tiếng Việt Bộ lý thuyết Rational Unified Process - RUP để họ làm phần mềm. Khởi sự là vậy và khi đó anh em có hẳn phần mềm riêng để dành riêng việc Quản trị LPM: tức là nhân viên tester bắt lỗi và log lỗi bằng tay và mắt... từ sản phẩm rồi log lên phần mềm quản trị lỗi đó, devteam đc giao xử lý lỗi, họ vào phần mềm quản trị lỗi xem lỗi và quay lại sản phẩm sửa; và thậm chí hồi 1999-2000 đó anh em còn bán được cái phần mềm đó nữa. Sang giai đoạn 2004 tới 2011, mình chuyển sang tìm và bắt LPM chủ yếu cho các dự án tại FPT. FPT thì lại làm chủ yếu trên Quy trình RUP nêu trên. Vậy anh chị em có thể tham khảo một vài hình ảnh log lỗi và tìm lỗi LPM thế nào từ RUP qua vài ảnh đính kèm dưới.

.

.

Vậy bài viết này nêu một vài quan điểm cá nhân: mà sau mấy chục năm tham gia các dự án làm phần mềm, từ 1996-2021, chia sẻ đúc rút trải nghiệm về công việc tìm kiếm LPM. Mình thấy có thể các bạn nhân viên tester mới vào làm cũng như các bạn đã lâu năm làm nghề kiểm thử/kiểm tra phần mềm ...cũng sẽ thấy hay và nhiều thú vị.


Nếu để nhanh, fans của group có thể vào xem clip YouTube mình làm vắn tắt đây: youtube.com/watch?v=d8ae2PbEOcA

Hoặc đọc các phần đúc rút kinh nghiệm mình viết dưới đây:

.

.

👉Thống nhất khái niệm LỖI PHẦN MỀM -LPM: 

CSTE - QAI 2006: LPM là các vấn đề, dẫn đến các ứng dụng chạy không hiệu quả hoặc theo cách hoạt động không chính xác.

RUP 1987 có khái niệm: Một sự bất thường, hoặc sai sót, trong một sản phẩm/ phần sản phẩm. Một khiếm khuyết hay bất kỳ loại vấn đề nào bạn muốn được theo dõi và giải quyết.

FPT Software 2004 (trải nghiệm cá nhân) định nghĩa: LPM là thứ mà làm phần mềm hoạt động không ổn định. Cái mà tester cần tìm kiếm lỗi càng sớm càng tốt và đảm bảo LPM không còn lưu lại trên hệ thống sản phẩm khi chuyển giao cho khách hàng cuối.


👉Thống nhất quá trình tìm kiếm bắt lỗi và ngăn ngừa lỗi phần mềm (trải nghiệm cá nhân) ở gia công phần mềm CNTT Việt Nam giai đoạn 1996-2021, và có thể 20-50 năm nữa:

- Việc tìm kiếm, truy vết, ngăn ngừa LPM cần bắt đầu, thực thi càng sớm càng tốt trong vòng đời dự án

- Khi phát hiện ra LPM cần có những biện pháp để xử lý, sửa chữa hệ thống với LPM đó, và xác nhận việc sửa chữa tìm ra nguồn gốc LPM đó.

- Khi sửa chữa xong, cần ngăn ngừa LPM không tái hiện hoặc xuất hiện trên sản phẩm nữa.


👉Thống nhất CƠ SỞ - CHUẨN để... tìm kiếm bắt lỗi và ngăn ngừa lỗi phần mềm - để sau này không bị cãi nhau, mâu thuẫn với team khác.

- Dựa trên văn bản yêu cầu functional/non-functional được bóc tách, phân tích, và theo đó xác nhận ĐÚNG/SAI/CHƯA ĐẠT với yêu cầu.

- Dựa trên một số chuẩn làm phần mềm: chuẩn phần mềm cho MS Windows, cho Apple, theo web app Facebook, ...theo tốc độ như tìm kiếm Google, theo chuẩn Payment của VISA, ....theo CMMlv3, theo McCall1977, theo ISO 9001, theo BS2700, theo CSQA của QAI 2006, theo RUP 1987...

- Dựa trên trải nghiệm của chính bản thân đã từng sử dụng phần mềm nhiều năm; hoặc trải nghiệm từ các dự án khác về tình huống hình thái gây LPM, rồi ta so sánh với, coi đó là LPM.


👉Trải nghiệm hình thái LPM - nặng, nghẹ, hiếm gặp, hoặc từ LPM dẫn tới nhiều team cãi nhau và không hiểu tiếng nói của nhau:

- Theo mình 90% lỗi vụn vặt và nhẹ, ngay cả mức trung bình.... (tức là dev dành 3-10 phút hoặc 20 phút để sửa) các bạn sẽ tìm đc trong 2-8h đầu khi tiếp cân module/sản phẩm từ devteam

- Theo mình 90% lỗi khó sửa, khó tìm (devteam cần 1-2 tuần, hoặc thậm chí làm lại phần mềm/module) khi bạn thực hiện performance test hoặc security/penetration test. Có 5% trong số này là sau khi acceptance test, tức là sau khi khách hàng xem và phán... phải làm lại vì nó không giống cái tao nghĩ.

- Theo mình 70% các fans là tester sẽ không rõ hoặc khi log lỗi để devteam xem, luôn bị mâu thuẫn, cãi nhau với devteam, và làm devteam hiểu lầm về LPM đó.... đơn giản là tester log lỗi KHÔNG RÕ NGHĨA; hoặc chưa rõ ràng.


👉Trải nghiệm TỐC ĐỘ log lỗi:

- Ví dụ như team này đang test cho phần mềm game cho play station: God of War, mỗi ngày họ log đc 200 lỗi: youtube.com/watch?v=Yu75J3tku2A&t=906s

- FPT Software thì quy định mỗi ngày nhân viên tester trung bình: log từ 20-50 lỗi; có thể có đột biến: 100-300 lỗi.

.

.

Vậy quá trình tìm kiếm bắt lỗi và ngăn ngừa LPM có thể ở nhiều level testing khác nhau là khác nhau; có thể nhiều dạng sản phẩm khác nhau là khác nhau. Ở đây mình phân ra 2 loại sản phẩm theo trải nghiệm của mình - và kèm theo là các ý kiến làm thế nào cho HIỆU QUẢ:

👉 1. LPM trong việc đi theo quy trình áp dụng dự án đang làm sản phẩm phần mềm

- Cái này chúng tôi hay gọi là LỖI QUY TRÌNH - LQT. Vậy đơn giản khi làm phần mềm, các bạn cứ theo đúng quy trình, hoạt động và làm đúng biểu mẫu là...hết lỗi không thì nhân viên QA sẽ hàng ngày kiểm tra và log lỗi. Có thể team bạn sẽ bị trừ thưởng cuối dự án. Bạn có thể tham khảo Quy trình test, Quy trình làm Yêu cầu trong dathoc.net/booktest

- Có khi Quy trình hay tới mức, nhiều team dự án chúng tôi có...25 người: xong quan sát nhìn thực tế chỉ có ..2 người làm, cho 23 người học hỏi theo vì họ trình còn non. Không biết quan điểm của bạn về Quy trình này thế nào?

- Những LPM - LQT thông thường là: dự án không đi theo các bước quy trình: dự án các phần sp đầu ra thiếu tài liệu; thiếu thuyết phục gọi là xong phần sản phẩm; thiếu thuyết phục gọi là vượt trội nguồn lực so với dự trù; thiếu quản trị giờ đi làm, nghỉ làm; thiếu bước làm theo quy định quy trình....


+ Vậy: Tìm kiếm LQT thế nào cho hiệu quả?

Đơn giản tổ chức FPT chúng tôi có hẳn team đi rà soát và có nhiều CHECKLIST mỗi quy trình mỗi sản phẩm, bạn có thể tham khảo dathoc.net/booktest, các phần template, hoặc checklist.. để xem chúng tôi validate quy trình thế nào.


+ Vậy: Log lỗi thế nào cho hiệu quả, tránh conflict?

Như một mẫu log lỗi trong dathoc.net/booktest, folder test_process, folder template, có file bugs_sample, các bạn sẽ thấy nó có đầy đủ: mô tả lỗi, các bước tạo lại lỗi, bằng chứng, nguồn gốc lỗi, độ ưu tiên, độ nặng nhẹ, loại lỗi, nguyên nhân, cách sửa chữa.... Nếu bạn điền đầy đủ thì...chúng tôi gọi là hiệu quả. Xong để làm thế nào gọi là đầy đủ, bạn xem phần dưới.

---> Để log nhanh: chúng tôi dùng công cụ copy template từng mẫu lỗi; và có công cụ cắt ảnh làm bằng chứng; và có thể 1-2 động tác đã có một lỗi mới; sau đó chỉnh sửa các bước tạo lại lỗi và mô tả lỗi.

---> Để log tránh cãi nhau: khi nêu các bước tạo lỗi: chúng tôi cố gắng nhất có thể mapping vào các phần yêu cầu của sản phẩm; tức là dùng yêu cầu đã nêu đã viết của khách hàng, làm bản lề để xác định lỗi đó có hay không

---> Để log hiệu quả: 

Trong Mô tả lỗi: nêu rõ phần sản phẩm, version, phần chức năng bạn đang bắt, vd: 

[login][eng][client][ui] để mô tả lỗi ở chức năng login, bản tiếng Anh, phần máy trạm, và lỗi UI

hoặc [login][eng][client][sec] để mô tả lỗi ở chức năng login, bản tiếng Anh, phần máy trạm, và lỗi security


Trong Các bước tạo lại lỗi: đây là gần như 99% các bạn tester mô tả không rõ dẫn tới hay...cãi nhau với devteam, hoặc conflict ko rõ ràng với nhiều team khác: Vậy theo tôi bạn cần viết theo KHUNG này:

(bạn có thể tham khảo dathoc.net/booktest, folder test_process, folder template, có file bugs_sample)

Bước 1: làm abc..input data cdef...

Bước 2: làm xyz...thấy output ikgh...

Bước 3: ..làm egh... thấy thông báo, thấy khác thường...

Theo yêu cầu khác hàng... mục1, phần A, gạch đầu dòng 1: hệ thống đi tới A

Hiện trạng tới bước 3: hệ thống lại đi tới ..B

Vậy hệ thống đang xử lý SAI với yêu cầu. Đây là lỗi.


Trong Bằng chứng kèm lỗi: Cần có những ảnh đính kèm, hoặc clip mô tả nếu lỗi là thường gặp. Đặc biệt cần clip ghi lại rõ ràng lỗi khi hiếm gặp, tần suất lỗi xảy ra.


+ Vậy: Ngăn ngừa thế nào cho hiệu quả?

Bạn có thể tham khảo 2 văn bản:

dathoc.net/booktest, folder test_process, folder template, có file bugs_report_sample

dathoc.net/booktest, folder test_process, folder template, có file bugtrend_analysis_sample

Hai văn bản này nói gì:

Trong báo cáo lỗi: Bạn cần nêu rõ tính TRUY VẾT và LOẠI, qua báo cáo hình xương cá (fishbone) hoặc tốc độ gây lỗi, soán chiếm các loại lỗi (pareto chart); hay mật độ để bạn thấy khi nào lỗi loại nào thường tập trung (scatter plot chart)

Trong văn bản họp truy vết lỗi: Tổ chức họp giữa team test và dev, để mổ xẻ vì sao từng loại lỗi lại xuất hiện; vì sao tầt suất như vậy; báo cáo họp, ghi chép và...rút kinh nghiệm từng team trong giai đoạn tiếp theo.

.

.

👉 2. LPM trong phần sản phẩm, module của devteam hoặc, sản phẩm đầu ra của dự án

- Đây là cái mà tester hay va chạm và tìm kiếm LPM nhiều nhất, cũng như dựa vào đó

- Tôi phân ra 2 giai đoạn:

A. Unit và Integration bugs: LPM trong quá trình kiểm thử đơn vị hoặc tích hợp

B. System test bugs: LPM trong quá trình kiểm thử chức năng, hiệu năng, bảo mật

.

.

👉 A. Unit và Integration bugs: LPM trong quá trình kiểm thử đơn vị hoặc tích hợp

1.Tìm kiếm unit bug, integration bug....thế nào cho hiệu quả?

- Đầu tiên, các lỗi gay gặp là: số hàm lớp quá nhiều không theo chuẩn quality code; độ phức tạp của thừa kế vượt ngưỡng 50; bound chưa chuẩn của hàm; thừa biến đếm; thừa bộ nhớ; lỗi bộ nhớ; thừa biến không sử dụng; cận trên cận dưói không thực thi; loop nhiều lần dư thừa; hàm lớp chưa bao giờ được gọi, chạy; thuật toán chạy chậm, lâu không theo chuẩn mong đợi; dữ liệu gửi đi gửi về bị rò rỉ, dễ bị bên thứ 3 xem ngang; ....bạn dựa vào đây rồi thiết kế case, rồi bắt LPM. Như vậy: nếu lỗi tìm ra trong giai đoạn này chi phí của nó sẽ thường là $1-$5/lỗi.

Bạn có thể tham khảo thêm chuẩn coding quality qua sách: CleanCode trong dathoc.net/booktest ..để học cách đào bới ra nhanh LPM.

- Tham khảo các chuẩn Quality Code trong sách, hoặc tôi đã đưa ra trong template ut_checklist và oo_checklist  trong dathoc.net/booktest

- Đây là hai công đoạn mà chính devteam là bên phải tự design testcase và tự thực thi testing; cũng như log lại bug nếu có. Xong ở VN, gia công phần mềm về thời gian dự án không cho phép; nên luôn bỏ qua khâu này; hay nói cách khác team dự án và quan điểm là: thời gian không có; thời gian làm coding sản phẩm đã mệt rồi; lại còn bắt ngồi thực thi testing, và logbug. Dẫn tới nhiều lỗi coi là nhẹ, là nhỏ bị bỏ qua. Xong nếu bạn là quản trị, bạn sẽ thấy các lỗi nhỏ ở đây thông thường sẽ là chi phí trăm đô, ngàn đô nếu bị phát hiện sau này.

- Thứ đến là: nhiều team thường làm Unit Test-UT kiểu: nhờ tester viết case, và họ thực thi trên phần module. Cái này cũng tốt. Còn bên tôi thì thực thi theo mẫu UT từ khách hàng: bạn có thể xem mẫu unittest và integration test trong dathoc.net/booktest, folder template.... rồi thiết kế case, rồi bắt LPM.


2. Log lỗi thế nào cho hiệu quả, tránh conflict?

<tham khảo LOG như "LPM trong việc đi theo quy trình..." nêu>


3. Ngăn ngừa thế nào cho hiệu quả?

<tham khảo LOG như "LPM trong việc đi theo quy trình..." nêu>, bổ sung:

- Tạo nhiều script auto tự động chạy series các unit testcase cho loạt module, chức năng để so sánh các chỉ số Quality Code, trong sách hoặc tôi đã đưa ra trong template ut_checklist và oo_checklist  trong dathoc.net/booktest

.

.

👉 B. System test bugs: LPM trong quá trình kiểm thử chức năng, hiệu năng, bảo mật

1. Tìm kiếm thế nào cho hiệu quả?

- System test bugs: là những lỗi thông thường là SAI về chức năng, về KHÔNG ĐÚNG giao diện UI, về KÉM hiệu năng, về RÒ RỈ bảo mật mà... khi phần mềm đã đóng gói và chuyển giao, sau đó team tester sẽ đào bới tìm kiếm lỗi bằng việc chạy và thực thi các testcase họ thiết kế. Như vậy: nếu lỗi tìm ra trong giai đoạn này chi phí của nó sẽ thường là $10-$100/lỗi.

- Việc tìm nhanh ra rất phụ thuộc: trải nghiệm của bạn với phần mềm; áp dụng chuẩn làm phần mềm; áp dụng chuẩn sử dụng phần mềm và... yêu cầu bóc tách rõ ràng để tester so sánh, để tìm kiếm nhanh ra LPM.

- Tốc độ, hoặc tần suất tìm và loc... đã nêu trên.

- Có lưu ý về Lỗi hiệu năng (đã chia sẻ trong bài viết testing hiệu năng)

- Có lưu ý về Lỗi bảo mật và cách tìm nhanh ra: bạn cứ đối chiếu các case rõ ràng từng bước, từng step...trong OWASP hoặc OSSTMM là ra. Bạn chưa rõ thì Google ra. Tôi hay training từ cái này. Nếu dễ hơn bạn có thể cài WebGoat lên để thực hành trước.


2. Log lỗi thế nào cho hiệu quả, tránh conflict?

<tham khảo LOG như "LPM trong việc đi theo quy trình..." nêu>

3. Ngăn ngừa thế nào cho hiệu quả?

<tham khảo LOG như "LPM trong việc đi theo quy trình..." nêu>

- Với dạng dự án chỉ chấm mút vài phần hệ thống; mà muốn bảo toàn các phần khác: vậy đây là lúc thích hợp nhất bạn xử lý regression test; và áp dụng automation test cho regression test

- Với dạng dự án giám sát và bám vào yêu cầu nào được hoàn thành; vậy bạn áp dụng traceability test

.

.

Vậy các quan điểm trên là cá nhân tôi đúng kết về công việc tìm kiếm, phát hiện, và ngăn ngừa lỗi phần mềm.

Bạn chắc cũng có vài trải nghiệm. Vậy mời bạn cho ý kiến nhé.

Gluk!


--------------------------------

SÁCH - TẠP CHÍ - TÀI LIỆU ĐÚC KẾT KINH NGHIỆM làm về SOFTWARE TESTING cần tham khảo: dathoc.net/booktest

Bạn muốn thông thạo hơn việc viết thiết kế testcase, sử dụng công cụ automation test HERA để auto test, các framework Appium, TestNG, xin tham gia FREE tại: youtube.com/c/TesterPRO/

By: dathoc.net/cv