Смоук тестирование пример сценария тестирования

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

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

Преимущества Smoke-тестирования

У дымового тестирования много достоинств. Из самых важных:

• Простота выполнения тестирования
• Обнаружение дефектов на ранних этапах
• Повышение качества системы
• Экономия времени и ресурсов при тестировании
• Минимизация рисков интеграции

Различие между Smoke, Sanity и Регрессионным тестированием.

1. Smoke проверяет рабочее состояние новой сборки. Sanity-тестирование проверяет изменения, которые были сделаны в текущей сборке. Регресс проводится для проверки всего функционала, который был затронут в ходе изменения в текущей сборке.
2. Дымовое тестирование можно выполнить на любой сборке. Sanity и Регресс выполняются только на стабильных сборках.
3. Smoke-тестирование может выполняться как разработчиками, так и тестировщиками. Sanity и Регресс выполняются только тестировщиками
4. Смоук-тестирование обязательно проводится для каждой новой сборки. Sanity-тестирование осуществляется, только если нет времени делать более глубокое регрессионное тестирование. Регрессионное тестирование выполняется всегда, когда нет ограничения во времени.

Как выполняется смоук-тестирование

Smoke-тестирование выполняется при каждой новой сборке. Для этого определяется минимальный набор тест-кейсов для критически важного функционала. На этапе написания тест-кейсов определяют Priority и Severity кейса. В Smoke-прогон входят кейсы с Priority High и Severity Critical, как правило, это основные пользовательские сценарии, набор кейсов для проверок интеграционных модулей. К примеру, у нас в системе используются сторонние модули для скачивания документов, отображения карт, отправки писем, регистрации через интеграционную систему – эти кейсы добавлены в Smoke-прогон.
С помощью них проверяется их рабочее состояние и дается гарантия, что все критически важные функции работают правильно. Задача – проверить, подключен ли модуль, выполняет ли он свою основную функцию. К примеру, при проверке модуля скачивания документов нужно убедиться, что документ скачивается, а что конкретно в нем отображено – это проверка в рамках регресса. Исходя из Smoke мы поняли, что модуль в общей сборке корректен и подключен к системе.

Основная цель дымового тестирования – раннее обнаружение проблем в сборке. Если в сборке присутствуют ошибки, то дальнейшее тестирование будет лишь тратой времени и ресурсов.

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

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

Если же обнаружены проблемы, то сборка отклоняется и передается обратно разработчикам для исправления. После внесения исправления тестировщик снова должен провести смоук-тестирование.

Все результаты Smoke-прогона тестировщики фиксируют в системе управления. На основании этой информации формируются диаграммы Smoke-прогона.

Пример Smoke-тестирования

Например, в тестируемом приложении есть следующие основные пользовательские сценарии:

1. Вход в систему
2. Регистрация пользователя
3. Личная страница пользователя
4. Редактирование личных данных

Для такого приложения тестировщик в ходе Smoke-тестирования должен проверить все основные пользовательские сценарии. Например:

1. Пользователь смог войти с действительными учетными данными.
2. Пользователь не смог войти c недействительными учетными данными.
3. Успешное создание нового пользователя при заполнении формы регистрации валидными данными.
4. Просмотр страницы пользователя после входа в систему.
5. Пользователь смог отредактировать Имя/email

Заключение

Таким образом, Smoke-тестирование или проверка сборки проводится для того, чтобы до запуска продукта убедиться, что всё работает стабильно и отвечает требованиям заказчика. Оно проводится при каждой новой сборке. У этого вида тестирования много преимуществ: оно помогает заметить дефекты на раннем этапе, повысить качество системы и экономит время.

• Почему так странно называется
• Когда применяется
• Зачем нужно в жизненном цикле
• Может быть и ручным, и автоматизированным
• Примеры дымового тестирования
• Контрольные вопросы, которые надо знать на собеседовании

Когда говорят о тестировании в ИТ, подразумевают процесс поиска ошибок, длящийся недели, а то и месяцы. Существует быстрое тестирование — это так называемое smoke-тестирование (smoke testing, “дымовое тестирование”). Коротко: это предварительное тестирование самых важных функций.

Происхождение. Почему smoke-тестирование так называется

Есть несколько версий:

