Dự án lớn, thời gian ngắn và chỉ có một nhân viên kiểm thử. Vậy kế hoạch kiểm thử của bạn trong tình huống này là gì? Mình nghĩ, sẽ có nhiều bạn rơi vào trường hợp tương tự và mình muốn chia sẻ với các bạn cách mình đã vượt qua. Và dù bằng cách này hay cách khác, mục tiêu chung của chúng ta vẫn là: dự án chạy đúng deadline, người dùng có một trải nghiệm tốt. Những gì mình chia sẻ, nó có thể đúng hoặc sai nhưng với mình đó là cách mà mình đã áp dụng thành công tại các công ty startup. 

Vẽ kế hoạch kiểm thử trong đầu

Hãy vẽ kế hoạch kiểm thử trong đầu ngay khi đọc tài liệu mô tả tính năng. Đầu tiên, mình hình dung bộ Test Case của mình là một cái cây. Và tính năng mới là một thân cây, luồng tính năng chính sẽ nhánh lớn, rồi tới các nhánh nhỏ hơn,.. và nhỏ hơn nữa. Cứ thế, sao cho bao quát hết toàn bộ tính năng mà mình sẽ kiểm thử.

Tiếp theo, trong thời gian hạn hẹp cho phép, từ “Cây Kiểm Thử” mình xác định sẽ bắt đầu nhánh nào trước, nhánh nào sau. Nhánh nào phải hoàn hảo và nhánh nào có thể chưa hoàn hảo. Nhưng quy tắc của mình thì các nhánh Main Flow phải được hoàn thiện trước và không được sót BUG. Nếu hối thúc Dev mình cũng sẽ ưu tiên những gì liên quan tới Main Flow.

Ví dụ

Mình lấy một ví dụ đơn giản về một “Cây kiểm thử” đó là Màn hình đăng nhập. Thân cây của mình chính là Tính năng đăng nhập, mình tạm gọi là “Thân Cây A”. 

Đầu tiên, bạn hãy nghĩ xem đóng vai trò là người dùng khi chúng ta đăng nhập sẽ có trường hợp nào xảy ra? Hoặc đăng nhập thành công, hoặc đăng nhập thất bại. Vậy từ thân cây A, mình có lần lượt hai nhánh lớn là A1 và A2.

Tiếp theo, như thế nào thì gọi là Đăng nhập thành công, nghĩa là username phải đúng và password phải đúng. Vậy từ nhánh cây lớn A1 mình có nhánh cây nhỏ hơn là A1.1

Tiếp theo, như thế nào thì gọi là Đăng nhập thất bại, nghĩa là hoặc username sai, hoặc password sai hoặc cả username và password đều sai. Vậy từ nhánh cây A2, mình có các nhánh nhỏ hơn là A2.1, A2.2 và A2.3

Cứ thế, từ các nhánh cây lớn nhỏ mình tiếp tục phát triển thêm các nhánh cây lớn nhỏ khác để “Cây kiểm thử” của mình ngày càng lớn ra.

Đại loại như, cũng từ màn hình đăng nhập mình lại có thêm các nhánh lớn A3, A4, A5 như là Quên mật khẩu, Đăng ký khi chưa có tài khoản, Bảo mật.

Hoặc kiểm thử UI của màn hình Đăng nhập nó cũng là 1 nhánh lớn A6.

Khi “Cây kiểm thử” đã hoàn thiện mình có thể quyết định nhánh nào đi trước và nhánh nào đi sau một cách dễ dàng. Như trong ví dụ này, bắt buộc các nhánh A1 và A2 của mình không được sót BUG vì đây là Main Flow của màn hình này.

>>> Xem thêm: Tạo và quản lý Bug một cách hiệu quả trong kiểm thử phần mềm

Chấp nhận sự không hoàn hảo 

“Là nhân viên kiểm thử thì không được sót BUG!”. Tất nhiên khi đóng vai trò nhân viên kiểm thử, mình cần yêu cầu sự hoàn hảo tuyệt đối của các tính năng. Hoàn hảo ở đây bắt buộc là không được sót BUG (nếu có phát sinh BUG thì đó phải là các BUG ở mức minor).

