Khách hàng thực sự mong đợi điều gì ở các Tester phần mềm?

Là một Tester phần mềm, đã bao giờ bạn tự đặt ra câu hỏi này chưa vậy?

Có lẽ nhiều người trong chúng ta thường sẽ nghĩ:

“Ta chỉ là Software Tester. Việc của mình là tìm bug”

Giống như câu:

Ta chỉ là chiếc lá. Việc của mình là xanh =))

Nói vui vậy chứ, chắc chắn một điều với các bạn là Khách hàng không chỉ mong đợi đơn giản như thế đâu. Vậy hãy cùng tìm hiểu xem Khách hàng thực sự mong đợi điều gì ở các Tester nhé!

Các dịch vụ IT vốn là một phần quan trọng và không thể thiếu trong ngành công nghiệp phần mềm và sự hài lòng của khách hàng là điều quan trọng để thành công. Mỗi khách hàng/tổ chức có thể khác nhau trong quy trình, tuân theo các giao thức khác nhau và giao dịch với các loại hình doanh nghiệp khác nhau.

Nhưng, nói chung các yếu tố sau đây là phổ biến và quan trọng đối với mọi người.

5 thứ mà khách hàng mong đợi từ các Software Tester:

1) Lợi ích về chi phí

Khi bạn nghĩ về việc bán hay mua cái gì đó, thì giá cả đóng vai trò chính và nó thường là một trong những nhân tố quyết định chính. Không phải tất cả chúng ta đều háo hức chờ đợi ngày Black Friday, ngày giảm giá Flipkart Billion Day hoặc lễ hội mua sắm tuyệt vời của Amazon đúng không?

Chúng ta trở thành những người mua sắm điên cuồng trong suốt thời gian giảm giá. Nó là một hành vi đơn giản của con người mong đợi vào giá trị đúng hoặc giá trị bổ sung đối với tiền của chúng ta.

Các công ty và các khách hàng thì không khác nhau. Lợi ích chi phí thúc đẩy mối quan hệ dịch vụ - khách hàng và không có gì lạ đối với trường hợp các công ty dịch vụ mất giá thầu do các đối thủ cạnh tranh báo giá thấp hơn.

Một câu hỏi LỚN được đặt ra là: Chúng ta có thể thể hiện ra các lợi ích về chi phí cho khách hàng của chúng ta không?

Những điều dưới đây có thể có ích:

• Chỉ cho họ giá trị của tiền của họ. Biện minh và cung cấp các bằng chứng hỗ trợ cho các ước tính của bạn.
• Hãy nghĩ ra những cách sáng tạo để tiết kiệm chi tiêu.
• Điều chỉnh báo giá của bạn. Thay vì tuân thủ quy trình tiêu chuẩn của bạn tiêu tốn số tiền là X, thì hãy cung cấp các lựa chọn thay thế rẻ hơn. Ví dụ: Đề xuất kiểm thử đường dẫn quan trọng thay vì kiểm thử cả hệ thống hoàn chỉnh.
• Biết về đối thủ cạnh tranh của bạn. Hãy kiểm tra thực tế một cách nhanh chóng về những thứ mà các công ty dịch vụ khác đang cung cấp cho khách hàng của họ với chi phí nào là một việc quan trọng để giữ cân bằng với mô hình thị trường định giá của bạn. (Nói các khác là biết người biết ta. Trăm trận trăm thắng)

2) Chất lượng công việc

Chất lượng và chất lượng công việc của bạn là hai thứ rất khác nhau. Đã qua những ngày mà số lượng Testcase được tạo ra hoặc các lỗi được báo cáo được sử dụng cho các chỉ số đo năng suất hoặc chất lượng. Nói các khác là việc sử dụng 2 tiêu chí trên để đo năng suất hoặc chất lượng Không còn nữa. Tình huống đó giống như hình ảnh dưới đây:

A) Biết được khi nào nói “Không”

Tất cả chúng ta đã ở những nơi mà chúng ta phải làm overtime, có những cuộc điện thoại vào cuối tuần, đêm khuya hoặc vào sáng sớm, v.v. Tuy nhiên, chúng ta không nhận ra là chúng ta có thể nói KHÔNG nếu mọi thứ tiếp tục trở nên tồi tệ hơn. Nói KHÔNG là cách duy nhất chúng ta có thể duy trì chất lượng công việc và sự tỉnh táo của chúng ta.

