Đáp: Tôi biết rằng có những người kiểm thử chưa bao giờ thấy tài liệu kiểm thử và chưa bao giờ viết ra tài liệu như thế. Tôi cũng biết rằng nhiều người kiểm thử bận rộn thế và không có thời gian cho bất kì cái gì như bạn đã mô tả. Có nhiều trường dạy về lập trình và kiểm thử nhưng chưa bao giờ nhắc tới cái gì về làm tài liệu kiểm thử. Nhiều người kiểm thử học về kĩ thuật và phương pháp kiểm thử nhưng chưa bao giờ học về làm tài liệu kiểm thử. Chúng ta xem một kịch bản: “Giả sử rằng bạn làm việc trong một dự án như người kiểm thử. Bạn đã kiểm thử mọi thứ và thấy không có lỗi cho nên bạn đưa ra phần mềm cho khách hàng. Vài ngày sau, khách hàng quay lại với danh sách nhiều lỗi họ tìm ra ở công ti họ. Người quản lí của bạn rất giận bạn và những người phát triển và nghĩ rằng bạn không có năng lực nên để nhiều lỗi thế mà vẫn bỏ qua. Bỗng nhiên việc làm của bạn bị lâm nguy. Tuy nhiên, bạn thấy rằng những lỗi này bị gây ra bởi khách hàng vì họ thực hiện phần mềm trên nền khác nền đã được làm tài liệu trong đặc tả yêu cầu phần mềm Software Requirement Specification (SRS). Nếu bạn viết kế hoạch kiểm thử dựa trên SRS và đã mô tả rõ ràng nền mà phần mềm này được giả định chạy trên đó, và nếu tài liệu của bạn được kiểm điểm và chấp thuận bởi cả người quản lí dự án và khách hàng thì đó là lỗi của ai? Bây giờ bạn an toàn bởi vì bạn có bằng chứng rằng đó KHÔNG phải là lỗi của bạn. Điều gì xảy ra nếu bạn KHÔNG có kế hoạch kiểm thử? Điều gì xảy ra nếu không có tài liệu? Bạn có thể rút ra kết luận từ kịch bản đơn giản này liệu tài liệu là quan trọng hay không?
Nhiều công ti không coi làm tài liệu là quan trọng cho tới khi cái gì đó xảy ra. Nhiều người phát triển và kiểm thử KHÔNG thích làm tài liệu bởi vì họ KHÔNG hiểu lí do tại sao họ phải làm tài liệu. Nhiều người thậm chí còn nghĩ làm tài liệu là phí thời gian. Sự kiện là làm tài liệu có thể tiết kiệm cho công ti nhiều thời gian, nỗ lực và tiền bạc. Nó là cách thức trao đổi và thoả thuận chính thức giữa khách hàng và tổ phát triển. Nó cũng là tài liệu pháp lí trong trường hợp cái gì đó đi sai. Trong kinh doanh, nếu nó KHÔNG được đưa vào việc viết ra, nó không có giá trị gì. Tài liệu phải được kiểm điểm và chấp thuận trước khi bất kì công việc nào có thể bắt đầu. Tài liệu dự án làm sáng tỏ mục tiêu dự án, mục đích, phương pháp để đảm bảo nhất quán và hiệu năng. Tài liệu kiểm thử giải thích điều được kiểm thử, trường hợp kiểm thử được dùng có chứa cả dữ liệu kiểm thử. Nếu mọi trường hợp kiểm thử đều qua, phần mềm đáp ứng yêu cầu của khách hàng. Bản kế hoạch kiểm thử cũng là thoả thuận chính thức, bản hợp đồng giữa tổ phát triển và khách hàng.
Có vài tài liệu kiểm thử phần mềm mà mọi người kiểm thử phải biết: Bản kế hoạch kiểm thử bao quát phạm vi, mục tiêu, chiến lược kiểm thử, phương pháp kiểm thử, thiết kế kiểm thử và lịch biểu kiểm thử. Báo cáo kiểm thử (Báo cáo lỗi) bao quát tình trạng của hoạt động kiểm thử, số các lần thực hiện kiểm thử, và tình trạng của từng kiểm thử như số lỗi tìm ra (mở hay đã đóng), kí sự kiểm thử, trường hợp kiểm thử, dữ liệu kiểm thử và phân tích kiểm thử v.v.
Tài liệu kiểm thử phần mềm đóng vai trò quan trọng trong mọi dự án phần mềm. Là người kiểm thử, bạn phải giữ mọi thứ được làm tài liệu bất kì khi nào có thể được. ĐỪNG dựa vào trao đổi miệng. Nói là dễ nhưng nó KHÔNG là cách chính thức và hợp pháp cho thoả thuận. Nếu cái gì đó xảy ra, khách hàng thậm chí có thể phủ nhận rằng họ biết bạn. Bạn cần làm tài liệu để bảo vệ bạn. Là người kiểm thử chuyên nghiệp bạn cần để cho mọi người biết rằng bạn có cả tri thức và kĩ năng về hoạt động kiểm thử bằng việc tuân theo qui trình kiểm thử chính thức.
A reader send me email after reading the article “What does a new tester need?”. He wrote “In my career as tester, I never see any testing documents. Testers are always busy, have no time for anything else. Do testers need to have documents? Is testing document important? Please explain.”
Answer: I know that there are testers who never see a testing document and never write one. I also know that many testers are so busy and have no time for anything just like you described. There are many schools that teach programming and testing but never mention anything about testing documentation. Many testers learn about testing techniques and methods but never learn about testing documentation. Let us look at a scenario: “Assume that you work in a project as a tester. You tested everything and found no defect so you released the software to the customer. Few days later, the customer came back with a list of many defects that they found at their company. Your manager is very angry at you and developers think that you are incompetent for letting so many defects passed. Suddenly your job is in jeopardy. However, you found that these defects were caused by the customer as they execute software in different platform than the one documented in the Software Requirement Specification (SRS). If you wrote your Testing Plan based on the SRS and clearly described the platform the software is supposed to run on, and if your document was reviewed and approved by both project manager and customer then whose fault is that? Now you are safe because you have proof that it was NOT your fault. What happened if you do NOT have a Testing plan? What happened if there is no document? You can draw a conclusion from this simple scenario whether document is important or not?
Many companies do not consider documentation is important until something happened. Many developers and testers do NOT like to document because they do NOT understand the reason why they must document. Many even think documentation is a waste of time. The fact is documentation can save a company a lot of time, efforts and money. It is a formal way of communication and agreement between customer and development team. It is also a legal document in case something go wrong. In business, if it is NOT put in writing, it does not worth anything. Document must be reviewed and approved before any work can start. A project document clarifies project objective, goals, methods to ensure consistency and performance. A testing document explains what to be tested, the test cases to be used including test data. If all test cases pass, the software meets the customer’s requirements. Test plan is also a formal agreement, a contract between the development team and customer.
There are several software testing documents that every tester must know: Project testing plan that covers scope, objectives, test strategy, test methods, test design and test schedules. Test report (Bug report) covers status of testing activities, numbers of test perform, and status of each test such as number of defects found (open or closed), Test log, test cases, test data and test analysis etc.
Software Testing documents play an important role in every software project. As tester, you must keep things documented whenever possible. Do NOT rely on verbal communication. Talk is easy but it is NOT a formal and legal way for agreement. If something happens, customer may deny that they even know you. You need document to protect you. As a professional tester you do need to let people know that you have both knowledge and skills about testing activities by following a formal testing process.
