Phát triển Tư duy QA: Nghĩ như một Người Kiểm thử

Chào mừng các bạn đến với series “Roadmap Lộ trình học Kỹ sư QA (Tester) 2025“!

Trong các bài viết trước, chúng ta đã cùng tìm hiểu về bức tranh toàn cảnh của nghề QA, nắm rõ “Đảm bảo Chất lượng là gì?” và đặt những viên gạch đầu tiên trên con đường sự nghiệp này. Hôm nay, chúng ta sẽ đi sâu vào một khía cạnh quan trọng không kém những kiến thức kỹ thuật: **Tư duy của một người Kiểm thử (Tester Mindset)**.

Trở thành một QA giỏi không chỉ đơn thuần là học cách viết test case, sử dụng công cụ hay chạy automation script. Quan trọng hơn, đó là cách bạn **nghĩ**. Tư duy QA là khả năng nhìn nhận sản phẩm từ nhiều góc độ khác nhau, không ngừng đặt câu hỏi, và tìm kiếm những vấn đề mà người khác có thể bỏ qua. Đây chính là yếu tố phân biệt một người kiểm thử thụ động với một QA chủ động, sắc bén và có giá trị.

Bài viết này sẽ giúp bạn hiểu rõ hơn về tư duy QA là gì, tại sao nó lại cần thiết, và làm thế nào để rèn luyện nó. Hãy cùng bắt đầu hành trình khám phá “bộ não” của một người kiểm thử nhé!

Tư duy QA là gì? Tại sao nó quan trọng?

Tư duy QA không phải là một danh sách các quy tắc cố định, mà là một tập hợp các đặc điểm, thái độ và cách tiếp cận công việc. Nó bao gồm:

* **Sự tò mò và hoài nghi:** Không dễ dàng tin vào mọi thứ. Luôn tự hỏi “Điều gì sẽ xảy ra nếu…?”, “Liệu nó có hoạt động như mong đợi trong mọi trường hợp không?”.
* **Chú ý đến chi tiết:** Phát hiện những lỗi nhỏ nhặt, những điểm không nhất quán, những vấn đề về giao diện hoặc trải nghiệm người dùng mà người khác có thể bỏ qua.
* **Empati với người dùng:** Đặt mình vào vị trí của người dùng cuối, hiểu nhu cầu, hành vi và cách họ tương tác với sản phẩm.
* **Khả năng phân tích và đánh giá rủi ro:** Nhận biết những khu vực nào của ứng dụng có khả năng xảy ra lỗi cao nhất hoặc những lỗi nào sẽ gây ra hậu quả nghiêm trọng nhất.
* **Tư duy hệ thống:** Hiểu cách các thành phần khác nhau của ứng dụng tương tác với nhau và cách một thay đổi ở nơi này có thể ảnh hưởng đến nơi khác.
* **Tinh thần học hỏi liên tục:** Thế giới công nghệ thay đổi không ngừng. Một QA giỏi luôn sẵn sàng học hỏi công nghệ mới, kỹ thuật kiểm thử mới và cập nhật kiến thức về lĩnh vực mà sản phẩm phục vụ.
* **Kỹ năng giao tiếp và cộng tác:** Khả năng diễn đạt vấn đề một cách rõ ràng, làm việc hiệu quả với đội ngũ phát triển, quản lý sản phẩm và các bên liên quan khác.

Tại sao tư duy này lại quan trọng? Đơn giản là vì **nó giúp bạn tìm thấy lỗi hiệu quả hơn**. Một người chỉ làm theo kịch bản kiểm thử có sẵn có thể tìm thấy lỗi, nhưng một người có tư duy QA mạnh mẽ sẽ khám phá ra những vấn đề tiềm ẩn, những kịch bản không ngờ tới, và những điểm yếu trong thiết kế hoặc logic của sản phẩm. Họ không chỉ kiểm tra xem sản phẩm *có hoạt động hay không* mà còn kiểm tra xem sản phẩm *có hoạt động đúng và tốt như người dùng mong đợi hay không*.

Những trụ cột của Tư duy Kiểm thử

Hãy đi sâu hơn vào từng yếu tố cấu thành nên tư duy đặc biệt này:

1. Sự Tò mò và Hoài nghi (Curiosity & Skepticism)

Đây có lẽ là đặc điểm nổi bật nhất của một người kiểm thử bẩm sinh. Bạn không chấp nhận mọi thứ một cách hiển nhiên.

