Home

Автор: Ким Энджел (Kim Engel)

Оригинал статьи: https://www.testingcircus.com/documents/TestingTrapeze-2014-February.pdf#page=10

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

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

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

• Автоматизированные юнит-тесты не проверяются неделями или месяцами.
• Релизы для тестирования и для прода выполняются разными командами.

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

Команда тестирования, проверяющая результаты юнит-тестов

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

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

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

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

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

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

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

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

Тест-команда, создающая релизные сборки

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

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

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

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

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

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

Где остановиться, помогая другим?

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

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

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