Для чего используются smoke тесты
Как протестировать идею продукта с помощью смоук-тестирования
Представьте, что вам в голову пришла идея нового товара или новой функции (компонента) уже имеющегося продукта. Идея кажется замечательной, но прежде чем вы потратите десятки часов и несколько тысяч долларов на ее реализацию, вам необходимо ее оценить и проверить. Другими словами, вы должны убедиться, что аудитория будет в таком же восторге от вашего замысла, как и вы.
Возникает вопрос: как проверить идею продукта, не затрачивая при этом слишком много времени и ресурсов? Ответ прост: с помощью смоук-теста.
Что такое смоук-тест?
Сам термин «смоук-тест» был в недавнем времени позаимствован из области компьютерного программирования, где он обозначает минимальный набор тестов, главная цель которых — выяснить, корректно ли исполняются основные функции программы или приложения, нет ли каких-либо явных ошибок, наличие которых мешает более глубоким тестам.
Используя это определение, можно сказать, что смоук-тестирование дает ответы на такие вопросы:
Иными словами, все ли работает так, как планировалось? Такие тесты, как правило, не занимают много времени, но при этом проводятся на протяжении всего процесса разработки программного обеспечения.
В мире маркетинга смоук-тест имеет аналогичный смысл, однако вместо того чтобы фокусироваться на том, все ли компоненты системы работают правильно (как это делают программисты), маркетологи хотят знать, принесет ли им грядущий продукт прибыль?
Тревор Лорбир (Trevor Lohrbeer) из консалтингового агентства Teikametrics & Lab Escape определяет данный метод, как «способ тестирования восприятия товара рынком до создания самого продукта».
Вы можете вложить колоссальные средства в разработку и производство продукта, не зная, будет ли он продаваться или принесет убытки вашей компании. Смоук-тест способен помочь вам найти ответ на этот вопрос.
Доминик Кориелл (Dominic Coryell) из GIMME GROWTH поясняет:
«С помощью смоук-теста вы сможете довольно быстро сформировать дорожную карту вашего продукта. То, что мы пытаемся сделать — доказать, что список нереализованных требований к продукту (product backlog) — это потенциал его роста. Ключевые действия: проверить, узнать, повторить».
Зачем маркетологам смоук-тесты?
Рассмотрим две ситуации.
1. У вас есть новая бизнес-идея, которая кажется довольно перспективной, и вы хотите ее развить.
2. У вас есть идея нового свойства, характеристики товара, и вы также возлагаете на нее большие надежды и планируете реализовать.
В обоих случаях вам придется затратить кучу времени и денег. Вам также, вероятно, потребуется помощь. Вы будете искать соучредителя или наймете команду разработчиков.
Но что, если эта идея после нескольких месяцев разработки и тысяч долларов вложений не оправдает себя? Занавес.
Маркетологи используют тесты, чтобы избежать развития именно такого сценария. Дэн Мартелл (Dan Martell), основатель пяти компаний, который в настоящее время помогает другим предпринимателям развивать свои высокотехнологичные продукты, объясняет:
«Люди бывают сильно воодушевлены появившейся у них идеей и бросают все силы на разработку и создание продукта, только чтобы через 6 месяцев понять, что он никому не нужен и их энтузиазма никто не разделяет. Перед запуском вам необходимо пройти 4 этапа:
1. Идея: проблема, боль, страсть.
2. Валидационные исследования.
3. Кликабельный прототип.
4. Предпродажи.
Я использовал этот подход для построения всех моих кампаний — и не важно, было ли это потребительским приложением или решением для брендов из Fortune 500 — он должен быть соблюден в любом случае».
Четыре этапа Дэна можно представить в виде следующих действий:
1. Как выбрать правильную идею? Выберите проблему, с которой вы сталкивались на личном опыте, выберите продукт, который обязателен к покупке (а не тот, который просто «было бы неплохо иметь»), выберите что-то, чем вы по-настоящему увлечены.
2. Найдите клиентов, пользующихся продуктом вашего конкурента, и проведите валидационное испытание. Ваши друзья скажут вам, что ваша идея отличная, но лучше остановиться на тех людях, которые уже платят за аналогичный продукт.
3. Разработайте 3 ключевых признака идеи, но не всего продукта. Что можно создать в течение 6-недельного спринта?
4. Найдите людей, которые оформят предзаказ. Они помогут вам довести разработку до конца.
Этот процесс обязателен и применим не только к стартапам или начинающим предпринимателям. Он должен быть взят на вооружение и в крупных компаниях, которые также время от времени выпускают на рынок новые продукты и нуждаются в предварительном тестировании новых бизнес-идей, функций и т. д.
Гибкое мышление — вот что по-настоящему важно.
Вышесказанное предполагает, что концепция минимально жизнеспособного продукта (MVP) уже неактуальна. Если вы маркетолог, который заинтересован в быстрых экспериментах и росте эффективности, вы в правильном месте.
Вот как это объясняет команда разработчиков Spotify:
Как создать минимально жизнеспособный продукт? Вариант сверху — ошибочен, вариант снизу — верен
Самое распространенное возражение смоук-тесту заключается в том, что, якобы, клиенты будут расстроены недоступностью полного функционала. А ведь совершенно неразумно не оправдывать клиентских ожиданий, верно?
Эрик Рис (Eric Ries), CEO в Long-Term Stock Exchange и автор «Бережливого стартапа» (Lean Startup), объясняет, почему это не имеет отношения к гибким командам:
«Если вы обеспокоены тем, что разочаруете некоторых своих клиентов — не стоит. Как правило, во время проведения экспериментов коэффициент конверсии равен нулю. Это означает, что проведением испытаний никого из ваших потенциальных покупателей вы не расстроите.
И если все же вам удастся привлечь небольшую группу людей, вы всегда можете принести им персональные извинения. Если таких людей будет сотни и тысячи — тут впору радоваться, а не горевать. Будем надеяться, что некоторые из них простят вам эту маленькую хитрость».
Пример: Pijon Box
Рассмотрим кейс компании Pijon Box, которая предоставляет пакеты услуг в области здравоохранения для родителей студентов. Руководство сервиса хотело провести тест функции «Add to Box», которая позволяла клиентам добавлять больше продуктов в их пакеты услуг.
Вот сколько времени заняла бы разработка этой функции:
Планирование новой функции — 1 неделя. Разработка новой функции — две недели. Тест и запуск новой функции — 1 неделя
Конечно, если бы разработчики Pijon Box пошли этим маршрутом, они потратили бы месяц на разработку и не уложились в срок до конца апреля.
Поэтому они опробовали смоук-тест:
Планирование: от идеи до метода тестирования — 1 час. Запуск — в этот же день. Генерация прибыли
Они выяснили, какие продукты могли бы дополнить опыт покупателей, поместили информацию о них в электронном письме и разослали его своим клиентам. Если клиент кликал по ссылке, разработчики вручную отвечали ему и уведомляли соответствующих менеджеров.
Каков результат? 9,55% перешли по ссылке в письме и приняли предложение. Ежемесячная валовая прибыль выросла на 45%, предельная валовая прибыль компании повысилась на 357%.
Не так уж плохо для одного дня работы. Идея была подтверждена — теперь компания, не опасаясь пустой траты ресурсов, реализует ее в полном объеме.
Пример: Flowtown
Рассмотрим еще один пример от компании Flowtown. По словам Дэна, который принимал участие в проведении смоук-тестов, компания является образцом минимального экономичного жизнеспособного предложения (MEVO):
«Сначала создайте MEVO.
Можно сказать так: «Я собираюсь разработать оффер, по-настоящему ценное предложение с минимальным числом функций, достаточных для того, чтобы кто-то решил приобрести этот продукт. Затем я создам посадочную страницу и приложу все усилия, чтобы убедить подписаться всех посетителей, даже если продукт все еще будет на стадии разработки».
Именно такой подход я исповедую в своей компании, Flowtown. Даже если у меня не будет продукта, а люди вдруг зарегистрируются, я просто скажу им: «Эй, мы еще в самом начале. Мы будем продвигаться вперед постепенно, но с вашей кредитки не будет снято ни одного доллара. Когда мы будем готовы, мы дадим вам знать».
Это и есть самая настоящая валидация».
Вот как выглядел Flowtown в феврале 2009 года:
Все верно, это обслуживающая компания. После трех месяцев работы с 15+ клиентами они решили использовать все отзывы, которые им удалось собрать, во благо улучшения продукта.
В итоге за три месяца они смогли привлечь только одного клиента. Тогда они начали проводить множество смоук-тестов:
Наконец, они прибыли сюда:
В самый первый день у них сразу появился первый клиент. Затем наступила эпоха роста.
Два года спустя они были приобретены Demandforce.
Что следует тестировать в первую очередь?
Предположим, что с вами случился один из двух сценариев:
1. У вас есть дюжина бизнес-идей, которые вы бы хотели протестировать.
2. У вас есть масса идей нового функционала для имеющегося продукта, которые вы были бы также не прочь протестировать.
Как решить, что следует подвергнуть проверке в первую очередь?
Дерек Сиверс (Derek Sivers), американский предприниматель, предлагает подвергнуть смоук-тесту сначала самое рискованное предложение.
Также первыми в списке могут идти:
1. Идеи сильного воздействия. Если вы устанавливаете приоритетность планируемых экспериментов, вы, вероятно, уже знаете, каких результатов можно ждать от каждого испытания в случае его положительного исхода. Первыми должны идти те, эффект от которых будет наиболее весомым.
2. Идеи, которые откладывались слишком долго. Проведите смоук-тест и, наконец, отпустите их.
6-ступенчатое смоук-тестирование
В своей презентации Доминик поведал о 6 этапах смоук-тестирования, которые используются многими разработчиками и повсеместно считаются наиболее исчерпывающими.
Шаг 1: Определите необходимые доказательства
Как и большинство других тестов, смоук-тестирование начинается с формулировки гипотезы. Если я делаю X, я ожидаю, что произойдет Y.
Шаг 2: Разработка эксперимента без привлечения инженеров
Смысл проведения смоук-теста в том, чтобы ограничить объем времени и денег, вложенных в продукт до его валидации. Поэтому смоук-тест должен быть проведен без помощи программистов и разработчиков.
Шаг 3: Обеспечьте трафик, необходимый для проведения эксперимента
Как только вы подготовите смоук-тест к запуску, первое, что вам понадобится — это трафик, и этот трафик должен быть правильным.
Вот как определяет правильность собранной аудитории Доминик:
«Я не знаю лучшего способа поиска правильной аудитории для теста, кроме наблюдения за тем, кто делится моим предложением в социальных сетях, потому как если люди делятся этой информацией со своими друзьями, значит, они верят в идею, верят в вас.
Это помогает направлять аудиторию, которую вы создаете. Так, на Facebook, если люди не рассказывают о вашем предложении на своих страницах после перехода на него по платному объявлению, то, вероятно, это не ваша аудитория, тогда как люди, пришедшие с поисковой рекламы, наверняка мотивированы сильнее.
Это помогает понять, куда вкладывать свои средства, в какой канал».
Во время поиска трафика для проведения смоук-тестов Эрик Рис обращается к помощи AdWords:
«Если вы хотите запустить какой-либо онлайн-сервис, а проводить поддельные кампании в AdWords для его проверки не стали, вы просто сошли с ума. Это тот вывод, к которому я пришел после просмотра массы онлайн-продуктов, так и не сумевших привлечь покупателей.
Просто убедитесь, что выбрали максимальный дневной бюджет, который позволит вам запустить кампанию сразу на несколько недель. Я бы нацеливался на цифру, не превышающую 100 кликов в день — и в течение недели или, может быть, двух, вы соберете неплохую статистику.
Вам следует обратить пристальное внимание на следующие данные: процент покупателей, прошедших весь путь от посадочной страницы до завершения регистрации, кликабельность объявлений по разным ключевым словам и показатель отказов для целевой страницы по разным ключевым запросам».
Если вы тестируете какую-то новую функцию продукта, то, вероятно, у вас уже есть сформировавшийся пул пользователей, и вам потребуется просто задействовать их в своем тесте. Возможно, вы захотите рассмотреть вопрос об использовании сегментации. Например, можете направить на тест только активных пользователей вашего сервиса.
Какой бы маршрут вы ни выбрали, главное быть уверенным в двух вещах:
1. Вы обратились к правильной аудитории. Самый лучший в мире продукт с треском провалится, если будет предложен не тем людям.
2. Вы сгенерировали достаточно трафика, чтобы сделать правильный выбор. Если вы достаточно крупная компания, чтобы проводить сплит-тесты, используйте калькулятор для расчета размера выборки. Если вы небольшая компания, то нацеливайтесь на получение 100 кликов в день на протяжении двух недель, как советует Эрик Рис.
Шаг 4: Определите ключевые показатели и измерьте их
Этот шаг достаточно очевиден, но потрудитесь заранее проверить, что вы отслеживаете все ключевые показатели. Вы должны знать, откуда приходят люди, как они ведут себя на каждом этапе воронки продаж, какие устройства они используют и т. д.
Выберите те показатели, которые релевантны доказательствам, установленным на первом шаге.
Шаг 5: Анализ результатов и проведение повторных тестов, оптимизация
Если вы попали в список тех, кому посчастливилось тестировать идею с нуля, у вас, вероятно, нет трафика (и вы не можете позволить себе этот трафик), чтобы сделать ваш тест статистически значимым.
Но это не значит, что вы не можете запустить смоук-тестирование. Это просто означает, что ваш тест не будет идеальным и наверняка будут допущены ошибки, так что результаты окажутся не самыми достоверными. (Думайте о нем, как о некой форме эвристического анализа, например).
Даже если вы можете получить статистически значимый результат, всегда существует вероятность, что результат будет недостоверным.
Здесь-то и вступают в игру A/B-тестирование и неформальные итерации. Эрик объясняет свой итерационный процесс:
«Используйте Google Optimizer, чтобы попробовать в деле разные посадочные страницы (даже радикально отличающиеся друг от друга) и определить, оказывают ли разные способы представления вашего продукта влияние на коэффициент конверсии.
Если вам удается получить тот показатель конверсии, который вы намеревались достигнуть, попробуйте попросить клиента произвести оплату.
Если это сведет конверсию к нулю, это вовсе не значит, что у вас нет бизнеса. Дело в том, что продукты, которые по-настоящему решают какую-либо серьезную проблему, обычно могут найти некоторое количество дальновидных покупателей, которые оформят предзаказ только на основе того видения, которое вы продаете.
Если вы не сможете найти вообще никого, вполне возможно, что вы все еще не определились с тем, кем является ваш покупатель».
Пример: Suprizr
Suprizr — это сервис, смысл которого в доставке блюд, приготовленных на основе ваших предпочтений. Вот как выглядела посадочная страница до проведения тестов:
Процент полученных электронных адресов был ниже 3%. Это тот самый момент, где важность проведения тестов становится очевидной. Низкий уровень конверсии может быть свидетельством того, что сама идея далека от совершенства и не востребована аудиторией.
Но вместо того, чтобы отказаться от этой идеи вовсе, Suprizr изменили свой подход, запросив сначала только индекс клиента:
Как только посетитель вводил свой индекс, он видел сообщение, в котором Suprizr приносила извинения за то, что сервис еще не начал обслуживать их район, но вот-вот начнет, и если человек хочет получить уведомление о запуске, он должен оставить адрес электронной почты для связи:
Какой результат? 30% посетителей ввели свой индекс, 25% оставили электронную почту, а 10% поделились информацией о сайте.
Бывает, что провести смоук-тест так, как вы планировали, с первой попытки не получается. Продолжайте итерации до полного отказа от идеи.
Шаг 6: примите решение
Некоторые из вас могут быть в состоянии позволить себе статистически значимый набор данных, некоторые — нет. Независимо от вашей ситуации, в конце концов вам придется принять судьбоносное решение.
Было бы неплохо установить конкретные сроки для пятого шага, поскольку анализ и итерации могут продолжаться бесконечно, а результаты смоук-теста должны быть получены как можно раньше.
Работайте с данными, которые у вас на руках, примите решение и двигайтесь дальше.
Заключение
Как и при проведении регулярных сплит-тестов, смоук-тесты приведут вас к положительным итогам, даже если ваш продукт вдруг окажется никому не нужным.
«Даже если ваша идея провалится, вы все равно в числе победителей. Ведь вы не будете чувствовать себя командой, потратившей зря столько времени и ресурсов. К тому же, иначе вы бы не узнали больше о своих покупателях» — утверждает Доминик.
На какие вопросы еще можно получить ответ:
Смоук-тест как инструмент валидации бизнес-идей обязателен для использования не только предпринимателями и стартаперами, но и крупными компаниями, когда они намереваются вывести на рынок новый продукт. Не упустите из внимания и тот аспект, что этот вид теста поможет вам не только сэкономить время и деньги, но и гораздо быстрее выявить удачную бизнес-идею.
Smoke-тестирование: назначение и примеры
Сразу после сборки программного обеспечения его нужно подвергать первичному смоук-тестированию. Эти меры направлены на быстрое выявление явных дефектов до того, как ПО будет отправлено на дальнейшее тестирование. Оперативное обнаружение ошибок на начальном этапе позволит значительно сократить время и трудозатраты на их исправление.
Что такое Smoke Tests? Это разработка минимального набора сценариев, с помощью которых тестируются базовые функции системы после каждой сборки. Другими словами, дымовое тестирование определяет, корректно ли был собран и установлен цифровой продукт. Если не сделать первичную проверку, то при наличии ошибок дальнейшие тесты будут лишней тратой времени. Если в ПО обнаружен дефект, оно сразу направляется на доработку, не проходя весь сложный цикл исследований.
Дымовые тесты исследуют стабильность системы. С помощью проверки можно определить, запускается ли программа, есть ли обратная связь с пользователем, открывается ли правильно интерфейс, выполняются ли основные функции системы.
Примером Smoke-тестов служат следующие сценарии проверки функциональности:
Дымовому тестированию можно подвергать как модернизированные продукты, так и только что выпущенные программы, которые ранее нигде не использовались. Приемочные испытания проводятся с высокой интенсивностью, поэтому проще и дешевле заказать их автоматизацию.
Достоинства дымового тестирования
Дымовая тесты конструируются таким образом, чтобы покрыть самые приоритетные функции системы. К преимуществам относятся:
Компания IBS AppLine реализует комплекс мер, направленных на проверку соответствия ПО требованиям заказчика и бизнес-задачам. Работа осуществляется в несколько этапов:
Дымовое тестирование значительно улучшает качество приложения. Оно направлено на проверку корректности переноса баз данных со старой версии на новую. Smoke-тесты контролируют корректность взаимодействия систем между собой.
IBS AppLine реализует масштабные проекты по улучшению качества программных продуктов. Наши специалисты обеспечивают максимальное тестовое покрытие нужных сегментов ПО и за короткое время проводят наиболее критичные проверки.
Покрываем проект smoke-тестами, пока он не сгорел
Привет, Хабр! Как-то раз на нашем внутреннем семинаре мой руководитель – глава отдела тестирования – начал свою речь со слов «тестирование не нужно». В зале все притихли, некоторые даже пытались упасть со стульев. Он продолжил свою мысль: без тестирования вполне возможно создать сложный и дорогостоящий проект. И, скорее всего, он будет работать. Но представьте, насколько увереннее вы будете себя ощущать, зная, что продукт работает как надо.
В Badoo релизы происходят довольно часто. Например, серверная часть наравне с desktop web релизится дважды в день. Так что мы не понаслышке знаем, что сложное и медленное тестирование – камень преткновения разработки. Быстрое же тестирование – это счастье. Итак, сегодня я расскажу о том, как в компании Badoo устроено smoke-тестирование.
Что такое smoke-тестирование
Первое своё применение этот термин получил у печников, которые, собрав печь, закрывали все заглушки, затапливали её и смотрели, чтобы дым шёл только из положенных мест. Википедия
В оригинальном своём применении smoke-тестирование предназначено для проверки самых простых и очевидных кейсов, без которой любой другой вид тестирования будет неоправданно излишним.
Давайте рассмотрим простой пример. Предпродакшн нашего приложения находится по адресу bryak.com (любые совпадения с реальными сайтами случайны). Мы подготовили и залили туда новый релиз для тестирования. Что стоит проверить в первую очередь? Я бы начал с проверки того, что приложение всё ещё открывается. Если web-сервер нам отвечает «200», значит, всё хорошо и можно приступать к проверке функционала.
Как автоматизировать такую проверку? В принципе, можно написать функциональный тест, который будет поднимать браузер, открывать нужную страницу и убеждаться, что она отобразилась как надо. Однако, у этого решения есть ряд минусов. Во-первых, это долго: процесс запуска браузера займёт больше времени, чем сама проверка. Во-вторых, это требует поддержания дополнительной инфраструктуры: ради такого простого теста нам потребуется где-то держать сервер с браузерами. Вывод: надо решить задачу иначе.
Наш первый smoke-тест
В Badoo серверная часть написана по большей части на PHP. Unit-тесты по понятным причинам пишутся на нём же. Итого у нас уже есть PHPUnit. Чтобы не плодить технологии без необходимости, мы решили писать smoke-тесты тоже на PHP. Помимо PHPUnit, нам потребуется клиентская библиотека работы с URL (libcurl) и PHP extension для работы с ней – cURL.
По сути, тесты просто делают нужные нам запросы на сервер и проверяют ответы. Всё завязано на методе getCurlResponse() и нескольких типах ассертов.
Сам метод выглядит примерно так:
Сам метод умеет по заданному URL возвращать ответ сервера. На вход принимает параметры, такие как cookies, headers, user agent и прочие данные, необходимые для формирования запроса. Когда ответ от сервера получен, метод проверяет, что код ответа совпадает с ожидаемым. Если это не так, тест падает с ошибкой, сообщающей об этом. Это сделано для того, чтобы было проще определить причину падения. Если тест упадёт на каком-нибудь ассерте, сообщив нам, что на странице нет какого-то элемента, ошибка будет менее информативной, чем сообщение о том, что код ответа, например, «404» вместо ожидаемого «200».
Когда запрос отправлен и ответ получен, мы логируем запрос, чтобы в дальнейшем при необходимости легко воспроизвести цепочку событий, если тест упадёт или сломается. Я об этом расскажу ниже.
Самый простой тест выглядит примерно так:
Такой тест проходит менее чем за секунду. За это время мы проверили, что стартовая страница отвечает «200», и на ней есть элемент body. С тем же успехом мы можем проверить любое количество элементов на странице, продолжительность теста существенно не изменится.
Плюсы таких тестов:
Авторизация
Представим, что с момента, как мы написали наш первый smoke-тест, прошло три дня. Само собой, за это время мы покрыли все неавторизованные страницы, какие только нашли, тестами. Немного посидели, порадовались, но потом осознали, что всё самое важное в нашем проекте находится за авторизацией. Как бы получить возможность это тоже тестировать?
Чем отличается авторизованная страница от неавторизованной? С точки зрения сервера всё просто: если в запросе есть информация, по которой пользователя можно идентифицировать, нам вернётся авторизованная страница.
Самый просто вариант – авторизационная cookie. Если добавить её к запросу, то сервер нас «узнает». Такую cookie можно захардкодить в тесте, если её время жизни довольно большое, а можно получать автоматически, отправляя запросы на страницу авторизации. Давайте подробнее рассмотрим второй вариант.
На нашем сайте страница авторизации выглядит так:
Нас интересует форма, куда надо ввести логин и пароль пользователя.
Открываем эту страницу в любом браузере и открываем инспектор. Вводим данные пользователя и сабмитим форму.
В инспекторе появился запрос, который нам надо имитировать в тесте. Можно посмотреть, какие данные, помимо очевидных (логин и пароль), отсылаются на сервер. Для каждого проекта по-разному: это может быть remote token, данные каких-либо cookies, полученных ранее, user agent и так далее. Каждый из этих параметров придётся предварительно получить в тесте, прежде чем сформировать запрос на авторизацию.
В инструментах разработчика любого браузера можно скопировать запрос, выбрав пункт copy as cURL. В таком виде команду можно вставить в консоль и рассматривать там. Там же её можно опробовать, поменяв или добавив параметры.
В ответ на такой запрос сервер вернёт нам cookies, которые мы будем добавлять в дальнейшие запросы, чтобы тестировать авторизованные страницы.
Поскольку авторизация – довольно долгий процесс, авторизационную cookie я предлагаю получать только один раз для каждого пользователя и сохранять где-то. У нас, например, такие cookies хранятся в массиве. Ключом является логин пользователя, а значением – информация о них. Если для следующего пользователя ключа ещё нет, авторизуемся. Если есть – делаем интересующий нас запрос сразу.
Пример кода теста, проверяющего авторизованную страницу, выглядит примерно так:
Как мы видим, добавился метод, который получает авторизационную cookie и просто добавляет её в дальнейший запрос. Сам метод реализуется довольно просто:
Метод сначала проверяет, есть ли для данного e-mail (в вашем случаем это может быть логин или что-то ещё) уже полученная ранее авторизационная cookie. Если есть, он её возвращает. Если нет, он делает запрос на авторизационную страницу (например, bryak.com/auth_page_adds) с необходимыми параметрами: e-mail и пароль пользователя. В ответ на этот запрос сервер присылает заголовки, среди которых есть интересующие нас cookies. Выглядит это примерно так:
Из этих заголовков нам при помощи несложного регулярного выражения надо получить название cookie и её значение (в нашем примере это name=value). У нас метод, который парсит ответ, выглядит так:
После того, как cookies получены, мы можем смело добавлять их в любой запрос, чтобы сделать его авторизованным.
Разбор падающих тестов
Из вышесказанного следует, что такой тест – это набор запросов к серверу. Делаем запрос, совершаем манипуляцию с ответом, делаем следующий запрос и так далее. В голову закрадывается мысль: если такой тест упадёт на десятом запросе, может оказаться непросто разобраться в причине его падения. Как упростить себе жизнь?
Прежде всего я бы хотел посоветовать максимально атомизировать тесты. Не стоит в одном тесте проверять 50 различных кейсов. Чем тест проще, тем с ним проще будет в дальнейшем.
Ещё полезно собирать артефакты. Когда наш тест падает, он сохраняет последний ответ сервера в HTML-файлик и закидывает в хранилище артефактов, где этот файлик можно открыть из браузера, указав название теста.
Например, тест у нас упал на том, что не может найти на странице кусочек HTML:
Мы заходим на наш коллектор и открываем соответствующую страницу:
С этой страницей можно работать так же, как с любой другой HTML-страничкой в браузере. Можно при помощи CSS-локатора попытаться разыскать пропавший элемент и, если его действительно нет, решить, что либо он изменился, либо потерялся. Возможно, мы нашли баг! Если элемент на месте, возможно, мы где-то ошиблись в тесте – надо внимательно посмотреть в эту сторону.
Ещё упростить жизнь помогает логирование. Мы стараемся логировать все запросы, которые делал упавший тест, так, чтобы их легко можно было повторить. Во-первых, это позволяет быстро руками совершить набор аналогичных действий для воспроизведения ошибки, во-вторых – выявить часто падающие тесты, если такие у нас имеются.
Помимо помощи в разборе ошибок, логи, описанные выше, помогают нам формировать список авторизованных и неавторизованных страниц, которые мы протестировали. Глядя на него, легко искать и устранять пробелы.
Последнее, но не по важности, что могу посоветовать – тесты должны быть настолько удобными, насколько это возможно. Чем проще их запустить, тем чаще их будут использовать. Чем понятнее и лаконичнее отчет о падении, тем внимательнее его изучат. Чем проще архитектура, тем больше тестов будет написано и тем меньше времени будет занимать написание нового.
Если вам кажется, что тестами пользоваться неудобно – скорее всего вам не кажется. С этим необходимо бороться как можно скорее. В противном случае вы рискуете в какой-то момент начать обращать меньше внимания на эти тесты, а это уже может привести к пропуску ошибки на продакшн.
На словах мысль кажется очевидной, согласен. Но на деле всем нам есть куда стремиться. Так что упрощайте и оптимизируйте свои творения и живите без багов. 🙂
Итоги
На данный момент у нас *открываю Тимсити* ого, уже 605 тестов. Все тесты, если их запускать не параллельно, проходят чуть меньше, чем за четыре минуты.
За это время мы убеждаемся, что:
Конечно, это не замена Selenium. Нам всё равно придётся проверять корректное поведение клиента и кросс-браузерные кейсы. Мы можем заменить лишь те тесты, которые проверяют поведение сервера. Но, помимо этого, мы можем осуществлять предварительное тестирование, быстрое и простое. Если на этапе smoke-тестирования нашлись ошибки и «дым идёт не оттуда», возможно, запускать долгий набор тяжеловесных Selenium-тестов до фиксов смысла нет? Это уже на ваше усмотрение! 🙂
Спасибо за внимание.
Виталий Котов, QA-инженер по автоматизации.