* **Sự tò mò:** Thúc đẩy bạn khám phá. Thay vì chỉ đi theo con đường được vạch sẵn, bạn muốn biết “Điều gì nằm ở cuối con đường khác?”, “Nếu tôi nhập dữ liệu không hợp lệ thì sao?”, “Nếu tôi thực hiện các bước theo trình tự ngược lại thì sao?”.
* **Hoài nghi:** Giúp bạn đặt câu hỏi về những giả định. Bạn không tin rằng tính năng X chắc chắn hoạt động chỉ vì nó được developer nói là “đã xong”. Bạn cần tự mình xác nhận điều đó. Bạn không tin rằng dữ liệu sẽ luôn sạch đẹp; bạn nghĩ về trường hợp dữ liệu bị thiếu, bị trùng lặp, hoặc có định dạng sai.

Hãy tưởng tượng bạn đang kiểm thử một chức năng đăng nhập:
* Một người kiểm thử thụ động sẽ kiểm tra: Đăng nhập với email/mật khẩu đúng, đăng nhập với email sai/mật khẩu đúng, đăng nhập với email đúng/mật khẩu sai, để trống cả hai.
* Một người kiểm thử có tư duy tò mò/hoài nghi sẽ hỏi thêm:
* “Email/mật khẩu có phân biệt chữ hoa chữ thường không?”
* “Tôi có thể sử dụng khoảng trắng ở đầu/cuối email/mật khẩu không?”
* “Nếu tôi nhập mật khẩu rất dài/rất ngắn thì sao?”
* “Nếu tôi cố gắng đăng nhập bằng tài khoản đã bị khóa/chưa được kích hoạt thì sao?”
* “Nếu kết nối mạng bị gián đoạn trong lúc đang gửi yêu cầu đăng nhập thì sao?”
* “Màn hình đăng nhập có bị tấn công CSRF, XSS không?” (Đây là cấp độ cao hơn, nhưng xuất phát từ sự tò mò về bảo mật).

Sự tò mò không giới hạn này mở ra vô số kịch bản kiểm thử tiềm năng.

2. Chú ý đến Chi tiết (Attention to Detail)

Lỗi không phải lúc nào cũng là “ứng dụng bị crash”. Đôi khi, lỗi chỉ là một chữ cái bị sai chính tả, một căn chỉnh bị lệch pixel, một thông báo lỗi khó hiểu, hoặc một trường dữ liệu cho phép nhập quá số ký tự quy định.

Một QA giỏi có “đôi mắt đại bàng” để phát hiện những chi tiết nhỏ nhất. Họ nhìn thấy:
* Sai sót trong chính tả, ngữ pháp.
* Sự không nhất quán giữa các màn hình (ví dụ: màu sắc nút bấm khác nhau, font chữ khác nhau).
* Các vấn đề về bố cục, căn chỉnh (ví dụ: chữ bị tràn ra ngoài, hình ảnh bị méo).
* Thông báo lỗi không rõ ràng hoặc không thân thiện với người dùng.
* Dữ liệu hiển thị không chính xác (ví dụ: số tiền làm tròn sai).
* Các vấn đề về hiệu năng (ví dụ: trang load chậm hơn bình thường).
* Các mục trong log file cảnh báo hoặc lỗi.

Rèn luyện khả năng quan sát. Đừng chỉ nhìn vào chức năng chính, hãy quét toàn bộ màn hình, đọc kỹ từng dòng chữ, kiểm tra từng biểu tượng.

3. Empati với Người dùng (User Empathy)

Bạn không kiểm thử cho chính mình hoặc cho developer. Bạn kiểm thử cho người dùng cuối – những người có thể không am hiểu công nghệ như bạn, những người có thể sử dụng sản phẩm trong điều kiện không lý tưởng, hoặc những người có nhu cầu và hành vi khác nhau.

* **Hãy nghĩ về các loại người dùng khác nhau:** Người dùng mới bắt đầu, người dùng thành thạo, người dùng lớn tuổi, người dùng khuyết tật (cần hỗ trợ về khả năng tiếp cận), người dùng sử dụng thiết bị di động, người dùng sử dụng trình duyệt cũ…
* **Hãy nghĩ về các kịch bản sử dụng thực tế:** Người dùng sẽ làm gì khi họ lần đầu tiên mở ứng dụng? Họ sẽ sử dụng chức năng này như thế nào trong công việc hàng ngày của họ? Điều gì sẽ khiến họ cảm thấy khó chịu hoặc bối rối?
* **Hãy nghĩ về môi trường sử dụng:** Người dùng có thể sử dụng ứng dụng trên đường đi (kết nối mạng yếu), trong môi trường ồn ào (không nghe được âm thanh cảnh báo), hoặc trên màn hình nhỏ.

