Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

Как автоматизировать тестирование на проекте, где по 100 релизов в месяц

Автоматизация или ручное тестирование — один из неразрешимых холиваров в среде тестировщиков. Я QA-менеджер в Parimatch Tech и адепт автоматизации. В своей команде стремлюсь к тому, чтобы вообще отказаться от мануального тестирования. В колонке расскажу о том, почему это выгодно, почему многие до сих пор (зря) боятся автотестов, и об опыте внедрения такого подхода в стриме «Спорт».

Перед нами как командой разработки стоят серьезные задачи. Требуется высокое качество, чтобы мы работали постоянно и стабильно. Мы должны обеспечивать аптайм в 99,99%. При этом компания работает в сфере высокой конкуренции. На этом рынке побеждают те, кто может постоянно предоставлять пользователям новые фичи, которые стабильно работают.

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

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

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

Иллюстрация Алины Самолюк

Как правильно автоматизировать тесты

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

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

Поэтому, когда мы говорим о внедрении автоматизации, это подразумевает изменения самого подхода к автотестам. То есть изменения культуры разработки. Автотесты должны стать частью работы команды.

Самое сложное в автоматизации — это донести людям, которые привыкли тестировать вручную, что теперь можно работать по-другому. Эту идею нужно «продать».

Что нужно поменять в команде, чтобы внедрить автотесты

Внедрение автоматизации я всегда начинаю с малого. Сначала выбираю небольшой компонент (обычно он либо только начинает писаться, либо недавно появился). Для него делаю MVP, который состоит из нескольких тестов. Он сразу внедряется в CI, и я показываю его команде. Если решение нравится, мы договариваемся, что эти тесты должны быть всегда зелёными и вся новая функциональность в этом сервисе должна автоматизироваться на потоке.

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

Если ты разобрался с продуктом и его спецификой, первые локальные тесты можно получить через пару дней. А иногда в этот же день. Работающий MVP будет спустя 2–3 дня, максимум неделю. Потому меня удивляет, когда говорят, что нужно написать некий «тестовый фреймворк» и это займет месяцы.

1. Необходимо объяснить, что автоматизированные тесты — это не мифические вещи, которые пишутся в другом отделе. Тесты — часть функциональности команды. С их помощью можно обеспечить критерии качества своих сервисов и приложений.

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

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

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

3. Не нужно писать тесты, которыми не будут пользоваться. Нужно понимать, что, если автотест уже написан, не стоит опять тратить время на ручное прохождение задачи. Потому что существует еще один антипаттерн: «Лучше я перепроверю это все руками». Это противоречит моему подходу, потому что требует двойных затрат ресурса.

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

Почему за автотестами будущее

При создании нового продукта даже три перепроверки функционала руками — это уже повод автоматизировать тестирование. А если это стоит на потоке, вложения в автоматизацию окупятся уже от 0,4 до 0,7 ручного прогона. То есть это уже дешевле, чем тестировать руками даже 1 раз.

Мы запускаем тесты на каждый коммит. Поскольку мы живем в микросервисной архитектуре, в течение дня может быть до 400–500 запусков. А такое количество ручных прогонов в день никто не мог бы себе позволить.

Так мы выработали определенные правила работы:

  • Без тестов мы не можем гарантировать стабильный мастер. Поэтому тесты становятся базовой частью функциональности.
  • Зеленые тесты — обязательное правило для мержа. Если хотя бы один тест Flaky, это признак того, что что-то не так. Тест не должен быть красным. Либо у нас баг, либо плохой тест, который сразу же нужно менять.

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

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

К тому же, когда это стоит на потоке, написание нового теста отнимает все меньше времени.

Конфликты с разработчиками начинаются в тот момент, когда ты отказываешься мержить продукт до тех пор, пока отсутствуют тесты. Ты предлагаешь сначала написать автотесты и избавиться от красных тестов. Сначала командно, а потом делать это силами самих разработчиков. Разработчики воспринимают такие задачи как дополнительную работу, которую не должны выполнять. Но на самом деле стратегически это, наоборот, экономит время.

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