• Из-за того, что проверка начинается “пока аппарат еще дымится”, то есть устройство только что собрано (то есть, только что закончена пайка).
• Терминология водопроводчиков. Водопроводчики проверяли герметичность труб, запуская туда дым. Если в трубе была дыра, ее находили по струйке дыма.
• Наиболее правдоподобная версия: термин инженеров-электротехников. Когда на электрическую цепь впервые подавалось питание, она могла дымиться если пайка была небрежной, или если в устройстве были дефекты.

Smoke-тестирование — когда применяется

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

В терминологии QA, это предварительное тестирование приложения после билда, но перед релизом, отвечающее на вопрос “работает ли приложение в целом?”

Смок-тестирование по предназначению похоже на санитарное тестирование, но санитарное тестирование “более узкое”, обычно проверяет какую-то одну проблемную функцию, а не все приложение.

Зачем нужно smoke-тестирование в жизненном цикле

Если смотреть “интегрально”, с точки зрения QA и CI-CD-пайплайна, то смок-тестирование — это о том как проверить, что остальные виды тестирования уже валидные, то есть “можно идти дальше”. Ведь если билд падает при установке, или если половина страниц сайта не грузится, то нет смысла продолжать тестирование, пока такие крупные дефекты не уберут.

Smoke-тестирование может быть и ручным, и автоматизированным

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

Автоматизированное смок-тестирование — пишутся скрипты, проверяющие ключевые функции. Иногда это бывает целесообразно, если действия стандартные и повторяемые.

Может быть и “гибридное” тестирование: сочетание ручного и автоматизированного.

Конкретные этапы смок-тестирования зависят от приложения — далее.

Примеры smoke-тестирования

Итак, цель “дымного тестирования” — убедиться, что приложение уже рабочее, функциональности уже достаточно, чтобы идти дальше, к следующим этапам тестирования/разработки. Теперь поговорим о том, на что смотрят во время smoke testing “стандартного” приложения:

• Какие главные функции пользователь использует — работают ли они?
• Какие “поддерживающие” функции он использует? (то есть тоже необходимые, вроде входа в свой аккаунт)
• Работает ли навигация?
• Приложение может  читать/записывать данные без проблем?

Например такие грубые дефекты не должно “пропустить” смок-тестирование:

Пример 1: пользователь не может “вылогиниться” из приложения.

Пример 2: на странице логина не срабатывает кнопка “Submit” перехода к следующей странице, несмотря на корректные логин/пароль.

***

В некоторых книгах по QA встречаются более “академически правильные” названия smoke-тестов: “входные тесты” (intake tests, термин одобряет ISTQB); тесты верификации билда (build verification tests, BVT-тесты); или тестирование сборки. 

Контрольные вопросы, которые нужно знать для собеседования / junior QA Interview Questions & Answers: smoke testing

Что входит в смок-тестирование?

Смок-тестирование проверяет “общую пригодность” AUT-приложения. Приложение должно запуститься и продемонстрировать работоспособность своих базовых функций.

Какие дефекты являются целью смок-тестирования?

Легко находимые критические и блокирующие дефекты.

Когда проводится смок-тест? На каком этапе нужно проводить смок-тестирование?

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

Зачем нужно Smoke тестирование?

Цель такого тестирования – проверить, что после очередной сборки программного продукта нет явных, грубых дефектов, “блокирующих дальнейший путь”. 

Почему называется smoke testing?

Это странное название происходит из истории XX века, а именно: крайне несовершенных электрических приборов того времени. Если при включении электроприбора был виден дым (или был запах горелой проводки) – прибор еще нерабочий.

Что такое sanity-тестирование? Это не то же, что smoke-тестирование? В чем разница между “дымовым” тестированием и “санитарным”?

Смок-тестирование проверяет критически важный функционал AUT-приложения; а санитарное тестирование проверяет отдельный модуль приложения. 

(Более правильно “санитарное тестирование” называется “тестированием согласованности”, но термин “санитарное” уже прижился у российских тестировщиков).

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

Расположите известные вам типы тестов в порядке их выполнения:

QA-тесты стандартно выполняются в таком порядке: юнит-тесты, интеграционные, санити-тесты, смок-тесты, функциональные тесты.

Как связаны смок-тесты и регрессионные?

Смок-тесты являются подмножеством регрессионных.

Кто проводит 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.

Важно рассмотреть вопрос о передаче средств при проверке идеи продукта или его компонентов. Много людей скажут вам, что идея отличная: «Да, конечно, я бы использовал этот продукт». Но они действительно потратили бы на это свои деньги? Даже что-то стоимостью в $5 или $9.99 в месяц может требовать дополнительной валидации.