Ví dụ: Khi kiểm thử một ứng dụng đặt hàng, empati với người dùng sẽ khiến bạn kiểm tra:
* Người dùng có dễ dàng tìm thấy sản phẩm không?
* Quy trình thanh toán có đơn giản và rõ ràng không?
* Điều gì xảy ra nếu người dùng thoát ứng dụng giữa chừng quá trình thanh toán?
* Thông báo về trạng thái đơn hàng có dễ hiểu không?
* Người dùng lớn tuổi có gặp khó khăn với kích thước font chữ nhỏ hoặc các nút bấm bé không?

Empati giúp bạn kiểm thử những kịch bản thực tế và tìm ra những vấn đề ảnh hưởng trực tiếp đến trải nghiệm người dùng.

4. Khả năng Phân tích và Đánh giá Rủi ro (Risk Assessment)

Bạn không thể kiểm thử *mọi thứ* trong mọi trường hợp. Thời gian và tài nguyên luôn có hạn. Tư duy QA giúp bạn ưu tiên nỗ lực kiểm thử vào những khu vực quan trọng nhất.

* **Xác định các khu vực rủi ro cao:** Những phần nào của hệ thống là quan trọng nhất đối với người dùng hoặc doanh nghiệp? Những phần nào đã có nhiều lỗi trong quá khứ? Những phần nào vừa được thay đổi đáng kể? Những phần nào liên quan đến tiền bạc, dữ liệu nhạy cảm hoặc tuân thủ pháp lý?
* **Đánh giá mức độ nghiêm trọng của lỗi:** Một lỗi nhỏ về giao diện có mức độ nghiêm trọng khác với lỗi khiến người dùng không thể đặt hàng hoặc làm mất dữ liệu.
* **Ưu tiên kiểm thử:** Dựa trên rủi ro, bạn sẽ quyết định những kịch bản kiểm thử nào cần được thực hiện trước, những khu vực nào cần được kiểm thử sâu hơn.

Ví dụ: Trong một ứng dụng ngân hàng trực tuyến, chức năng chuyển tiền, thanh toán hóa đơn và xem số dư tài khoản sẽ có mức độ rủi ro cao hơn chức năng cập nhật ảnh đại diện. Bạn sẽ dành nhiều thời gian và kịch bản kiểm thử hơn cho các chức năng liên quan đến tiền bạc.

5. Tư duy Hệ thống (System Thinking)

Một phần mềm thường là một hệ thống phức tạp gồm nhiều thành phần tương tác với nhau (frontend, backend, database, API bên ngoài, hệ thống khác…). Một QA giỏi hiểu được bức tranh tổng thể này.

* **Hiểu luồng dữ liệu:** Dữ liệu đi từ đâu, qua những đâu, và cuối cùng đến đâu?
* **Nhận biết sự phụ thuộc:** Chức năng A có phụ thuộc vào chức năng B không? Hệ thống của chúng ta có phụ thuộc vào dịch vụ của bên thứ ba nào không?
* **Phân tích tác động:** Khi một thay đổi được thực hiện ở một nơi, nó có thể ảnh hưởng đến những nơi nào khác trong hệ thống?

Ví dụ: Nếu bạn đang kiểm thử việc cập nhật thông tin người dùng, bạn không chỉ kiểm tra giao diện người dùng có hiển thị đúng thông tin mới hay không. Bạn còn cần xem xét:
* Dữ liệu đã được lưu đúng trong database chưa?
* Các hệ thống hoặc dịch vụ khác sử dụng thông tin này có nhận được bản cập nhật không?
* Nếu có cache, cache đã được xóa hay cập nhật chưa?
* Log file có ghi lại hoạt động cập nhật này không?

Tư duy hệ thống giúp bạn tìm ra những lỗi “ẩn mình” ở giao điểm của các thành phần khác nhau.

Làm thế nào để Rèn luyện Tư duy QA?

Tư duy QA không phải là thứ bạn sinh ra đã có hoặc không có. Đó là một kỹ năng có thể học hỏi và rèn luyện qua thời gian và thực hành.

1. Thực hành, Thực hành, Thực hành

Lý thuyết là cần thiết, nhưng thực hành mới là yếu tố quyết định.

