Khách hàng thật sự mong đợi điều gì ở nhân viên Kiểm thử phần mềm?

Bài đăng này đã không được cập nhật trong 4 năm

Ngày nay, ngành Công Nghệ Thông Tin 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à trong đó sự hài lòng của khách hàng là điều quan trọng nhất để dẫn đến thành công. Nhân viên Kiểm thử phần mềm cũng là một phần của sự thành công đó. Họ tập trung kiểm tra chất lượng phần mềm để cho ra sản phẩm tốt nhất đến khách hàng Và mỗi khách hàng hay là tổ chức có thể sử dụng quy trình, giao thức khác nhau hay giao dịch với các loại hình doanh nghiệp khác nhau. Vậy làm sao để biết khách hàng mong đợi điều gì ở nhân viên Kiểm thử phần mềm để sản phẩm mà khách hàng nhận được là sản phẩm tốt nhất? Sau đây là 5 điều mà khách hàng mong đợi ở một người kiểm thử phần mềm

1. Chi phí lợi ích (Cost benefit)

Khi bạn nghĩ đến việc bán hoặc mua một cái gì đó, chi phí đóng vai trò chính và nó thường là một trong những yếu tố quyết định quan trọng. Không phải tất cả chúng ta đều háo hức chờ đợi Black Friday, chương trình khuyến mại hay lễ hội mua sắm tuyệt vời của Tiki, Lazada, Shopee, v v ? Chúng ta rất muốn mua đồ trong thời gian sale đó. Đó là một hành vi đơn giản của con người để mong đợi được nhiều quyền lợi hoặc giá trị tăng thêm cho đồng tiền của họ Các công ty và khách hàng cũng như vậy. 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ạ khi 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.

Vậy câu hỏi lớn ở đây là: Làm thế nào Người kiểm thử chỉ ra chi phí lợi ích để khách hàng thấy được?

Cho Khách hàng thấy giá trị đồng tiền của họ: Thuyết phục và đưa những chứng cứ về các estimates (ước tính). Từ đó đưa ra những cách sáng tạo để tiết kiệm chi phí
Điều chỉnh bảng báo giá: Thay vì tuân thủ quy trình tiêu chuẩn tốn X số tiền, hãy đưa ra các lựa chọn thay thế rẻ hơn

2. Chất lượng công việc (Quality of Word)

Chất lượng và số lượng công việc là hai định nghĩa rất khác nhau. Số lượng các Test case được tạo ra hoặc các lỗi (bugs) được báo cáo thì nó sử dụng cho các chỉ số năng suất hoặc chất lượng.

2.1 Biết khi nào nói “Không”

Khi chúng ta có thể làm việc ngoài giờ vào cuối tuần, hoặc tham dự các cuộc gọi công việc vào đêm khuya hoặc sáng sớm. Tuy nhiên, nó liên tục diễn ra thì ta có thể nói “Không” khi mọi thứ trở nên tồi tệ hơn. Nói “Không” là cách duy nhất cho chất lượng và bạn có thể tỉnh táo để làm việc

Ví dụ: Khi tôi được giao nhiều công việc cùng một lúc và một trong những công việc đó nằm ngoài phạm vi và không phù hợp với kỹ năng của tôi

Tôi đã trao đổi của leader của mình về tình hình:

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 để nắm bắt 100% tất cả các công việc
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ì tôi không phù hợp, nên tôi có thể không hiểu 100% trong quá trình làm công việc đó

Từ đó leader hiểu vấn đề và đưa ra cách giải quyết để mọi người có thể hoàn thành công việc 1 cách tốt nhất Bạn nên nhớ rằng: Nếu có nhiều thứ trên đĩa thức ăn của bạn, không có nghĩa là bạn phải ăn hết nó mà nó phải thỏa hiệp về chất lượng lên hàng đầu

2.2 Hoàn thành Test case

Bạn có đồng ý với tôi rằng nếu chúng ta cải thiện cách viết Test case thì nó sẽ dẫn đến 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 Test case

Test Case Compnents	Vấn đề hiện tại	Cách giải quyết
Test Object	Test Object là phần quan trọng nhất ở tất cả cả test case, đây là điều làm cho các test case khác nhau. Nhưng lỗi thường gặp là thiếu sự rõ ràng. Hầu hết tât cả các test case được tạo cho cùng một chức năng có một Test Object mà không chỉ các test case đó khác nhau như thế nào	Test Object của từng test case phải rõ ràng để giải thích cho chức năng, điều kiện nào. Cùng một chức năng có thể có các test case normal và abnormal, vì vậy test object phải đủ rõ ràng để thể hiện sự khác biệt. Ý tưởng tốt là tham khảo requirement để xác định test object
Pre-Conditions	Nhiều testers hoàn toàn bỏ lỡ đề cập đến điều kiện tiên quyết hoặc nhiều người sẽ chỉ đơn giản là sao chép và dán.Sao chép dán dẫn đến lỗi vì mỗi test case	Tránh lỗi từ sao chép-Dán và chú ý đến chi tiết.
Test Data	Đây là cột bị bỏ qua nhất và hầu hết các test case sẽ có trường hợp trống hoặc thiếu định nghĩa chính xác	Đề cập đến Data được nhật thì đô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 đề.Nhưng việc xác định rằng một tên hợp lệ có tất cả các ký tự và có độ dài từ 4-10 có thể giúp làm rõ rất nhiều điều.
Test Case Steps	Các bước bị thiếu, chủ yếu là bởi những tester biết rất rõ các bước. Họ có thể giả định mọi thứ và bỏ qua đề cập đến các bước. Điều này gây ra vấn đề cho doanh nghiệp, người đánh giá và người tester 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 từng giai đoạn thiết kế, chất lượng đầu ra test sẽ vượt trội hơn nhiều