Что следует тестировать в первую очередь?

Предположим, что с вами случился один из двух сценариев:

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

Как решить, что следует подвергнуть проверке в первую очередь?

Дерек Сиверс (Derek Sivers), американский предприниматель, предлагает подвергнуть смоук-тесту сначала самое рискованное предложение.

Также первыми в списке могут идти:

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

2. Идеи, которые откладывались слишком долго. Проведите смоук-тест и, наконец, отпустите их.

6-ступенчатое смоук-тестирование

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

Шаг 1: Определите необходимые доказательства

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

Например:

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

Шаг 2: Разработка эксперимента без привлечения инженеров

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

К примеру:

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

Шаг 3: Обеспечьте трафик, необходимый для проведения эксперимента

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

Вот как определяет правильность собранной аудитории Доминик:

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

Это помогает направлять аудиторию, которую вы создаете. Так, на Facebook, если люди не рассказывают о вашем предложении на своих страницах после перехода на него по платному объявлению, то, вероятно, это не ваша аудитория, тогда как люди, пришедшие с поисковой рекламы, наверняка мотивированы сильнее.

Это помогает понять, куда вкладывать свои средства, в какой канал».

Во время поиска трафика для проведения смоук-тестов Эрик Рис обращается к помощи AdWords:

«Если вы хотите запустить какой-либо онлайн-сервис, а проводить поддельные кампании в AdWords для его проверки не стали, вы просто сошли с ума. Это тот вывод, к которому я пришел после просмотра массы онлайн-продуктов, так и не сумевших привлечь покупателей.

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

Вам следует обратить пристальное внимание на следующие данные: процент покупателей, прошедших весь путь от посадочной страницы до завершения регистрации, кликабельность объявлений по разным ключевым словам и показатель отказов для целевой страницы по разным ключевым запросам».

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

Какой бы маршрут вы ни выбрали, главное быть уверенным в двух вещах:

1. Вы обратились к правильной аудитории. Самый лучший в мире продукт с треском провалится, если будет предложен не тем людям.

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

Шаг 4: Определите ключевые показатели и измерьте их

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

Выберите те показатели, которые релевантны доказательствам, установленным на первом шаге.

Шаг 5: Анализ результатов и проведение повторных тестов, оптимизация

Если вы попали в список тех, кому посчастливилось тестировать идею с нуля, у вас, вероятно, нет трафика (и вы не можете позволить себе этот трафик), чтобы сделать ваш тест статистически значимым.

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

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

Здесь-то и вступают в игру A/B-тестирование и неформальные итерации. Эрик объясняет свой итерационный процесс:

«Используйте Google Optimizer, чтобы попробовать в деле разные посадочные страницы (даже радикально отличающиеся друг от друга) и определить, оказывают ли разные способы представления вашего продукта влияние на коэффициент конверсии.

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

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

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

Пример: Suprizr

Suprizr — это сервис, смысл которого в доставке блюд, приготовленных на основе ваших предпочтений. Вот как выглядела посадочная страница до проведения тестов: 

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

Но вместо того, чтобы отказаться от этой идеи вовсе, Suprizr изменили свой подход, запросив сначала только индекс клиента:

Как только посетитель вводил свой индекс, он видел сообщение, в котором Suprizr приносила извинения за то, что сервис еще не начал обслуживать их район, но вот-вот начнет, и если человек хочет получить уведомление о запуске, он должен оставить адрес электронной почты для связи:

Какой результат? 30% посетителей ввели свой индекс, 25% оставили электронную почту, а 10% поделились информацией о сайте.

Бывает, что провести смоук-тест так, как вы планировали, с первой попытки не получается. Продолжайте итерации до полного отказа от идеи.

Шаг 6: примите решение

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

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

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

Заключение

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

«Даже если ваша идея провалится, вы все равно в числе победителей. Ведь вы не будете чувствовать себя командой, потратившей зря столько времени и ресурсов. К тому же, иначе вы бы не узнали больше о своих покупателях» — утверждает Доминик.

На какие вопросы еще можно получить ответ:

• почему эта идея провалилась?
• это ошибка исполнения?
• были итерации, которые работали лучше других?

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

Высоких вам конверсий!

По материалам conversionxl.com Image source Javier Pérez

21-03-2017

Перевод: Алексей Лемешко

