Как побудить клиента провести домашнее тестирование?

14

Обновление / разъяснение. Мой клиент понимает необходимость их внутреннего тестирования, и он / они всегда клянется, что «сделают лучше» (то есть сделают что-то), но этого просто не происходит. У них нет бюджета для внешнего тестирования. Я предполагаю, что спрашиваю (смутно, признаю), что могло бы привести к «раннему тестированию, частому тестированию, тестированию на идеале целевых машин»?

Вопрос: как побудить пользователей тратить время на явное тестирование и сообщать о проблемах с новыми выпусками, а не «тестировать как они» в производственных проектах.

Предыстория: у меня есть небольшой клиент, для которого я написал набор инструментов для мультимедийных презентаций. Они хороший клиент, и у нас хорошие отношения. Проект продолжается, добавляя новые функции по мере продвижения.

У меня есть две проблемы:

  1. Определение функции выполняется на лету, часто по телефону, может быть изменено, изменено, изменено. (что-то вроде «Кеннеди» «Мы поедем на Луну и будем заниматься другими делами» - меня всегда удивляла эта «другая вещь»)

  2. Практически не проводится тестирование качества с их стороны.

Я могу иметь дело с # 1, более или менее. Это не клиент, который даже прочитал бы спецификацию перед встречей, не говоря уже о том, чтобы написать ее. Я привык к этому. У меня проблема с пунктом 2: они не тестируют или не будут тестировать новые версии. Что они делают, так это используют их для производства, поэтому, когда появляются ошибки, они либо находят обходной путь и не сообщают об этом, либо они так торопятся приступить к проекту, что сообщения об ошибках расплывчаты.

У нас было много дискуссий обо всем этом, но мне удалось лишь слегка их подтолкнуть (например, мы используем github для отслеживания проблем - хотя в основном я использую его). Коренные причины двояки: они являются небольшой консалтинговой компанией и не имеют (или не думают, что у них есть) ресурсы для тестирования (и бюджет для его аутсорсинга). И культурный: хотя они думают о себе как о «разработчиках», на самом деле они просто пользователи мультимедийного программного пакета. (например, у них нет навязчивого невроза внимания к деталям «настоящих» разработчиков).

