Что пишут в блогах

Подписаться

Онлайн-тренинги

Конференции

Что пишут в блогах (EN)

Разделы портала

Про инструменты

Лучшие вакансии

.
Могут ли тест-менеджеры снизить качество продукта, чересчур помогая ему?
11.12.2017 10:11

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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