Источник: Steve McConnell, Construx Software Builders, P.O. Box 6922, Bellevue, WA 98008.
E-mail:
Этот e-mail адрес защищен от спам-ботов, для его просмотра у Вас должен быть включен Javascript
— WWW: http://www.construx.com/stevemcc/

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

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

Практика применяемая, к примеру, в Microsoft и некоторых других компаниях, занимающихся разработкой ПО, заключается в ежедневной сборке (билдовании) программы, которая дополняется дымовым тестированием. Ежедневно, после того, как каждый файл собран (сбилдован, построен), связан (слинкован), и объединен в выполнимую программу, сама программа подвергается достаточно простому набору тестов, цель которых заключается в том, чтобы увидеть, «дымит» ли программа во время работы. Эти тесты и называются дымовыми (от англ. smoke — дым). Чаще всего этот процесс достаточно хорошо автоматизирован (или должен таким быть).

ПРЕИМУЩЕСТВА. Этот простой процесс обеспечивает несколько существенных преимуществ.

Минимизация риска при интеграции

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

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

Снижения риска низкого качества программного продукта

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

Помощь в диагностике ошибок

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

Улучшение морального духа

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

Использование ежедневного билдования и дымовых тестов

Вот несколько подробностей этого принципа.

Ежедневная сборка приложения

Фундаментальной частью ежедневной сборки является сборка той части, что была сделана последней. Джим Маккарти (Jim McCarthy) в журнале Dynamics of Software Development (Microsoft Press, 1995) назвал ежедневное билдование проекта его сердцебиением. Если сердцебиения нет — проекта нет, он мертв. Менее образно ежедневное билдование описали Майкл Касамано (Michael Cusumano) и Ричард Селби (Richard W. Selby), назвав его синхронизирующим импульсом проекта (Microsoft Secrets, The Free Press, 1995). Каждый разработчик пишет код по своему и он, код, может выходить за общепринятые на проекте рамки — это нормально, но при каждом воздействии синхронизирующего импульса код возвращается к стандарту. Настаивая на ведении разработки с использованием импульса синхронизации постоянно, Вы препятствуете выходу проекта из синхронизации полностью.

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

Проверка на неудачную сборку

В случае ежедневной сборки проекта подразумевается, что проект должен работать. Однако, если же проект оказывается не рабочим, то его починка становится задачей с приоритетом 1.

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

Хорошей сборкой является та, при которой как минимум:

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

Ежедневные дымовые тесты

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

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

Дымовое тестирование должно развиваться на уровне с проектом. В начале, дымовые тесты будут проверять что-то простое, например, может ли проект выдавать сообщение «Hello, World!». С развитием системы, дымовые тесты становятся более глубокими. Время, которое тратится на первые дымовые тесты, исчисляется несколькими секундами, однако с ростом системы растет и количество необходимого для дымового тестирования времени. В конце проекта дымовое тестирование может длится на протяжении часов.

Определение группы сборки

На большинстве проектов, есть определенный сотрудник, ответственный за проверку ежедневной сборки системы и выполнение дымовых тестов. Эта работа является частью обязанностей данного сотрудника, но на больших проектах таких сотрудников может быть больше и такая работа является основной их обязанностью. Например, в группе сборки проекта Windows NT 3.0 было четыре человека (Pascal Zachary, Showstopper!, The Free Press, 1994).

Добавляйте ревизию в сборку только если это имеет смысл

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

На большинстве проектов есть система штрафов за срыв выпуска очередной сборки. В самом начале проекта стоит четко дать понять, что сохранение рабочего проекта является задачей самого высокого приоритета. Срыв выпуска очередной сборки может быть исключением, но ни как не правилом. Настаивайте на том, чтоб разработчики оставляли все дела до тех пор, пока система опять не заработает. В случае частого срыва сборки (выпуска не рабочей сборки) достаточно трудно вернуть проект в нормальное русло.

Незначительные штрафы подчеркивают высокую степень необходимости следить за качеством сборки системы. На некоторых проектах разработчикам, по вине которых сборка «падает», выдают леденцы за выпуск неработающей сборки. На двери кабинета такого разработчика висит соответствующая вывеска до тех пор, пока он не починит сборку (при условии, что у разработчиков отдельные кабинеты :)). На других проектах виновные разработчики должны носить искусственные козлиные рога или вносить определенную сумму в «фонд морального духа» (примеры взяты из истории реальных компаний).