Это влияет на меня, как и следовало ожидать: без обратной связи я не могу сказать, завершена ли функция (см. # 1), или есть другие последствия. Это также делает меня немного ленивым.

Не хватая
источник
3
Если ошибка настолько мала, что сами пользователи, похоже, не заботятся, исправлена ​​она или нет, почему вы настаиваете?
Камилк
2
@kamilk - короткий ответ заключается в том, что я вкладываюсь в то, чтобы мой клиент работал хорошо, продуктивно и т. д. Длинный ответ заключается в том, что зачастую это не просто «маленькая» ошибка - это также может быть проблемой юзабилити, отсутствует реализация функции и т. д. Если я не знаю об этом, я не могу это исправить. Кроме того, «обходные пути», которые они придумывают, часто являются для них огромной тратой времени или даже остаются с более ранними версиями программного обеспечения.
Не хватать
18
Если вы инвестируете в то, что у вашего клиента все хорошо; Вы должны увидеть очень твердое тестирование, прежде чем выпускать их. Клиенты не тестеры. Наймите тестера, или проведите собственное тестирование, или напишите кодированные тесты, но если вы хотите быть абсолютно уверены, что ваши материалы работают для ваших клиентов, тестируйте, прежде чем дать им это.
Джимми Хоффа
4
@djechlin - это вообще тестирование (и отчетность). И разработчик может тестировать только так много: я не использую его, как пользователи.
Не хватать

Ответы:

18

у них нет навязчивого невроза внимания к деталям «настоящих» разработчиков

Предисловие : Тип языка, который вы здесь используете, обычно для меня красный флаг. Когда я слышу, как люди говорят о «настоящих» разработчиках или (единственном и единственном) «правильном» способе ведения дел, я начинаю думать о разработчиках культового видения с туннельным видением .

Я не говорю, что вы определенно один из этих разработчиков (у меня нет достаточных доказательств, чтобы утверждать это), но если да, то вам может пригодиться этот ответ.

Ответ

Похоже, вы и ваш клиент оптимизируете под разные вещи. К сожалению, в разработке программного обеспечения часто не всегда совпадают потребности бизнеса и желания разработчиков.

Разработчики программного обеспечения часто страстные люди с акцентом на улучшение. Им нравится повышать производительность программного обеспечения, процесс разработки, бизнес-процессы, методы коммуникации и т. Д. И это здорово. Сосредоточение внимания на этих вещах - это то, что отделяет мастеров и ремесленниц от бездумных клавишников.

Но ваш клиент не специалист по программному обеспечению. Ваш клиент - это бизнес с совершенно другим набором приоритетов. И иногда эти приоритеты выглядят нелепо для нас, мастеров-программистов ... но это только потому, что мы оптимизируемся под разные вещи.

Бизнес часто хочет оптимизировать для таких вещей, как ранний выход на рынок и краткосрочная экономия средств. При этом им, возможно, придется пожертвовать такими вещами, как QA, пользовательский опыт, долгосрочная экономия средств и другие вещи, которые заставляют разработчиков тикать.

Это плохо? Ну, не обязательно. Я не могу говорить от имени всех компаний, но, по моему опыту, мои клиенты делают это, чтобы увеличить собственную рентабельность инвестиций (возврат инвестиций). Такие вещи, как QA, UX-совершенствование и долгосрочное планирование, предлагают им более низкую рентабельность. Хуже того, многие компании имеют инвестиционные структуры, которые вознаграждают только краткосрочные выигрыши, а не устойчивые подходы и долгосрочные выигрыши.

Таким образом, хотя вы можете попытаться продать идею QA своему клиенту, вы можете тратить свое время и напрягать свои отношения с ними. В лучшем случае вы получите кого-то, кто хочет опробовать ваши идеи (маловероятно). В худшем случае вам придется убедить всю компанию переделать свои стимулирующие структуры, чтобы вознаградить долгосрочные инвестиции, такие как обеспечение качества. В любом случае ваши шансы на успех невелики.

MetaFight
источник
4
+1, пытаясь изменить внутреннюю работу целого другого бизнеса, потому что это кажется вам неправильным , обычно разрывает отношения. Профессионал должен проконсультировать, если он может предвидеть серьезные проблемы, особенно если они могут также посоветовать, как их смягчить. Однако, если проблемы настолько малы, что компания даже не удосуживается сообщить о них, лучшее, что вы можете сделать, это время от времени отправлять дружеское напоминание о том, что, если X или Y не настаивали, было сэкономлено время.
Ордус
-1 Так как, хотя это хорошо написанное сообщение, на самом деле это не решает вопрос о том, как вы будете это делать. Ответ заключается в том, что вы делаете это очень похоже на то, как вы убеждаете обычных разработчиков в тестировании: покажите, что тестирование помогает снизить риск. Меньше риска == меньше производственных проблем в середине демонстрации клиента.
Дэвид говорит восстановить Монику
Нет - далеко от базы, но спасибо за ответ.
Не хватать
@DavidGrinberg - это все хорошо, если только сокращение количества производственных проблем не стоит затраченных усилий / затрат / времени для клиента. Если это так, никакая логика разработчика не убедит их пожертвовать своей рентабельностью, чтобы удовлетворить вас. И вот почему я не ответил на хау этого вопроса и сосредоточившись на потенциальный изъян в его помещении.
MetaFight
Ремесленники :-)
Тони Ли
10

Интересным является вопрос, когда вам платят, а не проводит ли ваш клиент какие-либо собственные тесты.

  • если вам платят в зависимости от вашего времени, нет проблем.
  • Если вам заплатят заранее, нет проблем.
  • если вам платят, когда клиент объявляет проект «выполненным», это большая проблема.

Проблема в том, как вы можете узнать, когда клиент примет программное обеспечение и заплатит вам. Это явно не работает, когда клиент постоянно дополняет проект неопределенными новыми запросами. Если это означает, что день оплаты всегда откладывается - и становится менее вероятным при каждом запросе - это становится для вас несостоятельным.

Фиксированный контракт, который тщательно определяет все функции и определяет, при каких условиях клиент будет принимать эти функции, явно очень неудобен, но он позволяет планировать проект заранее (также следующий проект). Это также гарантирует, что вы получите свои деньги за программное обеспечение, которое вы поставили, если оно соответствует спецификации. В таком сценарии единственная ответственность клиента лежит на этапе определения контракта и в конце для приемочного тестирования .

Такое приемочное тестирование, проводимое клиентом, отделено от других форм тестирования:

  • модульные тесты
  • тесты системной интеграции
  • юзабилити-тесты
  • нагрузочные тесты
  • предварительные тесты