Khi làm như vậy, trước tiên sẽ nâng cao mối quan tâm của bạn và sau đó là sự ủng hộ về chất lượng.

Đây là một tình huống tôi đã gặp phải và điều này có thể mang tới cho bạn một ý tưởng tốt hơn về những gì tôi đang nói:

Công ty của tôi đã giành được một logo mới và là một phần của chuyển giao từ một công ty cũ sang công ty hiện tại của tôi, các phiên chuyển giao kiến thức đã được lên kế hoạch.

Chúng tôi, một nhóm gồm 6 thành viên đã đi đến địa điểm làm việc của khách hàng. Ngày đầu tiên sau khi giới thiệu, chúng tôi đã chia sẻ về kế hoạch KT. Tôi thấy tên của tôi đã được gắn vào nhiều module. Một trong những module đó hoàn toàn nằm ngoài phạm vi của tôi vì thậm chí tôi còn không biết về công nghệ đó; thế nên không có cách nào để khớp với những kỹ năng của tôi cho nhiệm vụ đó.

Tôi đã nói với người trưởng nhóm vụ chuyển giao kiến thức và nói với anh ấy về tình hình đang gặp phải: "Quá nhiều mục công việc được giao cho tôi, điều này sẽ cản trở chất lượng và khả năng của tôi trong việc nắm bắt 100% kiến thức trong các phiên chuyển giao."

Các mục đã được lên kế hoạch có các lĩnh vực mà các kỹ năng của tôi không phù hợp và vì không phù hợp nên có thể tôi sẽ không thể hiểu 100% trong quá trình chuyển giao.

Người trưởng nhóm đã hiểu vấn đề và sửa đổi kế hoạch KT.

Tôi hy vọng điều này sẽ giúp xác nhận rằng: Nếu có thứ gì đó trên đĩa của chúng ta thì cũng không có nghĩa là chúng ta phải ăn tất cả. Đặc biệt là không nếu nó có nghĩa là thỏa hiệp về chất lượng. (Tức là làm gì thì làm cũng phải đảm bảo chất lượng sản phẩm là điều quan trọng)

B) Các thành phần của Testcase

Có bao nhiêu bạn đồng ý với tôi rằng nếu chúng ta cố gắng cải thiện cách chúng ta viết các Testcase sẽ làm cho chất lượng tốt hơn? Dưới đây là một số lỗi phổ biến thường gặp trong hầu hết các Testcase:

