Làm thế nào để khuyến khích khách hàng thực hiện một số thử nghiệm QA tại nhà?

Cập nhật / Làm rõ Khách hàng của tôi hiểu sự cần thiết của thử nghiệm nội bộ của họ và anh ấy / họ luôn thề rằng họ sẽ "làm tốt hơn" (nghĩa là làm một cái gì đó) nhưng điều đó không xảy ra. Họ không có ngân sách để thử nghiệm bên ngoài. Tôi đoán tôi đang hỏi (một cách mơ hồ, tôi thừa nhận) về những gì có thể thấm nhuần "kiểm tra sớm, kiểm tra thường xuyên, kiểm tra các đặc tính của máy mục tiêu?

Câu hỏi: làm thế nào để khuyến khích người dùng dành thời gian để kiểm tra và báo cáo rõ ràng các vấn đề với các bản phát hành mới, chứ không phải "thử nghiệm khi họ đi" trong các dự án sản xuất.

Bối cảnh: Tôi có một khách hàng nhỏ mà tôi đã viết một bộ công cụ trình bày đa phương tiện. Họ là một khách hàng tốt và chúng tôi có một mối quan hệ tốt. Dự án đang được thực hiện, thêm các tính năng khi chúng tôi đi cùng.

Có hai vấn đề tôi có:

1. Định nghĩa tính năng được thực hiện nhanh chóng, thường qua điện thoại, có thể thay đổi, sửa đổi, đảo ngược. (một chút giống như "Chúng ta sẽ lên mặt trăng và làm những việc khác" của Kennedy - Tôi luôn cảm thấy thú vị bởi phần "những thứ khác" trong đó)

2. Hầu như không có xét nghiệm QA nào được thực hiện vào cuối của họ.

Tôi có thể đối phó với # 1, nhiều hay ít. Đây không phải là một khách hàng thậm chí sẽ đọc một thông số kỹ thuật trước một cuộc họp, hãy để một mình viết lên. Tôi đã quen với nó. Đây là mục số 2 mà tôi gặp phải vấn đề: họ không hoặc sẽ không thử nghiệm các bản phát hành mới. Những gì họ làm là sử dụng chúng để sản xuất để khi các lỗi xuất hiện, họ sẽ tìm cách khắc phục và không báo cáo, hoặc họ rất vội vàng để tiếp tục với dự án, các báo cáo lỗi đó là mơ hồ.

Chúng tôi đã có nhiều cuộc thảo luận về tất cả những điều này nhưng tôi chỉ có thể huých chúng một chút (ví dụ: chúng tôi sử dụng github để theo dõi các vấn đề - mặc dù chủ yếu tôi sử dụng nó). Lý do sâu xa có hai mặt: họ là một công ty tư vấn nhỏ và không có (hoặc không nghĩ rằng họ có) các tài nguyên để thử nghiệm (cũng không phải ngân sách để thuê ngoài nó). Và văn hóa: mặc dù họ nghĩ mình là "nhà phát triển" nhưng họ thực sự chỉ là người dùng gói phần mềm đa phương tiện. (ví dụ, họ không có sự chú ý về bệnh thần kinh ám ảnh đến chi tiết của các nhà phát triển "thực sự").

