Tâm Sự Chuyện Nghề Tester: Hành Trình 10 Năm Từ "Vạch Lá Tìm Sâu" Đến Kiến Tạo Chất Lượng Phần Mềm P1

1 giờ trước đây

Lời Mở Đầu – Lỡ Duyên Hay Lựa Chọn Định Mệnh Với Nghề Tester?

Có bao giờ bạn tự hỏi: “Tại sao mình lại chọn ngồi đây, dành 8 đến 10 tiếng mỗi ngày chỉ để tìm lỗi của người khác?”

Hơn 10 năm trước, khi mới chân ướt chân ráo bước ra khỏi cổng trường đại học với tấm bằng Công nghệ thông tin, tôi – cũng giống như hàng ngàn sinh viên IT khác – từng nuôi ước mơ trở thành một Software Developer lừng lẫy, viết ra những dòng code hoa mỹ thay đổi thế giới. Nhớ lại những ngày đầu bước chân vào dự án thực tế đầu tiên, tôi được giao nhiệm vụ "test tạm vài màn hình" trước khi bắt tay vào code.

Nhưng cuộc đời luôn có những bước ngoặt bất ngờ.

Ngày hôm đó, tôi vô tình tìm thấy một lỗi hổng bảo mật nghiêm trọng trên môi trường Staging – một lỗi có thể khiến toàn bộ dữ liệu giao dịch tài chính của khách hàng bị rò rỉ chỉ qua một câu lệnh SQL Injection đơn giản. Cảm giác lúc nhấn nút nộp Bug Report, nhìn thấy toàn bộ team Dev nháo nhào sửa chữa và anh Project Manager thở phào vỗ vai tôi bảo: "Chú cứu team một bàn thua trông thấy!" – chính là khoảnh khắc làm thay đổi hoàn toàn suy nghĩ của tôi.

Tôi nhận ra rằng: Developer tạo ra sản phẩm, nhưng Tester là người bảo vệ uy tín của sản phẩm đó trước thế giới.

Từ vị thế của một kẻ "lỡ duyên", tôi dấn thân vào con đường Software Testing. Hơn một thập kỷ trôi qua, từ Outsourcing, Product cho đến Startup, trải qua hàng trăm dự án với đủ mọi công nghệ từ Web, Mobile App, Microservices đến Blockchain và AI, tôi đã chứng kiến biết bao thăng trầm của nghề này. Bài viết này không phải là một cuốn sách giáo khoa khô khan về khái niệm testing, mà là những dòng tâm sự rút ruột rút gan, những kinh nghiệm xương máu được đánh đổi bằng vô số đêm thức trắng.

Thực Tế Phũ Phàng & Những "Định Kiến" Về Nghề Tester

Khi nói về nghề Tester, xã hội và thậm chí cả một bộ phận người làm trong ngành IT vẫn giữ những định kiến vô cùng lệch lạc. Nếu bạn có ý định bước chân vào con đường này, hãy chuẩn bị tâm lý đối mặt với những định kiến dưới đây:

Định kiến 1: "Tester là nghề nhàn hạ, chỉ cần nhấp chuột dạo"

Nhiều người nghĩ Tester chỉ đơn giản là mở ứng dụng lên, bấm vài cái nút, thấy cái nào lệch thì báo lỗi.

Thực tế: Nhấp chuột chỉ là 5% bề nổi của tảng băng chìm. Để bấm được một cú nhấp chuột đúng nghĩa, Tester phải trải qua hàng giờ đồng hồ đọc hàng trăm trang tài liệu Requirement, phân tích luồng nghiệp vụ (Business Logic), thiết kế kịch bản kiểm thử (Test Case), chuẩn bị dữ liệu (Test Data), mô phỏng các môi trường khắt nghiệt và dự đoán những hành vi bất thường nhất của người dùng cuối.

Định kiến 2: "Không biết code mới đi làm Tester"

Đây là định kiến phổ biến nhất đối với các bạn sinh viên hoặc những người chuyển ngành.

Thực tế: Định kiến này có lẽ chỉ đúng với khái niệm Manual Tester cấp độ cơ bản nhất từ chục năm trước. Ngày nay, một Automation Tester chuyên nghiệp cần thông thạo các ngôn ngữ lập trình như Java, Python, TypeScript, C#, hiểu sâu về cấu trúc dữ liệu, thuật toán, kiến trúc phần mềm, CI/CD pipeline và API design. Thậm chí, để test được Performance hay Security, trình độ kỹ thuật của Tester đòi hỏi không kém cạnh – nếu không muốn nói là rộng hơn – so với Developer.