* **Thực hành Kiểm thử Khám phá (Exploratory Testing):** Đây là cách tuyệt vời để rèn luyện sự tò mò. Thay vì chỉ chạy theo kịch bản có sẵn, hãy dành thời gian “lang thang” trong ứng dụng, thử nghiệm các kịch bản ngẫu nhiên, các luồng đi khác thường. Ghi lại những gì bạn làm và những gì bạn quan sát được.
* **Viết Test Case:** Ngay cả khi bạn đang làm kiểm thử khám phá, việc ghi lại các bước thực hiện và kết quả mong đợi giúp bạn rèn luyện tính logic, sự chi tiết và khả năng hệ thống hóa suy nghĩ.

    Test Case: Đăng nhập với tài khoản hợp lệ

    Mục đích: Kiểm tra chức năng đăng nhập với thông tin hợp lệ.
    Điều kiện tiên quyết:
    - Người dùng đã có tài khoản hợp lệ.
    - Kết nối internet ổn định.

    Các bước thực hiện:
    1. Mở trình duyệt và truy cập vào trang đăng nhập.
    2. Nhập địa chỉ email hợp lệ vào trường "Email".
    3. Nhập mật khẩu hợp lệ vào trường "Mật khẩu".
    4. Nhấn nút "Đăng nhập".

    Kết quả mong đợi:
    - Người dùng được chuyển hướng thành công đến trang Dashboard hoặc trang chủ.
    - Tên người dùng hoặc thông tin tài khoản được hiển thị chính xác.
    - Không có thông báo lỗi nào xuất hiện.
    

* **Tìm kiếm Bug Bounty:** Tham gia các chương trình bug bounty (tìm lỗi nhận thưởng) trên các nền tảng như HackerOne, Bugcrowd (nếu có kinh nghiệm nhất định) hoặc đơn giản là tìm lỗi trên các trang web, ứng dụng bạn thường dùng (và báo cho họ nếu có kênh).

2. Đặt câu hỏi “Tại sao?” và “Điều gì sẽ xảy ra nếu?”

Biến việc đặt câu hỏi thành thói quen.
* Khi thấy một tính năng: “Tại sao nó lại hoạt động như thế này?”, “Còn cách nào khác mà người dùng có thể sử dụng nó không?”.
* Khi thấy một lỗi: “Tại sao lỗi này lại xảy ra?”, “Điều kiện gì đã dẫn đến lỗi này?”.
* Khi đọc yêu cầu: “Tại sao yêu cầu này lại cần thiết?”, “Điều gì sẽ xảy ra nếu chúng ta không thực hiện yêu cầu này?”.
* “Điều gì sẽ xảy ra nếu… tôi nhập ký tự đặc biệt?”, “…tôi tắt kết nối mạng?”, “…tôi mở rất nhiều tab cùng lúc?”, “…tôi sử dụng một trình duyệt khác/thiết bị khác?”.

3. Học cách “Phá vỡ” mọi thứ (một cách có kiểm soát)

Công việc của QA là tìm ra điểm yếu của hệ thống. Đừng ngại thử nghiệm các tình huống bất thường, nhập dữ liệu không hợp lệ, thực hiện các hành động không được khuyến khích. Mục tiêu là để hệ thống bộc lộ điểm yếu của nó *trước* khi người dùng cuối phát hiện ra. Tất nhiên, điều này cần được thực hiện trong môi trường kiểm thử an toàn và có sự phối hợp với đội phát triển.

4. Hiểu về Lĩnh vực Kinh doanh (Business Domain)

Phần mềm được tạo ra để giải quyết một vấn đề hoặc đáp ứng một nhu cầu kinh doanh cụ thể. Việc hiểu rõ lĩnh vực mà sản phẩm của bạn hoạt động (ví dụ: thương mại điện tử, ngân hàng, y tế, giáo dục…) giúp bạn hiểu rõ hơn về mục đích của các tính năng, các quy trình nghiệp vụ quan trọng và những rủi ro tiềm ẩn từ góc độ kinh doanh. Kiến thức này giúp bạn kiểm thử hiệu quả hơn và đưa ra những đề xuất giá trị.

5. Hiểu về Công nghệ (Technology Stack)

Bạn không cần phải trở thành một developer, nhưng hiểu biết cơ bản về công nghệ đằng sau ứng dụng (ví dụ: ứng dụng web sử dụng ngôn ngữ gì ở backend, loại database nào, có sử dụng API bên ngoài không…) giúp bạn đoán được những nơi có khả năng xảy ra lỗi và giao tiếp tốt hơn với developer.

6. Tìm kiếm Phản hồi và Học hỏi từ Người khác

