Bài này được viết lần đầu vào ngày 22/11/2024. Mình viết lại vì phần kiến thức cũ có chỗ chưa đủ, nhưng cách học vẫn giữ nguyên: hiểu cái nghề này đang làm gì trước, còn quy trình và đống tài liệu sẽ đi sau.
Khái niệm
Câu đầu tiên khi học Manual Testing thường là:
Software Testing là gì?
Trả lời rằng kiểm thử phần mềm là đi tìm bug thì không sai. Tester đi làm mà cả tháng không đụng được con bug nào chắc cũng bắt đầu thấy bất an. Nhưng nếu chỉ có thế thì hơi thiếu, vì nhiều việc của tester diễn ra từ lúc chưa có dòng code nào để chạy.
Ví dụ, BA đưa ra một requirement như này:
Người dùng nhập sai mật khẩu nhiều lần thì tài khoản sẽ bị khoá.
Đọc xong phải hỏi ngay: bao nhiêu lần, tính trong khoảng thời gian nào, khoá bao lâu, người dùng tự mở hay gọi tổng đài? Chưa có màn hình, chưa có build, nhưng việc review này vẫn là testing. Bắt được vấn đề ở đây thì cả BA, dev lẫn tester đều đỡ phải làm lại về sau.
Vậy hiểu đầy đủ hơn, Software Testing là tập hợp các hoạt động để đánh giá sản phẩm phần mềm và các sản phẩm làm việc liên quan đến nó. Chúng ta kiểm tra xem sản phẩm có đi đúng requirement không, có dùng được cho nhu cầu thật không, còn defect và rủi ro gì, sau đó đưa thông tin đó cho những người cần quyết định.
Nó bao gồm cả:
- Static testing: review requirement, design, code, test case mà không chạy chương trình.
- Dynamic testing: chạy code, gọi API, bấm vào app rồi quan sát nó hoạt động ra sao.
Typical question: What is software testing?
Software testing is a set of activities to evaluate software work products, find defects, verify requirements, validate user needs and provide information about quality and risk.
Mục tiêu
Quay lại câu “testing để tìm bug”. Cứ hỏi tiếp sẽ ra thế này:
Tìm bug để làm gì?
Để dev sửa.
Sửa để làm gì?
Để sản phẩm chạy đúng và đỡ gây thiệt hại.
Đấy, cuối cùng vẫn quay về chất lượng và rủi ro.
Một app ngân hàng tính sai số tiền thì có thể làm mất tiền. Một trang bán hàng cứ thanh toán là crash thì làm mất doanh thu. Một nút đặt ở chỗ rất khó nhìn không làm app crash, nhưng khách không dùng được thì tính năng viết ra cũng gần như bỏ.
Tuỳ dự án, hoạt động testing sẽ có mấy mục tiêu chính:
- Tìm defect và ngăn defect xuất hiện từ sớm.
- Kiểm tra sản phẩm có đúng requirement, design và các tiêu chí đã thống nhất hay không.
- Xem sản phẩm có thực sự giải quyết nhu cầu của người dùng hay không.
- Đưa ra thông tin về chất lượng để quyết định release, hoãn release hoặc chấp nhận một rủi ro nào đó.
- Giảm khả năng sản phẩm thất bại khi đi vào vận hành.
Testing không chứng minh được sản phẩm hết sạch bug. Nó chỉ cho team thêm bằng chứng để tự tin rằng với thời gian, tiền và phạm vi hiện có, bản build này đã đủ ổn để đi tiếp.
Verification và Validation
Hai khái niệm này rất dễ bị học thuộc ngược.
| Khái niệm | Hiểu nôm na | Ví dụ |
|---|---|---|
| Verification | Chúng ta có làm đúng theo cái đã viết không? | Requirement yêu cầu mật khẩu tối thiểu 12 ký tự, hệ thống có chặn 11 ký tự không? |
| Validation | Cái đã viết và đã làm có đúng thứ người dùng cần không? | Bắt người dùng nhập 12 ký tự có phù hợp với cách họ dùng sản phẩm và yêu cầu bảo mật không? |
Có thể làm một sản phẩm đúng từng dòng tài liệu nhưng tài liệu mô tả sai nhu cầu. Trường hợp đó verification vẫn có thể pass, còn validation thì không.
Ai sẽ làm kiểm thử?
Trong bài cũ mình gom thành ba nhóm chính là Tester, Developer và Customer. Cách chia đó đủ để nhập môn, nhưng đi làm thật thì người tham gia testing rộng hơn:
- Developer test code, component, integration và review code của nhau.
- Tester phân tích requirement, rủi ro, thiết kế test, chạy test và báo cáo chất lượng.
- BA, Product Owner, domain expert review business rule và acceptance criteria.
- Customer hoặc end user tham gia acceptance testing.
- Tuỳ sản phẩm còn có người chuyên về security, performance, accessibility hoặc vận hành.
Tức là không có chuyện quality được ném riêng sang bàn tester. Ai tạo ra sản phẩm thì người đó cũng có phần trách nhiệm kiểm tra nó.
Tại sao vẫn cần Tester?
Thế thì lại có câu:
Dev tự test code của mình được, thuê tester làm gì?
Thứ nhất, dev đương nhiên phải test. Không thể code xong, chưa chạy thử lần nào rồi quăng sang bên test với câu “nhờ em check giúp anh”. Tester không phải compiler chạy bằng cơm.
Nhưng để một người vừa thiết kế, code, tự nghĩ toàn bộ test, test cả sản phẩm rồi lại sửa hết bug thì cũng quá tải. Nếu thuê thêm một nhóm dev chỉ để chuyên đi test phần dev khác viết thì...
Ơ, thế khác gì thuê tester?
Ờ ha.
Thứ hai, testing có kỹ thuật riêng. Phân tích boundary, state transition, rủi ro, coverage hay cách điều tra một failure không phải cứ biết code là tự nhiên biết làm.
Cuối cùng là góc nhìn. Người vừa xây một flow thường biết nó được định làm như thế nào, nên rất dễ đi đúng con đường mình vừa tạo ra. Một người đứng ngoài implementation sẽ hỏi các câu hơi khó chịu hơn: đang thanh toán mà mất mạng thì sao, bấm hai lần thì sao, dữ liệu cũ thì sao, quay lại giữa chừng thì sao.
Bài cũ gọi dev là builder, tester là breaker. Nghe vui và dễ nhớ, nhưng đem vào công việc thì không đúng hẳn. Tester không được trả tiền để phá cho sướng tay, còn dev cũng chẳng phải chỉ biết xây. Cả hai đang làm cùng một sản phẩm; tester chỉ có vị trí quan sát độc lập hơn và tập trung nhiều hơn vào chuyện nó có thể sai ở đâu.
Cùng một người làm được cả dev lẫn test không? Có. Nhưng tự review thứ mình vừa viết luôn có thiên kiến, vậy nên code review, peer review và independent testing mới tồn tại.
Typical question: Why do we need testers when developers can test their own work?
Developers should test their own work. Testers add an independent point of view and specialized testing skills, helping the team find risks that the author may overlook.
Kiểm thử ra làm sao?
Kiểm thử có quy trình của nó, và bản thân nó lại nằm trong một quy trình lớn hơn là phát triển phần mềm. Phần này nếu nhét SDLC, Test Levels, Test Process vào luôn thì bài sẽ dài như sớ, nên ở đây chỉ cần nhớ hai thời điểm.
Trước khi có build, tester có thể review requirement, hỏi lại acceptance criteria, chuẩn bị test data, nghĩ test condition và viết test case. Đây là lúc sửa một câu sai còn rẻ.
Khi có build, tester chạy test, quan sát actual result, so với expected result, điều tra khi có khác biệt rồi log bug. Đây là dynamic testing, phần mà mọi người thường nhìn thấy nhất.
Không nên đợi dev code xong hết rồi tester mới xuất hiện. Đợi đến lúc đó mới hỏi “requirement này nghĩa là gì?” thì cả team cùng mệt.
Bảy nguyên tắc kiểm thử
Phần này hay vào phỏng vấn. Đừng chỉ học tên tiếng Anh; hiểu nôm na nó đang cảnh báo mình điều gì là được.
| Nguyên tắc | Hiểu nôm na |
|---|---|
| Testing shows the presence of defects | Test tìm thấy defect, nhưng không tìm thấy không có nghĩa là sản phẩm sạch bug. |
| Exhaustive testing is impossible | Không thể test mọi input, mọi thiết bị, mọi thứ tự thao tác. Phải chọn dựa trên rủi ro. |
| Early testing saves time and money | Bắt requirement sai lúc review rẻ hơn bắt cùng lỗi đó sau khi đã code và deploy. |
| Defects cluster together | Bug thường tập trung ở vài module phức tạp hoặc thay đổi nhiều. Nhưng không phải vì thế mà bỏ luôn phần còn lại. |
| Tests wear out | Chạy mãi một bộ test cũ thì dần dần chỉ kiểm tra lại thứ mình đã biết. Test cần được xem lại và bổ sung. |
| Testing is context dependent | Test app ghi chú cá nhân không thể dùng cùng mức kiểm soát với app ngân hàng hay máy y tế. |
| Absence-of-defects fallacy | Phần mềm ít bug mà làm sai thứ khách hàng cần thì vẫn là thất bại. |
Nguyên tắc đầu tiên và cuối cùng rất dễ bị lẫn. Một cái nói chúng ta không thể chứng minh hết bug; cái còn lại nói kể cả ít bug cũng chưa chắc sản phẩm có ích.
Typical question: What are the seven testing principles?
Testing shows the presence of defects; exhaustive testing is impossible; early testing saves time and money; defects cluster together; tests wear out; testing is context dependent; and absence of defects does not guarantee a useful product.
Kết
Đến đây chỉ cần chốt lại một ý: Software Testing không phải công đoạn ngồi chờ build rồi bấm tìm bug. Nó bắt đầu từ lúc team còn đang nói xem phải làm cái gì, kéo dài đến lúc có đủ thông tin để quyết định sản phẩm đã nên đi tiếp hay chưa.
Trong bài này mình đã dùng lẫn mấy chữ error, defect, bug và failure. Chúng liên quan với nhau nhưng không phải cùng một thứ. Bài tiếp theo sẽ xử lý riêng đống này, vì không hiểu nó thì về sau nói Severity, Priority hay Bug Logging rất dễ thành một mớ.