Định kiến 3: "Tester là kẻ thù của Developer"

Hình ảnh Tester và Developer "lườm quýt" nhau, tranh cãi gay gắt mỗi khi có Bug đã trở thành meme huyền thoại trong làng IT.

Thực tế: Nếu bạn coi Dev là đối thủ, bạn đã thất bại ngay từ bước đầu làm nghề. Tester và Developer thực chất là hai người bạn đồng hành trên cùng một chiếc thuyền, cùng chung mục tiêu: Đưa sản phẩm tốt nhất đến tay người dùng. Sự khác biệt chỉ nằm ở góc nhìn: Dev nhìn sản phẩm bằng ánh mắt của người sáng tạo (How to build it), còn Tester nhìn sản phẩm bằng ánh mắt của người tiêu dùng khắt khe nhất (How to break it).

Những "Vết Thẹo" Đáng Giá – 6 Case Studies Thực Chiến Đêm Prod

Trong nghề này, người ta thường nói: "Tester chưa từng làm lọt Bug nghiêm trọng lên Production thì chưa phải là Tester trưởng thành." Dưới đây là 6 câu chuyện thực tế xương máu mà tôi từng trải qua:

Case Study 1: Thảm họa lặp đơn hàng (Race Condition) đêm Flash Sale

Bối cảnh: Dự án E-commerce lớn chạy chương trình Flash Sale vào đêm 30 Tết với hàng triệu người dùng đồng thời.
Sự cố: Mặc dù Test Case đã thông qua 98%, khi deploy lên Production, khách hàng bấm nút "Thanh toán" liên tục do mạng giật lag khiến hệ thống sinh ra 5-10 đơn hàng trùng lặp cho 1 lần trả tiền.
Root Cause: API thanh toán thiếu cơ chế khóa Idempotence và xử lý bất đồng bộ (Async Queue) trên backend.
Bài học: Môi trường Test không bao giờ phản ánh 100% Production nếu thiếu Stress Testing. Luôn đặt câu hỏi: "Hệ thống sẽ ra sao nếu người dùng thao tác sai hoặc mạng chập chờn?"

Case Study 2: Trận rò rỉ bộ nhớ (Memory Leak) trên Mobile App

Bối cảnh: Ứng dụng ngân hàng số chạy mượt mà ở các kịch bản test ngắn hạn.
Sự cố: Khách hàng phản ánh ứng dụng bị đơ cứng và tự động văng (App Crash) sau khoảng 2-3 tiếng mở liên tục.
Root Cause: Developer quên unregister Event Listener khi chuyển giữa các Screen, làm bộ nhớ RAM tăng tích lũy đến khi chạm ngưỡng Out-Of-Memory.
Bài học: Không chỉ test tính đúng đắn về mặt chức năng (Functional), Tester phải sử dụng Android Studio Profiler / Xcode Instruments để kiểm tra mức độ tiêu thụ RAM, CPU và Pin trong thời gian dài (Soak Testing).

Case Study 3: Khi Client thay đổi Requirement vào phút 89

Bối cảnh: Dự án gia công (Outsourcing) cho thị trường Nhật Bản. Trước đợt Release 2 ngày, khách hàng yêu cầu thay đổi luồng tính thuế VAT cho các mặt hàng xuất khẩu.
Sự cố: Do thời gian quá gấp, team vội vã sửa code và chỉ re-test tính năng thuế. Đến ngày Release, toàn bộ luồng xuất hóa đơn điện tử bị lỗi định dạng PDF.
Root Cause: Thiếu hoạt động Phân tích ảnh hưởng (Impact Analysis) và bỏ qua Regression Test.
Bài học: Bất kể Requirement thay đổi muộn thế nào, Tester phải duy trì Ma trận truy xuất nguồn gốc (Requirement Traceability Matrix - RTM) và chạy lại bộ Automation Regression Test bắt buộc trước khi cấp chứng chỉ Quality Gate.

Case Study 4: Bug hiển thị đặc thù trên Safari iOS (Cross-Browser Issue)