3. Hiểu biết về kinh doanh (Business Understanding)

Đây là cũng một trong những yếu tố quan trọng nhất mà khách hàng tìm kiếm ở người tester. Tuy nhiên, khi một số người tester tin rằng công việc của họ là viết các test case dựa trên FRS (Function Requirements) và không nỗ lực để hiểu doanh nghiệp. Hãy thử tìm hiểu doanh nghiệp trước và sau đó xem xét chức năng; bạn có thể hình dung nhu cầu của khách hàng nhiều hơn và tạo cách test phù hợp hơn

Dưới đây là một ví dụ:

Báo cáo FRS (Function Requirements) của XYZ phải được tạo với 3 cột là Date, Name và Status . Sau đây là các test case mà bạn sẽ kết thúc khi bạn thực hiện yêu cầu về mặt giá trị của nó:

Xác thực báo cáo XYZ được tạo
Báo cáo xác thực có 3 cột là Date, Name, Status
Xác thực dữ liệu trong 3 cột.

Nhưng, khi bạn ghi nhớ khả năng áp dụng kinh doanh của báo cáo này, bạn có thể phải kiểm tra:

Mục đích kinh doanh của báo cáo này là gì?
Báo cáo này có được tạo ra mỗi ngày không?
Những người doanh nghiệp đang xem báo cáo này là ai?
Nguồn dữ liệu cho báo cáo này là gì?
Báo cáo có nên được tạo nếu không có dữ liệu?

Đây chỉ là một ví dụ, nhưng tôi đoán tất cả chúng ta đều đồng ý rằng có thể kiểm thử tốt hơn bằng cách đạt được nhận thức tốt về chuyên môn kinh doanh

4. Luôn sẵn sàng (Availability)

Cho dù bạn là một cá nhân duy nhất hỗ trợ khách hàng hay nhóm, tính khả dụng của bạn phải luôn được kiểm tra (). Theo tính khả dụng, điều đó không có nghĩa là 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ế ..vv

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, khách hàng nên biết về thời gian làm việc của bạn và vắng mặt theo kế hoạch để có thể sắp xếp cần thiết.

Mô hình quản lý dự án

Trong mô hình dự án được quản lý, trong đó các nhóm dự án lớn được thành lập và lãnh đạo bởi người quản lý giao hàng / quản lý dự án. Quản lý dự án (PM) cần quản lý cả thời gian nghỉ theo kế hoạch và ngoài dự kiến. Trong mô hình này, khuyến nghị rằng PM cố gắng lên kế hoạch dựa theo dữ liệu nhân lực của team trước thời hạn và quản lý theo đó để có những trường hợp khách hàng yêu cầu hỗ trợ 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 luân phiên tài nguyên. Một nhóm nên bao gồm các thành viên có thể ghi nhớ 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 (Scope of Improvement)

Đây không chỉ là mong muốn trong ngành công nghiệp phần mềm mà ở mọi ngành khác. Mang lại sự cải thiện không phải là một công việc nói là làm được ngay trong một ngày. Phạm vi cải tiế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

Thực hiện 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 một quy trình, sẽ đến lúc bạn sẽ cảm thấy rằng bạn muốn rời khỏi dự án hoặc bạn thay đổi cách kiểm thử. Đó là cách cải tiến được đưa vào khi chúng ta chán các phương pháp hiện có, chúng ta nghĩ đến việc thay đổi và cải tiến .

Bước 2: Đưa vào các cải tiến

Nếu mọi thứ được thực hiện một cách thủ công, bạn có thể cố gắng tự động hóa một vài thứ . Khi nói đến 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 hiện, bạn sẽ cần đảm bảo rằng nó hoạt động như mong đợi và không có tác dụng ngoài ý muốn. Kiểm tra xem đầu ra từ cách tự động mới được tạo và đầu ra từ cách thủ công có giống nhau không. Ngoài ra cần theo dõi các lợi ích 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 (chẳng hạn về thời gian thực hiện kiểm thử, từ đó giảm chi phí, …).

Phần kết luận

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