Tuy nhiên, khi mình độc mã với một tính năng lớn mà thời gian không cho phép mình hoàn hảo thì lúc này mình phải chấp nhận sự không hoàn hảo có sắp đặt. Nghĩa là, mình chủ động lựa chọn những phần kiểm tra bị hạn chế và chấp nhận sự không hoàn hảo. Tất nhiên mình phải chủ động trao đổi với đội Sản Phẩm điều này và trên tất cả nó sẽ không ảnh hưởng tới trải nghiệm của người dùng.

Ví dụ

Mình lấy ví dụ, trên “Cây Kiểm Thử” màn hình đăng nhập. Nếu lựa chọn sự không hoàn hảo, mình sẽ chấp nhận đối với nhánh cây UI- A5. Nghĩa là, đóng vai trò là một người dùng thông thường khi mình vào màn hình Đăng nhập, mọi thành phần trên màn hình đều Ổn (không có thành phần nào bất thường). Mình sẽ tạm bỏ qua các trường hợp mà mọi thành phần phải đúng chính xác 100% những gì thiết kế mô tả. 

Bên cạnh đó, mình cũng sẽ hạn chế những trường hợp ngoại lệ: username hoặc password vượt quá kích thước yêu cầu, username hoặc password có khoảng trắng đầu cuối,…

Và mình cũng nhắc lại một lần nữa, mình chấp nhận sự không hoàn hảo ở đây là ở giai đoạn đầu của tính năng. Nhưng khi tính năng đã được đưa lên thì mọi nhánh cây phải được kiểm tra để tiến tới sự hoàn hảo tuyệt đối.

Sàng lọc các lỗi

Chắc chắn 100% các lỗi mình ghi nhận sẽ không được sửa. Điều này là tất yếu khi thời gian không cho phép mình hoàn hảo. Nhưng mình phải đảm bảo rằng các lỗi đã được sàng lọc cẩn thận về độ ưu tiên. Những lỗi liên quan tới main flow (kế hoạch kiểm thử của mình đã quy định) sẽ có độ ưu tiên cao nhất. 

Mình cũng sẽ chủ động thảo luận với Product Manager về các lỗi có độ ưu tiên thấp và chưa được sửa. Để đảm bảo rằng hai bên sẽ thống nhất và Production Manager sẽ lường trước tới những tình huống lỗi xảy ra. 

Bên cạnh đó, sẽ có những trường hợp có thể làm ảnh hưởng tới trải nghiệm người dùng mà Product Manager không đề cập. Mình cũng sẽ chủ động thảo luận nhưng cũng sẽ sàng lọc về độ ưu tiên. Đúng thời gian là quan trọng, nhưng bản thân mình phải hiểu và nắm toàn bộ những tình huống có thể xảy ra. Điều này rất quan trọng vì có thể quyết định thành công của dự án. 

Tiếp tục hoàn thiện kế hoạch kiểm thử sau khi tính năng đã được sử dụng

Đối với mình, mục tiêu của việc kiểm thử là đi đến sự hoàn hảo nhất có thể. Như mình nói ở trên, trong kế hoạch kiểm thử của mình bắt buộc phải hoàn thiện những nhánh cây mà mình chấp nhận sự không hoàn hảo có sắp đặt. Thêm nữa, các lỗi còn tồn động phải được sửa 100% mà không phân biệt theo độ ưu tiên như trước. Hoàn thiện sau khi tính năng được đưa vào sử dụng là kế hoạch kiểm thử mà mình phải lựa chọn trong trường hợp này. Dù cách này hay cách khác, tất cả đều đi đến một mục tiêu chung là sự trải nghiệm của người dùng. 

Kết luận

Hơn 10 năm kinh nghiệm kiểm thử, mình may mắn được làm với các công ty startup. Khối lượng công việc nhiều và áp lực cũng nhiều nhưng nó giúp mình quản lý đầu việc tốt hơn. Qua mỗi dự án, mình lại có thêm một bài học để đúc kết được nhiều thứ ở hiện tại. Những gì mình chia sẽ ở trên, là kinh nghiệm lập kế hoạch kiểm thử thực tế cho từng dự án. Đó là cách để mình không những sống sót qua từng dự án lớn mà ngày càng làm tốt hơn.

Hy vọng bài viết này sẽ mang đến một điều gì đó bổ ích cho bạn. Bởi vì chúng mình yêu nghề Kiểm Thử nên sẽ không ngại thử thách bản thân, phải không? 

Vi Phan