Но на некоторых проектах вводятся более серьезные штрафные санкции. Например, разработчики компании Microsoft, состоящие в проектах с высоким приоритетом (Windows NT, Windows 95, Excel), носили пейджеры и, в случае обнаружения проверки, они должны были прибыть на работу. Даже если поломка или ошибка были обнаружены в 3 утра.

Собирайте систему и «дымите» ее даже под давлением

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

Кто выигрывает от этого процесса? Некоторые разработчики протестуют против ежедневных сборок, обосновывая свои протесты непрактичностью этого занятия и его большими временными затратами. Но все сложные системы последнего времени подвергались ежедневным сборкам и прогонке дымовых тестов. К моменту своего выпуска, Microsoft Windows NT 3.0 содержала в 40 000 файлах 5,6 миллионов строк. Полная сборка занимала 19 часов и выполнялась на нескольких компьютерах. Несмотря на это, разработчики умудрялись ежедневно собирать систему. Будучи профессиональной командой, группа разработчиков NT, своим успехом во многом обязана ежедневной сборке. Те разработчики, которые работают на менее сложных проектах и, поэтому, не пользуются преимуществами процесса ежедневной сборки, должны задуматься над тем, чтоб придумать себе какие-то разумные объяснения.

Smoke-тестирование — проверка программного обеспечения на стабильность и наличие явных ошибок. Тест должен подтвердить или опровергнуть правильность выполнения ПО своих основных функций перед его передачей на более глубокое тестирование.

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

Дымовое тестирование осуществляется при выпуске каждой новой сборки. Такая проверка включает в себя несколько этапов.

Планирование. Smoke-тест планируется, как правило, в начале проекта командой quality assurance (QA) инженеров в сотрудничестве с менеджером проекта, программистами, заказчиками и пользователями. Типичное планирование выглядит следующим образом:

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

Выполнение. Это непосредственно этап самого тестирования. В ходе него проверяемая сборка подвергается испытанию в рамках предварительно разработанных тест-кейсов:

• в продукт водятся определенные на этапе планирования исходные данные;
• полученные выходные данные фиксируются для дальнейшей оценки.

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

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

Рассмотрим алгоритм smoke-тестирования на примере основных функций сайта или веб-приложения, где предусмотрена регистрация и авторизация пользователей, — например, соцсети или электронной почты. В них предусмотрены основные пользовательские функции:

• регистрация пользователя;
• авторизация в системе;
• личная страница пользователя;
• редактирование личных данных.

Для проверки этого функционала тестировщик в ходе дымового тестирования должен провести основные пользовательские сценарии:

• успешное создание аккаунта при введении валидных сведений (телефона, электронной почты, имени, фамилии и т.д.) в поля регистрационной формы;
• успешный вход с валидными учетными данными (логином и паролем, полученными или заданными при регистрации);
• неудачная авторизация с помощью недействительных учетных данных;
• просмотр страницы пользователя после авторизации;
• успешное изменение регистрационных данных (например имени или адреса email).

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

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

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

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

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

• Экономия времени и ресурсов. Smoke-тесты сравнительно простые и не требуют значительных затрат на свое проведение, могут осуществляться самими разработчиками или ограниченной командой QA-инженеров. В то же время они могут показать, что текущая сборка не выполняет даже основных своих задач и потому проводить более глубокое и затратное тестирование просто не имеет смысла до тех пор, пока главный функционал продукта не будет стабильно работать.
• Автоматизация. Дымовые тесты обычно стандартные и повторяющиеся для каждой сборки одного и того же продукта или различных однотипных проектов. Соответственно, для ускорения и упрощения тестирование можно автоматизировать. Однако автоматизация самого теста зачастую может быть труднее его «ручного» проведения, поэтому ее нужно осуществлять соразмерно сложности проекта.
• Стабильность сборки. В случае, когда сборки выпускаются часто, регулярное проведение smoke-тестов придает разработчику и другим задействованным в разработке продукта сторонам уверенность, что он будет работать стабильно по крайней мере в отношении основных функций. Соответственно, на каких-то этапах можно опустить затратную глубокую проверку — например, если текущий билд отличается от предыдущего незначительными изменениями.
• Обнаружение проблем на ранних этапах. Особенно это преимущество проявляется в непрерывной интеграции, когда продукт проходит быструю и частую смену итераций. Потенциально такая скорость может привести к накоплению большого количества ошибок в финальной версии. Внедрение smoke-тестов в рамках каждого цикла позволяет этого избежать.

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

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