Trong Dự án 1 của học kì 3, sinh viên ngành Ứng dụng phần mềm FPT Polytechnic TP HCM được tiếp cận với nền tảng quản lí nội dung(CMS) mã nguồn mở WordPress, WordPress có khả năng tùy biến cao, kho Theme và Plugin phong phú nên sinh viên có thể dễ dàng xây dựng và vận hành thành công một website dưới dạng phiên bản Beta. Tuy nhiên để website có thể bật chế độ “Go-live”, dự án cần phải vượt qua giai đoạn kiểm thử chặt chẽ, kéo dài và chỉnh sửa liên tục để hoàn thiện.
Với môn học mới “Kiểm thử cơ bản” trong học kì 4, sinh viên được giảng viên hướng dẫn để kiểm thử sản phẩm Dự án 1 của mình bằng hình thức kiểm thử chéo, nhóm 1 kiểm thử sản phẩm của nhóm 2, nhóm 2 kiểm thử sản phẩm nhóm 3….để tuân theo nguyên tắc “Không được kiểm thử sản phẩm của chính mình tạo ra”.
Môn học giúp sinh viên tiếp thu và thực hành với nhưng keyword như: Manual Testing, BlackBox/WhiteBox Testing, Beta Testing, In Acceptance Testing, và Static/Dynamic Testing. Hơn thế nữa, sau khi hoàn thành việc kiểm thử, sinh viên có thể báo cáo với giảng viên và gửi hồ sơ kiểm thử về cho nhóm phát triển dự án bằng file mềm gồm các yếu tố quan trọng sau: Requirement, Test Plan, Test Design, Test Case, Test Defect, Test Report. Nhờ đó sinh viên rèn luyện được tư duy kiểm thử như một chuyên viên QA.
WhiteBox Testing và Static Testing
Thực tế là kể từ khi sinh viên phát triển Dự án 1, các nhóm cũng đã bắt đầu “kiểm tra” chính dự án của mình thông qua code(một dạng WhiteBox Testing); “kiểm tra” GUI, pages, các thành phần của dự án(một dạng Static Testing giúp phát hiện lỗi sớm thông qua việc Verification-xác minh, và do đó rất dễ chỉnh sửa ngay giai đoạn phát triển)…
Tuy nhiên khi đó khái niệm kiểm thử chưa hình thành trong suy nghĩ của sinh viên, đến môn học này các bạn sẽ được tiếp cận phương pháp Dynamic Testing-một dạng kiểm thử mà sản phẩm đã hoàn thiện và đi vào hoạt động, test team chủ yếu đi vào phần kiểm thử chức năng-Function và phi chức năng – Non-function. Vậy môn kiểm thử cho chúng ta hiểu biết kiến thức và thực hành kĩ năng gì?
Kiểm thử thủ công – Nền tảng của tư duy kiểm thử
Trong môi trường học tập thực tế, sinh viên được tiếp cận với Manual Testing – phương pháp kiểm thử thủ công giúp hiểu rõ từng bước thao tác của người dùng. Đây là cách hiệu quả để phát hiện lỗi chức năng, logic nghiệp vụ và trải nghiệm người dùng. Đặc biệt, sinh viên được hướng dẫn thực hiện BlackBox Testing – kỹ thuật kiểm thử không cần biết mã nguồn, tập trung vào đầu vào và đầu ra của hệ thống.
Việc thực hành đầy đủ các bước này giúp sinh viên hiểu rõ quy trình kiểm thử chuyên nghiệp, từ giai đoạn In Acceptance Testing (kiểm thử chấp nhận-giai đoạn tiền phát hành Go-line) đến Beta Testing (kiểm thử người dùng cuối-phiên bản dùng thử).
BlackBox Testing và cách thức kiểm thử chéo
Với cách thức triển khai này, sinh viên sẽ được tiếp cận website của nhóm khác để thực hiện kiểm thử bằng phương pháp BlackBox Testing, như vậy mỗi nhóm khi làm kiểm thử cho website của nhóm khác thì họ như một người dùng thực sự của website, từ đó họ có cái nhìn khách quan và đánh giá chính xác những điểm đạt được và chưa đạt được của nhóm khác.
Khi kết thúc giai đoạn kiểm thử chéo, các nhóm nộp “Hồ sơ kiểm thử” cho GV đánh giá, sau cùng có thể gửi hồ sơ này cho “Chính chủ” của website để họ nhìn lại sản phẩm của chính mình, nếu phát hiện những lỗi ở mức độ khác nhau mà chỉnh sửa lại cho phù hợp.
Hồ sơ kiểm thử
Để hoàn thiện được hồ sơ đầy đủ của quá trình kiểm thử-một trong những thành phần quan trọng tạo nên Hồ sơ dự án, sinh viên chủ yếu hoàn thành file mềm(thường được làm mẫu dưới dạng file Excel gồm 6 sheet) chứa đựng các nội dung sau:
- Requirement – các yêu cầu chức năng và phi chức năng của hệ thống
- Test Plan – kế hoạch kiểm thử tổng thể của mỗi nhóm
- Test Design – thiết kế các trường hợp kiểm thử dựa trên yêu cầu chức năng của hệ thống, với các yêu cầu phi chức năng thường được thực hiện trong Automation Testing
- Test Case – kịch bản kiểm thử cụ thể, đây là nội dung quan trọng và để thực hiện thành công cần nhiều thời gian, sự tỉ mỉ của tester vì số lương test case rất lớn. Qua test case cũng giúp đánh giá được độ phủ của kiểm thử chức năng theo Requirement và test design.
- Test Defect – ghi nhận lỗi phát hiện được từ test case. Đây là một tài liệu mà nhà phát triển website cần nhất, vì thông qua test defect họ nhận ra dự án còn lỗi và theo mức độ mà chỉnh sửa lại website.
- Test Report – báo cáo kết quả kiểm thử. Một tài liệu tổng kết đầy đủ về kiểm thử dưới dạng những con số.
Trong toàn bộ hồ sơ kiểm thử thì test case là nội dung quan trọng nhất, vậy tìm hiểu xem test case sẽ có gì nhé.
Test Case – Đánh giá toàn bộ chức năng của website
Một yếu tố mang tính quyết định của website là chức năng mà nó cung cấp cho người dùng, điều đó được thể hiện rất rõ trong Test Case, nó giúp xác nhận (Validation) rằng hệ thống hoạt động đúng như mong đợi. Một số ví dụ tiêu biểu:
TC01 – Đăng ký với tài khoản của bên thứ 3 như Google, Facebook..
→ Kết quả mong đợi: Đăng nhập thành công và thực hiện mua hàng.
TC02 – Tìm kiếm sản phẩm theo từ khóa
→ Kết quả mong đợi: Hiển thị danh sách sản phẩm phù hợp.
TC03 – Thanh toán với thông tin hợp lệ
→ Kết quả mong đợi: Đơn hàng được tạo và hiển thị thông báo thành công.
Kiểm thử – Hành trang và cơ hội nghề nghiệp
Việc đưa kiểm thử phần mềm vào chương trình học giúp sinh viên hiểu rõ hơn về quy trình phát triển phần mềm nói chung và website thương mại điện tử nói riêng. Đây là kỹ năng quan trọng, là một giai đoạn trong sơ đồ phát triển phần mềm, giúp sinh viên hiểu vị trí vai trò của testing trong phát triển phần mềm theo mô hình thác nước (WaterFall model), đây cũng là mô hình phổ biến dễ hiểu mà sinh viên còn được gặp lại trong những môn học sau. Tester cũng là một cơ hội nghề nghiệp của tương lai, vì “người có thể tìm ra lỗi mới chính là người mà nhà phát triển phần mềm cần”.
Giảng viên Trần Thế Bảy
Bộ môn Ứng dụng phần mềm
FPT Polytechnic TP HCM