Các thành phần của Test Case	Các vấn đề hiện hành	Các vấn đề hiện hành
Mục tiêu	Mục tiêu là phần quan trọng nhất của bất kỳ Testcase nào, đây là điều làm cho tất cả các testcase trở nên khác nhau. Những lỗi thường gặp với mục tiêu là thiếu sự rõ ràng.Giống như tất cả các testcase được tạo cho một chức năng có một mục tiêu mà không chỉ ra được mỗi testcase khác nhau như thế nào.	Mục tiêu/Mục đích của từng testcase phải rõ ràng để giải thích chức năng gì và điều kiện test nào sẽ được kiểm thử như là một phần của testcase đó. Cùng một chức năng có thể có các testcase tích cực và tiêu cực, vì vậy mục tiêu phải đủ rõ ràng để thể hiện sự khác biệt giữa các testcase này. Một ý tưởng hay là tham khảo kịch bản kiểm thử để xác định mục tiêu.
Tiền điều kiện	Nhiều Tester hoàn toàn bỏ lỡ việc đề cập đến điều kiện tiên quyết hoặc nhiều người sẽ chỉ đơn giản là copy and paste. Copy and paste dẫn đến các lỗi vì mỗi testcase có thể hoàn toàn khác với một trường hợp khác.	Nhiều Tester hoàn toàn bỏ lỡ việc đề cập đến điều kiện tiên quyết hoặc nhiều người sẽ chỉ đơn giản là copy and paste. Copy and paste dẫn đến các lỗi vì mỗi testcase có thể hoàn toàn khác với một trường hợp khác.
Dữ liệu kiểm thử	Đây có lẽ là cái bị bỏ qua nhiều nhất và hầu hết các Testcase sẽ có trường hợp rỗng hoặc thiếu định nghĩa chính xác	Đề cập các dữ liệu thích hợp được nhập vào. Đôi khi, nó không cần phải chính xác. Ví dụ: Đăng ký người dùng có thể đăng ký người dùng Anna hoặc John và điều đó không thành vấn đề. Thế nhưng việc xác định rằng một tên hợp lệ là phải có tất cả các ký tự và có độ dài từ 4-10 thì lại có thể giúp làm rõ rất nhiều điều trong quá trình kiểm thử.
Testcase ID	Đặt tên đơn giản hóa hoặc quy ước đánh. Khi bạn đang kiểm thử một nút đăng nhập. Thường các ID sẽ là: TC_1_Login, TC_2_Login	Mô tả chúng chi tiết hơn: TC_1_Login_Invalid_User , TC_2_Login_Valid_User
Tài liệu tham khảo	Copy-paste không nhất quán từ tài liệu tham khảo hoặc tệ hơn là việc sử dụng tài liệu tham khảo không chính xác.	Luôn luôn khuyến khích việc đề cập đến tài liệu tham khảo chính xác với số phiên bản chính xác, giả sử đối với một số testcase mà cả hai thông số kỹ thuật FRS (functional requirement specification) và Tech đều được đề cập, thì testcase trong phần tham chiếu nên đề cập đến cả hai.
Các bước của Testcase	Các bước bị thiếu, chủ yếu là bởi các Tester biết ứng dụng rất rõ. Họ có thể giả định mọi thứ và bỏ qua việc đề cập đến các bước. Điều này gây ra các vấn đề cho doanh nghiệp, người đánh giá và người kiểm thử mới.	Các bước và trình tự thích hợp nên được sử dụng

Tóm lại, nếu xem xét các chi tiết nhỏ trong giai đoạn thiết kế, chất lượng đầu ra của việc kiểm thử sẽ vượt trội hơn nhiều.

3) Hiểu nghiệp vụ

Đây là một trong những yếu tố quan trọng nhất mà khách hàng tìm kiếm ở các Tester. Tuy nhiên, thật đáng buồn khi một số Tester tin rằng công việc của họ là viết các Testcase dựa trên FRS (functional requirement specification) và không cố gắng hiểu nghiệp vụ.

Hãy thử tìm nghiệp vụ trước và sau đó xem xét chức năng; bạn có thể hình dung khách hàng của bạn cần nhiều hơn và kiểm thử một cách phù hợp.

Đây là một ví dụ: – các trạng thái FRS (functional requirement specification) “báo cáo XYZ phải được tạo với 3 cột là Ngày, Tên và Trạng thái”. Dưới đây là các Testcase mà bạn sẽ bạn thực hiện yêu cầu này:

• Xác thực báo cáo XYZ được tạo ra.
• Xác thực báo cáo với 3 cột là ngày, tên, trạng thái.
• Xác thực dữ liệu trong 3 cột.

Nhưng, khi bạn biết được ứng dụng kinh doanh của báo cáo này, bạn có thể phải kiểm thử những điều sau:

• Mục tiêu kinh doanh của bản báo cáo này là gì
• Báo cáo này có được tạo ra hàng ngày không?
• Người dùng doanh nghiệp nào tìm kiếm bản báo cáo này?
• Nguồn dữ liệu nào cho bản báo cáo này?
• Báo cáo có nên được tạo nếu không có dữ liệu sẵn có?

Trên đây chỉ là 1 ví dụ, nhưng tôi đoán mọi người sẽ đồng quan điểm đó là kiểm thử sẽ đạt được kết quả tốt hơn bởi họ có nhận thức và chuyên môn kinh doanh.

4) Tính sẵn sàng

Cho dù bạn là một cá nhân duy nhất hoặc là một nhóm hỗ trợ khách hàng, tính sẵn sàng của bạn phải luôn luôn được kiểm tra.

