На Android-митапе мы устроили короткие дискуссии на 10-15 минут, где вместе с экспертами из Авито, Ситимобила и Revolut делимся различными взглядами на необходимость тестирования в разных проектах, говорим о регрессе и тестировании на пользователях.
Смотрите видео, читайте расшифровку и пишите в комментариях своё мнение на озвученные вопросы. Вместе разберемся: быть или не быть?
Митап сразу начался с горячего — с обсуждений. Поэтому представим участников нашей онлайн-дискуссии:
Нина Семкина: Многие говорят, что тестирование обязательно нужно вводить в проекты… Но все понимают, что это очень дорого. Тратить время разработчиков и кучу ресурсов на то, чтобы покрыть весь код тестами, — это очень дорогое занятие. Неужели тестирование всегда нужно делать?
Дмитрий Манько: А что тестировать собрались?
Нина Семкина: Android-приложение. Когда мне нужно понять, что его 100% нужно тестировать?
Дмитрий Манько: Если рынок не ждет появление какой-либо функциональности, то, с точки зрения разработки или с точки зрения покрытия, тестирование можно упростить или им вообще пренебречь. Все зависит от продукта. Если мы делаем калькулятор с 2 функциями, то серию тест-кейсов мы, скорее всего, прошли и не раз. Таким образом, тесты можно не писать, быстрее выложить на рынок приложение и сократить time-to-market.
Нина Семкина: У нас всегда есть гонка time-to-market, рынок всегда требует кучу фичей, и мы не можем их тормозить. Особенно если речь идет о только-только начинающемся проекте, который нужно выпустить на рынок прямо сейчас, имени у нас никакого нет, мы конкурируем с другими компаниями. Какое нам дело в этот момент до тестирования? Нам нужно снабдить наше приложение фичами и быстрее их выкинуть, а то устареют через 3 недели. Зачем их тестировать?
Дмитрий Воронин: На самом деле скорость разработки в какой-то момент начинает зависеть от тестового покрытия. Если, например, бизнес архитектурно завязан на одном главном экране, где все основные фичи, и туда вносятся изменения много-много раз, то без тестов там можно начать двигаться медленнее даже при большом «фичепроводе». Кажется, как только есть сигналы, что вы часто возвращаетесь на регрессе обратно, то есть повод задуматься над тем, что с покрытием что-то не так и вы не предпринимаете реактивных действий. Например, что-то часто ломается — значит, это место не тестируется как надо.
Нина Семкина: Могу ли я сделать такой вывод, что нужно постоянно тестировать только базовый функционал, а фичи подключать «одной точкой». Пусть эти отдельные фичи будут с багами, но, возможно, они сегодня есть, а завтра их нет. Можно ли тестировать только одну часть приложения?
Дмитрий Манько: Я бы скорее сказал — ключевые части стоит протестировать. То, что важно с точки зрения бизнеса для этого продукта. А если есть фичи с багами, они где-то отдельно расположены и не влияют на что-то общее, то в идеале их закрыть удаленным тогглом. И если по аналитике ты видишь, что там действительно есть баги и пользователи жалуются, то эту фичу выключить.
Дмитрий Воронин: Дима хорошую тему затронул, что тесты — это не единственный инструмент для контроля качества, который есть у разработчика. Нужно всегда помнить, что помимо unit и интеграционных тестов, ручного тестирования, всегда есть и должен быть мониторинг. И есть способы выкатки и откатов своих изменений. Если все эти инженерные практики у тебя есть, то в принципе ты можешь пренебрегать одними инструментами в пользу других, если скорость от этого выигрывает. Но в целом всегда считается хорошим тоном, если у разработчика есть культура тестирования — то, что ему комфортнее и надежнее доставлять изменения с тем, что у него протестированы те функциональности, которые он должен выполнить. В нашей компании принято оставлять такой код, в который потом ты сможешь вносить изменения легко, и быстрым запуском тестов понять, что ты не испортил то, что уже было.
Нина Семкина: В чате пишут, что тестировать нужно то, что приносит доход. И когда затраты на тестирование меньше, чем возможные убытки от нерабочего функционала. В принципе это неплохой критерий, чтобы понять, что именно нужно тестировать. А вы могли бы назвать еще какие-то критерии тестирования конкретной функциональности?
Дмитрий Манько: Критерии можно выявить при помощи аналитики. К примеру, если зафиксировать наиболее часто используемые функции, то их тоже желательно тестировать, чтобы пользователи как можно меньше встречались с багами. Если баги находятся в редких местах, то это небольшая проблема. А если бан на экране авторизации — возможно, он не critical, но все же баг, который увидят все. И это уже репутационный риск.
Дмитрий Жаков: Тестирование в целом вообще нужно. Не надо забывать, что тестирование — это проверка тех требований, которые мы предъявляем к продукту. Если что-то не соответствует требованиям, то это проблема, баг, issue. Все тест-кейсы и тестирование можно автоматизировать, и если времени не хватает, то вначале стоит проверять критичные моменты, а потом все остальное. Например, если у вас завтра релиз и бизнес хочет фичу именно завтра, то вы проверяете самый критичный функционал. А если времени достаточно, то можете позволить себе проверить medium, low-кейсы. Тут больше вопрос, будет ли ваше тестирование мануальным или автоматизированным. Будут ли это метрики или UI-тестирование, полностью проверяемое роботом.
Нина Семкина: Мы все сейчас говорим от лица крупных компаний, где много ресурсов и возможностей. А если рассмотреть точку зрения мелких фирм, стартапов, у которых время и ресурсы ограничены. Думаю, что там поначалу все будут жертвовать тестированием. В какой момент мы можем понять, что это тот критический рубеж, когда мы должны остановиться и перестать катить фичи и потратить ресурсы на тестирование?
Дмитрий Манько: Могу поделиться своим мнением, так как я выходец из аутсорсинговой компании. Аутсорсинг — это в первую очередь про то, где продают человеко-часы, и там действительно тестирование дорогое. Иногда оно стоит дороже, чем разработать саму функциональность. Такие аутсорсинговые компании, когда заказчик ждет приложение и «пинает под бок», не славятся тестированием. В нашей команде мы столкнулись со следующей ситуацией. Продукт — меню для баров, где применялись акции по огромному количеству кейсов (день рождение, 2 по цене 1, студенческие и прочее). И мы заметили, что эта функциональность акций ломалась каждый месяц в течение года. И вот тогда Unit-тестирование описало все кейсы в идеале. Мы поняли, как все работает (было около 70 тест-кейсов). Мы победили этот продукт, но, конечно, не везде так получилось бы сделать.
Юрий Чечёткин: Мой опыт работы в крупных компаниях — Яндекс, Альфа-Банк, Revolut — в финтехе, где критичность любого бага просто зашкаливает. При этом у меня есть опыт в стартапе, и даже там тестирование было абсолютно нужно. Считаю, что неважно, стартап это или нет, потому что разработчик должен отвечать за свой код, и тесты — это гарантия того, что этот код работает. Разработчик — это в первую очередь инженер, который отвечает за разрабатываемый продукт. Поэтому тесты писать нужно не потому, что надо, а потому, что они должны тебе помочь. Если это тесты, написанные для галочки, то это может тормозить разработку. А если тесты тебе нужны и ты это сам понимаешь, то их обязательно нужно писать. Если разработчик пишет код и уверен, что он работает без тестов, — это риск, и это его выбор. А я все-таки считаю, что разработчик не должен так рисковать и должен прикрывать себя и покрывать все тестами.
Нина Семкина: Итак, мы решили, что нужно как-то тестировать свой код, разберем эту тему подробнее. Передаю слово Владимиру Геновичу с его докладом.
Дискуссия number two
Нина Семкина: Во время доклада к нам поступил вопрос в чате, и именно с него хотелось бы продолжить наше обсуждение. Как снять регрессионную нагрузку с QA перед релизами? Какие практики в выборе мест для тестирования применяют наши спикеры? Есть ли в компаниях стратегия по улучшению стабильности приложения и разгрузки QA-специалистов?
Дмитрий Жаков: У нас стратегия такая, что мы тестируем всё. Потому что мы являемся последним рубежом, как сотрудники перед пользователями. Поэтому отдаем только такое приложение клиенту, которое стабильно работает всегда и везде. Вопрос только в скорости. Изначально ручной прогон у нас занимал много времени — до недели. Но благодаря автоматизации мы достигли того, что релиз длится в среднем сутки. Поэтому если вы разрабатываете какой-либо функционал, то нужно договориться, что или вы или тестировщики будут сразу писать автотесты. И какие-то mobile specific кейсы, которые вы не можете автоматизировать, останется проверить только на регрессе, а все остальное проверит робот. Тем самым вы разгрузите тестировщиков, они будут заниматься более интересной, исследовательской работой, а всю рутину — прокликивание сценариев вы отдаете роботу.
Юрий Чечеткин: Большинство крупных компаний отказываются от QA, мануального тестирования. Это не то чтобы революционный путь, но немного пережиток прошлого. И, например, в моей компании, в которой я сейчас работаю, такое слово, как регресс, даже не произносится. Отдела QA у нас нет вообще.
Владимир Генович: Вы его автоматизировали, наверное?
Юрий Чечёткин: Не совсем так, он был только на начальных этапах проекта, а затем его не стало вовсе.
Владимир Генович: Вы же гоняете UI-тесты?
Юрий Чечёткин: UI-тесты есть, конечно.
Владимир Генович: И Unit-тесты? Так запуск этих тестов при выпуске релиза — это разве не регресс?
Юрий Чечёткин: Да, это регресс, но того мануального тестирования, о котором привыкли говорить, нет. И это довольно интересный подход. Он отрезвляет и превращает разработчика из «ребенка», который пишет код и отдает его тестировщикам, в более взрослого и самостоятельного инженера, который сам отвечает за свой код. Что касается визуальных вещей — ревью может проводить дизайнер или PO. И есть такие штуки, как скриншот-тесты, — например, у Facebook. Так что кажется, что сейчас продуктовые компании могут обойтись и без QA. А сами тестировщики могут заниматься более интересной работой. Конечно, немного другая история в аутсорсе — там продаются человеко-часы, и QA может продаваться как дополнительная услуга.
Дмитрий Жаков: Получается, у вас есть регресс, просто он отдан на автоматизацию, и у вас есть люди, которые занимаются исследовательской работой вашего приложения. Тестирование может быть не только UI, но и другим.
Юрий Чечёткин: Да, например, тестирование на пользователях.
Нина Семкина: Перед тем, как мы затронем это очень опасную тему, я бы хотела зачитать следующий вопрос от наших слушателей. Есть ли смысл использовать моки или фейк-объекты в UI-тестах?
Дмитрий Воронин: Есть смысл, и без них никуда. Потому что UI-тесты с полной интеграцией — это очень ненадежная штука. И вы никогда не сможете полагаться на тест, в котором 30 систем, в каждой из которой по куче точек отказа будет запускаться пул-реквест. Такие тесты нежизнеспособны. И никто ни в одной компании не смог такие штуки заставить работать. Поэтому UI-тесты — это проклятье мобильной разработки. Если есть возможность, то лучше тестировать без UI. Но из-за того, что мы вынуждены жить с фреймворком, а единственная альтернатива — это какой-нибудь роболетрик, а в iOS даже и такого нет. И чтобы проверить взаимодействие хотя бы с одной из важных для нас систем, мы запускаем всё на устройстве. UI здесь постольку, поскольку по нашей незрелости разработки мы хотим захватить по максимуму, чтобы проверить, как нажимает юзер, — нам так спокойнее. Мне кажется, что через какое-то время это уйдет в прошлое и мы перестанем бояться моков, нажатия и не будем бороться с системой, чтобы проверять все как надо, потому что все равно мы все не проверим. Могут быть визуальные баги, которые никакими UI-тестами не проверятся. Поэтому считаю, что мокировать и в UI-тестах можно и нужно, и главная цель у этого — повысить стабильность этого инструмента, довести его до такого состояния, чтобы он приносил пользу. А реальная польза в данном случае — убедиться в отсутствии регрессий. И любой инструмент, который флакует, превращается во второе «Д» из предыдущего доклада Владимира Геновича, когда мы перестаем доверять. Это происходит тогда, когда нам в тест начинают прилетать случайные значения в огромном количестве. И такой тест не дает никакой уверенности в себе, а только дает ложную надежду, что что-то протестировано.
Дмитрий Жаков: У нас около 70% кейсов автоматизированы, и они не используют ни одного мока на приложении. Возможно, их проще перенести на бэкенд. Например, если это относится к номеру карточки, то вы ожидаете, что у вас 3DS не запросится. То есть приложение не знает, что оно замокано. Думаю, что это проблема инфраструктуры.
Нина Семкина: Перед тем как перейдем к следующему докладу, я бы хотела, чтобы мы упомянули одну скользкую тему — тестирование на пользователях. Многие этим грешат: всегда хочется и колется… Что вы по этому поводу думаете? Можно ли себе позволять раскатывать на пользователей потихонечку, собирать с них краши и фиксить себе. А протестировав на них, выкатывать хорошие полноценные версии. Или же это вообще никак недопустимо? Или есть разумные границы?
Юрий Чечёткин: У нас в Revolut подобное немного практикуется в том плане, что это идет не прямо на бою, но на реальных пользователях. Демо — это тоже некоторое тестирование на пользователях, и во время демо возникают вопросы по флоу и так далее. На этом этапе могут быть вопросы по дизайну и по общей механике. Помимо прочего есть внутренняя раскатка — компания большая, больше 1000 человек, и мы можем раскатывать среди коллег. Это тестирование на пользователях, но не вовне, и кажется, что оно безопасное. А дальше это может быть раскатка на маленький процент реальных пользователей вовне, но с возможностью закрыть эту фичу тогглом. Как вы думаете, что может пойти не так на этих этапах?
Дмитрий Манько: В наших реалиях все может пойти не так. Как бы мы ни старались провести эти этапы хорошо, в любом случае проскакивают кейсы, когда нам нужно следить за аналитикой крашей. Релиз не заканчивается на том, что мы отправили его в store, все этапы прошли, у нас всё ОК. Нужно продолжать смотреть, как ведет себя приложение.
Юрий Чечёткин: Однозначно да. В нашем случае мы имеем демо, внутреннюю раскатку и тестирование на 5% пользователей вместо ручного тестирования. Конечно, после релиза фичи нужно посмотреть. Раскатка не должна быть на 100% сразу — это главный защитный механизм.
Дмитрий Воронин: Этический вопрос тестирования на пользователях за нас решает Google. У Apple вроде такого нет. Есть специальные каналы распространения, как вы знаете (альфа, бета… production). Каждый может вступить в бета-тестирование, и он соглашается со вполне понятной формой, в которой говорится, что он в здравом уме соглашается с тем, что может получить нестабильную версию продукта. И таким образом он хочет поволонтерить и помочь компании сделать продукт лучше. Как только мы открыто говорим человеку о таком, думаю, этот вопрос должен сниматься и мы не должны бояться раскатывать туда версию, в которой не уверены на 100%. А еще лучше, когда у нас есть фидбек оттуда, и с каждым таким нестабильным релизом этот процесс улучшать. Если в компании есть процессы, которые отслеживают тенденции качества в бете, то все должно становиться только лучше. А юзерам это тоже в плюс — они будут первыми получать фичи. В основном это замотивированные и лояльные вашему продукту пользователи, и они сами захотят протестировать новые вещи, которые появляются в приложении. И даже будут готовы пожертвовать чем-нибудь за это.
Нина Семкина: Мы же понимаем, что когда мы говорим о лояльной аудитории, то она лояльная, пока это не затрагивает ее личные интересы. Мы так можем выкатывать фичи с дополнительными мелкими плюшками, которые даже если упадут, этих пользователей не очень расстроит. Но даже если этот человек подтвердил, что готов взять тестовую версию, но у него что-то серьезное пойдет не так (например, спишутся лишние деньги), то он уже не будет лояльным. И чем больше фирма, тем жестче пользователь отзовется о продукте.
Владимир Генович: А как же early adopter, который любит тебя, как бы компания ни косячила? И, скорее всего, эта компания сможет возместить убытки. Согласись, если мы выкатим какую-нибудь штуку — скажем пользователю: «Слушай, мы очень боимся. И ты можешь потерять 1000 рублей. Но мы тебе возместим». Скорее всего, такой пользователь на свой страх и риск сделает это, и если деньги потеряются, то мы не скажем ему потом: «Ну ты сам виноват». Поэтому, думаю, даже в случае банковского приложения мы можем помочь пользователям.
Дмитрий Жаков: И если у вас бета-тестеров слишком мало, то можно использовать А/Б-тестирование с помощью конфигов включать/выключать какую-нибудь фичу, чтобы в случае падения можно было сразу что-то отключить и протестировать как надо. Как мы помним, в mobile очень сложно откатываться, поэтому перед релизом лучше по максимуму все проверять.
Владимир Генович: Или писать на React Native))
Нина Семкина: Прерву нашу беседу, так как подошло время следующего доклада. Дима, передаю слово тебе.
Дискуссия number three
Нина Семкина: Я бы хотела обратиться к Диме Воронину, чтобы послушать его мнение и про его опыт о том, как они в компании улучшали регрессионное тестирование и когда они вводят тестирование при разработке фич.
Дмитрий Воронин: Мне правда есть чем поделиться. Это пятилетняя история борьбы с ручным регрессом. И это частично продолжение ответа на вопрос, который у нас был между 2 первыми докладами. Этот вопрос про то, как быть, если у тебя есть ручной регресс. Потому что опыт Revolut повторить не у всех получится. Ребята молодцы, что рубанули с плеча, и у них получилось сделать надежно. Для этого нужно иметь много смелости, хорошую культуру разработки и самое важное — понимающих руководителей разработки, для которых такой подход не выглядит диким. Так получается, потому что в нашей работе есть инерция и менять устои, особенно в больших компаниях, бывает сложно. Пример Revolut доказывает, что если это работает, то это как минимум быстрее, чем ручной регресс, и каждый разработчик начинает задавать себе правильные вопросы. То есть он начинает быть ответственным за большую часть релизного цикла, то есть не до того момента, когда он закоммитил изменения, а как любой взрослый инженер, он еще и ведет продукт в релизной стадии.
Что произошло у нас? Мы находились в точке, когда у нас был ручной регресс, который выполняли 5 человек 12 рабочих дней, и без этого мобильное приложение не катилось. Это было в 2015 году. И в тот момент у нас не было ни одного автоматизированного UI-теста. Unit-тесты мы писали практически с самого начала и писали достаточно активно. Вот Владимир в докладе рассказывал про 10 секунд и 1000 тестов — мне это страшно представить, когда мы прошли такой момент в 2014 году. Сейчас у нас 12 000 Unit-тестов, и идут они далеко не 10 секунд, это тоже не бесплатная штука. Даже с учетом того, что все инженеры понимают и пишут тесты, был сложный момент. Все эти Unit-тесты ни грамма не доказывают про баги в продакшене и про то, как приложение себя ведет. То есть тестирование фиксирует поведение, позволяет проще вносить изменения и дает фидбек, правильно ли ты это делаешь. Проблема в том, что есть отдел QA. Конечно, не в нем проблема. Проблема в том, что у них есть задача обеспечить определенный уровень качества. И они привыкли добиваться этого уровня, они берут на себя эту ответственность. И переломить этот момент сложно, если это идет не с самого начала вашего продукта. Какие здесь есть рецепты? Самое правильное — не включать жесткий режим, когда мы всех увольняем и все захватывает автоматизация. Это наверное самый страшный и незрелый подход, который я видел. Что тут плохого? Во-первых, на какое-то время потеряется качество тестирования. Во-вторых, все процессы разрушаются, а новые быстро не строятся.
Что сделали мы? Мы начали оптимизацию с того, что писали UI-тесты, которые заменяют регресс. То есть это полноценные инфраструктурные тесты, которые задевают бэкенд с тестовыми пользователями. И, собственно, результатом этой работы стали, как вы знаете, всякие популярные фреймворки — например, Kaspresso. Это как раз то, что мы закладывали, когда всё начинали. Мы после себя оставили кучу артефактов, которые могут помочь разработчикам. И поэтому входить в тестирование сейчас проще. Также мы положили в опен-сорс различные раннеры, и все желающие могут посмотреть, как мы с ними работаем. Но мы не забывали про ручное тестирование, про его оптимизацию и про то, как эти два отдела начинают сливаться в один эффективный процесс. Наверное, точка Б — это состояние Revolut. Но наша дорога из точки А в точку Б, как и у многих других компаний, занимает долгое время. Сейчас мы на том этапе, когда QA выполняет роль исследователей, они больше погружаются в продукт, занимаются проработкой функциональных требований, пишут автотесты.
Самое интересное про практики улучшения ручного регресса — это impact-анализ. То есть попытка ответить на вопрос: «А что же поменялось в этот релиз?» И что мы можем тестировать, а что со спокойной душой выкатывать на следующие этапы. Impact-анализ — это сложный вопрос, потому что когда у тебя большой релизный цикл, то есть вы релизитесь 2-3 месяца, то impact-анализ ответит тебе всегда одинаково, потому что за такое время вряд ли какую-то часть приложения не потрогали. Но если сократить этот релизный цикл до недели, а еще лучше до дня, то impact-анализ показывает вполне адекватные вещи, оставляет отметки, которые помогут оптимизировать ручной регресс. Мы эту практику применили вполне успешно. Вначале были ошибки, но мы разово сокращали объем ручного тестирования.
Следующая практика — это оптимизация тестовой модели. Как ни странно, но в тестах тоже бывает легаси: тесты написаны, но они могут быть не очень оптимальны, потом туда добавилось что-то еще, а тест-кейсы были не обработаны для этого… При подробном анализе оказалось, что можно сократить в разы количество сценариев тестирования.
Вот эти три направления позволили нам дойти до того, что мы 1 раз в день релизим в бету, раз в неделю это долетает до 100% пользователей, ручного регресса нет. Я надеюсь, эта история побудит к действиям компании, которые недовольны своим состоянием релиза, — чтобы в будущем только нажимать на кнопку «релиз», все катится на пользователей, а все смотрят только на графики.
Юрий Чечёткин: Это, конечно, не только практики Revolut, но и мировые, их применяют Google, Facebook и так далее. Согласен, что это должен быть плавный переход. И когда многие становятся PO или уходят в автоматизированный QA — все это немного размывается, эволюционирует и превращается во что-то сказанное. И в России этот тренд, правда, только начинается. И как ты правильно сказал, он должен быть максимально здоровым.
Нина Семкина: Поступил такой вопрос. У кого где гоняются Unit-тесты? На CI или локально перед пушем?
Юрий Чечёткин: Кажется, что гонять локально — это задача разработчика, то есть насильно этого делать не стоит. Мне очевидно, что должно быть 100% на CI.
Нина Семкина: Спасибо всем участникам за дискуссию! Передаю слово нашему спикеру Диме Манько с его докладом.
Смотрите видео, читайте расшифровку и пишите в комментариях своё мнение на озвученные вопросы. Вместе разберемся: быть или не быть?
Дискуссия number one
Таймкоды
0:56 – Всегда ли нужно вводить тестирование?
2:00 – Зачем тестировать, если нужно скорее выкатывать фичи на рынок?
3:24 – Можно ли тестировать только базовый функционал или одну часть приложения?
5:29 – Критерии тестирования функциональности
7:28 – В какой момент стартапу или аутсорсинговой компании нужно прекратить релизить фичи и начать тратить время на тестирование
Митап сразу начался с горячего — с обсуждений. Поэтому представим участников нашей онлайн-дискуссии:
- Дмитрий Воронин, Lead engineer в команде Speed (Авито).
- Юрий Чечёткин, мобильный разработчик (Revolut)
- Дмитрий Манько, Android-разработчик (Ситимобил)
- Нина Семкина, старший программист (Яндекс.Деньги)
- Владимир Генович, ведущий программист (Яндекс.Деньги)
- Дмитрий Жаков, тестировщик (Яндекс.Деньги)
Нина Семкина: Многие говорят, что тестирование обязательно нужно вводить в проекты… Но все понимают, что это очень дорого. Тратить время разработчиков и кучу ресурсов на то, чтобы покрыть весь код тестами, — это очень дорогое занятие. Неужели тестирование всегда нужно делать?
Дмитрий Манько: А что тестировать собрались?
Нина Семкина: Android-приложение. Когда мне нужно понять, что его 100% нужно тестировать?
Дмитрий Манько: Если рынок не ждет появление какой-либо функциональности, то, с точки зрения разработки или с точки зрения покрытия, тестирование можно упростить или им вообще пренебречь. Все зависит от продукта. Если мы делаем калькулятор с 2 функциями, то серию тест-кейсов мы, скорее всего, прошли и не раз. Таким образом, тесты можно не писать, быстрее выложить на рынок приложение и сократить time-to-market.
Нина Семкина: У нас всегда есть гонка time-to-market, рынок всегда требует кучу фичей, и мы не можем их тормозить. Особенно если речь идет о только-только начинающемся проекте, который нужно выпустить на рынок прямо сейчас, имени у нас никакого нет, мы конкурируем с другими компаниями. Какое нам дело в этот момент до тестирования? Нам нужно снабдить наше приложение фичами и быстрее их выкинуть, а то устареют через 3 недели. Зачем их тестировать?
Дмитрий Воронин: На самом деле скорость разработки в какой-то момент начинает зависеть от тестового покрытия. Если, например, бизнес архитектурно завязан на одном главном экране, где все основные фичи, и туда вносятся изменения много-много раз, то без тестов там можно начать двигаться медленнее даже при большом «фичепроводе». Кажется, как только есть сигналы, что вы часто возвращаетесь на регрессе обратно, то есть повод задуматься над тем, что с покрытием что-то не так и вы не предпринимаете реактивных действий. Например, что-то часто ломается — значит, это место не тестируется как надо.
Нина Семкина: Могу ли я сделать такой вывод, что нужно постоянно тестировать только базовый функционал, а фичи подключать «одной точкой». Пусть эти отдельные фичи будут с багами, но, возможно, они сегодня есть, а завтра их нет. Можно ли тестировать только одну часть приложения?
Дмитрий Манько: Я бы скорее сказал — ключевые части стоит протестировать. То, что важно с точки зрения бизнеса для этого продукта. А если есть фичи с багами, они где-то отдельно расположены и не влияют на что-то общее, то в идеале их закрыть удаленным тогглом. И если по аналитике ты видишь, что там действительно есть баги и пользователи жалуются, то эту фичу выключить.
Дмитрий Воронин: Дима хорошую тему затронул, что тесты — это не единственный инструмент для контроля качества, который есть у разработчика. Нужно всегда помнить, что помимо unit и интеграционных тестов, ручного тестирования, всегда есть и должен быть мониторинг. И есть способы выкатки и откатов своих изменений. Если все эти инженерные практики у тебя есть, то в принципе ты можешь пренебрегать одними инструментами в пользу других, если скорость от этого выигрывает. Но в целом всегда считается хорошим тоном, если у разработчика есть культура тестирования — то, что ему комфортнее и надежнее доставлять изменения с тем, что у него протестированы те функциональности, которые он должен выполнить. В нашей компании принято оставлять такой код, в который потом ты сможешь вносить изменения легко, и быстрым запуском тестов понять, что ты не испортил то, что уже было.
Нина Семкина: В чате пишут, что тестировать нужно то, что приносит доход. И когда затраты на тестирование меньше, чем возможные убытки от нерабочего функционала. В принципе это неплохой критерий, чтобы понять, что именно нужно тестировать. А вы могли бы назвать еще какие-то критерии тестирования конкретной функциональности?
Дмитрий Манько: Критерии можно выявить при помощи аналитики. К примеру, если зафиксировать наиболее часто используемые функции, то их тоже желательно тестировать, чтобы пользователи как можно меньше встречались с багами. Если баги находятся в редких местах, то это небольшая проблема. А если бан на экране авторизации — возможно, он не critical, но все же баг, который увидят все. И это уже репутационный риск.
Дмитрий Жаков: Тестирование в целом вообще нужно. Не надо забывать, что тестирование — это проверка тех требований, которые мы предъявляем к продукту. Если что-то не соответствует требованиям, то это проблема, баг, issue. Все тест-кейсы и тестирование можно автоматизировать, и если времени не хватает, то вначале стоит проверять критичные моменты, а потом все остальное. Например, если у вас завтра релиз и бизнес хочет фичу именно завтра, то вы проверяете самый критичный функционал. А если времени достаточно, то можете позволить себе проверить medium, low-кейсы. Тут больше вопрос, будет ли ваше тестирование мануальным или автоматизированным. Будут ли это метрики или UI-тестирование, полностью проверяемое роботом.
Нина Семкина: Мы все сейчас говорим от лица крупных компаний, где много ресурсов и возможностей. А если рассмотреть точку зрения мелких фирм, стартапов, у которых время и ресурсы ограничены. Думаю, что там поначалу все будут жертвовать тестированием. В какой момент мы можем понять, что это тот критический рубеж, когда мы должны остановиться и перестать катить фичи и потратить ресурсы на тестирование?
Дмитрий Манько: Могу поделиться своим мнением, так как я выходец из аутсорсинговой компании. Аутсорсинг — это в первую очередь про то, где продают человеко-часы, и там действительно тестирование дорогое. Иногда оно стоит дороже, чем разработать саму функциональность. Такие аутсорсинговые компании, когда заказчик ждет приложение и «пинает под бок», не славятся тестированием. В нашей команде мы столкнулись со следующей ситуацией. Продукт — меню для баров, где применялись акции по огромному количеству кейсов (день рождение, 2 по цене 1, студенческие и прочее). И мы заметили, что эта функциональность акций ломалась каждый месяц в течение года. И вот тогда Unit-тестирование описало все кейсы в идеале. Мы поняли, как все работает (было около 70 тест-кейсов). Мы победили этот продукт, но, конечно, не везде так получилось бы сделать.
Юрий Чечёткин: Мой опыт работы в крупных компаниях — Яндекс, Альфа-Банк, Revolut — в финтехе, где критичность любого бага просто зашкаливает. При этом у меня есть опыт в стартапе, и даже там тестирование было абсолютно нужно. Считаю, что неважно, стартап это или нет, потому что разработчик должен отвечать за свой код, и тесты — это гарантия того, что этот код работает. Разработчик — это в первую очередь инженер, который отвечает за разрабатываемый продукт. Поэтому тесты писать нужно не потому, что надо, а потому, что они должны тебе помочь. Если это тесты, написанные для галочки, то это может тормозить разработку. А если тесты тебе нужны и ты это сам понимаешь, то их обязательно нужно писать. Если разработчик пишет код и уверен, что он работает без тестов, — это риск, и это его выбор. А я все-таки считаю, что разработчик не должен так рисковать и должен прикрывать себя и покрывать все тестами.
Нина Семкина: Итак, мы решили, что нужно как-то тестировать свой код, разберем эту тему подробнее. Передаю слово Владимиру Геновичу с его докладом.
Дискуссия number two
Таймкоды
0:09 – Как снять регрессионную нагрузку с QA перед релизами? Есть ли в компаниях стратегия по улучшению стабильности приложения?
4:25 – Есть ли смысл использовать моки или фейк-объекты в UI-тестах
8:05 – Тестирование на пользователях: допустимо или нет?
Нина Семкина: Во время доклада к нам поступил вопрос в чате, и именно с него хотелось бы продолжить наше обсуждение. Как снять регрессионную нагрузку с QA перед релизами? Какие практики в выборе мест для тестирования применяют наши спикеры? Есть ли в компаниях стратегия по улучшению стабильности приложения и разгрузки QA-специалистов?
Дмитрий Жаков: У нас стратегия такая, что мы тестируем всё. Потому что мы являемся последним рубежом, как сотрудники перед пользователями. Поэтому отдаем только такое приложение клиенту, которое стабильно работает всегда и везде. Вопрос только в скорости. Изначально ручной прогон у нас занимал много времени — до недели. Но благодаря автоматизации мы достигли того, что релиз длится в среднем сутки. Поэтому если вы разрабатываете какой-либо функционал, то нужно договориться, что или вы или тестировщики будут сразу писать автотесты. И какие-то mobile specific кейсы, которые вы не можете автоматизировать, останется проверить только на регрессе, а все остальное проверит робот. Тем самым вы разгрузите тестировщиков, они будут заниматься более интересной, исследовательской работой, а всю рутину — прокликивание сценариев вы отдаете роботу.
Юрий Чечеткин: Большинство крупных компаний отказываются от QA, мануального тестирования. Это не то чтобы революционный путь, но немного пережиток прошлого. И, например, в моей компании, в которой я сейчас работаю, такое слово, как регресс, даже не произносится. Отдела QA у нас нет вообще.
Владимир Генович: Вы его автоматизировали, наверное?
Юрий Чечёткин: Не совсем так, он был только на начальных этапах проекта, а затем его не стало вовсе.
Владимир Генович: Вы же гоняете UI-тесты?
Юрий Чечёткин: UI-тесты есть, конечно.
Владимир Генович: И Unit-тесты? Так запуск этих тестов при выпуске релиза — это разве не регресс?
Юрий Чечёткин: Да, это регресс, но того мануального тестирования, о котором привыкли говорить, нет. И это довольно интересный подход. Он отрезвляет и превращает разработчика из «ребенка», который пишет код и отдает его тестировщикам, в более взрослого и самостоятельного инженера, который сам отвечает за свой код. Что касается визуальных вещей — ревью может проводить дизайнер или PO. И есть такие штуки, как скриншот-тесты, — например, у Facebook. Так что кажется, что сейчас продуктовые компании могут обойтись и без QA. А сами тестировщики могут заниматься более интересной работой. Конечно, немного другая история в аутсорсе — там продаются человеко-часы, и QA может продаваться как дополнительная услуга.
Дмитрий Жаков: Получается, у вас есть регресс, просто он отдан на автоматизацию, и у вас есть люди, которые занимаются исследовательской работой вашего приложения. Тестирование может быть не только UI, но и другим.
Юрий Чечёткин: Да, например, тестирование на пользователях.
Нина Семкина: Перед тем, как мы затронем это очень опасную тему, я бы хотела зачитать следующий вопрос от наших слушателей. Есть ли смысл использовать моки или фейк-объекты в UI-тестах?
Дмитрий Воронин: Есть смысл, и без них никуда. Потому что UI-тесты с полной интеграцией — это очень ненадежная штука. И вы никогда не сможете полагаться на тест, в котором 30 систем, в каждой из которой по куче точек отказа будет запускаться пул-реквест. Такие тесты нежизнеспособны. И никто ни в одной компании не смог такие штуки заставить работать. Поэтому UI-тесты — это проклятье мобильной разработки. Если есть возможность, то лучше тестировать без UI. Но из-за того, что мы вынуждены жить с фреймворком, а единственная альтернатива — это какой-нибудь роболетрик, а в iOS даже и такого нет. И чтобы проверить взаимодействие хотя бы с одной из важных для нас систем, мы запускаем всё на устройстве. UI здесь постольку, поскольку по нашей незрелости разработки мы хотим захватить по максимуму, чтобы проверить, как нажимает юзер, — нам так спокойнее. Мне кажется, что через какое-то время это уйдет в прошлое и мы перестанем бояться моков, нажатия и не будем бороться с системой, чтобы проверять все как надо, потому что все равно мы все не проверим. Могут быть визуальные баги, которые никакими UI-тестами не проверятся. Поэтому считаю, что мокировать и в UI-тестах можно и нужно, и главная цель у этого — повысить стабильность этого инструмента, довести его до такого состояния, чтобы он приносил пользу. А реальная польза в данном случае — убедиться в отсутствии регрессий. И любой инструмент, который флакует, превращается во второе «Д» из предыдущего доклада Владимира Геновича, когда мы перестаем доверять. Это происходит тогда, когда нам в тест начинают прилетать случайные значения в огромном количестве. И такой тест не дает никакой уверенности в себе, а только дает ложную надежду, что что-то протестировано.
Дмитрий Жаков: У нас около 70% кейсов автоматизированы, и они не используют ни одного мока на приложении. Возможно, их проще перенести на бэкенд. Например, если это относится к номеру карточки, то вы ожидаете, что у вас 3DS не запросится. То есть приложение не знает, что оно замокано. Думаю, что это проблема инфраструктуры.
Нина Семкина: Перед тем как перейдем к следующему докладу, я бы хотела, чтобы мы упомянули одну скользкую тему — тестирование на пользователях. Многие этим грешат: всегда хочется и колется… Что вы по этому поводу думаете? Можно ли себе позволять раскатывать на пользователей потихонечку, собирать с них краши и фиксить себе. А протестировав на них, выкатывать хорошие полноценные версии. Или же это вообще никак недопустимо? Или есть разумные границы?
Юрий Чечёткин: У нас в Revolut подобное немного практикуется в том плане, что это идет не прямо на бою, но на реальных пользователях. Демо — это тоже некоторое тестирование на пользователях, и во время демо возникают вопросы по флоу и так далее. На этом этапе могут быть вопросы по дизайну и по общей механике. Помимо прочего есть внутренняя раскатка — компания большая, больше 1000 человек, и мы можем раскатывать среди коллег. Это тестирование на пользователях, но не вовне, и кажется, что оно безопасное. А дальше это может быть раскатка на маленький процент реальных пользователей вовне, но с возможностью закрыть эту фичу тогглом. Как вы думаете, что может пойти не так на этих этапах?
Дмитрий Манько: В наших реалиях все может пойти не так. Как бы мы ни старались провести эти этапы хорошо, в любом случае проскакивают кейсы, когда нам нужно следить за аналитикой крашей. Релиз не заканчивается на том, что мы отправили его в store, все этапы прошли, у нас всё ОК. Нужно продолжать смотреть, как ведет себя приложение.
Юрий Чечёткин: Однозначно да. В нашем случае мы имеем демо, внутреннюю раскатку и тестирование на 5% пользователей вместо ручного тестирования. Конечно, после релиза фичи нужно посмотреть. Раскатка не должна быть на 100% сразу — это главный защитный механизм.
Дмитрий Воронин: Этический вопрос тестирования на пользователях за нас решает Google. У Apple вроде такого нет. Есть специальные каналы распространения, как вы знаете (альфа, бета… production). Каждый может вступить в бета-тестирование, и он соглашается со вполне понятной формой, в которой говорится, что он в здравом уме соглашается с тем, что может получить нестабильную версию продукта. И таким образом он хочет поволонтерить и помочь компании сделать продукт лучше. Как только мы открыто говорим человеку о таком, думаю, этот вопрос должен сниматься и мы не должны бояться раскатывать туда версию, в которой не уверены на 100%. А еще лучше, когда у нас есть фидбек оттуда, и с каждым таким нестабильным релизом этот процесс улучшать. Если в компании есть процессы, которые отслеживают тенденции качества в бете, то все должно становиться только лучше. А юзерам это тоже в плюс — они будут первыми получать фичи. В основном это замотивированные и лояльные вашему продукту пользователи, и они сами захотят протестировать новые вещи, которые появляются в приложении. И даже будут готовы пожертвовать чем-нибудь за это.
Нина Семкина: Мы же понимаем, что когда мы говорим о лояльной аудитории, то она лояльная, пока это не затрагивает ее личные интересы. Мы так можем выкатывать фичи с дополнительными мелкими плюшками, которые даже если упадут, этих пользователей не очень расстроит. Но даже если этот человек подтвердил, что готов взять тестовую версию, но у него что-то серьезное пойдет не так (например, спишутся лишние деньги), то он уже не будет лояльным. И чем больше фирма, тем жестче пользователь отзовется о продукте.
Владимир Генович: А как же early adopter, который любит тебя, как бы компания ни косячила? И, скорее всего, эта компания сможет возместить убытки. Согласись, если мы выкатим какую-нибудь штуку — скажем пользователю: «Слушай, мы очень боимся. И ты можешь потерять 1000 рублей. Но мы тебе возместим». Скорее всего, такой пользователь на свой страх и риск сделает это, и если деньги потеряются, то мы не скажем ему потом: «Ну ты сам виноват». Поэтому, думаю, даже в случае банковского приложения мы можем помочь пользователям.
Дмитрий Жаков: И если у вас бета-тестеров слишком мало, то можно использовать А/Б-тестирование с помощью конфигов включать/выключать какую-нибудь фичу, чтобы в случае падения можно было сразу что-то отключить и протестировать как надо. Как мы помним, в mobile очень сложно откатываться, поэтому перед релизом лучше по максимуму все проверять.
Владимир Генович: Или писать на React Native))
Нина Семкина: Прерву нашу беседу, так как подошло время следующего доклада. Дима, передаю слово тебе.
Дискуссия number three
Таймкоды
0:05 – Как улучшать регрессионное тестирование? Как и когда вводят тестирование при разработке фич (опыт Авито)
10:43 – Где гоняются Unit-тесты: на CI или локально перед пушом?
Нина Семкина: Я бы хотела обратиться к Диме Воронину, чтобы послушать его мнение и про его опыт о том, как они в компании улучшали регрессионное тестирование и когда они вводят тестирование при разработке фич.
Дмитрий Воронин: Мне правда есть чем поделиться. Это пятилетняя история борьбы с ручным регрессом. И это частично продолжение ответа на вопрос, который у нас был между 2 первыми докладами. Этот вопрос про то, как быть, если у тебя есть ручной регресс. Потому что опыт Revolut повторить не у всех получится. Ребята молодцы, что рубанули с плеча, и у них получилось сделать надежно. Для этого нужно иметь много смелости, хорошую культуру разработки и самое важное — понимающих руководителей разработки, для которых такой подход не выглядит диким. Так получается, потому что в нашей работе есть инерция и менять устои, особенно в больших компаниях, бывает сложно. Пример Revolut доказывает, что если это работает, то это как минимум быстрее, чем ручной регресс, и каждый разработчик начинает задавать себе правильные вопросы. То есть он начинает быть ответственным за большую часть релизного цикла, то есть не до того момента, когда он закоммитил изменения, а как любой взрослый инженер, он еще и ведет продукт в релизной стадии.
Что произошло у нас? Мы находились в точке, когда у нас был ручной регресс, который выполняли 5 человек 12 рабочих дней, и без этого мобильное приложение не катилось. Это было в 2015 году. И в тот момент у нас не было ни одного автоматизированного UI-теста. Unit-тесты мы писали практически с самого начала и писали достаточно активно. Вот Владимир в докладе рассказывал про 10 секунд и 1000 тестов — мне это страшно представить, когда мы прошли такой момент в 2014 году. Сейчас у нас 12 000 Unit-тестов, и идут они далеко не 10 секунд, это тоже не бесплатная штука. Даже с учетом того, что все инженеры понимают и пишут тесты, был сложный момент. Все эти Unit-тесты ни грамма не доказывают про баги в продакшене и про то, как приложение себя ведет. То есть тестирование фиксирует поведение, позволяет проще вносить изменения и дает фидбек, правильно ли ты это делаешь. Проблема в том, что есть отдел QA. Конечно, не в нем проблема. Проблема в том, что у них есть задача обеспечить определенный уровень качества. И они привыкли добиваться этого уровня, они берут на себя эту ответственность. И переломить этот момент сложно, если это идет не с самого начала вашего продукта. Какие здесь есть рецепты? Самое правильное — не включать жесткий режим, когда мы всех увольняем и все захватывает автоматизация. Это наверное самый страшный и незрелый подход, который я видел. Что тут плохого? Во-первых, на какое-то время потеряется качество тестирования. Во-вторых, все процессы разрушаются, а новые быстро не строятся.
Что сделали мы? Мы начали оптимизацию с того, что писали UI-тесты, которые заменяют регресс. То есть это полноценные инфраструктурные тесты, которые задевают бэкенд с тестовыми пользователями. И, собственно, результатом этой работы стали, как вы знаете, всякие популярные фреймворки — например, Kaspresso. Это как раз то, что мы закладывали, когда всё начинали. Мы после себя оставили кучу артефактов, которые могут помочь разработчикам. И поэтому входить в тестирование сейчас проще. Также мы положили в опен-сорс различные раннеры, и все желающие могут посмотреть, как мы с ними работаем. Но мы не забывали про ручное тестирование, про его оптимизацию и про то, как эти два отдела начинают сливаться в один эффективный процесс. Наверное, точка Б — это состояние Revolut. Но наша дорога из точки А в точку Б, как и у многих других компаний, занимает долгое время. Сейчас мы на том этапе, когда QA выполняет роль исследователей, они больше погружаются в продукт, занимаются проработкой функциональных требований, пишут автотесты.
Самое интересное про практики улучшения ручного регресса — это impact-анализ. То есть попытка ответить на вопрос: «А что же поменялось в этот релиз?» И что мы можем тестировать, а что со спокойной душой выкатывать на следующие этапы. Impact-анализ — это сложный вопрос, потому что когда у тебя большой релизный цикл, то есть вы релизитесь 2-3 месяца, то impact-анализ ответит тебе всегда одинаково, потому что за такое время вряд ли какую-то часть приложения не потрогали. Но если сократить этот релизный цикл до недели, а еще лучше до дня, то impact-анализ показывает вполне адекватные вещи, оставляет отметки, которые помогут оптимизировать ручной регресс. Мы эту практику применили вполне успешно. Вначале были ошибки, но мы разово сокращали объем ручного тестирования.
Следующая практика — это оптимизация тестовой модели. Как ни странно, но в тестах тоже бывает легаси: тесты написаны, но они могут быть не очень оптимальны, потом туда добавилось что-то еще, а тест-кейсы были не обработаны для этого… При подробном анализе оказалось, что можно сократить в разы количество сценариев тестирования.
Вот эти три направления позволили нам дойти до того, что мы 1 раз в день релизим в бету, раз в неделю это долетает до 100% пользователей, ручного регресса нет. Я надеюсь, эта история побудит к действиям компании, которые недовольны своим состоянием релиза, — чтобы в будущем только нажимать на кнопку «релиз», все катится на пользователей, а все смотрят только на графики.
Юрий Чечёткин: Это, конечно, не только практики Revolut, но и мировые, их применяют Google, Facebook и так далее. Согласен, что это должен быть плавный переход. И когда многие становятся PO или уходят в автоматизированный QA — все это немного размывается, эволюционирует и превращается во что-то сказанное. И в России этот тренд, правда, только начинается. И как ты правильно сказал, он должен быть максимально здоровым.
Нина Семкина: Поступил такой вопрос. У кого где гоняются Unit-тесты? На CI или локально перед пушем?
Юрий Чечёткин: Кажется, что гонять локально — это задача разработчика, то есть насильно этого делать не стоит. Мне очевидно, что должно быть 100% на CI.
Нина Семкина: Спасибо всем участникам за дискуссию! Передаю слово нашему спикеру Диме Манько с его докладом.
Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.
Тестируете ли вы свой код?
100% Да, думаю так должны делать все6
0% Нет, а разве это должен делать я?0
0% Свой вариант в комментарии0
Проголосовали 6 пользователей. Воздержались 3 пользователя.