Bối cảnh: Nền tảng học trực tuyến SaaS.
Sự cố: Tất cả Tester đều test trên Chrome/Edge và khẳng định giao diện hoàn hảo. Khi chạy Prod, 40% học viên dùng iPhone không thể bấm vào nút "Bắt đầu làm bài thi".
Root Cause: Thuộc tính CSS CSS Grid / Flexbox bị lỗi render trên trình duyệt WebKit Safari bản cũ.
Bài học: Đừng bao giờ tin tưởng một trình duyệt duy nhất. Hãy lập danh sách thiết bị/trình duyệt phổ biến của tệp người dùng mục tiêu (Google Analytics) và tích hợp các nền tảng test đám mây như BrowserStack hoặc SauceLabs.

Case Study 5: Sự cố lệch múi giờ (Timezone & UTC Bug)

Bối cảnh: Hệ thống đặt lịch khám bệnh trực tuyến cho bệnh viện đa quốc gia.
Sự cố: Bệnh nhân đặt lịch lúc 8h00 sáng tại Việt Nam (UTC+7), nhưng hệ thống lưu giờ server ở dạng local string không kèm múi giờ. Kết quả là trên ứng dụng của Bác sĩ hiển thị lịch hẹn vào 1h00 sáng cùng ngày.
Root Cause: Backend không chuẩn hóa thời gian về dạng ISO 8601 UTC string (YYYY-MM-DDTHH:mm:ssZ) trước khi lưu xuống Database.
Bài học: Khi test các ứng dụng có yếu tố thời gian, luôn luôn verify dữ liệu dưới Database và test ở các máy khách có múi giờ khác nhau.

Case Study 6: Lỗi font chữ vỡ hóa đơn PDF (UTF-8 Encoding)

Bối cảnh: Phần mềm quản lý bán hàng xuất hóa đơn GTGT.
Sự cố: Khi in hóa đơn các tên khách hàng có dấu tiếng Việt phức tạp như "Nguyễn Trần Nhất Thắng", file PDF xuất ra bị biến thành các ký tự lạ dạng Nguy???n Tr??n....
Root Cause: Library sinh file PDF trên Server thiếu Font nhúng (Embedded Unicode Font) tương thích với định dạng UTF-8.
Bài học: Kiểm thử phần mềm tiếng Việt luôn phải chú trọng đến bài toán Encoding, nhãn Unicode và khả năng hiển thị ký tự đặc biệt.

Quy Trình Kiểm Thử Phần Mềm (STLC) Trong Mô Hình Agile/Scrum

Vòng đời kiểm thử phần mềm (Software Testing Life Cycle - STLC) không phải là một hoạt động đứng độc lập mà được đan kết chặt chẽ vào quy trình phát triển phần mềm (SDLC).

Giai đoạn STLC Chuẩn Quốc Tế:

Phân Tích Yêu Cầu (Requirement Analysis):

Tester đọc tài liệu User Story / SRS.
Tham gia buổi Refinement với Product Owner và Dev để làm rõ các điểm mơ hồ.
Đầu ra (Deliverable): Danh sách câu hỏi làm rõ (Requirement Clarification List), Ma trận RTM.

Lập Kế Hoạch Kiểm Thử (Test Planning):

Xác định phạm vi (In-scope / Out-of-scope), chiến lược (Test Strategy), nhân lực và tiến độ.
Uớc lượng khối lượng công việc (Test Estimation).
Đầu ra: Test Plan Document.

Thiết Kế Kịch Bản Kiểm Thử (Test Case Development):

Viết các kịch bản Test Case chi tiết, chuẩn bị Test Data.
Review Test Case với Dev và PO.
Đầu ra: Bộ Test Case trên Jira/TestRail.

Thiết Lập Môi Trường Kiểm Thử (Test Environment Setup):

Cấu hình server Staging/Testing, cài đặt bản Build, chuẩn bị cơ sở dữ liệu giả lập.
Đầu ra: Môi trường Test sẵn sàng, Smoke Test passed.

Thực Hiện Kiểm Thử & Quản Lý Bug (Test Execution & Defect Tracking):

Chạy các kịch bản test (Manual & Automation).
Log lỗi lên Jira, phối hợp với Dev để re-test và verify bug.
Đầu ra: Bug Report, Test Execution Log.

Đóng Dự Án & Báo Cáo (Test Closure & Reporting):

Phân tích chỉ số chất lượng, họp rút kinh nghiệm (Retrospective).
Đầu ra: Báo cáo nghiệm thu chất lượng (Test Summary Report).

Tạm tới đây đã. Minh sẽ viết tiếp phần 2 nhá