Tính sẵn sàng, không có nghĩa là bạn phải hỗ trợ 24/7. Nó chỉ có nghĩa là thông tin liên lạc rõ ràng và thẳng thắn về thời gian nghỉ, kế hoạch thay thế.

Dưới đây là một số mô hình mà ngành dịch vụ tuân theo:

• Mô hình tăng cường nhân viên - Nếu bạn đang làm việc trong một mô hình tăng cường nhân viên và là đại diện duy nhất từ công ty của bạn, thì khách hàng nên biết về thời gian làm việc và kế hoạch vắng mặt của bạn để có thể có những sắp xếp cần thiết.
• Mô hình dự án được quản lý - Trong mô hình dự án được quản lý, các nhóm dự án lớn được thành lập và quản lý bởi những người quản lý giao hàng/dự án, việc có kế hoạch về nguồn nhân lực dự phòng không còn là trách nhiệm của khách hàng. PM cần quản lý cả thời gian nghỉ có và không có kế hoạch của mọi người. Trong mô hình này, lời khuyên dành cho PM là nên cố gắng thu thập dữ liệu vắng mặt theo kế hoạch từ các thành viên trong nhóm trước thời hạn và quản lý nó. Có những trường hợp khách hàng yêu cầu hỗ trợ vào các ngày cuối tuần hoặc kéo dài thời gian làm việc. Những trường hợp như vậy cũng nên được lên kế hoạch bằng cách luân chuyển nguồn nhân lực. Một nhóm nên bao gồm các thành viên có thể backup lẫn nhau nếu được yêu cầu. Các chi tiết theo kế hoạch nên được chia sẻ với khách hàng.

5) Phạm vi cải thiện

Đây không chỉ là mong muốn trong ngành công nghiệp phần mềm mà ở khắp các lĩnh vực khác nữa. Việc cải thiện không phải là công việc một ngày. Phạm vi của việc cải thiện phải được thực hiện liên tục và có thể được chia thành 3 bước:

Bước #1: Xác định

Làm một nghiên cứu kỹ lưỡng và xác định các lĩnh vực/phạm vi để cải thiện. Giả sử, khi bạn được yêu cầu kiểm thử cùng một chức năng nhiều lần bằng cùng một quy trình, thì chắc chắn sẽ đến lúc bạn sẽ cảm thấy muốn rời khỏi dự án hoặc bạn thay đổi cách kiểm thử. Đó là cách cải thiện được đưa vào khi chúng ta cảm thấy chán các phương pháp hiện có, chúng ta nghĩ đến việc thay đổi và cải thiện.

Bước #2: đưa vào các cải thiện

Nếu mọi thứ được làm một cách thủ công thì có thể bạn sẽ cố gắng tự động hóa một vài thứ. Khi tôi nói tự động hóa, không phải lúc nào cũng có nghĩa là mua một công cụ tự động.

Bước #3: Đánh giá sự cải tiến

Bất cứ khi nào một quy trình mới được thực thi, bạn sẽ cần đảm bảo rằng nó hoạt động đúng như mong đợi và không có tác dụng phụ. Mở rộng ví dụ trước đó, giới thiệu các thủ tục được lưu trữ, kiểm tra xem đầu ra từ cách làm tự động mới được tạo và đầu ra từ cách làm thủ công có giống nhau không.

Phần khác là theo dõi các lợi ích đạt được trong một khoảng thời gian để hoàn toàn chắc chắn và trình bày kết quả cho khách hàng của bạn. Trong dự án của chúng tôi, chúng tôi đã cho khách hàng thấy nó đã giảm 30% thời gian thực hiện kiểm thử, từ đó giảm chi phí.

Kết luận

Tóm lại, tôi chỉ muốn đề cập vấn đề là mỗi người trong chúng ta đều có tài năng bẩm sinh và tất cả chúng ta đều có phong cách làm việc của riêng mình và đây chỉ là một số mẹo mà tôi tin rằng nó có thể cung cấp cho khách hàng của chúng tôi trải nghiệm dịch vụ tốt hơn.

Bài dịch từ link: https://www.softwaretestinghelp.com/what-do-clients-really-expect-from-the-software-testers/