Comments 21
Автотесты.. прочие модные смузи..
Перестаньте автоматом перенаправлять меня сайт перекрестка с вакансиями продавцов!
Мне очень странно слышать слово "автотест". Тесты - это содержимое tests/
А уж кто их запускает - CI, или человек руками, или даже script exporter по расписанию - это дело десятое. И да, проект без тестов - это "набросок" (study), пока делаешь exploratory programming. Закончил прототип, начал к продакшену готовить - тесты.
.... кто-то вообще принимает изменения без тестов.
Стоит уточнить, что по большей части я тут говорю про UI-тесты.
В настоящее время достаточно много проектов (особенно в мобильной разработке), которые выпускаются/разрабатываются без тестов. Не без тестирования, а именно без тестов. Такие проекты просто тестируются силами ручных тестировщиков.
Почему говорю, что тесты должны запускаться на CI.
Запускать тесты локально - не стабильно, можно пропустить этот момент, забить на какие-то фэйлы или пропустить их.
По расписанию - уже ближе к истине, но между двумя запусками могут случиться «множественные» мержи и потом нужно будет дольше разбираться, чьи изменения повлияли.
Стабильность локальных тестов - это одно из условий комфортной разработки. Мы когда работаем над проектами, условие "могу запустить сам, без CI" - обязательное. Потому что иначе development loop (попушить в гит, получить сообщение об опечатке через 20 минут) становится не tight, а для продуктивной работы должен быть tight.
Я бы даже сказал, что время, через которое программист получает сообщение об ошибке - главная метрика его продуктивности. Если ошибка в течение секунды-двух, то человек на пике своей продуктивности. Если через час-полтора, то человек делает 8 коммитов в день, из которых 7 - исправление опечаток.
Для таких быстрых проверок существует статический анализ, который для своего проекта можно настроить максимально комфортно, и все подобные «опечатки» будут выявляться сразу. (У нас максимально быстро приходит сообщение об ошибках такого рода).
Так же для быстрой проверки, что ветка ничего не сломала есть юнит-тесты, которые мы запускаем на PR-ах. Это тоже достаточно быстрый способ узнать, что все ок и получить уже более существенные ошибки.
Разработчики, разумеется, гоняют юнит-тесты и стат. анализ локально.
UI-тесты это уже полная проверка всего приложения. Их не имеет смысла запускать на каждом коммите, это верно (по крайней мере полный набор). Но перед каждым мержем в девелоп уже стоит. Тут стоит еще сказать, что у нас не trunk-base.
Плюс то, что все эти тесты будут запускаться на CI не исключает возможности запустить эти же тесты локально. Все или какие-то отдельные, связанные с вашим функционалом. Это уже по желанию самих разработчиков.
Также для отладки мы сделали специальные планы на CI, в которых можно запустить не все тесты, а только помеченные аннотацией. Их часто используют для отладки
lint не способен найти опечатки. Он способен найти отклонения от стиля. Если я сделал
if configuration['litsen']:то никакой линтер не поймает такое. Однако, это тупая опечатка, которая может быть поправлена в течение 2-10 секунд если тест упадёт в течение секунды, и которая займёт 1 час 3 минуты, если CI сообщит о проблеме через час. Это называется tight loop, и он определяет продуктивность разработчика.
Нет ли тут путаницы между unit-тестированием, интеграционным и UI-тестами? Последние два вы, как разработчик, сомнительно, что делаете. Если только не один пишете весь проект
Я как девопс, пишу всё. И юнит, и интеграционные, и ui (если у наших продуктов есть ui), и более того, я очень хочу, чтобы интеграционные тесты можно было запускать локально. Не всегда возможно, но с максимом усилий, чтобы можно было.
Последний раз я писал интеграционные тесты для распределённой peer to peer VPN сети. Полное время поднятия системы (включая кластер из трёх серверов, три рабочие станции и три независимых сервера) занимало у меня примерно минут 5 на моей рабочей машине, плюс около минуты интеграционные тесты (добавить пользователя, проверить, что он может подключиться, забанить пользователя, увидеть, что он отвалился и т.д.). Это - tight loop. И это причина, почему моё желание иметь много денег находит отклик у работодателя.
Я мог бы всё это оставить непротестированным (сложно!), либо переложить на CI (час-полтора, и всё готово), но тогда задача была бы всё ещё в стадии отладки.
Мне очень странно слышать слово "автотест".
Хм... А что тогда находится посредине между ручным тестом и автоматизированным?..
Между ручным и автоматическим еще понятно, как раз автоматизированный...
Ручной запуск тестов, не по расписанию. Обычно туда кладутся очень flaky тесты, либо тесты, требующие немалой компетенции, либо очень разрушительные тесты, которые человек знает когда можно запускать.
На самом деле все они - это сценарии, а проверка "работает или нет" уже обязательно хорошо описана. Если не описана - проект сырой и к продакшену не готовый.
Я конечно прошу прощения, что домахиваюсь до формулировок, но вы как раз говорите тоже об автоматизированном тестировании. Автоматизированное что-то-там допускает участие человека, в отличии от автоматического, которое работает без него. И оба отличаются от ручного, где "программа" тестирования выполняется руками оператора.
Или вы хотите сказать, что автор статьи "топит" за автоматический запуск тестов, а надо, чтобы был выбор - вручную или автоматом?
Тогда надо подобные статьи начинать с определений, похоже.
Потому что наличие скрипта (п.2) предполагает использование автоматизации для тестирования, в отличии от п.1, где тестирование производится без автоматизации (ну не считать же автоматизацией использование компьютера в данном случае?).
И в контексте ссылки на предыдущию статью из этой - по-моему да, 2-4 все вместе попадают в категорию "автотесты", т.к. используют автоматизацию для тестирования, насколько я понял ту статью.
Но с другой стороны, ручной запуск тест-скрипта - по подобной логике является автоматизированным тестированием, а автоматический его запуск в CI - автоматическим, и промежуточное звено между ручным и автоматизированным отсутствует за ненадобностью...
По крайней мере в контексте UI. Но в контексте юнит-тестов я с трудом могу себе представить на практике тест, не использующий автоматизацию... Так что и с ним - ручной запуск это "автоматизация", без прямого участия человека - уже "автоматическое".
У меня возникло пару вопросов:
Примерно за год мы пришли к практически полному покрытию регрессов на обе платформы. И это с учетом того, что мы продолжали тестировать функционал руками и проводить ручные регрессы, а на андроид дважды переезжали на новый фреймворк.
Подскажите, а как часто осуществлялись релизы/какой объём задач ежедневно падал на плечи тестировщиков, что команда смогла написать автотесты на регресс за достаточно небольшой промежуток времени?
И второе:
Понимаем, что автотесты в недалеком будущем принесут нам максимум пользы и выделяем каждому тестировщику, например, один день в неделю под автоматизацию
Команда тестировщиков состояла из людей, которые имеют достаточно большой опыт в написании автоматизированных тестов?
Почему меня заинтересовали эти два момента: допустим, мы имеем достаточно крупную команию с достаточно частым циклом непрерывной интеграции. В команде есть один тестировщик и, допустим, 7 разработчиков, пишущих код. Задачи, поступающие на тестировщика могут быть разноплановыми: от тривиальной (орфографические правки) до сложных бизнесовых с неявными требованиями и сложной логикой. При таком темпе работ, ИМХО, шансы заавтоматизировать регресс, а в идеале ещё и покрыть автотестами выпущенный функционал, стремятся к нулю. А если у тестировщика недостаточно навыков в автоматизации (читай джун), то вероятность написания автоматизированных тестов ещё больше уменьшается. Как тогда качественно покрыть кодом регресс?
Согласен, что, чтобы перевести регресс в от ручных проверок в автоматизированные, не нужно нанимать целую команду автоматизаторов. Тут нужно взвешенное решение, основанное на том, справляе(ю)тся ли тестировщик(и) с потоком разработки и хватает ли у него(них) времени на написание кода.
Предусловия у нас были такие:
Нас было 4 тестировщика на 4 мобильных приложения (по 2 приложения на 2 платформы) - 2 тестировщика уже умели автоматизировать, 2 пришли учиться автоматизировать с нуля. При этом уровень мануального тестирования у всех был мидл+.
Релизы были примерно раз в две недели (выпускали приложения попарно: первую неделю первое на обе платформы, вторую неделю - второе). Тогда, два года назад, релиз-трейн у нас был только в планах и еще не встал на рельсы. Но это скорее даже минус, так как многие задачи приходилось тестировать обязательно и срочно, чтобы выпустить релиз.
Разработчиков на 4 тестировщика было примерно человек 15, задач было достаточно много, и были все шансы закопаться в них на 100%, но мы сделали именно так, как я пишу в статье - для каждого тестировщика один день в неделю ставили автоматизацию первым приоритетом.
Ну и не знаю, насколько корректно писать об этом здесь же, но когда участвуешь в автоматизации регресса с самого начала, у тебя есть особый азарт и интерес этим заниматься, поэтому время на первые автотесты находилось очень часто у тестировщиков и в самые загруженные дни по остаточному принципу.
Стоит так же отметить, что да, какое-то продолжительное время покрываться автотестами будет именно регресс - устоявшийся, редко меняющийся, стабильный функционал. До покрытия автотестами нового функционала мы вот пришли только спустя полтора года.
На счет качества получаемых таким образом автотестов. Да, по началу они могут быть написаны кривовато и флаковать, но со временем тестировщик будет лучше понимать как всё работает, как написать лучше, как сделать так, чтобы меньше флаковало и работало стабильнее. То есть чем дальше, тем тесты будут лучше и качественнее. Плюс, автотесты должны проходить ревью от кого-нибудь, кто в этом разбирается. Тогда в код не будет просачиваться совсем уж что-то на джунском)
Мое мнение на счет 1 тестировщика на 7 разработчиков - тут всё реально, если разработчики помогут своему тестировщику с первыми автотестами и настройкой всего для автоматизации. Дальше тесты уже пишутся очень просто и быстро. Самое сложное всегда это начать. В нашем случае было просто во-первых потому что разработчики нам помогали, а во-вторых, что нас было 2-4, а не 1. Всегда была возможность договориться между собой, что один возьмет на себя чуть больше ручного, чтобы освободить время другому не отвлекаться и довести автотесты до пул реквеста.
@benavir от себя еще предложил бы вам хотя бы временно уменьшить нагрузку на тестировщика. Вообще 1 к 7 это еще хуже чем в известной картинке!
Как можно снять нагрузку? Можно найти много способов, например:
Отправить двоих разрабов разрабатывать фреймворк и инфру для автотестов (это убьет сразу же двух зайцев, кстати)
Взять на пару месяцев аутстаф тестировщика на мануальное тестирование, чтобы разгрузить Вас (мы, кстати, так сделали, когда запускали автотестирование на втором приложении)
Дождаться, когда команда уйдет в отпуск ( перед новогодними, например)
Удачи Вам, поговорите, со своим руководителям о балансе сил!
А сколько еще людей у вас задействовано для работы автотестов? кто поддерживает инфраструктуру? разработчики/девопсы? Большинство толковых ручников конечно можно научить пилить автотесты UI "по образцу". Но это до первой серьезной проблемы (или обновления ОС). Прошлую статью тоже прочитал, ответа на этот вопрос не нашел
Поддержкой и настройкой тестовых сред у нас занимается отдельная команда. Это команда девопсов, состоящая из 5 человек, которая занимается всем тестовым бэкендом компании, железом и администрированием CI-сервера.
По факту из этой команды нам обычно помогает один человек, и в основном это настройки железа. Но это не совсем частые задачи, так что в целом времени на это у команды инфраструктуры уходит не много.
Всей мобильной спецификой инфраструктуры занимаемся мы сами. И тестировщики, и разработчики. На нас такие задачи, как настройка CI, скрипты и автоматизации под мобилки. В основном такие задачу попадают на платформенные кор-команды (2 разработчика с каждой платформы, но это, конечно, не единственное, чем они занимаются).
Ручные тестировщики, которые у нас постепенно превращаются в автоматизаторов, наравне с разработчиками берут задачи, связанные с инфраструктурой. Это одно из направлений развития.
ТОП-5 вопросов менеджера про автоматизацию