Home

Автор: Виктор Славчев (Viktor Slavchev)
Оригинал статьи
Перевод: Ольга Алифанова

Хотите, я расскажу вам рождественскую сказку? Кто-то, возможно, скажет, что Рождество давно прошло, но знаете, что не пройдет никогда? Глупости, которые делают люди и называют это рабочим процессом. Не слышали, как разработчики (а может, и тестировщики) говорят "Надо поправить CI-билд, чтобы все тесты прошли"? Или что-то вроде "Мой CI-билд снова упал, как быть с этими плавающими, нестабильными тестами?" Знакомо звучит? Мне кажется, разработчики убеждены, что цель билда – быть вечно зеленым. Я называю это "вечнозеленым CI-билдом" (и поэтому это рождественская сказка), или, чтоб покороче, Эвергринчем. Эвергринч – это на самом деле монстр, который хочет украсть ваше качество и убить ваш проект. Это жуткая рождественская сказка.

Цель CI-билда

Если вы любопытны, как я, вы, возможно, листали книги про CI/CD, когда они гремели как новый тренд в разработке, чтобы выяснить, о чем вообще речь.

Цель CI/CD билдов, согласно книгам и сообществу – давать быструю обратную связь или сократить информационную петлю. Но встает вопрос – быструю обратную связь по поводу чего?

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

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

Почему падающий билд – это хорошо?

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

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

Встаньте на их место

Это звучит отлично, но почему же люди стремятся к вечнозеленым билдам?

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

В современной разработке все участники процесса создания продукта имеют свою долю участия в тестировании.

Думаете, вы защищены от синдрома строителя? Следите за собой, создавая автоматические проверки, а? Вы прогоните их разок и засунете в систему контроля версий, не успеешь и глазом моргнуть. В будущем они упадут сотню раз, а вы будете заявлять, что они "нестабильные". Нет, это не они нестабильные – это в их коде баги!

Проблема "протестируй это мне"

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

1. На тестирование не остается времени, или время на него даже не выделяется при планировании.
2. Разработчики будут сообщать, что задачи "готовы", хотя на самом деле они стоят в очереди ваших задач, и тестирование еще даже не начато. Потом вы станете участником игры в козла отпущения, или попадете в жесткий цейтнот.
3. Вы будете получать злобные, пассивно-агрессивные замечания, найдя новые баги.

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

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

Как с этим бороться?

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

Во-первых, это наша проблема, потому что когда ты часть команды – это проблема команды, в командах нет "нас" и "их" – мы провалились, и это общий провал.

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

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

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

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

Неплохими уроками может стать:

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

Вместо заключения

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

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

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