Что делать с Manual-тестировщиками

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

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

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

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

Сейчас у нас 25 автоматизаторов и 12 ручных тестировщиков. Плюс уже треть Manual-тестировщиков изучает автоматизацию. Ещё около 7 открытых вакансий на автоматизаторов. Так что пропорцию мы скоро изменим.

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

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

Так что мы движемся огромными шагами к автоматизации. Мой идеальный мир: в проекте не будет ни одного тестировщика, который будет заниматься только ручным тестированием.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось10
До обраногоВ обраному7
LinkedIn

Схожі статті




33 коментарі

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

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

Главный вопрос к автору — у вас вся команда ответственна за ВСЕ виды тестов? И поддержание стабильности после выпуска фичи? Если еще юнит, компонентные, контрактные тесты на отдельно взятый микросервис можно жестко поставить в ответственность команде, то что делать с UI тестами? Как вы доказываете что, изменение в отдельно взятом сервис сломало именно вот этот ЮАЙ тест и команда должна остановить релиз и фиксить этот Flaky тест?

Делая автотесты сразу, мы решаем проблему наперед.
К тому же, когда это стоит на потоке, написание нового теста отнимает все меньше времени

Автор «забув» згадати, що у автоматизованих тестів є і відносні мінуси. Їх тепер потрібно підтримувати, тобто міняти, якщо змінюється функціональність проекту.

Любой код нуждается в поддержке. По такой логике вообще не надо тесты писать.

более того, мануал тест кейсы тоже нужно поддерживать

Якщо приходить задача змінити функціонал чи росширити його, то задача змінити чи дописати тести йдуть по дефолту.

Не нужно писать тесты, которыми не будут пользоваться.

Це взагалі муть якась. З моєї точки зору, якщо є автоматизовані тести, то вони прогоняются при збиранні проекта. Як вони можуть не використовуватися?

Где-то видел опрос по этому поводу. Так вот очень не маленький процент был о том, что тесты есть и их иногда ранят локально руками.

Юніт тести запускаються при білді. Але є ще компонентні, інтеграційні тести — які ти запускаєш тільки після того, як в тебе сервіс збілдився.

Але це більше відноситься до випадків, коли тести пишуть окремі «команди автоматизаторів» і не зрозуміло для кого вони їх пишуть

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

Прочитав кілька разів, але так і не зрозумів, як правильно автоматизувати тести.

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

Головна ідея статті, що автоматизація — має бути культурою розробки, кожен член команди розуміє навіщо їх пишуть і як ними користуватись. І вони стають скоупом реалізації будь якої фічі чи сервісу.

Технічні деталі не надто принпипові, якщо немає культури. Все одно вони нікому не будуть потрібні, навіть якщо код ідеальний.

Гарна стаття. Навідь трохи для себе знайшов цікавих речей.
Але ...дуже вузька. Автор розповів що в нього «зараз болить», але все... значно ширше.

От коли шось робити «from scratch» найбільш еффекивним є TDD/BDD/ATDD підхід. Звісно, при правильній реалізації...

А інколи — особливо коли робимо міграцію корпоративного середовища без зміни функціоналу... чекати три-чотири тижні на «проектну область» на Jenkins довше, ніж мануально протестити все і вся....

Думаю, багатьом було б цікаво почитати про практику як першого, так і другого!

Как автоматизировать тестирование на проекте, где по 100 релизов в месяц

Раз шмаркнути й 100500 тестів написати 😸

Я вірю, що наша спільнота, колись виросте з тверджень: «Це підходить не всім», «Це вже 100 років тому придумано» 🙏

А можно тут подробней? ) А то на фейсбуке видел, раз увидел второй раз, то пора разобраться ) Чем плохое утверждение «нам это не подходит». Нет же универсального решения под все проекты?