Điều này ảnh hưởng đến tôi như bạn mong đợi: không có phản hồi Tôi không thể biết liệu một tính năng đã hoàn thành hay chưa (xem # 1) hoặc nếu có những hậu quả khác. Nó cũng làm cho tôi một chút lười biếng.

họ không có sự chú ý về bệnh thần kinh ám ảnh đến chi tiết của các nhà phát triển "thực sự"

Lời nói đầu : Loại ngôn ngữ bạn sử dụng ở đây thường là cờ đỏ đối với tôi. Khi tôi nghe mọi người nói về các nhà phát triển "thực sự" hoặc cách làm việc "đúng" (một và duy nhất), tôi bắt đầu nghĩ đến các nhà phát triển giáo dục hàng hóa có tầm nhìn đường hầm .

Bây giờ, tôi không nói rằng bạn chắc chắn là một trong những nhà phát triển này (tôi không có đủ bằng chứng để khẳng định điều đó), nhưng nếu là bạn, thì bạn có thể hưởng lợi từ câu trả lời này.

Câu trả lời

Có vẻ như bạn và khách hàng của bạn đang tối ưu hóa cho những thứ khác nhau. Đó là một thực tế đáng tiếc trong công nghệ phần mềm thường là nhu cầu của doanh nghiệp và mong muốn của các nhà phát triển không nhất thiết phải xếp hàng.

Các nhà phát triển phần mềm thường là những người đam mê với sự tập trung vào sự ngẫu hứng. Họ thích cải thiện hiệu suất phần mềm, quy trình phát triển, quy trình kinh doanh, phương thức giao tiếp, v.v. Tập trung vào những điều này là những gì tách biệt các thợ thủ công và thợ thủ công từ các keypushers vô tâm.

Nhưng, khách hàng của bạn không phải là một thợ thủ công phần mềm. Khách hàng của bạn là một doanh nghiệp với một loạt các ưu tiên hoàn toàn khác nhau. Và, đôi khi, những ưu tiên đó trông thật lố bịch đối với những người thợ thủ công phần mềm ... nhưng đó chỉ là do chúng tôi tối ưu hóa cho những thứ khác nhau.

Doanh nghiệp thường muốn tối ưu hóa cho những thứ như phát hành sớm ra thị trường và tiết kiệm chi phí ngắn hạn. Để làm như vậy, họ có thể cần phải hy sinh những thứ như QA, Trải nghiệm người dùng, tiết kiệm chi phí dài hạn và những thứ khác khiến các nhà phát triển đánh dấu.

Đó có phải là một điều xấu? Vâng, không nhất thiết. Tôi không thể nói cho tất cả các doanh nghiệp, nhưng theo kinh nghiệm của mình, khách hàng của tôi làm những điều này để tăng ROI của chính họ (lợi tức đầu tư). Làm những việc như QA, sàng lọc UX và lập kế hoạch dài hạn mang lại cho họ ROI thấp hơn. Thậm chí tệ hơn, nhiều doanh nghiệp có cơ cấu đầu tư chỉ thưởng cho các chiến thắng ngắn hạn trái ngược với các phương pháp tiếp cận bền vững và chiến thắng dài hạn.

Vì vậy, trong khi bạn có thể cố gắng bán ý tưởng về QA cho khách hàng của mình, bạn có thể đang lãng phí thời gian và làm căng thẳng mối quan hệ của bạn với họ. Trong trường hợp tốt nhất, bạn sẽ khiến ai đó háo hức thử ý tưởng của mình (không chắc). Trong trường hợp xấu nhất, bạn sẽ phải thuyết phục toàn bộ công ty làm lại các cấu trúc khuyến khích của mình để các khoản đầu tư dài hạn như QA được thưởng. Trong cả hai trường hợp, tỷ lệ thành công của bạn là thấp.

Câu hỏi thú vị là khi bạn được trả tiền, không phải khách hàng của bạn có thực hiện bất kỳ thử nghiệm nào của riêng họ hay không.

• nếu bạn được trả tiền dựa trên thời gian của bạn, không có vấn đề gì.
• nếu bạn được trả tiền trước, không có vấn đề gì.
• nếu bạn được trả tiền khi khách hàng tuyên bố dự án đã thực hiện, thì vấn đề lớn.

Vấn đề là làm thế nào bạn có thể biết khi nào khách hàng chấp nhận phần mềm và sẽ trả tiền cho bạn. Điều này rõ ràng không hoạt động khi khách hàng liên tục sửa đổi dự án với các yêu cầu mới được xác định mơ hồ. Nếu điều này có nghĩa là ngày thanh toán luôn bị hoãn lại - và trở nên khó xảy ra hơn bởi mỗi yêu cầu - điều này trở nên không thể thực hiện được đối với bạn.

Hợp đồng cố định chỉ định cẩn thận tất cả các tính năng và xác định theo điều kiện nào khách hàng sẽ chấp nhận các tính năng này rõ ràng rất khó chịu, nhưng nó cho phép bạn lên kế hoạch trước cho dự án (cũng là dự án tiếp theo). Nó cũng đảm bảo bạn sẽ nhận được tiền của mình cho phần mềm bạn đã phân phối, nếu nó phù hợp với thông số kỹ thuật. Trong một kịch bản như vậy, trách nhiệm duy nhất của khách hàng là trong giai đoạn xác định hợp đồng và cuối cùng là thử nghiệm chấp nhận .

Thử nghiệm chấp nhận như vậy được thực hiện bởi khách hàng tách biệt với các hình thức thử nghiệm khác:

• kiểm tra đơn vị
• kiểm tra tích hợp hệ thống
• kiểm tra khả năng sử dụng
• kiểm tra tải
• kiểm tra trước khi phát hành

Càng xa càng tốt, bạn sẽ dự đoán các bài kiểm tra chấp nhận và tự thực hiện chúng trước khi cung cấp chức năng để tránh mọi sự bối rối. Ngoài các thử nghiệm chấp nhận (chỉ đo lường mức độ hoàn thành hợp đồng , không phải chất lượng phần mềm ), tất cả Đảm bảo Chất lượng là trách nhiệm của bạn. Cụ thể, khách hàng của bạn không nhất thiết phải có tư duy QA, nền tảng kỹ thuật cần thiết hoặc nghĩa vụ hợp đồng để làm QA. Ngoài ra, tôi thấy việc săn lỗi gia công cho khách hàng khá không chuyên nghiệp.

Điều đó không có nghĩa là lỗi sẽ không xảy ra. Giả sử bạn có mối quan hệ dựa trên dự án với khách hàng của mình, bạn sẽ muốn đi đến một ranh giới giữa việc cung cấp các bản sửa lỗi lịch sự và nhanh chóng, và giải thích rằng họ đã chấp nhận bản phát hành hiện tại là đủ cho nhu cầu của họ - những thay đổi lớn cần có hợp đồng mới. Nếu bạn có hợp đồng hỗ trợ liên tục, tất nhiên bạn sẽ phải tuân theo mức độ dịch vụ đã thỏa thuận.

Trong một thiết lập nhanh, đáp ứng nhu cầu của khách hàng được đánh giá cao hơn so với việc tuân thủ thư của hợp đồng, nhưng bạn vẫn muốn được trả tiền. Do đó, nhiều phương pháp dự án định hướng nhanh có giá trị tương tác khách hàng chặt chẽ, đến mức khách hàng có thể trở thành một phần của nhóm. Sau đó, bạn luôn có thể nói chuyện với chủ sở hữu sản phẩm này của bạn để làm rõ bất kỳ điểm cần thiết nào. Vì PO có quyền cấp cho bạn thời gian để làm việc trên bất kỳ tính năng nào họ thấy có giá trị, điều này có thể hoạt động ngay cả khi bắt đầu với nhu cầu mơ hồ của khách hàng. Nếu bạn không có một giao tiếp chặt chẽ như vậy, bạn sẽ cần phải làm theo một cách tiếp cận chính thức hơn.

• Khi bạn tìm hiểu về nhu cầu của khách hàng mới, hãy làm việc với khách hàng để dịch chúng theo yêu cầu. Điều này giúp khách hàng có được những gì họ thực sự muốn.
• Các yêu cầu có thể đo lường khách quan - chúng có thể được đáp ứng hoặc không. Điều này tiết kiệm cho khách hàng từ một nửa giải pháp mà chỉ loại công việc.

• Tất cả các yêu cầu của khách hàng phải được cung cấp dưới dạng văn bản để bạn có thể lập hóa đơn cho họ. Điều này bảo vệ chúng khỏi bị lập hóa đơn cho những thứ bạn cảm thấy thích làm việc - chẳng hạn như viết lại toàn bộ giao diện khi yêu cầu một nút được căn chỉnh khác nhau.

  Rất nhiều giao tiếp có thể được thực hiện trực tiếp hoặc qua điện thoại, nhưng cuối cùng, bạn sẽ muốn có một tờ giấy để ghi lại rằng khách hàng muốn bạn thực hiện các yêu cầu này . Trong các trường hợp đơn giản, có thể đủ để tóm tắt lại một cuộc gọi điện thoại và gửi email cho họ để xác minh những gì họ yêu cầu bạn làm.

Báo cáo lỗi luôn khó khăn. Nếu khách hàng của bạn là nhà phát triển cần giúp đỡ vì họ có thể hiểu nhu cầu của bạn: có các bước rõ ràng để tái sản xuất. Một cách đơn giản để có được cái nhìn sâu sắc mạnh mẽ là cho phép đăng nhập vào phần mềm được triển khai. Với điều kiện là các vấn đề riêng tư dữ liệu có thể được giải quyết, yêu cầu mọi báo cáo lỗi phải có nhật ký hiện tại được đính kèm không chỉ đảm bảo một số giao tiếp bằng văn bản mà còn cho bạn biết người dùng thực sự đã làm gì (ngược lại với những gì họ nghĩ họ đang cố gắng làm) .

Cách để khuyến khích giao tiếp với các lỗi là khuyến khích giao tiếp thường xuyên, chi tiết về các tính năng. Nếu bạn đào tạo một công ty mà họ có thể yêu cầu bất cứ điều gì với nghi lễ bằng không, họ cũng sẽ sử dụng tính năng đó cho các lỗi nhỏ. Hãy từ bỏ việc thay đổi quy trình làm việc của khách hàng trừ khi những thay đổi này giúp cuộc sống của họ dễ dàng hơn.

Yêu cầu khách hàng của bạn thực hiện kiểm tra nội bộ là khó khăn, nhưng để họ thực sự báo cáo lỗi không khó như âm thanh. Cách để có thêm thông tin phản hồi là giảm ma sát người dùng ... ngay cả khi điều đó có nghĩa là truyền một số ma sát đó cho chính bạn.

1. Sử dụng các công cụ đơn giản hơn, ngay cả khi những công cụ đó không đầy đủ và không phù hợp. Ví dụ, BaseCamp là một trình theo dõi lỗi khá khủng khiếp (vì nó dành cho quản lý dự án), nhưng mọi người thực sự sẵn sàng sử dụng nó.

2. Vì các trình theo dõi lỗi mà chúng tôi đang sử dụng không hỗ trợ sao chép hình ảnh, tôi thực sự đã viết một chương trình tầm thường sao chép hình ảnh clipboard hiện tại vào đĩa (dưới dạng Hướng dẫn), sau đó sao chép Hướng dẫn vào bảng tạm. Sau khi đào tạo tối thiểu, người dùng có thể đính kèm hình ảnh clipboard vào các vấn đề bằng cách chỉ cần nhấn vào màn hình in, nhấp vào nút và sau đó dán vào hộp thoại chọn tệp của công cụ gửi lỗi.

Một ảnh chụp màn hình (có thể được chỉnh sửa trong MS Paint với chú thích) và 1-2 câu là đủ để xác định hầu hết các tính năng / lỗi.

Cả hai đề xuất này đều nhắm mục tiêu các điểm ma sát mà tôi đã trải nghiệm và cả hai đề xuất này đều tăng báo cáo theo hệ số hơn 10. Tuy nhiên, bạn sẽ cần nhắm mục tiêu các điểm ma sát của riêng mình.

Làm cho việc kiểm tra cho khách hàng của bạn trở nên dễ dàng, nhưng làm cho khách hàng của bạn thực sự khó sử dụng bất kỳ tính năng mới nào trong một phiên bản chưa được kiểm tra trong sản xuất. Điều này có thể được thực hiện như sau:

Bất cứ khi nào bạn cung cấp một tính năng mới, bạn sẽ triển khai tính năng này đầu tiên trong "phiên bản beta", được đánh dấu rõ ràng bằng một dấu hiệu "không dành cho sản xuất". Bạn cung cấp phiên bản beta này cho khách hàng để thử nghiệm. Bạn cũng cung cấp "phiên bản sản xuất" mới nhất mà anh ấy sẽ sử dụng cho sản xuất thực (không có các tính năng mới, nhưng với các bản sửa lỗi mới nhất) và bạn từ chối chuyển các tính năng beta mới vào phiên bản sản xuất cho đến khi bạn nhận được phản hồi mà ai đó tại phía khách hàng ít nhất đã thử nó trước.

Nếu khách hàng bắt đầu sử dụng phiên bản beta trên dữ liệu sản xuất thực của mình mặc dù nó luôn hiển thị một thông điệp lớn "Không sử dụng cho sản xuất" bất cứ khi nào anh ta khởi động chương trình, thì bạn không thể giúp anh ta, nhưng ít nhất bạn đã nói rõ rằng bất cứ khi nào anh ta mất sản xuất làm việc vì anh ta đã sử dụng bản beta cho mục đích sai mà rõ ràng đó là lỗi của anh ta. Nếu khách hàng không học được điều đó, bạn có thể cân nhắc vô hiệu hóa khả năng sử dụng "beta" của khách hàng trong sản xuất bằng cách hủy kích hoạt một số chức năng quan trọng như lưu kết quả vào đĩa trong "beta", nếu cần thiết.

Việc cung cấp một "beta" riêng biệt sẽ buộc bạn phải thiết lập quản lý cấu hình / kiểm soát phiên bản phù hợp, do đó bạn có thể quản lý một nhánh sản xuất và một nhánh thử nghiệm beta cạnh nhau mà không gặp rắc rối. Nhưng vì bạn đang làm việc với Github, tôi đoán bạn đã sử dụng một cái gì đó như GIT, điều này làm cho loại quản lý này rất đơn giản.