Home

Автор: Деннис Мартинез (Dennis Martinez)
Оригинал статьи
Перевод: Ольга Алифанова

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

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

Почему у большинства команд тесты со временем деградируют

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

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

Единственное долгосрочное решение для стабильной автоматизации – это поддержка

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

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

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

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

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

Упростите онбординг новым коллегам

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

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

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

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

Не давайте скорости выполнения тестов становиться варящейся лягушкой

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

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

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

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

Повышайте доверие к вашим тестам и их надежность

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

Чем больше у вас тестов, тем выше вероятность, что вы добавляете потенциальные причины падений, которые позднее затронут всю команду. Зачастую во многих компаниях так происходит при настройке end-to-end тестов. Эти тесты могут быстро стать нестабильными и хрупкими из-за всего того, что происходит в ходе их выполнения. Нередко набор end-to-end тестов доходит до стадии, когда тесты вредят процессам команды, а не помогают им.

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

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

Заключение

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

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

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

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