日本語
EnglishSẢN PHẨM ĐẦU RA CỦA CÁC HOẠT ĐỘNG TEST
Trong bài viết trước, chúng ta đã tìm hiểu về các hoạt động trong quy trình kiểm thử cơ bản. Lần này, chúng ta sẽ cùng xem qua các sản phẩm đầu ra của từng hoạt động đó nhé!
Sản phẩm đầu ra của giai đoạn Lập kế hoạch kiểm thử
Kế hoạch kiểm thử được lập cho từng dự án theo chính sách và chiến lược kiểm thử của tổ chức. Tùy thuộc vào quy mô, đối tượng của dự án và mức độ phức tạp của các mục kiểm thử, có thể lập kế hoạch kiểm thử cho từng mục hoặc cấp độ kiểm thử. Các tiêu chí chuyển giao (bao gồm tiêu chí hoàn tất) và thông tin liên kết về các sản phẩm đầu vào và đầu ra cũng là các sản phẩm đầu ra trong giai đoạn Lập kế hoạch kiểm thử.
Sản phẩm đầu ra của giai đoạn Giám sát và kiểm soát kiểm thử
Các báo cáo tiến độ kiểm thử và báo cáo tổng kết kiểm thử theo từng mốc thời gian là những sản phẩm chính được tạo ra. Thông tin bao gồm trong báo cáo sẽ khác nhau tùy thuộc vào dự án và cấp độ kiểm thử. Điểm quan trọng là cung cấp thông tin phù hợp và chính xác cho các bên liên quan vào thời điểm thích hợp. Trong quá trình thực hiện kiểm thử, cần báo cáo kịp thời các rủi ro dự án như vấn đề về chất lượng, chức năng chưa đầy đủ, hoặc thiếu nguồn lực.
Sản phẩm đầu ra của giai đoạn Phân tích kiểm thử
Điều kiện kiểm thử thu được từ quá trình phân tích kiểm thử cần đảm bảo liên kết với cơ sở kiểm thử để xác nhận đầy đủ điều kiện. Điều này cũng cần thiết khi xác định các mục và cấp độ kiểm thử. Thông tin về thứ tự ưu tiên các điều kiện kiểm thử quan trọng cho hệ thống hoặc sản phẩm cũng là một phần của sản phẩm đầu ra.
Báo cáo về các lỗi phát hiện được qua phân tích cơ sở kiểm thử cũng được bao gồm. Trong trường hợp sử dụng kỹ thuật kiểm thử dựa trên kinh nghiệm, phương pháp kiểm thử khám phá không yêu cầu tạo test case chi tiết mà sử dụng các “kịch bản kiểm thử”.
Sản phẩm đầu ra của giai đoạn Thiết kế kiểm thử
Sản phẩm đầu ra của Thiết kế kiểm thử bao gồm tài liệu đặc tả thiết kế kiểm thử và test case. Đặc tả thiết kế kiểm thử xác định cấp độ và phương pháp kiểm thử cần thiết để đáp ứng các điều kiện kiểm thử mà không nêu rõ các giá trị đầu vào hoặc giá trị kỳ vọng. Trong test case, các chi tiết như giá trị đầu vào, kỳ vọng, và thứ tự thực hiện được mô tả chi tiết để hỗ trợ triển khai kiểm thử.
Trong thực tế, đôi khi tài liệu đặc tả thiết kế kiểm thử có thể bị lược bỏ, chỉ tạo sản phẩm đầu ra dưới dạng test case. Tuy nhiên, việc này khiến cho việc xác nhận sự đầy đủ hoặc thiếu sót của điều kiện kiểm thử cũng như việc ứng phó với các thay đổi trở nên khó khăn. Các test case ở cấp độ cao có thể giúp xác nhận mức độ bao phủ của các điều kiện kiểm thử và ứng phó linh hoạt với các thay đổi trong đặc tả, từ đó giúp đạt được thiết kế kiểm thử có khả năng tái sử dụng cao.
Sản phẩm đầu ra của giai đoạn Phát triển kiểm thử
Sản phẩm đầu ra của triển khai kiểm thử là “testware” giúp thực hiện kiểm thử, bao gồm các bước kiểm thử và thứ tự của chúng, bộ kiểm thử (test suite), và lịch trình thực hiện kiểm thử. Ngoài ra, các dữ liệu kiểm thử, script, và cài đặt môi trường cũng là sản phẩm đầu ra. Tùy thuộc vào đối tượng và môi trường kiểm thử, có thể sử dụng các giả lập (simulation) hoặc bản mô phỏng (mockup).
Trong mọi tình huống, điều quan trọng là phải duy trì khả năng truy vết nguồn gốc (traceability) để xác nhận rằng các điều kiện đã được đáp ứng theo kế hoạch khi thực hiện kiểm thử. Để làm được điều này, các điều kiện kiểm thử trừu tượng có thể được chia nhỏ và cụ thể hóa hơn. Ngoài ra, trong kiểm thử thăm dò (exploratory testing), cần chuẩn bị một tài liệu hướng dẫn (test charter) để đảm bảo phạm vi bao phủ đầy đủ và cung cấp thông tin cần thiết.
Sản phẩm đầu ra của giai đoạn Thực hiện kiểm thử
Các sản phẩm đầu ra của việc thực hiện kiểm thử bao gồm:
- Tài liệu trạng thái của các trường hợp kiểm thử và quy trình kiểm thử (ví dụ: có thể thực hiện, đạt, không đạt, chặn, bỏ qua, v.v.)
- Báo cáo lỗi
- Tài liệu liên quan đến các đối tượng kiểm thử, mục tiêu kiểm thử, công cụ kiểm thử và testware
Trong các sản phẩm này, tính tái hiện của kiểm thử là rất quan trọng. Đặc biệt, khi báo cáo sự cố, cần phải tái hiện sự cố để phân tích nguyên nhân và đưa ra giải pháp. Ngay cả khi thời gian tái hiện gặp khó khăn, vẫn cần cung cấp thông tin đầy đủ cho việc phân tích. Ngoài ra, các chỉ số độ bao phủ, như kết quả thực hiện và tiến độ liên quan đến các sự kiện kiểm thử được thiết lập trong giai đoạn triển khai kiểm thử, cũng là những sản phẩm đầu ra quan trọng. Các chỉ số này có thể được sử dụng làm báo cáo tiến độ kiểm thử cho các bên liên quan, và báo cáo tiến độ kiểm thử được phân loại là sản phẩm đầu ra của công việc giám sát và kiểm soát kiểm thử.
Sản phẩm đầu ra của giai đoạn Hoàn thành kiểm thử
Sản phẩm đầu ra của giai đoạn hoàn tất kiểm thử bao gồm báo cáo tóm tắt kiểm thử nhằm thông báo và đạt được sự đồng thuận từ các bên liên quan về việc kiểm thử đã hoàn thành. Báo cáo tóm tắt kiểm thử được lập cho từng mốc quan trọng và là sản phẩm của hoạt động giám sát và kiểm soát kiểm thử, nhưng khi tất cả các kiểm thử đã hoàn tất, báo cáo này được coi là sản phẩm đầu ra của giai đoạn hoàn tất kiểm thử.
Ngoài ra, khi chuyển đổi mức kiểm thử hoặc chuyển đổi vòng lặp kiểm thử, các thông tin sau đây được lưu lại cho chu kỳ tiếp theo:
- Thông tin có ích cho việc cải thiện kiểm thử
- Các trường hợp kiểm thử chưa thực hiện và các lỗi chưa được báo cáo sẽ chuyển sang chu kỳ sau
- Dữ liệu kiểm thử, môi trường kiểm thử, và các testware có thể tái sử dụng
Các báo cáo tóm tắt kiểm thử, dữ liệu kiểm thử, và môi trường kiểm thử này sẽ được chuyển tiếp làm sản phẩm đầu ra hoàn tất cho các chu kỳ tiếp theo.
Đến đây, chúng ta đã hoàn thành phần giới thiệu về các hoạt động chính của kiểm thử. Vậy, mọi người đã bao giờ nghĩ đến mối quan hệ giữa tâm lý con người và kiểm thử chưa?
Để cải thiện chất lượng phần mềm, việc “chỉ ra các lỗi” là rất quan trọng, tuy nhiên, các lập trình viên có thể dễ dàng cảm thấy bị chỉ trích và khó chấp nhận những lỗi được chỉ ra này. Đặc biệt, khi việc phân công vai trò và giao tiếp không rõ ràng, họ có thể cảm thấy đội ngũ kiểm thử như một bộ phận nằm ngoài, dẫn đến tâm lý phản kháng. Lập trình viên thường tin tưởng vào tính đúng đắn của code mình viết và có xu hướng khó chấp nhận những chỉ trích từ đội ngũ kiểm thử.
Mặc dù chỉ ra các lỗi giúp nâng cao chất lượng, nhưng phía các lập trình viên lại có thể cảm thấy điều này gia tăng chi phí mà không đóng góp trực tiếp vào năng suất. Do đó, cần thiết phải có lời giải thích về tầm quan trọng của các hoạt động kiểm thử cũng như xây dựng mối quan hệ đáng tin tưởng giữa hai phía. Nếu việc chỉ ra các lỗi được xem như là một hoạt động nhằm “cải thiện chất lượng” thì mối quan hệ tích với lập trình viên có thể dễ dàng được xây dựng một cách tích cực hơn.
Kỹ năng giao tiếp là điều cần thiết cho đội ngũ kiểm thử để thiết lập lòng tin với các lập trình viên. Thông qua việc thường xuyên thông báo tiến độ kiểm thử, số lượng lỗi phát hiện được và chia sẻ mục đích của hoạt động kiểm thử, việc hợp tác có thể trở nên suôn sẻ hơn. Ngoài ra, có thể thông báo trước nội dung đánh giá và kiểm thử để đạt được sự đồng thuận từ các lập trình viên hơn.
Các cách giao tiếp hiệu quả:
- Bắt đầu với thái độ hợp tác thay vì đối đầu, cùng nhắc nhở mọi người rằng mục tiêu chung là xây dựng một hệ thống chất lượng cao.
- Nhấn mạnh lợi ích của kiểm thử. Chẳng hạn, đối với lập trình viên, thông tin về lỗi giúp nâng cao chất lượng sản phẩm và cải thiện kỹ năng cá nhân; đối với tổ chức, phát hiện và sửa lỗi thông qua kiểm thử giúp tiết kiệm thời gian, chi phí và giảm rủi ro tổng thể cho chất lượng sản phẩm.
- Truyền đạt kết quả kiểm thử và các phát hiện một cách trung lập, tập trung vào sự thật và tránh đổ lỗi cho người phụ trách phát triển đã tạo ra lỗi. Cần tạo báo cáo lỗi và đánh giá các phát hiện dựa trên tính khách quan và tính thực tế.
- Hiểu và đồng cảm với cảm xúc của các lập trình viên cũng như lý do họ phản ứng tiêu cực đối với các báo cáo lỗi được nhận.
- Đảm bảo người khác hiểu điều bạn nói và bạn cũng hiểu điều người khác nói.
Tâm lý của người phụ trách kiểm thử và lập trình viên
Lập trình viên và người phụ trách kiểm thử có các mục tiêu khác nhau, do đó nội dung và phương pháp hoạt động của họ cũng khác nhau. Lập trình viên thiết kế hệ thống và phần mềm để đáp ứng yêu cầu của khách hàng, tạo ra các sản phẩm theo đúng như tài liệu thiết kế và chương trình. Ngược lại, người phụ trách kiểm thử thực hiện các công việc nhằm xác minh chất lượng và phát hiện lỗi, bao gồm kiểm thử tĩnh, kiểm thử động, báo cáo lỗi và cung cấp thông tin về chất lượng. Mặc dù tâm lý của họ khác nhau, nhưng khi hỗ trợ lẫn nhau, họ có thể góp phần vào việc phát triển sản phẩm chất lượng cao hơn.
Ngoài ra, vai trò và góc nhìn của nhân viên cũng thay đổi tùy thuộc vào mô hình phát triển. Trong mô hình Waterfall, công việc được tiến hành theo từng giai đoạn, trong khi các mô hình như Spiral hoặc Incremental yêu cầu sự linh hoạt hơn. Đặc biệt, trong các dự án lớn hoặc trong các lĩnh vực yêu cầu độ an toàn cao, người phụ trách kiểm thử độc lập có khả năng phát hiện lỗi tốt hơn. Kỹ năng này cũng rất hữu ích trong các lĩnh vực chuyên môn như y tế và tài chính, nơi mà kiến thức chuyên ngành là cần thiết.
Cùng làm các câu hỏi kiểm tra lại kiến thức bên trên nào!