Đặt câu hỏi là một kỹ năng quan trọng để giúp chúng ta hoàn thành công việc một cách hiệu quả nhất. Tuy nhiên vẫn có nhiều tester vẫn còn tâm lý “ngại hỏi” hoặc không biết phải hỏi như thế nào cho hợp lý và hiệu quả. Bài viết này sẽ giúp bạn xóa bỏ vấn đề này và hướng dẫn bạn cách đặt câu hỏi hiệu quả để trở thành tester xịn hơn.
Lý do thường ngại đặt câu hỏi
Đưa ra câu hỏi là một cách để chúng ta trao đổi và xác nhận thông tin. Trong quá trình phát triển phần mềm cũng vậy, sẽ gặp những “mô tả yêu cầu” không rõ ràng, một phát biểu mơ hồ có nhiều cách hiểu khác nhau, hoặc có nhiều trường hợp có thể xảy ra nhưng không được đề cập cụ thể, v.v… Nhưng đôi khi, thay vì tìm kiếm câu trả lời, chúng ta lại chọn cách im lặng và bỏ qua.
Vì sao lại như vậy? Việc ngại hỏi có thể xuất phát từ nhiều nguyên nhân nhưng với tester mới, đặc biệt là tester trái ngành, thì hai yếu tố tâm lý này là phổ biến nhất:
- Bạn sợ người khác chê cười hoặc đánh giá không tốt về bạn
- Bạn ngại “va chạm” với người khác
Việc đưa ra câu hỏi đôi khi sẽ dẫn đến các cuộc thảo luận hay thậm chí là tranh luận để giải đáp thắc mắc và cần “chốt” được câu trả lời, nhưng bạn thì không thoải mái về việc đó. Hoặc ở khía cạnh khác, khi đọc tài liệu bạn thấy có những mô tả không rõ ràng, thiếu tính logic hoặc thậm chí mô tả sai, v.v… và người viết tài liệu này có chức vụ và kinh nghiệm cao hơn bạn, làm cho bạn có suy nghĩ rằng “đặt câu hỏi sẽ khiến họ không hài lòng.”
Có một thực tế là, dù một người có nhiều kiến thức, kinh nghiệm, hay vị trí cao thấp trong công ty thì khi làm việc họ đều có thể mắc lỗi và có sai sót. Ví dụ, PM hay BA có thể hiểu nhầm ý khách hàng dẫn đến mô tả (viết) tài liệu sai hoặc không được rõ ràng. Hay Tester thì viết test case bị thiếu trường hợp hoặc không bao phủ hết các yêu cầu trong tài liệu SRS. Tuy nhiên, càng có nhiều kinh nghiệm thì chúng ta sẽ càng ít mắc sai sót.
Vì thế, việc đặt câu hỏi để làm rõ yêu cầu là một điều cần làm càng sớm càng tốt. Khi đưa ra câu hỏi để làm rõ yêu cầu có nghĩa là bạn đã phát hiện lỗi của tài liệu, với tester thì khi phát hiện lỗi thì phải thông báo ngay cho nhóm dự án. Điều này không chỉ giúp bản thân bạn hiểu rõ và hiểu đúng yêu cầu để viết test case và kiểm thử hệ thống đó một cách chắc chắn và tự tin, mà còn có thể giúp PM/BA phát hiện sai sót của họ và rút kinh nghiệm để tránh những lỗi sai tương tự trong tương lai, và lập trình viên thì sẽ có tài liệu rõ ràng để lập trình thì sẽ hạn chế sai sót trong mã nguồn (source code) của họ.
Và việc đặt câu hỏi sẽ không còn là nỗi lo nếu bạn biết cách đặt câu hỏi để các bên liên quan không cảm thấy khó chịu và họ luôn sẵn lòng trả lời bạn, và câu trả lời đúng trọng tâm – đầy đủ thông tin bạn đang cần, mình gọi đó là cách đặt câu hỏi hiệu quả.
Cần làm gì trước khi đặt câu hỏi?
Để dễ hình dung, chúng ta sẽ sử dụng tình huống dưới đây để làm ví dụ xuyên suốt cho bài viết này.
Giả sử bạn vừa được nhận vào một dự án với vai trò tester và bạn đang “bơi” trong đám tài liệu để tìm hiểu về một hệ thống rồi viết test case cho nó. Đang viết test case thì gặp một đoạn mô tả yêu cầu “hoạt động tốt trên mọi thiết bị” thì bạn sẽ làm gì trong trường hợp này?
Trước tiên, là một tester, bạn hãy giữ cho mình một mindset (tư duy) luôn thắc mắc, luôn đặt câu hỏi cho mọi thứ, mọi vấn đề mà mình nghiên cứu. Trong trường hợp này, mình nên đặt câu hỏi “mọi thiết bị là gồm những thiết bị nào? Máy tính và cả trên các thiết bị điện thoại? Và nếu là điện thoại, thì iPhone, điện thoại sử dụng Android hay bao gồm cả các hệ điều hành khác? v.v…
Tuy nhiên, điều này không có nghĩa là bạn sẽ mang mọi câu hỏi ở trên đặt trên bàn PM hay khách hàng ngay thức thì. Nên ghi nhớ câu “thần chú” này: “Trước khi hỏi người khác, hãy hỏi chính mình.” Hay nói cách khác, trước khi đặt câu hỏi cho ai đó, bạn hãy chắc chắn rằng mình đã tìm kiếm câu trả lời trong phạm vi hiện tại, với những tài liệu hiện có. Với ví dụ trên, bạn thử tìm xem các loại tài liệu quy định về môi trường vận hành của hệ thống/sản phẩm phần mềm đang được phát triển này, nếu làm công ty phát triển sản phẩm bạn có thể xem trên phần “online help” của trang web công ty mình, có khi được đề cập. Hoặc bạn có thể tìm kiếm trên Google với từ khoá “tên sản phẩm + supported devices”
Tóm lại, bạn nên tự tìm câu trả lời thông qua việc xem lại kỹ tài liệu mô tả yêu cầu, tài liệu thiết kế, bảng liệt kê các cụm từ viết tắt, các chú thích, v.v… nếu có. Sau khi tự tìm hiểu mà vẫn chưa thể giải quyết được thắc mắc trên, lúc này bạn có thể đặt câu hỏi cho người khác như PM hay khách hàng.
Các loại câu hỏi
Cách đặt câu hỏi sẽ khác nhau tùy vào tình huống bạn hỏi trực tiếp người cần hỏi (ví dụ PM hay khách hàng) hoặc hỏi qua một người khác như Comtor hoặc tạo ticket trên hệ thống. Nếu hỏi trực tiếp người cần hỏi qua chat hoặc nói chuyện trực tiếp, bạn có thể bắt đầu từ câu hỏi tổng quát như “PM ơi, cho mình hỏi: dự án/công ty mình/khách hàng có tài liệu nào mô tả môi trường hay thiết bị mà hệ thống mình phải hỗ trợ không?”
Có nhiều cách để đặt câu hỏi, một số loại câu hỏi sẽ phù hợp hơn trong tình huống này, nhưng lại không phù hợp với tình huống khác. Ở bài viết này, mình xin đề cập đến hai loại câu hỏi chính là “câu hỏi đóng” dùng để xác nhận thông tin và “câu hỏi mở” để yêu cầu cung cấp thông tin.
Quay lại tình huống giả định trên, trong yêu cầu mô tả việc kiểm thử chức năng cho phép người dùng tải hình ảnh lên máy chủ, trong đó không mô tả về môi trường và thiết bị cần phải kiểm thử. Bạn sẽ cần phải đặt thêm câu hỏi khác để có thêm thông tin chi tiết.
Thì câu hỏi “Với mỗi loại thiết bị chỉ cần kiểm thử trên một hệ điều hành đại diện thì có được không?” – Đây là một dạng câu hỏi đóng.
Hoặc nếu bạn hỏi: “Chức năng này sẽ được kiểm thử trên những thiết bị hay môi trường nào?” – Đây là một dạng câu hỏi mở.
Hai dạng câu hỏi chính
- Câu hỏi đóng là dạng câu hỏi chủ yếu dùng để xác nhận thông tin, thông thường câu trả lời là đúng – sai, có – không, hoặc một danh sách các lựa chọn. Đối với tester, câu hỏi đóng thường được sử dụng khi cần xác định cách hiểu của mình có đúng không, nhất là khi phân tích yêu cầu và viết test case.
- Câu hỏi mở thường được dùng khi bạn chưa có bất kỳ thông tin hay hiểu biết gì về vấn đề đó và muốn người trả lời đưa ra các thông tin hoặc muốn đào sâu thông tin và chi tiết hơn.
Hãy xem xét ví dụ này để hiểu hơn về câu hỏi đóng và câu hỏi mở
Giả sử khi bạn đang phân tích tài liệu của chức năng (của một ứng dụng web) cho phép người dùng tải tài liệu lên Cloud (như Google Drive) có mockup (thiết kế mẫu) như hình sau, thì bạn cần phải đưa ra câu hỏi để yêu cầu cung cấp thêm thông tin.
Câu hỏi của bạn trong trường hợp này là gì?
Và đây có thể là “câu trả lời” mà bạn đang mong đợi
Trong trường hợp này, nếu chỉ có mockup và không kèm theo mô tả gì thì chắc chắn một câu hỏi đóng sẽ không phù hợp, bởi vì có quá nhiều thông tin cần làm rõ, như hỗ trợ upload những loại file nào, dung lượng tối đa là bao nhiêu, có thể upload nhiều file thì tối đa là bao nhiêu file cùng lúc, v.v…
Bạn có thể hỏi từng câu, hoặc cũng có thể gom lại thành một câu như:
- Nếu bạn không chắc lắm thì hỏi “Hệ thống có ràng buộc về loại file, dung lượng tối đa của file, số lượng file đồng thời được upload, v.v… hay không? Nếu có, vui lòng cho biết thông tin cụ thể” – Bạn không chắc là có ràng buộc hay không
- Nếu bạn “tin rằng” hệ thống phải có những quy định này (theo kinh nghiệm của bản thân) thì bạn có thể hỏi “Vui lòng mô tả thêm thông tin về loại file, dung lượng tối đa, số lượng file đồng thời có thể tải lên hệ thống.” – Bạn nghĩ rằng sẽ phải có.
Các nội dung cần có trong một câu hỏi
Như đã đề cập đến ở trên, tuỳ vào tình huống, bối cảnh mà sẽ có những cách đặt câu hỏi cho phù hợp. Tuy nhiên khi đặt câu hỏi bạn nên suy xét và đề cập 3 nội dung sau: ngữ cảnh, vấn đề và các đề xuất.
1. Ngữ cảnh (context)
Thử đặt mình vào vị trí của người nhận câu hỏi, bạn sẽ thế nào và nghĩ gì khi nhận được câu hỏi một cách đột ngột trong khi không có ngữ cảnh gì về nó. Vì thế, việc cung cấp đủ thông tin để tạo ngữ cảnh cho người nhận câu hỏi là điều rất cần thiết.
2. Vấn đề (problem)
Bạn cần giải thích rõ vì sao “điều đó là vấn đề”. Bạn có thể nêu ra những vấn đề bất hợp lý hay mô tả không rõ ràng, hay mô tả sai hoặc nêu ra những vấn đề mà mình không hiểu trong tài liệu bằng một đoạn trích dẫn.
3. Đề xuất hướng giải quyết (solution)
Trong hầu hết các trường hợp, việc đề xuất cách giải quyết vẫn luôn được khuyến khích vì nó thể hiện rằng bạn đã có đọc kỹ và nghiên cứu tìm hiểu thông tin trước khi đưa ra câu hỏi. Bạn có thể đưa ra một đề xuất theo một số dạng:
- “Tôi hiểu… có đúng không?”
- “Có thể thực hiện theo cách… được không?”
- Hoặc bạn cũng có thể đề xuất nhiều cách giải quyết khác nhau để xác nhận khách hàng/PM muốn chọn cách nào
Tester đặt câu hỏi khi phân tích yêu cầu
Để dễ hình dung hơn, chúng ta vẫn sẽ lấy chức năng upload file làm ví dụ. Nhưng tình huống bây giờ là trong tài liệu mô tả có viết cho phép upload file có dung lượng tối đa là 5MB. Tuy nhiên, bạn không thấy mô tả về việc nếu upload quá dung lượng thì sẽ xử lý như thế nào.
Bạn có thể đặt câu hỏi như sau:
Chức năng upload file được mô tả ở trang 23 (ví dụ) trong tài liệu SRS “Tên tài liệu, phiên bản v3.14” không đề cập cách xử lý khi upload file quá dung lượng cho phép. Vui lòng xác nhận cách xử lý nào sau đây là đúng:
- Nút Upload sẽ tự động disable khi người dùng chọn file có dung lượng quá 5MB
- Hệ thống sẽ hiển thị thông báo “Chỉ được phép tải file từ dưới 5MB!”
Nếu không phải các cách trên, vui lòng mô tả cách xử lý cho trường hợp này.
Hãy cùng phân tích kỹ hơn câu hỏi trên.
- Ngữ cảnh ở đây bao gồm:
- Chức năng upload file
- Mô tả yêu cầu ở trang 23 trong tài liệu SRS “Tên tài liệu, phiên bản v3.14”
- Vấn đề: chưa đề cập đến cách xử lý khi người dùng tải file quá dung lượng cho phép
- Ở đây có 2 đề xuất: (đây là một ví dụ của câu hỏi đóng)
- Nút Upload sẽ tự động disable khi người dùng chọn file có dung lượng quá 5MB
- Hệ thống sẽ hiển thị thông báo “Chỉ được phép tải file từ dưới 5MB!”
- Và một câu hỏi phụ (câu hỏi mở): vui lòng mô tả cách xử lý
Những lưu ý khi đặt câu hỏi
Bên cạnh việc đặt câu hỏi rõ ràng, đầy đủ nội dung thì bạn cũng cần tránh viết câu dông dài, tránh việc lặp từ quá nhiều. Nên trình bày câu hỏi thật ngắn gọn và đầy đủ thông tin cần thiết.
Tránh việc tự suy đoán mọi thứ dựa trên ý kiến chủ quan trong khi đọc và phân tích tài liệu, khi gặp một số vấn đề mà bạn cảm thấy không chắc chắn, nhưng lại áp đặt những suy nghĩ cá nhân lên vấn đề rồi từ đó tự cho rằng ý kiến của bản thân là đúng. Điều này thường dẫn đến xung đột giữa tester và developer khi họ có cách hiểu yêu cầu khác nhau. Cách xử lý tốt nhất trong trường hợp này là đặt câu hỏi cho khách hàng hay PM để làm rõ yêu cầu.
Để hạn chế xảy ra tình huống này, bạn có thể tham khảo và áp dụng kỹ thuật “6 chiếc mũ tư duy” để có cái nhìn đa chiều hơn.
Ngoài ra, việc xác định thời điểm nên đặt câu hỏi cũng rất quan trọng. Nếu trong cuộc họp, bạn có câu hỏi thì không nên ngắt lời người đang trình bày mà hãy ghi chú lại để hỏi sau khi họ trình bày xong phần đó, vì đôi khi câu trả lời “nằm ở slide tiếp theo.” Còn nếu như bạn đang phân tích tài liệu nghiệp vụ, bạn không nên cứ gặp vấn đề là phải đi hỏi ngay, mà nên tổng hợp lại sau khi nghiên cứu xong một màn hình, một phần mô tả chức năng lớn, hoặc các chức năng có liên quan đến nhau. Hoặc sẽ tốt hơn nếu bạn có cho mình một công cụ để quản lý quá trình hỏi đáp như Jira, MS Excel, Redmine, v.v…
Có như vậy thì sẽ không làm mất thời gian của người khác và câu hỏi cũng được quản lý một cách có hệ thống và hiệu quả hơn.
Tổng kết lại, có nhiều cách đặt câu hỏi tuỳ thuộc vào tình huống và bối cảnh khác nhau. Bạn có thể sử dụng câu hỏi đóng để xác nhận thông tin hoặc câu hỏi mở để yêu cầu thông tin. Dù là loại câu hỏi nào thì khi đặt câu hỏi đừng quên 3 phần chính phải có trong một câu hỏi: ngữ cảnh, vấn đề, và đề xuất.
