Home

Автор: Майкл Болтон (Michael Bolton).

Оригинал статьи

Перевод: Ольга Алифанова

Вопрос от тестировщиков: "Зачастую мне дают продукт на тестирование, но не выделяют достаточно времени. Как мне одобрить релиз, если я недостаточно протестировал?"

Вот мой ответ.

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

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

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

С большей вероятностью на каком-то этапе ваш протест будет отклонен. Менеджмент решит, что ваше беспокойство недостаточно важно, чтобы блокировать релиз. Затем вы сможете сказать "То есть решение, разрешать или запрещать релиз, на самом деле мне не принадлежит? ОТЛИЧНО". А еще, возможно, добавите про себя "Я рад, что это все-таки не моя работа. Меня вполне устраивает, если меня не заставляют играть роль фальшивого продакт-оунера".

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

Итак, как же быть, если кто-то просит вас что-либо подписать? Я готов подписаться под тем, что я знаю о статусе продукта и тем, что я делал, чтобы изучить его. Это заявление может быть довольно кратким, а в расширенном виде может выглядеть как-то так:

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

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

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

Нашел я проблемы или нет, я всегда готов подписаться под заявлением "я покрыл эти конкретные условия до этой конкретной степени, и я не покрыл вот эти условия". Условия включают специфичные продуктовые факторы и критерии качества – к примеру, описанные в эвристической модели тест-стратегии, или же относящиеся к проектному контексту. Это подкрепит мое заявление, что в продукте есть проблемы (или что я о них не знаю), и расскажет, почему менеджмент должен достаточно полагаться И достаточно скептично относиться к моей оценке. Чтобы принять информированное решение о релизе, менеджменту нужно знать, что не было покрыто тестированием, и как я оцениваю риски, связанные с отсутствием такого покрытия.

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

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

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

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

Обсудить в форуме