Насколько это возможно, вы ожидаете приемочные испытания и выполняете их самостоятельно, прежде чем предоставлять функциональность, чтобы избежать каких-либо затруднений. Помимо приемочных испытаний (которые измеряют только выполнение контракта , а не качество программного обеспечения ), вся ответственность за обеспечение качества лежит на вас. В частности, ваш клиент не обязательно имеет образ мышления QA, необходимую техническую подготовку или договорное обязательство выполнять QA. Кроме того, я нахожу аутсорсинговую охоту на клиента совершенно непрофессиональной.

Это не значит, что ошибок не будет. Предполагая, что у вас есть клиентские отношения на основе проекта, вы захотите пройти границу между вежливостью и быстрым предоставлением исправлений и объяснением того, что они приняли текущий выпуск как достаточный для своих нужд - большие изменения требуют нового контракта. Если у вас есть постоянный контракт на поддержку, вам, конечно, придется придерживаться вашего согласованного уровня обслуживания.

В гибких условиях реагирование на потребности клиентов ценится больше, чем соблюдение буквы контракта, но вы все равно хотите получать оплату. Поэтому многие методологии гибкого проектного проекта ценят тесное взаимодействие с клиентом до такой степени, что клиент может стать частью команды. Затем вы всегда можете поговорить с этим «владельцем продукта», чтобы уточнить любые необходимые моменты. Поскольку у ПО есть право предоставлять вам время для работы с любой функцией, которая окажется ему полезной, это может сработать, даже если вы начинаете с неопределенных потребностей клиента. Если у вас нет такого тесного общения, вам нужно будет придерживаться более формального подхода.

  • Когда вы узнаете о новых потребностях клиентов, поработайте с ними, чтобы привести их в соответствие с требованиями. Это помогает клиенту получить то, что он на самом деле хочет.
  • Требования объективно измеримы - они либо выполнены, либо нет. Это избавляет клиента от полу-решений, которые только работают.
  • Все клиентские запросы должны быть представлены в письменной форме, чтобы вы могли выставить счет. Это защищает их от выставления счетов за то, над чем вы только что работали - например, переписывание всего интерфейса при запросе выравнивания кнопки по-другому.

    Много общения может быть сделано лично или по телефону, но в конце вы захотите лист бумаги, чтобы документировать, что клиент хотел, чтобы вы работали над этими требованиями. В простых случаях может быть достаточно повторить телефонный звонок и отправить им электронное письмо, чтобы проверить, что они просили вас сделать.

Сообщения об ошибках всегда сложны. Если ваши клиенты сами разработчики, это должно помочь, так как они могут понять ваши потребности: иметь четкие шаги для воспроизведения. Простой способ получить глубокое понимание - включить регистрацию в развернутом программном обеспечении. При условии, что проблемы конфиденциальности данных могут быть решены, требуя, чтобы к каждому отчету об ошибках был прикреплен текущий журнал, не только гарантируется некоторая письменная связь, но также и сообщается вам, что на самом деле сделал пользователь (в отличие от того, что они думали, что пытались сделать) ,

Амон
источник
1
Деньги не проблема (у меня ежемесячный авансовый платеж - мне платят, кодирую я или нет). Это как подтолкнуть их офисную культуру ... или что-то, чего я не понимаю.
Не хватать
2

Способ поощрения сообщения об ошибках заключается в поощрении частой, детальной передачи функций. Если вы обучаете компанию, что они могут просить что-либо с нулевой церемонией, они будут использовать эту функцию и для мелких ошибок. Откажитесь от изменения рабочего процесса вашего клиента, если эти изменения не облегчат его жизнь.

Заставить вашего клиента выполнить внутреннее тестирование довольно сложно, но заставить его фактически сообщать об ошибках не так сложно, как кажется. Чтобы получить больше откликов, нужно уменьшить трения пользователей ... даже если это означает, что некоторые из этих трений нужно передать себе.

  1. Используйте более простые инструменты, даже если эти инструменты неадекватны и не подходят. Например, BaseCamp - довольно ужасный трекер ошибок (потому что он предназначен для управления проектами), но люди на самом деле хотят его использовать.

  2. Поскольку используемые нами средства отслеживания ошибок не поддерживают копирование и вставку изображений, я на самом деле написал тривиальную программу, которая копирует текущее изображение буфера обмена на диск (как Guid), а затем копирует Guid в буфер обмена. После минимального обучения пользователь может прикреплять изображения буфера обмена к проблемам, просто нажимая на экран печати, нажимая кнопку, а затем вставляя в диалоговое окно выбора файлов инструмента отправки ошибок.

Снимок экрана (возможно, отредактированный в MS Paint с аннотациями) и 1-2 предложения достаточно, чтобы определить большинство функций / ошибок.