имхо, в 9 из 10 случаев когда пишут «нам это не подходит» вопрос в том, что просто не умеют/не знают как. А не потому что специфика проекта такая. Я вот слабо представляю проекты, где не нужно автоматизированное тестирование. Думаю, что если проект перерос стадию MVP и это больше чем сайт-визитка и планируется дальнейшее развитие продукта, то точно нужно )

Приєднуюсь до коментаря від Віталія)
Доповню лиш тим, що ця фраза капітанська
І так зрозуміло, що не існує сільвер булєтів,
А просто комусь, може в певній ситуації, із певною командою командою, із певною культурою, із певними можливостями, із певним настроєм, із певним бюджетом може мабуть підійти будь який підхід — і якщо пощастить

І майже те саме можна сказати і про те що «Це вже було», ну блін, в нас на рік вайтішників по 20к з 200к
Певні знання мають повторюватись, актуалізуватись з часом та спливати в «медіа»

Хай вже і сто років тому написано, але далеко не кожен матеріал ідеально кожному розуміється за буде корисним.
І варіативність знань це кльово!

Хоча кожен має право на капітанство)

Амінь)

There are good practices in context, but there are no best practices

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

Спасибо за фидбек. Постараюсь в следующей статье раскрыть детальней специфику тестирования GUI.

Зачем для такой простой штуки как «пейшите автотесты и будет все пучком» писать целую статью на доу?

Автоматизация была хобби для тестировщиков, но никак не стандартная практика.

Шёл все ещё 2021 год а где-то тестили ручками и специально обученные человеки.

Потому меня удивляет, когда говорят, что нужно написать некий «тестовый фреймворк» и это займет месяцы.

Дак уже же все давно написано, даже водилки микросервисов, мок апи.

Если разраб не может написать элементарных юнитов, то он проф непригоден.

Стаття хороша. Спасибі. Але, на жаль, є завжди якісь але.
По-перше, підхід не новий. Йому років десять, а то і більше. Таке відчуття, що автор надихався роботою Джеймса Уіттакера про те як тестують в гуглі)
По-друге, не враховано пару моментів.
— Як багато проектів в країні, котрі релізаються по сто разів на місяць? не думаю, що багато.
— Знову ж таки, є особливості ринку. На галєрах, припустимо, таке важко втілити, бо там сейлз політика інша. Часто замовники звертаються до українських ресурсів, знаючи, що там типу недорогі мануальні тестери (хоча зараз цей вектор зміщується в сторону Індії і тд, а ми стаємо доволі дорогими), компаніям вигідно тримати часто легіон мануальщиків, яких можна дорого продати.
— Є певні принципи та парадигми тестування, котрі нам говорять, що автоматизувати все неможливо. Є ряд типів тестування, котрі потребують мануальних перевірок. Так, з цим можна сперечатися, але тоді скажу так — багато що залежить від продукту.
— Ну, і звісно є нюанс, що тестування — це процес дослідження продукту. Процес дослідження. В автотестах по суті мало дослідження продукту) Якщо писати тести ще не на готову фічу, то і не вдасться зрозуміти — з яким продуктом ти працюєш))
Але якщо автор мав на увазі юніт тести, то звісно — питання відпадає.

Сколько проектов вы уже сделали именно по этой схеме? Это хороший подход, но он не всем подходит. Вы правильно упомянули, что такой подход замедляет разработку. Как минимум митинги становятся дольше, т.к. обсуждается ещё и автоматизируемость нового функционала. Дальше зависит от уровня команды.
Ещё крайне важный фактор — этап проекта. Если цель захватить рынок, а потом причесать продукт, то время разработки гораздо важнее качества продукта. Ну и функционал часто переделывается в таком случае. На моём текущем проекте новые фичи разрабатываются в течение недель, а то и месяцев и фича в этот период может несколько раз меняться кардинально, так что тесты нужно будет не подправить, а выкинуть и написать новые.
Количество мануальных проверок, после которого стоит автоматизировать тоже сильно зависит от продукта, в первую очередь от качества кода разработки. Если мы говорим про UI e2e тест, в котором компоненты не работают так, как везде (т.е. разработчики там что-то нахачили), то и автоматизировать это будет не так просто, следовательно количество мануальных прогонов вырастает перед необходимостью автоматизации. Конечно, если это простой апи тест и вся инфраструктура готова, то конечно его легче и правильней сразу автоматизировать.
И, если вы дочитали до конца, то у меня вопрос ) Я так понял, что у вас всё совсем красиво и автоматизация тестирования — задача все команды. Вы сами себе делаете локаторы или это задача разработчиков?

