Chào mừng các bạn quay trở lại với chuỗi bài viết “Lộ trình Kỹ sư QA (Tester)”! Sau khi đã cùng nhau tìm hiểu về các mô hình phát triển phần mềm (Các Mô Hình SDLC: Agile, V-Model, và Waterfall), các phương pháp Agile phổ biến (Vai trò của Kỹ sư QA trong các Phương pháp Phát triển Agile), và đặc biệt là cách xây dựng các trường hợp kiểm thử (Cách Viết Kế Hoạch Kiểm thử, Trường hợp Kiểm thử và Kịch bản Kiểm thử Hiệu quả) hay báo cáo kết quả kiểm thử (Báo cáo Kết quả Kiểm thử để Nhà phát triển Cảm ơn Bạn), chúng ta đã tích lũy được nền tảng vững chắc về việc tìm ra lỗi.
Tuy nhiên, hành trình của một Kỹ sư QA không chỉ dừng lại ở việc tìm ra lỗi và báo cáo chúng. Một trong những kỹ năng quan trọng nhất để trở thành một QA thực thụ và được các nhà phát triển “cảm ơn” (như tiêu đề bài viết trước đã gợi ý) là khả năng điều tra sâu hơn về *nguyên nhân gốc rễ* của thất bại kiểm thử. Khi một bài kiểm thử tự động (như các bài viết về Cypress cho Kiểm thử API và Giao diện Người dùng hay Tự động hóa Kiểm thử Backend với Postman, Newman và REST Assured) hoặc thậm chí là kiểm thử thủ công báo cáo lỗi, thông tin ban đầu thường chỉ là triệu chứng.
Ví dụ: “Không thể click vào nút Mua hàng” hoặc “API trả về lỗi 500”.
Những thông báo này cung cấp thông tin *gì đã xảy ra*, nhưng không giải thích *tại sao nó xảy ra*. Để tìm hiểu *tại sao*, chúng ta cần “nhìn” sâu hơn vào bên trong ứng dụng và môi trường chạy thử nghiệm. Đây chính là lúc các công cụ giám sát và phân tích dữ liệu phát huy sức mạnh. Bài viết này sẽ tập trung vào ba công cụ phổ biến và cực kỳ hữu ích mà Kỹ sư QA hiện đại nên làm quen: Grafana, Kibana, và Sentry.
Mục lục
Thách Thức Khi Điều Tra Thất Bại Kiểm Thử
Khi một bài kiểm thử thất bại, đặc biệt là trong môi trường CI/CD tự động (Roadmap Lộ trình học Kỹ sư QA (Tester) 2025 thường bao gồm CI/CD), việc xác định nguyên nhân có thể tốn rất nhiều thời gian nếu không có các công cụ phù hợp. Các vấn đề có thể rất đa dạng:
- **Lỗi ứng dụng (Application Errors):** Exception, crash, logic sai trong code.
- **Vấn đề môi trường (Environment Issues):** Database lỗi, network chập chờn, dịch vụ bên thứ ba không phản hồi, thiếu tài nguyên (CPU, RAM).
- **Lỗi dữ liệu (Data Issues):** Dữ liệu test không hợp lệ hoặc bị thiếu.
- **Vấn đề về hiệu năng (Performance Issues):** Ứng dụng phản hồi chậm dẫn đến timeout trong test tự động.
- **Lỗi kiểm thử (Test Flakiness):** Bản thân bài test không ổn định (một chủ đề nâng cao hơn).
Theo truyền thống, việc điều tra thường bao gồm việc tìm kiếm thủ công trong các file log phân tán, kiểm tra trạng thái server bằng dòng lệnh, hoặc dựa vào nhà phát triển để debug. Quá trình này chậm, kém hiệu quả và thường không cung cấp cái nhìn toàn diện về những gì đã xảy ra trong hệ thống *tại thời điểm* thất bại.
Các công cụ giám sát và phân tích dữ liệu giúp chúng ta thu thập, tập trung và trực quan hóa thông tin từ nhiều nguồn khác nhau (log, metric, error) để nhanh chóng xác định manh mối và nguyên nhân gốc rễ.
Grafana: Bảng Điều Khiển Trực Quan Về Sức Khỏe Hệ Thống và Kết Quả Kiểm Thử
Grafana là một nền tảng phân tích và giám sát nguồn mở hàng đầu. Nó cho phép bạn tạo các bảng điều khiển (dashboards) mạnh mẽ và tùy chỉnh để trực quan hóa dữ liệu từ nhiều nguồn khác nhau (database, hệ thống thu thập metric như Prometheus, InfluxDB, Graphite, v.v.).
Đối với Kỹ sư QA, Grafana không chỉ là công cụ của Ops hay Devops. Nó là một trợ thủ đắc lực để:
- **Giám sát kết quả kiểm thử theo thời gian:** Tạo dashboard hiển thị tỷ lệ pass/fail của các bộ test tự động theo từng bản build, từng môi trường. Giúp nhanh chóng nhận diện xu hướng và phát hiện khi nào chất lượng bắt đầu đi xuống.
- **Theo dõi hiệu năng ứng dụng trong lúc chạy test:** Kết hợp dữ liệu metric của ứng dụng (CPU, RAM, network traffic, số lượng request, thời gian phản hồi API) với thời gian chạy test. Nếu một bài test hiệu năng (Kiểm thử Tải, Kiểm thử Sức chịu tải, và Kiểm thử Hiệu năng) thất bại, bạn có thể nhìn vào Grafana để xem liệu có sự kiện nào bất thường về tài nguyên hệ thống xảy ra cùng lúc không.
- **Đối chiếu thất bại với tình trạng môi trường:** Dashboard có thể hiển thị metric từ database, message queues, hoặc các dịch vụ phụ thuộc khác. Một bài test thất bại có thể do database bị quá tải chứ không phải do lỗi trong ứng dụng chính.
Ví dụ sử dụng Grafana cho QA:
Bạn có thể tạo một dashboard với các panel sau:
- Panel 1: Biểu đồ đường hiển thị tỷ lệ Passed/Failed/Skipped của bộ test hồi quy tự động trong 24 giờ qua.
- Panel 2: Biểu đồ cột hiển thị thời gian chạy trung bình của các bộ test chính.
- Panel 3: Biểu đồ đường hiển thị mức sử dụng CPU và RAM của server ứng dụng trong cùng khoảng thời gian.
- Panel 4: Biểu đồ đường hiển thị thời gian phản hồi trung bình của API quan trọng mà các test đang gọi.
Khi thấy tỷ lệ fail tăng đột biến trong Panel 1, bạn ngay lập tức có thể nhìn sang Panel 3 và 4 để xem liệu có tương quan với sự tăng vọt tài nguyên hay giảm sút hiệu năng không. Đây là bước đầu tiên để khoanh vùng vấn đề.
Cấu hình một panel hiển thị CPU usage có thể trông như sau (ngôn ngữ query tùy thuộc vào nguồn dữ liệu, ví dụ Prometheus Query Language – PromQL):
rate(node_cpu_seconds_total{mode="idle"}[5m]) * 100 # Hiển thị % CPU idle, có thể đổi sang mode="user", "system" để xem mức sử dụng
Hoặc một panel hiển thị số lượng test thất bại từ một nguồn dữ liệu test results (giả định):
count(test_run_status{status="failed"}) by (test_suite) # Đếm số test failed theo test suite
Khả năng tùy chỉnh và kết nối với nhiều nguồn dữ liệu biến Grafana thành trung tâm giám sát cho QA.
Kibana: Thám Tử Log cho Mọi Vấn Đề
Kibana là một phần của bộ công cụ ELK Stack (Elasticsearch, Logstash, Kibana) hoặc hiện đại hơn là Elastic Stack. Elasticsearch là cơ sở dữ liệu tìm kiếm và phân tích phân tán, Logstash (hoặc Beats) thu thập và xử lý log, còn Kibana là giao diện người dùng để tìm kiếm, phân tích và trực quan hóa dữ liệu trong Elasticsearch.
Log là “nhật ký” chi tiết của ứng dụng, ghi lại mọi hoạt động quan trọng, thông báo lỗi, cảnh báo, thông tin debug, v.v. Khi một bài kiểm thử thất bại, log là một trong những nguồn thông tin quý giá nhất để hiểu chính xác trình tự các sự kiện đã dẫn đến thất bại đó.
Kibana cung cấp cho Kỹ sư QA khả năng:
- **Tìm kiếm log hiệu quả:** Thay vì mở hàng tá file log trên server, bạn có thể tìm kiếm tập trung trên Kibana với các bộ lọc mạnh mẽ (theo thời gian, cấp độ log – INFO, WARN, ERROR, DEBUG, theo nội dung log, theo ID request, ID user, v.v.).
- **Phân tích ngữ cảnh lỗi:** Khi tìm thấy một dòng log lỗi, Kibana cho phép bạn dễ dàng xem các dòng log xung quanh (trước và sau) để hiểu bối cảnh hệ thống lúc đó.
- **Trực quan hóa xu hướng log:** Tạo dashboard trong Kibana để xem số lượng lỗi/cảnh báo theo thời gian, theo service, theo môi trường.
Ví dụ sử dụng Kibana cho QA:
Một bài test API thất bại với lỗi 500. Báo cáo test có thể chỉ ghi lại response status code. Để điều tra:
- Xác định thời điểm bài test thất bại và ID request (nếu có trong báo cáo test hoặc log test runner).
- Mở Kibana, chọn khoảng thời gian tương ứng.
- Nhập query tìm kiếm. Ví dụ: `level: ERROR AND request_id: “ABC-123″` (trong đó “ABC-123” là ID request).
- Kibana sẽ hiển thị các dòng log lỗi khớp với tiêu chí tìm kiếm. Bạn có thể tìm thấy một stack trace chi tiết hoặc thông báo lỗi nghiệp vụ cụ thể.
- Nếu không có ID request, bạn có thể tìm kiếm dựa trên thời gian và các thông tin khác có thể biết (ví dụ: user test, endpoint API bị gọi). Query có thể là: `level: (ERROR OR WARN) AND user: “test_user_api”`.
Việc sử dụng Kibana đòi hỏi ứng dụng phải được cấu hình để đẩy log tập trung vào Elasticsearch. Khi đó, Kỹ sư QA có thể tự mình điều tra phần lớn các vấn đề liên quan đến log mà không cần nhờ đến nhà phát triển.
# Ví dụ cú pháp KQL (Kibana Query Language)
status: 500 AND path: "/api/v1/orders" AND timestamp >= "now-15m"
# Tìm log liên quan đến một user cụ thể trong 30 phút qua
user.id: "user123" AND timestamp >= "now-30m"
# Tìm log cảnh báo hoặc lỗi từ một service nhất định
level: (WARN OR ERROR) AND service.name: "payment-service"
Sức mạnh của Kibana nằm ở khả năng tìm kiếm nhanh chóng và linh hoạt trên một lượng lớn dữ liệu log.
Sentry: Phát Hiện Lỗi Ứng Dụng Ngay Lập Tức
Sentry là một nền tảng giám sát lỗi thời gian thực, giúp nhà phát triển phát hiện, khắc phục và ưu tiên các lỗi trên ứng dụng của họ. Sentry tập trung vào việc thu thập các ngoại lệ (exceptions), lỗi (errors) và sự cố (crashes) xảy ra trong ứng dụng (frontend và backend).
Đối với Kỹ sư QA, Sentry cực kỳ hữu ích vì:
- **Tự động báo cáo lỗi ứng dụng:** Khi một bài test (thủ công hoặc tự động) kích hoạt một ngoại lệ không được xử lý trong ứng dụng, Sentry sẽ tự động bắt lấy lỗi đó và tạo một event.
- **Cung cấp thông tin chi tiết về lỗi:** Mỗi event trong Sentry chứa stack trace chi tiết, ngữ cảnh thực thi (request payload, user info, phiên trình duyệt, hệ điều hành, phiên bản code), giúp dễ dàng xác định nguyên nhân và vị trí lỗi trong mã nguồn.
- **Liên kết lỗi với bản release:** Sentry có thể tích hợp với quy trình triển khai để biết lỗi xảy ra trên phiên bản code nào.
Ví dụ sử dụng Sentry cho QA:
Bạn đang thực hiện kiểm thử một tính năng mới. Khi thực hiện một action nào đó (ví dụ: submit form), ứng dụng gặp lỗi và không hoạt động như mong đợi (UI có thể bị treo, hiển thị thông báo lỗi chung chung, hoặc không có gì xảy ra). Thay vì chỉ báo cáo “Tính năng XYZ lỗi khi submit form”, bạn có thể:
- Ghi lại chính xác các bước thực hiện và dữ liệu test.
- Mở Sentry (nếu ứng dụng được tích hợp).
- Tìm event lỗi mới nhất xảy ra gần thời điểm bạn thực hiện action đó, có thể lọc theo user test của bạn (nếu được cấu hình).
- Xem chi tiết event lỗi trong Sentry. Bạn sẽ thấy stack trace chỉ ra dòng code bị lỗi, giá trị các biến, thông tin request, v.v.
- Báo cáo lỗi cho nhà phát triển kèm theo link đến event Sentry đó. Thông tin chi tiết này giúp Dev dễ dàng tái hiện và khắc phục lỗi.
Sentry đặc biệt mạnh mẽ trong việc theo dõi các lỗi xảy ra trên môi trường staging hoặc production trong quá trình kiểm thử, cung cấp bằng chứng rõ ràng về các vấn đề ổn định của ứng dụng.
Kết Hợp Sức Mạnh: Grafana, Kibana, và Sentry Cùng Nhau
Sức mạnh thực sự đến từ việc sử dụng các công cụ này một cách kết hợp. Chúng cung cấp các góc nhìn khác nhau về cùng một hệ thống và có thể bổ sung cho nhau trong quá trình điều tra.
Hãy xem xét kịch bản điều tra thất bại phức tạp hơn:
- Bạn nhận thấy tỷ lệ test tự động thất bại tăng vọt trên dashboard Grafana của bộ test hồi quy hàng đêm.
- Trên cùng dashboard Grafana, bạn nhìn vào các panel hiển thị metric hệ thống và nhận thấy lượng request đến một service backend cụ thể tăng đột biến, cùng với sự gia tăng về thời gian phản hồi của service đó.
- Bạn nghi ngờ có vấn đề về hiệu năng hoặc tải trên service backend đó. Bạn chuyển sang Kibana, lọc log của service backend đó trong khoảng thời gian xảy ra sự cố. Bạn tìm kiếm các log cảnh báo (WARN) hoặc lỗi (ERROR) và có thể thấy các thông báo về timeout khi gọi đến database hoặc một service nội bộ khác.
- Đồng thời, bạn kiểm tra Sentry và phát hiện một loạt các exception mới được ghi lại từ service backend đó, có thể là lỗi kết nối database hoặc lỗi logic khi xử lý lượng request lớn.
Bằng cách kết hợp thông tin từ cả ba nguồn, bạn có thể nhanh chóng khoanh vùng vấn đề: tỷ lệ test fail tăng là triệu chứng, nguyên nhân có thể là do service backend bị quá tải (thấy trên Grafana), dẫn đến timeout/error khi gọi DB/service khác (thấy trên Kibana), gây ra các exception (thấy trên Sentry), làm cho các bài test phụ thuộc vào service đó thất bại.
Bảng tóm tắt vai trò của từng công cụ trong bối cảnh QA:
| Công cụ | Mục đích chính (trong bối cảnh QA) | Loại dữ liệu chính | Điều tra thất bại | Giám sát |
|---|---|---|---|---|
| Grafana | Trực quan hóa metric hệ thống và kết quả kiểm thử | Metric (hiệu năng, tài nguyên, kết quả test) | Tìm tương quan giữa test failure và các bất thường về hiệu năng/tài nguyên | Theo dõi xu hướng kết quả test, hiệu năng hệ thống theo thời gian |
| Kibana | Tìm kiếm và phân tích log tập trung | Log (thông tin hệ thống, nghiệp vụ, debug) | Tìm nguyên nhân gốc rễ của lỗi trong log dựa trên timestamp, ID request, nội dung… | Theo dõi volume log, số lượng lỗi/cảnh báo log theo service/thời gian |
| Sentry | Theo dõi và báo cáo lỗi ứng dụng (Exception, Crash) | Exception, Crash, Error details | Nhận thông báo lỗi chi tiết (stack trace, context) ngay khi test gây ra lỗi ứng dụng | Theo dõi tỷ lệ lỗi, các loại lỗi phổ biến, impact của lỗi trên các môi trường test |
Áp Dụng Vào Thực Tế Công Việc QA
Để có thể sử dụng hiệu quả các công cụ này, Kỹ sư QA cần:
- **Hiểu cấu trúc hệ thống:** Biết các thành phần chính của ứng dụng, các service liên kết, nơi log được tạo ra.
- **Làm quen với công cụ:** Dành thời gian khám phá giao diện, học cách xây dựng query (ví dụ KQL cho Kibana, PromQL cho Grafana), tạo dashboard đơn giản.
- **Phối hợp với Dev/DevOps:** Các công cụ này cần được cài đặt và cấu hình để thu thập dữ liệu từ ứng dụng. Kỹ sư QA có thể cần làm việc với đội Dev/DevOps để đảm bảo log, metric, và error tracking được triển khai đầy đủ trên môi trường test.
- **Liên kết thông tin:** Khi một test fail, đừng chỉ nhìn vào báo cáo test. Hãy mở các công cụ này ra, tìm kiếm thông tin liên quan dựa trên thời gian, ID test, user test, v.v.
Việc thành thạo các công cụ này sẽ nâng cao đáng kể khả năng và giá trị của bạn với tư cách là một Kỹ sư QA. Bạn không chỉ là người tìm lỗi, mà còn là người giúp định vị và cung cấp thông tin quan trọng để khắc phục lỗi một cách hiệu quả hơn, góp phần vào việc Đảm bảo Chất lượng tổng thể của sản phẩm.
Đừng ngần ngại yêu cầu quyền truy cập và hướng dẫn sử dụng các công cụ này trong công ty của bạn. Việc chủ động học hỏi và sử dụng chúng sẽ giúp bạn phát triển Tư duy QA một cách sâu sắc hơn, vượt ra ngoài phạm vi kiểm thử bề mặt (như Black Box Testing) để có thể “nhìn” vào bên trong hệ thống (gần hơn với White Box hoặc Gray Box Testing).
Tạm Kết
Việc giám sát và điều tra thất bại kiểm thử là một phần không thể thiếu trong quy trình phát triển phần mềm hiện đại. Grafana, Kibana và Sentry là những công cụ mạnh mẽ giúp Kỹ sư QA thực hiện nhiệm vụ này hiệu quả hơn rất nhiều.
Thay vì dành hàng giờ vật lộn với các file log hoặc chờ đợi nhà phát triển debug, bạn có thể chủ động sử dụng các công cụ này để thu thập thông tin, khoanh vùng vấn đề và cung cấp manh mối chính xác cho đội phát triển. Điều này không chỉ giúp sửa lỗi nhanh hơn mà còn xây dựng sự tin tưởng và phối hợp tốt hơn giữa QA và Dev.
Hãy bắt đầu làm quen với ít nhất một trong ba công cụ này nếu bạn chưa có kinh nghiệm. Tìm hiểu xem công ty của bạn đang sử dụng những công cụ nào cho việc giám sát và log, và đề xuất được tham gia vào quá trình sử dụng chúng. Đó sẽ là một bước tiến quan trọng trên Lộ trình Kỹ sư QA (Tester) của bạn.
Trong các bài viết tiếp theo, chúng ta sẽ tiếp tục khám phá những khía cạnh khác của Lộ trình Kỹ sư QA hiện đại, có thể bao gồm việc tích hợp kiểm thử vào CI/CD, hoặc các kỹ năng nâng cao hơn. Hẹn gặp lại các bạn!