Оба эти предложения нацелены на точки трения, которые я испытал, и оба эти предложения увеличили количество сообщений более чем в 10 раз. Однако вам нужно нацеливать свои собственные точки трения.

Брайан
источник
Этот ответ доходит до сути. Вы хотите, чтобы они внедрили строгие протоколы тестирования: это вряд ли произойдет, особенно если это происходит извне организации (например, вы). Лучшее, что нужно сделать в этом случае, так как вам все равно платят, это сделать его как можно более безболезненным, чтобы сообщать вам об ошибках. Если вы действительно настроены на тщательное тестирование, сделайте это сами и узнайте больше о бизнес-процессах, если вам нужно ... Это печальная реальность, что многие компании никогда не будут отдавать предпочтение тестированию.
DrewJordan
1

Сделайте тестирование для вашего клиента легким, но сделайте так, чтобы вашему клиенту было очень трудно использовать какие-либо новые функции в непроверенной версии в производстве. Это можно сделать следующим образом:

Всякий раз, когда вы предоставляете новую функцию, вы сначала внедряете ее в «бета-версию», четко помеченную знаком «не для производства». Вы делаете эту бета-версию доступной для тестирования клиенту. Вы также предоставляете последнюю «рабочую версию», которую он будет использовать для реальной работы (без новых функций, но с последними исправлениями ошибок), и вы отказываетесь переносить новые бета-функции в рабочую версию, пока не получите отзыв о том, что кто-то клиентская сторона по крайней мере попробовала это сначала.

Если клиент начинает использовать бета-версию на своих реальных производственных данных, хотя он всегда показывает большое сообщение «Не для производственного использования» всякий раз, когда он запускает программу, вы не можете ему помочь, но по крайней мере вы дали понять, что всякий раз, когда он теряет производство работать, потому что он использовал бета-версию для неправильных целей, что это явно его вина. Если клиент не извлекает уроки из этого, вы можете отключить возможность использования клиентом «бета» в производственной среде, отключив некоторые важные функции, такие как сохранение результатов на диск в «бета», если это необходимо.

Предоставление отдельной «беты» заставит вас установить надлежащий контроль версий / управление конфигурацией, чтобы вы могли без проблем управлять производственным отделением и отделом бета-тестирования. Но так как вы работаете с Github, я думаю, вы уже используете что-то вроде GIT, что делает этот вид управления очень простым.

Док Браун
источник
Я не совсем согласен с первым абзацем. Часто люди искренне осознают, что что-то важно, но не могут этого сделать (например, бросить курить). Тестирование является классическим примером чего-то подобного: даже если вы понимаете, что это действительно важно, требуется много дисциплины, чтобы не использовать ярлыки на нем, когда сталкиваются со сроками и т. Д. Однако идея беты хорошая, учитывая Заявленное желание клиента улучшить результаты тестирования.
Я бы также использовал это как возможность обратиться к пункту № 1. Предложите заказчику целый процесс, в котором новые требования будут записаны, согласованы, протестированы в непроизводственной среде, а затем выпущены.
Я отмечаю новые выпуски как «альфа» или «предварительный релиз - не для производства», плюс делаю всю «веху» github с проблемами (ошибки, новые функции для тестирования и т. Д.), Но это не сделало разница. Вся ситуация как бы смущает меня. Я предложил такие вещи, как ежемесячное тестирование на ошибки в день пиццы, чтобы сосредоточить их команду (2-3 человека) на тестировании, «голосование за ваш любимый / самый раздражающий вопрос». Это немного странно - все же они все время используют мое программное обеспечение для крупных презентаций, поэтому я не понимаю, почему больше нет откатов. Я предполагаю, что это попадает в «другое дело, а не в мою работу»
не хватая
@ TOMATO: вы строго отказываетесь переносить функции из предварительной версии в рабочую версию, пока клиент не скажет вам, что он протестировал эту функцию? Ваш клиент пытается обойти этот отказ?
Док Браун
2
+1 за четко обозначенную бета-версию: если вы раздаете тестовую версию ярко-фиолетового цвета с огромным зеленым мигающим баннером в верхней части основного экрана с криком «ТЕСТОВАЯ ВЕРСИЯ - НЕ ДЛЯ ИСПОЛЬЗОВАНИЯ В ПРОДУКЦИИ - НЕ БЕЗОПАСНО - АААРАГ!» «Они не будут использовать его для презентаций или даже там, где клиент может его увидеть. Вы можете сдерживать чистую производственную версию (если хотите, возьмите ее в заложники), пока они не дадут какую-то полезную обратную связь.
Кристиан Северин