Trao đổi với các QA giàu kinh nghiệm hơn. Quan sát cách họ tiếp cận vấn đề, cách họ đặt câu hỏi và cách họ báo cáo lỗi. Nhận phản hồi về cách bạn viết test case, cách bạn tìm lỗi và cách bạn giao tiếp. Tham gia các cộng đồng QA để học hỏi kinh nghiệm từ những người khác.

7. Đọc và Nghiên cứu

Đọc sách, blog, bài viết về kiểm thử phần mềm. Theo dõi các chuyên gia trong ngành. Học hỏi về các kỹ thuật kiểm thử mới, các loại lỗi phổ biến và các phương pháp tư duy. Kiến thức là nền tảng vững chắc để phát triển tư duy.

Sự Khác biệt mà Tư duy QA mang lại

Một QA với tư duy sắc bén không chỉ là người tìm lỗi. Họ là người đồng hành cùng đội phát triển để xây dựng nên sản phẩm tốt hơn.

Hãy xem xét sự khác biệt trong cách tiếp cận giữa một người chỉ “kiểm tra” và một người “kiểm thử” với tư duy QA:

Rõ ràng, người kiểm thử với tư duy QA mang lại giá trị lớn hơn rất nhiều cho dự án và sản phẩm. Họ không chỉ là “người gác cổng” mà là một phần không thể thiếu trong quá trình xây dựng và cải tiến sản phẩm.

Áp dụng Tư duy QA vào Quy trình làm việc hàng ngày

Phát triển tư duy QA không có nghĩa là bạn phải thay đổi hoàn toàn cách làm việc ngay lập tức. Hãy bắt đầu bằng việc tích hợp nó vào những hoạt động hàng ngày:

* **Trong Buổi họp lập kế hoạch (Planning Meeting) hoặc Grooming:** Đặt câu hỏi về yêu cầu, về cách người dùng sẽ sử dụng tính năng, về những rủi ro tiềm ẩn.
* **Trong Buổi họp Stand-up:** Chia sẻ không chỉ công việc đã làm mà còn những suy nghĩ, những câu hỏi hoặc những rủi ro bạn đang nhìn thấy.
* **Khi Viết Test Case:** Đừng chỉ viết những kịch bản “happy path”. Hãy suy nghĩ về các trường hợp ngoại lệ, dữ liệu không hợp lệ, điều kiện biên.
* **Khi Thực hiện Kiểm thử:** Luôn giữ sự tò mò. Nếu gặp phải điều gì đó bất ngờ, đừng bỏ qua. Dừng lại, điều tra, thử nghiệm thêm.
* **Khi Báo cáo Lỗi:** Cung cấp đầy đủ chi tiết để developer có thể tái hiện. Giải thích *tại sao* lỗi này quan trọng (liên quan đến người dùng, rủi ro kinh doanh…).
* **Khi Thảo luận với Developer:** Đừng ngại hỏi về cách hoạt động bên trong của tính năng. Hiểu được code giúp bạn kiểm thử thông minh hơn.

Kết luận

Phát triển Tư duy QA là một hành trình liên tục, đòi hỏi sự kiên nhẫn, thực hành và tinh thần học hỏi. Nó không chỉ giúp bạn trở thành một người kiểm thử giỏi hơn mà còn mở rộng góc nhìn của bạn về phát triển sản phẩm và cách làm việc nhóm.

Hãy bắt đầu ngay hôm nay bằng cách rèn luyện sự tò mò, chú ý đến chi tiết, đặt mình vào vị trí người dùng và không ngừng đặt câu hỏi. Khi bạn bắt đầu “nghĩ như một người kiểm thử”, bạn sẽ thấy thế giới phần mềm hiện ra với vô số những kịch bản, những vấn đề tiềm ẩn và những cơ hội để cải thiện chất lượng mà trước đây bạn chưa từng nhận ra.

Tư duy QA là yếu tố cốt lõi làm nên sự khác biệt giữa một người thực hiện kiểm thử và một Kỹ sư Đảm bảo Chất lượng thực thụ. Nắm vững nó, và bạn sẽ tiến xa hơn rất nhiều trên Lộ trình trở thành Kỹ sư QA chuyên nghiệp.

Trong các bài viết tiếp theo, chúng ta sẽ khám phá sâu hơn về các kỹ thuật kiểm thử cụ thể, cách viết test case hiệu quả và các công cụ hữu ích. Hãy tiếp tục đồng hành cùng series “Roadmap Lộ trình học Kỹ sư QA (Tester) 2025” nhé!

Chúc bạn thành công trên con đường sự nghiệp QA của mình!