Сколько проектов вы уже сделали именно по этой схеме?

Больше 10-15 проектов разных размеров. Все новые проекты у нас сразу же закладываются с такой схемой.

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

Согласен, что быстрее выйти с MVP будет без авто-тестов. Но, на моём опыте, потом причёсывать MVP никто не хочет, так как это уже работает и «давай-давай быстрее новый функционал» подавай. А ещё если нет человека или знаний, как это сделать — то ещё будут тратить пару месяцев на хайринг, онбординг и т.д. И тут начинается тех долг с самого начала приложения и новый продукт уже сразу становиться корявым. Потому нужен баланс, как обычно)
Но если есть опыт и капасити, можно уже рядом с МВП писать тесты (хотя бы смоуки) и это даст возможность быстрее потом отрефакторить решение.

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

Согласен, что легаси-монолиты точно не будут окупаться так быстро. Тут важно было показать, что такие цифры реальны и в это стоит вкладываться. Даже UI компоненты (веб или мобайл) могут быть достаточно тестабельными, что бы их быстро авто-тестировать.

Вы сами себе делаете локаторы или это задача разработчиков?

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

Монолит/не монолит не имеет значения в разрезе UI тестов. Юнит — да, без вопросов, но, чтоб пройтись по длинному флоу UI теста, на который ещё ничего не написано, то занимает трошки времени.
Как научили разработчиков писать локаторы? ) С кем я работал, то в упор нет понимания куда надо ставить. Даже, если у тебя есть или и там ежу понятно, что надо, то всё равно через 25 напоминаний. В какой-то момент я сдался и просто все локаторы добавляю сам.

Монолит/не монолит не имеет значения в разрезе UI тестов

Всё равно сложнее «готовить» данные — больше зависимостей, больше условий и нюансов. Да и длительность ранов другая.

Как научили разработчиков писать локаторы? )

Как говориться: «вода камень точит». Медленно и упорно рассказываешь и напоминаешь. А ещё лучше — дать им возможность пописать тесты самостоятельно.

Согласен полностью с подходом автора. Я на своих проектах стараюсь придерживаться практики automation first. Это когда фича проверяется и сразу же покрывается автотестами.
Часто это можно достаточно просто реализовать, когда бекенд часть уже готова, а фронт еще нет.
Тогда вместо того чтоб сидеть ждать полностью готовую фичу — можно начинать тестировать и покрывать тестами готовую часть бекенда.

Судя по

Поскольку мы живем в микросервисной архитектуре, в течение дня может быть до 400–500 запусков. А такое количество ручных прогонов в день никто не мог бы себе позволить.

вы делаете множество мелких проверок.
Под «тестом» что подразумеваете, юниты?

Не только юнит тесты.
Так же сюда входят компонентные (или некоторые называют их интеграционным) тесты, где мы тестируем поднятый микросервис в изоляции от других микросервисов, но с поднятой рядом инфраструктурой (базы или очереди). Их мы запускаем тоже на каждый коммит в фича бранч.
Так же есть интеграционные между несколькими микросервисами, если в этом есть нужда — тоже достаточно быстро отрабатывают + их намного меньше чем предыдущих тестов.
А в финале Е2Е, но они раняться намного реже (не каждый коммит это точно)

На этом рынке побеждают те, кто может постоянно предоставлять пользователям новые фичи, которые стабильно работают.

Я бы сказал, что на «этом рынке побеждает тот, кто больше налюбит людей», но это уже лирика, пожалуй...

Іронія долі) Євген працює в паріматч)

Підписатись на коментарі