Như đã giới thiệu trong bài “Automation testing và manual testing: Điểm mạnh và điểm yếu từng loại“, hiện tại ở Cybozu Việt Nam, chúng tôi đang thực hiện kiểm thử thủ công (manual testing) là chính, bên cạnh kiểm thử tự động.
Với chúng tôi, kiểm thử thủ công là phương pháp không thể thiếu do khối lượng công việc kiểm thử rất nhiều. Sử dụng phương pháp này, chúng tôi có thể phát hiện và giải quyết các vấn đề liên quan đến thao tác sử dụng nhanh chóng hơn kiểm thử tự động.
Trong khuôn khổ bài viết này, tôi xin giới thiệu về quy trình thực hiện kiểm thử thủ công trong dự án phát triển sản phẩm Garoon.
Phân tích yêu cầu, hiểu rõ specification
Đối với team Garoon, chúng tôi đang thực hiện theo mô hình Scrum. Do vậy, ở giai đoạn đầu tiên khi làm việc với một backlog, QA sẽ cùng với developer phân tích yêu cầu được Product Owner miêu tả trong User story của backlog, các tài liệu miêu tả kèm theo nếu có và nội dung của tiêu chí chấp nhận (Acceptance criteria) trong backlog đó. Các nội dung này giúp QA hiểu được mục đích của backlog, định hình được phạm vi cần kiểm thử, và công việc cần phải làm trong backlog. Trong quá trình phân tích, QA có thể đặt ra câu hỏi đối với Product Owner để làm rõ và hiểu yêu cầu chính xác hơn, cũng như bổ sung những nội dung còn thiếu.
Sau khi specification (tài liệu đặc tả) về chức năng cần kiểm thử được hoàn thành bởi developer, QA sẽ đọc để hiểu rõ và cùng developer review nội bộ để chỉnh sửa những điểm chưa chính xác trong specification.
Bên cạnh việc phát triển chức năng mới thì fix bug (sửa lỗi) cũng là một phần quan trọng của phát triển một sản phẩm. Đó có thể là bug chỉ xảy ra ở version hiện tại mà không xảy ra ở version trước, hoặc là bug phát sinh từ các version trước nhưng do mức độ nghiêm trọng không cao nên chưa được fix gấp. Khi thực hiện các backlog để fix bug, QA cần tái hiện lại bug, sau đó nghiên cứu kĩ lại specification của chức năng bị lỗi, và cả specification của những chức năng có ảnh hưởng.
Thiết kế kịch bản kiểm thử (test case)
Sau khi đã làm rõ các điểm nêu trên, QA có thể hiểu rõ hơn về quy trình nghiệp vụ cũng như tính năng trong backlog đang thực hiện. Từ đó, QA sẽ viết được test case.
Test case như người dẫn đường cho QA, đưa ra các bước chi tiết để giúp QA kiểm tra xem một chức năng hay một ứng dụng có hoạt động đúng theo yêu cầu hay không. Test case sẽ được viết dựa trên specification và những hiểu biết của QA về chức năng họ sẽ thực hiện kiểm thử.
Một test case chi tiết sẽ giúp cho QA thực hiện việc kiểm thử một cách trôi chảy. Ngoài ra, test case chi tiết cũng giúp một QA mới tham gia vào dự án có thể nắm bắt nhanh được nội dung kiểm thử và có thể thực hiện kiểm thử dễ dàng mà không cần quá nhiều thời gian để hỏi lại người viết test case.
Để viết test case một cách hiệu quả thì người viết cần phải bao phủ đầy đủ các nghiệp vụ liên quan đến chức năng sẽ thực hiện kiểm thử.
Để thiết kế nên bộ test case hiệu quả và đảm bảo chất lượng của sản phẩm, chúng tôi thường áp dụng các kĩ thuật thiết kế dựa trên specification (specification-based) như phân tích giá trị biên (Boundary value analysis), phân vùng tương đương (Equivalence partitioning) và kĩ thuật thiết kế dựa trên kinh nghiệm (experience-based).
Phân tích giá trị biên
Phân tích giá trị biên là kĩ thuật kiểm tra các giá trị trở thành giá trị biên và các giá trị gần kề biên. Lỗi thường xảy ra ở giá trị biên nhưng cũng thỉnh thoảng gặp ở các giá trị gần kề biên.
Phân vùng tương đương
Phân vùng tương đương là kĩ thuật sẽ phân loại các giá trị đầu vào thành những phân vùng theo một logic nhất định. Từ đó, QA sẽ chọn một giá trị đầu vào từ mỗi phân vùng để đưa vào test case. Nếu giá trị đầu vào đó hợp lệ hoặc không hợp lệ thì cả phân vùng cũng hợp lệ hoặc không hợp lệ.
Kĩ thuật thiết kế dựa trên kinh nghiệm
Kĩ thuật thiết kế test case dựa trên kinh nghiệm thì phụ thuộc vào kinh nghiệm và những hiểu biết của QA về sản phẩm, ví dụ như dựa trên các lỗi trước đây đã từng xảy ra để dự đoán các lỗi tiềm ẩn. Với một sản phẩm có lịch sử phát triển hơn 15 năm cùng số lượng tính năng rất nhiều như Garoon, việc thiết kế test case dựa trên kinh nghiệm khá quan trọng với QA của team Garoon. Và đội ngũ QA của chúng tôi vẫn đang tích luỹ kinh nghiệm hằng ngày qua từng backlog đã thực hiện.
Review test case
Sau khi test case được viết xong thì người viết sẽ tự kiểm tra lại test case (self-review), sau đó sẽ chuyển sang cho một thành viên khác trong team kiểm tra chéo (cross-review). Sau khi hoàn thành công đoạn review thì test case mới được đưa vào giai đoạn thực thi test. Hiện nay, một số Scrum team cũng đang áp dụng hình thức mob viết test case để giảm công việc review test case, giúp đẩy nhanh tốc độ hoàn thành test case.
Thực hiện kiểm thử
Sau khi chức năng được code xong và test case đã hoàn tất, QA sẽ chuẩn bị môi trường và bắt đầu thực hiện kiểm thử.
Khi thực hiện test cho sản phẩm Garoon, chúng tôi có các loại kiểm thử như sau:
Kiểm thử chức năng (Functional testing)
Kiểm thử chức năng để kiểm tra chức năng hoạt động theo yêu cầu và đảm bảo nghiệp vụ. Chúng tôi thực hiện cả kiểm thử API hay database tuỳ theo nội dung của backlog.
Chúng tôi sử dụng nhiều công cụ để thực hiện kiểm thử như Postman để test API, BurpSuite và Fiddler để test security, SQLYogs để test database, vv… Các công cụ này giúp QA có thể thực hiện công việc kiểm thử một cách hiệu quả và nâng cao năng suất làm việc.
Kiểm thử hồi quy (Regression test)
Kiểm thử hồi quy để kiểm tra xem những thay đổi trong một build không gây ảnh hưởng đến các tính năng khác hay tạo thêm lỗi mới.
Kiểm thử cài đặt (Installation testing)
Kiểm thử cài đặt để kiểm tra việc cài đặt và tháo gỡ Garoon bản On-Premise trên các môi trường khác nhau.
Kiểm thử cấu hình (Configuration test)
Đây là loại kiểm thử để đảm bảo sản phẩm hoạt động tốt trên các hệ điều hành và trình duyệt khác nhau. Vì ngày càng xuất hiện nhiều nền tảng công nghệ khác nhau nên loại kiểm thử này rất quan trọng.
Chúng tôi thường kiểm thử với:
- Các hệ điều hành khác nhau như Windows, Linux, CentOS trên các version khác nhau
- Các trình duyệt web khác nhau như Safari, Chrome, FireFox, vv…
Report bug
Trong quá trình thực hiện kiểm thử, nếu tìm thấy bug, QA cần phải báo cáo lỗi một cách chi tiết để developer tiến hành sửa lỗi.
Nội dung báo cáo bug cần ghi các bước để tái hiện một cách chi tiết, cùng với kết quả thực tế và kết quả mong muốn. Ngoài ra cần đính kèm nội dung bug các tài liệu có thể giúp hiểu rõ vấn đề hơn như video ghi lại các bước tái hiện, ảnh chụp màn hình, file log, tài liệu tham khảo, tài liệu spec. Việc báo cáo này là cần thiết cho những người có liên quan biết về tình trạng, mức độ nghiêm trọng và ưu tiên của các bug.
Hiện nay chúng tôi sử dụng application của kintone, một sản phẩm của Cybozu, để làm hệ thống quản lý bug. Mỗi bug được báo cáo sẽ gửi thông báo đến Product Owner và những người có liên quan để họ nắm được thông tin và có hành động phù hợp, như fix bug gấp nếu là bug nghiêm trọng hay lên kế hoạch để fix ở các version sau nếu là bug ít nghiêm trọng hơn.
Sau khi lỗi được sửa, QA sẽ test lại phần code đã được sửa. Nếu lỗi không còn xảy ra và các test case có liên quan đều pass thì QA sẽ đóng bug lại. Nếu các trường hợp kiểm thử bị fail thì lỗi sẽ được reopen và chuyển giao lại cho developer để fix lại.
Viết báo cáo kiểm thử (test report)
Sau khi công việc kiểm thử hoàn tất, QA sẽ viết báo cáo kiểm thử. Báo cáo kiểm thử tóm tắt lại nội dung kiểm thử và kết quả, giúp cho Product Owner và các developer cũng như các bên liên quan khác biết được nội dung test, phạm vi test và đánh giá xem tính năng đã có thể đưa ra release được hay chưa.
Trong test report, QA cũng sẽ cung cấp các thông tin về thực thi test như thông tin build, số lượng bug đã fix và chưa fix, số lượng test case, người thực hiện test, và những lưu ý nếu có.
Lời kết
Bài giới thiệu về manual testing tại Cybozu Việt Nam xin kết thúc ở đây. Hy vọng bài viết này đã giúp bạn hiểu được về quy trình thực hiện kiểm thử thủ công tại công ty chúng tôi và có hứng thú với công việc kiểm thử thú vị này. Xin hẹn gặp lại ở các bài viết tiếp theo giới thiệu về lĩnh vực kiểm thử.