Kiểm thử tài liệu

Chúng ta sẽ cùng đi tìm hiểu xem những tài liệu trong phần mềm bao gồm những gì:

• Đóng gói văn bản và đồ họa ( Packaging text and graphics )

• Chúng ta hình dung việc đóng gói như là việc một cái hộp bìa cứng được bọc lại bên ngoài một lớp giấy
• Tài liệu chứa những hình ảnh được chụp từ phần mềm, danh sách những đặc tính, những yêu cầu của hệ thống, và những thông tin về bản quyền.

• Đưa ra những tài liệu quảng cáo và tiếp thị (Marketing material, ads, and other inserts

• Khi sản phẩm phần mềm hoàn thành chúng ta thường quan tâm tới nó nhiều hơn là các tài liệu liên quan tới sản phẩm đó. Nhưng chúng lại là một trong những công cụ quan trọng trong việc đẩy mạnh bán sản phẩm phần mềm
• Thông tin mà chúng ta đưa cho khách hàng phải là những thông tin đúng để khách hàng có cảm giác là chúng ta luôn coi trọng họ.

• Đăng ký mua sản phẩm ( Warranty/registration )

• Khách hàng sẽ được dùng thử phần mềm đó
• Nếu sản phẩm được chấp nhận, Khách hàng điền vào phiếu đăng ký mua sản phẩm và gửi đến để nhà cung cấp.

• EULA (End User License Agreement)

• Đây là hồ sơ pháp lý mà khách hàng đồng ý khi mua sản phẩm với điều kiện:
  • Không được sao chép phần mềm đó
  • Nếu có lỗi xảy ra khách hàng không được kiện nhà sản xuất
• EULA có thể được xuất hiện trong quá trình cài đặt
• Có khi được ghi trong đĩa CD cùng với phần mềm
• Hoặc trong những phong bì gửi tới khách hàng

EULA là một phần của tài liệu phần mềm, giải thích thời hạn pháp lý để sử dụng phần mềm .

• Nhãn và nhãn hiệu ( Labels and stickers )

• Labels and stickers có thể xuất hiện trên:
  • Phương tiện truyền thông
  • Trên hộp
  • Hoặc trên tài liệu
• Labels and stickers cùng với số serial được đặt trong phong bì cùng với EULA

M ột ví dụ về một nhãn đĩa và tất cả những thông tin mà chúng ta cần kiểm tra.

• Những chỉ dẫn cài đặt và cài đặt (Installation and setup instructions )

• Thông tin này được tin trực tiếp trên đĩa CD đôi khi được ghi trong đĩa CD cùng với phần mềm.
• Nếu phần mềm đó phức tạp thì nó có thể là toàn bộ tài liệu cài đặt.

• Tài liệu của người sử dụng (User's manual)

• Sự xuất hiện của tài liệu trực tuyến với sự linh hoạt và hữu ích làm cho tài liệu trên giấy không còn được thông dụng như trước nữa.
• Ngày nay hầu hết các phần mềm đều hướng tới sự nhỏ gọn ngay từ những chi tiết đầu tiên.
• Những tài liệu trực tuyến có thể được phân bố trên các phương tiện truyền thông hoặc trên những website.

• Trợ giúp trực tuyến (Online help)

• Online help được lồng vào với tài liệu của người sử dụng, đôi khi Online help còn được thay thế tài liệu người sử dụng.
• Online help giúp cho việc tìm kiếm trở nên dễ dàng hơn
• Online help giúp cho người sử dụng đặt ra những câu hỏi giống như một ngôn ngữ tự nhiên.
• Ví dụ: Tell me how to copy text from one program to another! (Hãy nói với tôi làm thế nào để sao chép một đoạn văn bản giữa hai chương trình!)

• Các tài liệu hướng dẫn (Tutorials, wizards, and CBT -Computer Based Training)

• Người sử dụng đặt ra câu hỏi sau đó phần mềm sẽ hướng dẫn người sử dụng thông qua từng bước để hoàn thành nhiệm vụ.
• Một trong những vấn đề đó chính là trợ lý của Microsoft's Office "paper clip guy”

Trợ lý của Microsoft Office là một ví dụ rất tinh tế về sự trợ giúp của hệ thống

• Samples, examples và templates

• Đây là một loại văn bản với những mẫu mà người sử dụng có thể điền vào và cho một kết quả nhanh chóng
• Người biên tập sẽ tổng hợp những văn bản đó và trình bày theo một ngôn ngữ nhất định

• Thông báo lỗi (Error messages)

• Vấn đề về thông báo lỗi đã được đề cập đến trong cuốn sách này một vài lần nhưng sau đó nó lại bị lãng quên
• Cuối cùng những vấn đề này chỉ nằm trong tài liệu

Người sử dụng họ không quan tâm tới phần mềm được tạo ra như thế nào bởi ai. Cái mà người sử dụng quan tâm chính là chất lượng của sản phẩm sau khi đã được đóng gói.

• Chú ý:

• Nếu phần hướng dẫn cài đặt bị sai hoặc nếu những thông báo lỗi không đúng khi đó sẽ làm cho người sử dụng sang hiểu sai vấn đề.
• Người sử dụng sẽ gửi những lỗi đó cho nhà cung cấp sản phẩm, khi đó một vài lỗi phần mềm đó sẽ được tìm thấy bởi người kiểm thử phần mềm.

Một tài liệu phần mềm tốt nó sẽ làm cho chất lượng của toàn bộ phần mềm được tốt hơn.Điều đó được thể hiện ở ba cách sau:

• Tận dụng được tính khả dụng (It improves usability)

• Trong phần trước chúng ta đã được học “Tính khả dụng” -Usability Testing
• Tất cả những vấn đề liên quan đến tính khả dụng là gì?
• Liệu những tính khả dụng kia có liên quan đến tài liệu phần mềm không?

• Cải thiện sự tin cậy (It improves reliability)

• Sự tin cậy và ổn định của phần mềm là bao nhiêu ?
• Nó làm cho người sử dụng hy vọng hay không khi họ đón nhận nó.
• Nếu người sử dụng đọc tài liệu, sử dụng phần mềm và không tin cậy vào phần mềm đó.
• Trong phần này chúng ta sẽ thấy rằng kiểm thử phần mềm và tài liệu là một trong những cách tốt nhất để loại bỏ những lỗi đó.

• Nó giúp cho việc giảm chi phí (It lowers support costs)

• Trong phần trước bạn đã được học về những vấn đề tìm thấy bởi những khách hàng
• Chi phí bỏ ra ít hay nhiều tùy thuộc vào quá trình phát hiện sớm hay muộn của khách hàng
• Nếu khách hàng dùng sản phẩm và phát hiện ra lỗi sớm thì chi phí bỏ ra sửa lại sẽ không cao
• Nếu khách hàng dùng sản phẩm và phát hiện ra lỗi muộn thì chi phí bỏ ra sửa lại là rất đắt.

• Chú ý:

• Là một Tester bạn nên quan tâm tới tài liệu phần mềm giống như Coder đang nỗ lực hoàn thành sản phẩm.
• Nếu bạn không coi trọng tài liệu thì toàn bộ phần mềm mà bạn kiểm thử sẽ không đạt kết quả cao.

có thể xét ở hai trường hợp:

• Nếu tài liệu không phải là mã, thì kiểm thử thường là một quá trình tĩnh và được mô tả trong bài 3
• Nếu tài liệu và mã có ràng buộc gần với nhau, kiểm thử trở thành quá trình động và được mô tả trong bài 3

• Chú ý:

• Nếu có đoạn mã đơn giản, bạn hãy gõ nó vào máy và thử như mô tả, với cách tiếp cận thực tế đơn giản này, bạn sẽ tìm ra những lỗi trong cả phần mềm và tài liệu.
• Dù cho tài liệu có mã hay không, thì hãy đọc tài liệu cẩn thận, thực hiện từng bước, khảo sát tất cả các hình, thử mọi ví dụ.

Danh sách các trường hợp kiểm thử (là cơ sở để xây dựng các trường hợp kiểm thử tài liệu):

Cuối cùng, nếu bạn phải xét nhiều trường hợp kiểm thử, hãy sử dụng kỹ thuật phân lớp tương đương để chọn ra các trường hợp điển hình để kiểm thử.

Một Tester sẽ gặp nhiều khó khăn trong qúa trình kiểm thử bởi đôi khi người viết tài liệu cho phần mềm (writer) không phải là chuyên gia. Cách tốt nhất là nên làm việc gần gũi với writer để họ hiểu những khó khăn mà bạn gặp phải và giải thích rõ ràng hơn trong tài liệu.

Một tài liệu của sản phẩm phần mềm cần phải được cố định trước khi phần mềm hoàn thành. Nếu một chức năng nào đó của phần mềm bị thay đổi hoặc gây lỗi, tài liệu sẽ không kịp thời thay đổi theo. Đó là lý do tệp Readme ra đời.

Tệp Readme phản ánh những thay đổi cuối cùng của phần mềm cho người sử dụng biết mà chúng không được thay đổi trong tài liệu.

Để việc kiểm thử tài liệu có kết quả, hãy tiến hành trên các tệp đi kèm với phần mềm: Readme, hướng dẫn cài đặt..; các tài liệu quảng cáo; các bản đăng ký, thậm chí là các tiêu chuẩn của phần mềm; cùng với các hình, mẫu, và các ví dụ...

Là một Tester, nếu bạn kiểm thử các tài liệu đúng cách, bạn sẽ tìm thấy những lỗi trước khi khách hàng của bạn phát hiện ra chúng.