Бизнес тестирование как пишется - Портал по русскому языку

Пишем максимально эффективный тест-кейс

Что такое тест-кейс?

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

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

Зачем нужны тест-кейсы?

Атрибуты тест-кейса

Любой тест-кейс обязательно включает в себя:

Уникальный идентификатор тест-кейса — необходим для удобной организации хранения и навигации по нашим тест-наборам.
Название — основная тема, или идея тест-кейса. Кратное описание его сути.
Предусловия — описание условий, которые не имеют прямого отношения к проверяемому функционалу, но должны быть выполнены.
Например, оставить комментарий на вашем портале может только зарегистрированный пользователь. Значит для тест-кейса «Создание комментария» будет необходимо выполнение предусловия «пользователь зарегистрирован», и «пользователь авторизован»
Шаги — описание последовательности действий, которая должна привести нас к ожидаемому результату
Ожидаемый результат — результат: что мы ожидаем увидеть после выполнения шагов.

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

Что еще необходимо знать, перед созданием тест-кейса?

Во-первых, каждый выполненный тест-кейс, дает нам один из трех результатов:

1.Положительный результат, если фактический результат равен ожидаемому результату,
2.Отрицательный результат, если фактический результат не равен ожидаемому результату. В этом случае, найдена ошибка.
3.Выполнение теста блокировано, если после одного из шагов продолжение теста невозможно. В этом случае так же, найдена ошибка.

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

Чего не должно быть в тест-кейсе

1. Зависимостей от других тест-кейсов;
2. Нечеткой формулировки шагов или ожидаемого результата;
3. Отсутствия необходимой для прохождения тест-кейса информации;
4. Излишней детализации.

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

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

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

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

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

Источник статьи: http://habr.com/ru/post/246463/

Тестирование требований: как я нахожу ошибки в бизнес-логике фичи прежде, чем их закодят

Привет, Хабр. Меня зовут Ольга, я работаю в тестировании с 2013 года, специализируюсь на тест-анализе и тест-дизайне. Сегодня хочу рассказать, как при планировании тестирования сохранить фокус на пользователях и их потребностях.

Часто тестировщики начинают планирование тестирования с составления карты приложения. Т.е. формируют список страниц и перечисляют все контролы на странице. Это приводит к тому, что каждая страница сама по себе работает, но это не значит, что пользователь может выполнить свою задачу целиком.

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

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

Статья получилась объемной, так что вот оглавление:

Введение

Есть разные команды: в одних командах куча аналитиков пишут требования к софту на сотню страниц, в других есть 1 аналитик на несколько проектов и он пишет, как успеется, в третьих вообще нет аналитика и задачи ставит ПМ, а команда уже на ходу придумывает, что именно реализовать. Причем, может быть непонятно, что нужно сделать по задаче, независимо от того, есть ли аналитик на проекте. И чаще всего так и происходит. То задача идет вразрез с текущим функционалом, то никто не понимает, что там вообще надо сделать, то все всё понимают, но каждый по-своему.

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

Есть разные варианты, что может пойти не так:

Ожидания пользователей (пользователи хотят одно, а мы думаем, что они хотят другое; нет важных фичей; фичи есть, но неудобные).

Ожидания заказчика (ПМ хочет то, что невозможно/дорого реализовать; или то, что противоречит уже существующей логике).

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

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

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

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

Другой вопрос: а как тестить до разработки, если по постановке задачи ничего непонятно?

Для этого нам нужно определить:

Как пользователь/заказчик будет использовать эту фичу.

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

Зачем и для кого фича?

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

Это можно спросить у автора задачи.

Стоит различать пользователя продукта и заказчика.

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

Пользователи продукта тоже могут быть разные. Важно выявить:

Какие категории пользователей есть в вашей целевой аудитории (ЦА).

Зачем люди из каждой категории используют эту фичу.

Какие проблемы они решают с помощью нее.

Какие есть варианты использования фичи.

Итак, задача может быть для нужд бизнеса, например, чтобы организовать PR-компанию, или уменьшить затраты на Х, или увеличить доходы с У, или предотвратить/остановить отток пользователей.

Или для определенной категории пользователей нужно реализовать фичу, которую пользователи давно хотят и просят.

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

Для команды разработки — например, рефакторинг определенной области.

Для саппорта — чтобы лучше локализовать проблему или чтобы снизить нагрузку на саппорт.

Для другой команды — обычно это интеграции или еще какой-то обмен данными.

Какую проблему решает фича?

С заказчиком разобрались. Дальше нужно понять, какую проблему заказчика решает эта фича и действительно ли проблема будет решена релизом этой фичи.

Можно обдумать это еще и в ключе: как пользователь/заказчик решает эту проблему сейчас?

Делает руками, долго и болезненно. Или наоборот, руками получается быстро и ему ок.

Решает проблему через другое приложение.

Никак не делает и страдает.

Никак не делает и ему норм.

Ответ на этот вопрос поможет понять: а мы этой фичей точно улучшим пользователю работу или еще хуже сделаем?

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

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

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

Конфликт интересов

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

В книге «Разработка требований к программному обеспечению» (Карл Вигерс, Джой Битти) я нашла замечательную таблицу о том, как разрешать конфликты между сторонами при определении требований. Привожу ее здесь:

Разногласия между.

Как разрешать

Решение принимает сторонник или владелец продукта

Предпочтение отдается наиболее важному классу пользователей

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

Решение определяется на основе бизнес-целей

. пользователями и менеджерами

Решение принимает сторонник класса пользователей или владелец продукта

. разработчиками и клиентами

Предпочтение отдается клиентам, но с учетом бизнес-целей

. разработчиками и маркетингом

Предпочтение отдается специалистам по маркетингу

Как пользователь будет использовать эту фичу?

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

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

Если при разработке ориентироваться на пользователя и его работу с продуктом, то этих проблем можно избежать. Для этого удобно использовать технику Варианты Использования (Use Cases).

Варианты использования (Use cases)

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

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

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

Возьмем для примера агрегатор доставки заказов из ресторанов и магазинов. В нем можно найти вот такие варианты использования:

Заказать еду из ресторана с доставкой.

Заказать еду с самовывозом.

Заказать доставку продуктов из супермаркета.

Найти, в каком ресторане есть желаемое блюдо.

Посмотреть стоимость доставки из ресторана Х.

Посмотреть, где находится курьер, который доставляет заказ.

Имя варианта использования должно быть понятное (глагол + объект), описывающее, какую именно ценность пользователю дает этот вариант использования, например, информацию о чем-либо (внутри приложения) или еду на обед (в реальном мире, за пределами приложения).

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

Примеры вопросов, чтобы найти действующих лиц:

Кому приходит уведомление о событиях в системе?

Кто предоставляет системе информацию или услугу?

Кто помогает системе среагировать и выполнить задачу?

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

Т.е. у нас будет как минимум 4 действующих лица:

Система (т.е. само приложение)

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

Если покупатель выберет в заказе оплату картой, то добавится действующее лицо «Банк». Если закажет еду не себе, а бабушке, то появится еще «Получатель». А если будет писать в техподдержку, то добавятся «Бот» и «Оператор техподдержки».

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

Основное направление варианта использования

Определим варианты использования основной фичи агрегатора доставки — заказа еды из ресторана.

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

Действующие лица:

С — Система (т.е. само приложение)

Предусловия:

Пользователь авторизован в приложении

Доступен как минимум 1 ресторан

Заказ делается в часы работы ресторана

У ресторана есть блюда в наличии

Сценарий (основное направление):

П: Добавляет блюда в корзину

С: Проверяет доступность блюд

С: Показывает пользователю сумму заказа в корзине

С: Подсчитывает сумму и прогноз доставки

П: Переходит в Корзину

С: Показывает текущее содержимое заказа

П: Инициирует оформление заказа

С: Предлагает выбрать параметры заказа (адрес, время доставки, вид оплаты)

П: Выбирает оплату картой онлайн и инициирует оплату

Б: Открывает страницу подтверждения оплаты

П: Подтверждает оплату (вводит код из СМС)

Б: Проверяет подтверждение

Б: Передает в Систему данные, что заказ оплачен

С: Присылает покупателю чек об оплате

С: Показывает покупателю, что заказ принят

С: Запрашивает подтверждение заказа у Ресторана

Р: Подтверждает заказ

Р: Начинает готовить заказ (в реальном мире)

С: Находит Курьера и запрашивает у него подтверждение принятия заказа

К: Подтверждает, что принял заказ

К: Идет в ресторан (в реальном мире)

Р: Подтверждает, что заказ готов

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

К: Транспортирует заказ (в приложении видна геометка курьера на карте) (в реальном мире)

П: Получает заказ

К: Подтверждает, что передал заказ покупателю

С: Показывает, что заказ завершен

Альтернативные направления

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

Можно посмотреть на сценарий целиком и подумать, как можно получить заказ другим способом:

А-1 Зайти в раздел с завершенными заказами и повторить прошлый заказ

А можно смотреть на каждую строку и думать: «может ли действующее лицо сделать другой выбор на этом шаге?»

А-2 Покупатель оформляет заказ на другого получателя (а не на себя)

А-3 Покупатель выбирает оплату наличными (и сценарий минует шаги с онлайн-оплатой)

А-4 Покупатель применяет промокод и сумма к оплате пересчитывается

А-5 Покупатель выбирает доставку к определенному времени

А-6 Курьер сначала принимает заказ, а потом отказывается и заказ берет новый курьер

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

Каждую такую альтернативу можно пошагово расписать, как и основной сценарий. А можно нарисовать блок-схему.

Исключения

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

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

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

И-1.1 Добавляемое блюда закончилось в ресторане и больше недоступно для заказа.

И-1.2 У ресторана закончилось время работы.

И-1.3 Ресторан прекратил прием заказов и вообще исчез из списка.

И-1.4. В корзине лежат блюда другого ресторана (обычно при этом система предлагает убрать блюда другого ресторана из корзины).

На шаге подсчета суммы и прогноза времени доставки может оказаться, что:

И2.1 Сумма заказа недостаточна для доставки (возможен только самовывоз).

При оплате онлайн бывает, что страница банка зависает, и невозможно ввести код оплаты.

П: Выбирает оплату картой онлайн и инициирует оплату.

Б: Открывает страницу подтверждения оплаты (но страница зависает).

П: Не может ввести код оплаты.

П: Обновляет страницу.

П: ~~Психует и~~ Переходит на предыдущий экран (т.е. обратно в приложение).

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

И-3.1 Страница подтверждения оплаты зависла.

Еще несколько примеров исключений из этого сценария:

И-4.1 Курьер не вышел на связь с рестораном (Система отменила заказ автоматически).

И-4.2 Нет доступных курьеров в зоне доставки (Система отменила заказ автоматически).

И-5.1 Курьер случайно отменил заказ когда еда уже была у него ~~и отдал заказ бомжу~~.

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

От входных/выходных данных к тест-кейсам

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

При этом одни и те же параметры на входе в разные сценарии могут иметь разные значения.

Например, при заказе еды в агрегаторе доставки на вход поступают вот такие параметры:

Прогнозируемое время доставки

На выходе могут быть такие данные:

Количество доставленных блюд

Качество (вкус, температура) доставленных блюд

Доставленные приборы (количество, комплектность)

Фактическое время доставки

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

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

И наоборот, если Адрес покупателя находится в соседнем доме от ресторана, то доставка будет по минимальной стоимости.

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

Если способ оплаты — «Наличные курьеру», но по факту покупатель не заплатил курьеру, то заказ не будет доставлен (отменен).

То же самое, если на банковской карте не хватило средств для оплаты заказа, то заказ может быть отменен. Или отложен как не оплаченный и пользователь сможет поменять способ оплаты. Реальный исход зависит от реализации.

Что если покупатель закажет очень много блюд? В 2-3 раза больше, чем влезет в курьерскую термосумку. Сработает ли ограничение в, допустим, 15кг на 1го курьера? Или системе придется искать 3х курьеров?

Как будет в таком случае спрогнозировано время доставки? Ведь все эти блюда нужно еще успеть приготовить.

Если покупатель закажет доставку из ресторана за минуту до закрытия и ресторан не успеет подтвердить заказ, заказ доставят? Или перенесут на другой день? Или отменят?

Такие вопросы следует уточнять у постановщика задачи, ПМа или аналитиков на вашем проекте и не пытаться угадать/придумать «правильную» логику самостоятельно.

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

Пишите в сценариях смысл действия без опоры на внешний вид

При написании сценариев важно опираться на смысл пользовательского действия, а не на интерфейс. Это позволит не переписывать их при каждом редизайне. Т.е. мы можем написать:

Покупатель выбирает вид оплаты Картой.

Покупатель кликнул на серую кнопку «Visa/Mastercard» в правом нижнем углу формы.

Кнопка может поменять цвет и перестать быть серой.

В текущей версии приложения это кнопка, а потом ее поменяют на плитку/выпадашку/любой-другой контрол.

В десктопной версии термин «кликнуть» еще приемлем, в мобильной версии приложения это может быть тап, или свайп, или другое действие.

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

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

Т.е. при описании сценариев желательно не использовать:

Общий алгоритм применения подхода

Чтобы составить тест-кейсы по фиче с помощью техники Use Cases нужно сделать следующее:

Определить, зачем и для кого фича:

Какие категории пользователей есть в вашей целевой аудитории (ЦА).

Зачем люди из каждой категории используют эту фичу.

Какие проблемы они решают с помощью нее.

Выписать, какие есть варианты использования фичи.

Для каждого варианта использования нужно определить:

Какие действующие лица участвуют в сценарии (включая само приложение, ботов и сторонние системы).

Основное направление варианта использования.

Возможные исключения, когда что-то пошло не так.

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

Профит от подхода для тестировщика

С помощью всех этих сценариев можно протестировать требования и прототипы интерфейса от дизайнера раньше, чем задача придет к разработчику. А значит можно предотвратить большое количество переделок и недоделок. Мне в работе эта техника позволяет:

Найти пробелы в бизнес-логике.

Помочь дизайнеру и разработчику разобраться в том, как будет работать фича.

Убедиться, что есть обработка всех возможных ошибок.

Проверить, что пользователь может пройти сценарий от начала до конца.

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

Заключение

Есть много техник, чтобы тестировать требования, и Use Cases, показанные в этой статье — это тоже не панацея от всех бед.

Техника легко ложится на фичи, где есть взаимодействие пользователя с продуктом. И если фича не предусматривает участие человека, но это интеграция двух или более систем, техника все еще применима. Просто действующие лица будут не «Пользователь» и «Система», а «Система 1» и «Система 2».

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

Но не стоит забывать, что требования можно протестировать с помощью других инструментов, например, используя диаграмму «Сущность-Связь» (Entity-relationship), анализируя состояния объектов в продукте (State machine diagram) и т.д. Как при работе с требованиями, так и в тестировании все эти инструменты только усиливают друг друга, но это уже тема для отдельной статьи.

Хабравчане, о каких еще техниках по работе с требованиями вам было бы интересно узнать? Пишите в комментариях, поделюсь в следующих статьях.

Источник статьи: http://habr.com/ru/company/plesk/blog/550550/

Тестирование программного обеспечения — тестирование бизнес-аналитики (BI) с примерами тестовых случаев

Процедура сбора, очистки, интеграции, анализа и обмена данными для определения практического опыта, способствующего развитию бизнеса, известна как бизнес-аналитика (BI). Business Intelligence Testing проверяет организационную информацию, процесс ETL, отчеты BI и гарантирует правильность выполнения. BI-тестирование гарантирует достоверность информации и точность опыта, полученного в процессе BI. Здесь мы обсудим следующие моменты:

События в бизнес-аналитике.
Последовательность тестирования бизнес-аналитики.
Этапы бизнес-аналитики.
Тестовые примеры бизнес-аналитики.
Стратегия тестирования бизнес-аналитики.

Давайте подробно обсудим каждую из этих тем.

События в бизнес-аналитике

Потоком событий бизнес-аналитики являются:

Транзакционные данные клиента (реляционная база данных или OLTP) База данных плоских файлов, записи данных: это тип данных, которые записываются из транзакций клиентов. Эти данные хранятся в виде записей в базе данных плоских файлов. База данных с плоскими файлами — это разновидность базы данных, которая имеет единый формат и не содержит какой-либо индексации или структуры. Это база данных в формате одной таблицы. В основном он сохраняется в формате CSV.
Процессы ETL: метод извлечения данных из многочисленных исходных систем, последующего преобразования данных и загрузки их в хранилище данных известен как процесс ETL. Полная форма ETL — извлечение, преобразование и загрузка. На этом этапе извлекаются данные из базы данных плоских файлов. Преобразование важно, поскольку оно включает в себя различные бизнес-правила, а также сопряжено с некоторым риском просчетов. Это один из самых важных шагов.
Хранилище данных: процесс обработки и сбора данных из разных источников для обеспечения значительного понимания бизнес-данных — это хранилище данных. Он строит анализ данных и отчетность. Это процесс преобразования данных в информацию и периодического предоставления ее пользователю.
Витрина данных: это подмножество хранилища данных, в котором основное внимание уделяется одной предметной области бизнеса. Datamart собирает данные из нескольких источников и гораздо более гибок, чем хранилище данных. Понимание данных строится на этом этапе.
OLAP для создания важной информации бизнес-аналитики: это этап вычислений, который позволяет пользователю выборочно извлекать данные и запрашивать данные, чтобы понять различные точки зрения. Полная форма OLAP — онлайн-аналитическая обработка. Все данные в OLAP представляют собой предварительно суммированные данные, поэтому для выполнения запроса требуется очень меньше времени. Здесь выполняется поиск корреляции между различными данными.

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

MIS: Информационная система управления.
OLAP: онлайн-аналитическая обработка и многомерный анализ.
CRM: управление взаимоотношениями с клиентами.
EIS: Исполнительная информационная система.

Последовательность тестирования бизнес-аналитики

Последовательность тестирования Business Intelligence:

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

2. Проверка преобразования данных. Это место, где необработанные данные обрабатываются в явные для бизнеса данные. Исходный и конечный типы данных должны быть одинаковыми. Первичный ключ, внешний ключ, значение по умолчанию и нулевое значение должны оставаться нетронутыми. Свойства ACID исходного и целевого типов данных должны быть проверены.

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

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

4. Тестирование отчета BI: это то, что рассматривается как бизнес-аналитика. Обратите внимание, что если предыдущие уровни нарушены, отчеты никогда не будут точными, надежными или быстрыми.

Важными моментами являются:

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

Этапы бизнес-аналитики

Тестирование BI состоит из двух этапов:

Этап 1: Обработка и хранение данных:

Исходные данные: данные в исходной системе могут иметь некоторые проблемы с вводом данных. Инженеры BI не могли управлять исходными данными, а это приводило к возможности влиять на исходный отчет. По этой причине жизненно важно проверять целостность исходных данных, чтобы гарантировать их точность.
ETL: после того, как данные были собраны из исходной системы, они затем меняются и передаются в хранилище данных. Это изменение необходимо, поскольку оно включает бизнес-правила, поэтому на этом этапе существует высокая вероятность ошибок и просчетов.
Хранилище данных: независимо от того, не было ли обнаружено ошибок при тестировании исходного кода, проблема может заключаться в хранилище данных. Существует вероятность того, что несколько заказов могут быть пропущены в хранилище данных, что приведет к возникновению этих проблем. Данные по этим заказам были случайно утеряны.

Этап 2: Тестирование BI:

Уровни метаданных: он предоставляет высокоуровневые объекты с простым доступом для бизнес-клиентов. Данные здесь собираются из баз данных, и здесь рассматривается преобразование данных.
Отчеты. Каждый отчет BI состоит из SQL-запросов, подсказок и фильтров. Проблемы могут возникнуть в любой из этих вещей из-за специализированных ошибок или ошибок разработки. Создание этих отчетов является схемой значительного улучшения, поэтому ее следует протестировать, чтобы гарантировать точность всех данных.
Панели мониторинга. Панели мониторинга при тестировании бизнес-аналитики объединяют несколько отчетов с различными данными и графиками. Эти двое вполне могут быть связаны. Как правило, дашборды — это последние поучительные элементы, используемые бизнесом, поэтому их необходимо тестировать.

Тестовые примеры бизнес-аналитики

1. ETL-проверка:

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

2. Постановочные данные:

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

3. Загрузка данных BI:

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

4. Отчеты БИ:

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

Стратегия тестирования бизнес-аналитики

Различные стратегии тестирования Business Intelligence:

Организация и планирование тестирования.
Стратегия и техника проведения теста.
Дизайн текста (например, большинство тестовых случаев сосредоточены на запросе, а не на простом тексте). Это самое важное отличие проектов ETL/Data Warehouse от традиционных тестовых проектов.
Тестовая реализация
Отчетность об ограничениях и завершение проекта.

Источник статьи: http://progler.ru/blog/testirovanie-programmnogo-obespecheniya-testirovanie-biznes-analitiki-bi-s-primerami-testovyh-sluchaev

Фундаментальная теория тестирования

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

Перейдем к основным понятиям

Тестирование программного обеспечения (Software Testing) — проверка соответствия реальных и ожидаемых результатов поведения программы, проводимая на конечном наборе тестов, выбранном определённым образом.

Цель тестирования — проверка соответствия ПО предъявляемым требованиям, обеспечение уверенности в качестве ПО, поиск очевидных ошибок в программном обеспечении, которые должны быть выявлены до того, как их обнаружат пользователи программы.

Для чего проводится тестирование ПО?

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

Принципы тестирования

Принцип 1 — Тестирование демонстрирует наличие дефектов (Testing shows presence of defects).
Тестирование только снижает вероятность наличия дефектов, которые находятся в программном обеспечении, но не гарантирует их отсутствия.
Принцип 2 — Исчерпывающее тестирование невозможно (Exhaustive testing is impossible).
Полное тестирование с использованием всех входных комбинаций данных, результатов и предусловий физически невыполнимо (исключение — тривиальные случаи).
Принцип 3 — Раннее тестирование (Early testing).
Следует начинать тестирование на ранних стадиях жизненного цикла разработки ПО, чтобы найти дефекты как можно раньше.
Принцип 4 — Скопление дефектов (Defects clustering).
Большая часть дефектов находится в ограниченном количестве модулей.
Принцип 5 — Парадокс пестицида (Pesticide paradox).
Если повторять те же тестовые сценарии снова и снова, в какой-то момент этот набор тестов перестанет выявлять новые дефекты.
Принцип 6 — Тестирование зависит от контекста (Testing is context depending). Тестирование проводится по-разному в зависимости от контекста. Например, программное обеспечение, в котором критически важна безопасность, тестируется иначе, чем новостной портал.
Принцип 7 — Заблуждение об отсутствии ошибок (Absence-of-errors fallacy). Отсутствие найденных дефектов при тестировании не всегда означает готовность продукта к релизу. Система должна быть удобна пользователю в использовании и удовлетворять его ожиданиям и потребностям.

Обеспечение качества (QA — Quality Assurance) и контроль качества (QC — Quality Control) — эти термины похожи на взаимозаменяемые, но разница между обеспечением качества и контролем качества все-таки есть, хоть на практике процессы и имеют некоторую схожесть.

QC (Quality Control) — Контроль качества продукта — анализ результатов тестирования и качества новых версий выпускаемого продукта.

К задачам контроля качества относятся:

проверка готовности ПО к релизу;
проверка соответствия требований и качества данного проекта.

QA (Quality Assurance) — Обеспечение качества продукта — изучение возможностей по изменению и улучшению процесса разработки, улучшению коммуникаций в команде, где тестирование является только одним из аспектов обеспечения качества.

К задачам обеспечения качества относятся:

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

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

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

Валидация (validation) — это определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, его требованиям к системе.

Пример: когда разрабатывали аэробус А310, то надо было сделать так, чтобы закрылки вставали в положение «торможение», когда шасси коснулись земли. Запрограммировали так, что когда шасси начинают крутиться, то закрылки ставим в положение «торможение». Но вот во время испытаний в Варшаве самолет выкатился за пределы полосы, так как была мокрая поверхность. Он проскользил, только потом был крутящий момент и они, закрылки, открылись. С точки зрения «верификации» — программа сработала, с точки зрения «валидации» — нет. Поэтому код изменили так, чтобы в момент изменения давления в шинах открывались закрылки.

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

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

Этапы тестирования:

Анализ продукта
Работа с требованиями
Разработка стратегии тестирования и планирование процедур контроля качества
Создание тестовой документации
Тестирование прототипа
Основное тестирование
Стабилизация
Эксплуатация

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

Программный продукт проходит следующие стадии:

анализ требований к проекту;
проектирование;
реализация;
тестирование продукта;
внедрение и поддержка.

Требования

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

Корректность — точное описание разрабатываемого функционала.
Проверяемость — формулировка требований таким образом, чтобы можно было выставить однозначный вердикт, выполнено все в соответствии с требованиями или нет.
Полнота — в требовании должна содержаться вся необходимая для реализации функциональности информация.
Недвусмысленность — требование должно содержать однозначные формулировки.
Непротиворечивость — требование не должно содержать внутренних противоречий и противоречий другим требованиям и документам.
Приоритетность — у каждого требования должен быть приоритет(количественная оценка степени значимости требования). Этот атрибут позволит грамотно управлять ресурсами на проекте.
Атомарность — требование нельзя разбить на отдельные части без потери деталей.
Модифицируемость — в каждое требование можно внести изменение.
Прослеживаемость — каждое требование должно иметь уникальный идентификатор, по которому на него можно сослаться.

Дефект (bug) — отклонение фактического результата от ожидаемого.

Отчёт о дефекте (bug report) — документ, который содержит отчет о любом недостатке в компоненте или системе, который потенциально может привести компонент или систему к невозможности выполнить требуемую функцию.

Атрибуты отчета о дефекте:

Уникальный идентификатор (ID) — присваивается автоматически системой при создании баг-репорта.
Тема (краткое описание, Summary) — кратко сформулированный смысл дефекта, отвечающий на вопросы: Что? Где? Когда(при каких условиях)?
Подробное описание (Description) — более широкое описание дефекта (указывается опционально).
Шаги для воспроизведения (Steps To Reproduce) — описание четкой последовательности действий, которая привела к выявлению дефекта. В шагах воспроизведения должен быть описан каждый шаг, вплоть до конкретных вводимых значений, если они играют роль в воспроизведении дефекта.
Фактический результат (Actual result) — описывается поведение системы на момент обнаружения дефекта в ней. чаще всего, содержит краткое описание некорректного поведения(может совпадать с темой отчета о дефекте).
Ожидаемый результат (Expected result) — описание того, как именно должна работать система в соответствии с документацией.
Вложения (Attachments) — скриншоты, видео или лог-файлы.
Серьёзность дефекта (важность, Severity) — характеризует влияние дефекта на работоспособность приложения.
Приоритет дефекта (срочность, Priority) — указывает на очерёдность выполнения задачи или устранения дефекта.
Статус (Status) — определяет текущее состояние дефекта. Статусы дефектов могут быть разными в разных баг-трекинговых системах.
Окружение (Environment) – окружение, на котором воспроизвелся баг.

Жизненный цикл бага

Severity vs Priority

Серьёзность (severity) показывает степень ущерба, который наносится проекту существованием дефекта. Severity выставляется тестировщиком.

Градация Серьезности дефекта (Severity):

Блокирующий (S1 – Blocker)
тестирование значительной части функциональности вообще недоступно. Блокирующая ошибка, приводящая приложение в нерабочее состояние, в результате которого дальнейшая работа с тестируемой системой или ее ключевыми функциями становится невозможна.
Критический (S2 – Critical)
критическая ошибка, неправильно работающая ключевая бизнес-логика, дыра в системе безопасности, проблема, приведшая к временному падению сервера или приводящая в нерабочее состояние некоторую часть системы, то есть не работает важная часть одной какой-либо функции либо не работает значительная часть, но имеется workaround (обходной путь/другие входные точки), позволяющий продолжить тестирование.
Значительный (S3 – Major)
не работает важная часть одной какой-либо функции/бизнес-логики, но при выполнении специфических условий, либо есть workaround, позволяющий продолжить ее тестирование либо не работает не очень значительная часть какой-либо функции. Также относится к дефектам с высокими visibility – обычно не сильно влияющие на функциональность дефекты дизайна, которые, однако, сразу бросаются в глаза.
Незначительный (S4 – Minor)
часто ошибки GUI, которые не влияют на функциональность, но портят юзабилити или внешний вид. Также незначительные функциональные дефекты, либо которые воспроизводятся на определенном устройстве.
Тривиальный (S5 – Trivial)
почти всегда дефекты на GUI — опечатки в тексте, несоответствие шрифта и оттенка и т.п., либо плохо воспроизводимая ошибка, не касающаяся бизнес-логики, проблема сторонних библиотек или сервисов, проблема, не оказывающая никакого влияния на общее качество продукта.

Срочность (priority) показывает, как быстро дефект должен быть устранён. Priority выставляется менеджером, тимлидом или заказчиком

Градация Приоритета дефекта (Priority):

P1 Высокий (High)
Критическая для проекта ошибка. Должна быть исправлена как можно быстрее.
P2 Средний (Medium)
Не критичная для проекта ошибка, однако требует обязательного решения.
P3 Низкий (Low)
Наличие данной ошибки не является критичным и не требует срочного решения. Может быть исправлена, когда у команды появится время на ее устранение.

Существует шесть базовых типов задач:

Эпик (epic) — большая задача, на решение которой команде нужно несколько спринтов.
Требование (requirement ) — задача, содержащая в себе описание реализации той или иной фичи.
История (story) — часть большой задачи (эпика), которую команда может решить за 1 спринт.
Задача (task) — техническая задача, которую делает один из членов команды.
Под-задача (sub-task) — часть истории / задачи, которая описывает минимальный объем работы члена команды.
Баг (bug) — задача, которая описывает ошибку в системе.

Тестовые среды

Основные фазы тестирования

Основные виды тестирования ПО

Вид тестирования — это совокупность активностей, направленных на тестирование заданных характеристик системы или её части, основанная на конкретных целях.

Классификация по запуску кода на исполнение:
- Статическое тестирование — процесс тестирования, который проводится для верификации практически любого артефакта разработки: программного кода компонент, требований, системных спецификаций, функциональных спецификаций, документов проектирования и архитектуры программных систем и их компонентов.
- Динамическое тестирование — тестирование проводится на работающей системе, не может быть осуществлено без запуска программного кода приложения.
Классификация по доступу к коду и архитектуре:
- Тестирование белого ящика — метод тестирования ПО, который предполагает полный доступ к коду проекта.
- Тестирование серого ящика — метод тестирования ПО, который предполагает частичный доступ к коду проекта (комбинация White Box и Black Box методов).
- Тестирование чёрного ящика — метод тестирования ПО, который не предполагает доступа (полного или частичного) к системе. Основывается на работе исключительно с внешним интерфейсом тестируемой системы.
Классификация по уровню детализации приложения:
- Модульное тестирование — проводится для тестирования какого-либо одного логически выделенного и изолированного элемента (модуля) системы в коде. Проводится самими разработчиками, так как предполагает полный доступ к коду.
- Интеграционное тестирование — тестирование, направленное на проверку корректности взаимодействия нескольких модулей, объединенных в единое целое.
- Системное тестирование — процесс тестирования системы, на котором проводится не только функциональное тестирование, но и оценка характеристик качества системы — ее устойчивости, надежности, безопасности и производительности.
- Приёмочное тестирование — проверяет соответствие системы потребностям, требованиям и бизнес-процессам пользователя.
Классификация по степени автоматизации:
- Ручное тестирование.
- Автоматизированное тестирование.
Классификация по принципам работы с приложением
- Позитивное тестирование — тестирование, при котором используются только корректные данные.
- Негативное тестирование — тестирование приложения, при котором используются некорректные данные и выполняются некорректные операции.
Классификация по уровню функционального тестирования:
- Дымовое тестирование (smoke test) — тестирование, выполняемое на новой сборке, с целью подтверждения того, что программное обеспечение стартует и выполняет основные для бизнеса функции.
- Тестирование критического пути (critical path) — направлено для проверки функциональности, используемой обычными пользователями во время их повседневной деятельности.
- Расширенное тестирование (extended) — направлено на исследование всей заявленной в требованиях функциональности.
Классификация в зависимости от исполнителей:
- Альфа-тестирование — является ранней версией программного продукта. Может выполняться внутри организации-разработчика с возможным частичным привлечением конечных пользователей.
- Бета-тестирование — программное обеспечение, выпускаемое для ограниченного количества пользователей. Главная цель — получить отзывы клиентов о продукте и внести соответствующие изменения.
Классификация в зависимости от целей тестирования:
- Функциональное тестирование (functional testing) — направлено на проверку корректности работы функциональности приложения.
- Нефункциональное тестирование (non-functional testing) — тестирование атрибутов компонента или системы, не относящихся к функциональности.

Тестирование производительности (performance testing) — определение стабильности и потребления ресурсов в условиях различных сценариев использования и нагрузок.
Нагрузочное тестирование (load testing) — определение или сбор показателей производительности и времени отклика программно-технической системы или устройства в ответ на внешний запрос с целью установления соответствия требованиям, предъявляемым к данной системе (устройству).
Тестирование масштабируемости (scalability testing) — тестирование, которое измеряет производительность сети или системы, когда количество пользовательских запросов увеличивается или уменьшается.
Объёмное тестирование (volume testing) — это тип тестирования программного обеспечения, которое проводится для тестирования программного приложения с определенным объемом данных.
Стрессовое тестирование (stress testing) — тип тестирования направленный для проверки, как система обращается с нарастающей нагрузкой (количеством одновременных пользователей).
Инсталляционное тестирование (installation testing) — тестирование, направленное на проверку успешной установки и настройки, обновления или удаления приложения.
Тестирование интерфейса (GUI/UI testing) — проверка требований к пользовательскому интерфейсу.
Тестирование удобства использования (usability testing) — это метод тестирования, направленный на установление степени удобства использования, понятности и привлекательности для пользователей разрабатываемого продукта в контексте заданных условий.
Тестирование локализации (localization testing) — проверка адаптации программного обеспечения для определенной аудитории в соответствии с ее культурными особенностями.
Тестирование безопасности (security testing) — это стратегия тестирования, используемая для проверки безопасности системы, а также для анализа рисков, связанных с обеспечением целостного подхода к защите приложения, атак хакеров, вирусов, несанкционированного доступа к конфиденциальным данным.
Тестирование надёжности (reliability testing) — один из видов нефункционального тестирования ПО, целью которого является проверка работоспособности приложения при длительном тестировании с ожидаемым уровнем нагрузки.
Регрессионное тестирование (regression testing) — тестирование уже проверенной ранее функциональности после внесения изменений в код приложения, для уверенности в том, что эти изменения не внесли ошибки в областях, которые не подверглись изменениям.
Повторное/подтверждающее тестирование (re-testing/confirmation testing) — тестирование, во время которого исполняются тестовые сценарии, выявившие ошибки во время последнего запуска, для подтверждения успешности исправления этих ошибок.

Тест-дизайн — это этап тестирования ПО, на котором проектируются и создаются тестовые случаи (тест-кейсы).

Автор книги “A Practitioner’s Guide to Software Test Design”, Lee Copeland, выделяет следующие техники тест-дизайна:

Тестирование на основе классов эквивалентности (equivalence partitioning) — это техника, основанная на методе чёрного ящика, при которой мы разделяем функционал (часто диапазон возможных вводимых значений) на группы эквивалентных по своему влиянию на систему значений.
Техника анализа граничных значений (boundary value testing) — это техника проверки поведения продукта на крайних (граничных) значениях входных данных.
Попарное тестирование (pairwise testing) — это техника формирования наборов тестовых данных из полного набора входных данных в системе, которая позволяет существенно сократить количество тест-кейсов.
Тестирование на основе состояний и переходов (State-Transition Testing) — применяется для фиксирования требований и описания дизайна приложения.
Таблицы принятия решений (Decision Table Testing) — техника тестирования, основанная на методе чёрного ящика, которая применяется для систем со сложной логикой.
Доменный анализ (Domain Analysis Testing) — это техника основана на разбиении диапазона возможных значений переменной на поддиапазоны, с последующим выбором одного или нескольких значений из каждого домена для тестирования.
Сценарий использования (Use Case Testing) — Use Case описывает сценарий взаимодействия двух и более участников (как правило — пользователя и системы).

Методы тестирования

Тестирование белого ящика — метод тестирования ПО, который предполагает, что внутренняя структура/устройство/реализация системы известны тестировщику.

Согласно ISTQB, тестирование белого ящика — это:

тестирование, основанное на анализе внутренней структуры компонента или системы;
тест-дизайн, основанный на технике белого ящика — процедура написания или выбора тест-кейсов на основе анализа внутреннего устройства системы или компонента.
Почему «белый ящик»? Тестируемая программа для тестировщика — прозрачный ящик, содержимое которого он прекрасно видит.

Тестирование серого ящика — метод тестирования ПО, который предполагает комбинацию White Box и Black Box подходов. То есть, внутреннее устройство программы нам известно лишь частично.

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

Согласно ISTQB, тестирование черного ящика — это:

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

Тестовая документация

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

Тест план должен отвечать на следующие вопросы:

Что необходимо протестировать?
Как будет проводиться тестирование?
Когда будет проводиться тестирование?
Критерии начала тестирования.
Критерии окончания тестирования.

Основные пункты тест плана:

Идентификатор тест плана (Test plan identifier);
Введение (Introduction);
Объект тестирования (Test items);
Функции, которые будут протестированы (Features to be tested;)
Функции, которые не будут протестированы (Features not to be tested);
Тестовые подходы (Approach);
Критерии прохождения тестирования (Item pass/fail criteria);
Критерии приостановления и возобновления тестирования (Suspension criteria and resumption requirements);
Результаты тестирования (Test deliverables);
Задачи тестирования (Testing tasks);
Ресурсы системы (Environmental needs);
Обязанности (Responsibilities);
Роли и ответственность (Staffing and training needs);
Расписание (Schedule);
Оценка рисков (Risks and contingencies);
Согласования (Approvals).

Чек-лист (check list) — это документ, который описывает что должно быть протестировано. Чек-лист может быть абсолютно разного уровня детализации.

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

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

Предусловия (PreConditions) — список действий, которые приводят систему к состоянию пригодному для проведения основной проверки. Либо список условий, выполнение которых говорит о том, что система находится в пригодном для проведения основного теста состояния.
Шаги (Steps) — список действий, переводящих систему из одного состояния в другое, для получения результата, на основании которого можно сделать вывод о удовлетворении реализации, поставленным требованиям.
Ожидаемый результат (Expected result) — что по факту должны получить.

Источник статьи: http://habr.com/ru/post/549054/

Как наконец-то начать писать тесты и не пожалеть об этом

Приходя на новый проект, я регулярно сталкиваюсь с одной из следующих ситуаций:

Тестов нет совсем.
Тестов мало, их редко пишут и не запускают на постоянной основе.
Тесты присутствуют и включены в CI (Continuous Integration), но приносят больше вреда, чем пользы.

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

Что можно сделать, чтобы изменить сложившуюся ситуацию? Идея использования тестов не нова. При этом большинство туториалов напоминают знаменитую картинку про то, как нарисовать сову: подключаем JUnit, пишем первый тест, используем первый мок — и вперед! Такие статьи не отвечают на вопросы о том, какие тесты нужно писать, на что стоит обращать внимание и как со всем этим жить. Отсюда и родилась идея данной статьи. Я постарался кратко обобщить свой опыт внедрения тестов в разных проектах, чтобы облегчить этот путь для всех желающих.

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

Так как моя основная специализация — Java backend, то в примерах будет использован следующий стек технологий: Java, JUnit, H2, Mockito, Spring, Hibernate. При этом значительная часть статьи посвящена общим вопросам тестирования и советы в ней применимы к гораздо более широкому кругу задач.

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

Тесты vs скорость разработки

Главные вопросы, которые возникают при обсуждении внедрения тестирования: сколько времени займет написание тестов и какие преимущества это будет иметь? Тестирование, как и любая другая технология, потребует серьезных усилий на освоение и внедрение, поэтому на первых порах никакой значимой выгоды ожидать не стоит. Что касается временных затрат, то они сильно зависят от конкретной команды. Однако меньше чем на 20–30 % дополнительных затрат на кодирование рассчитывать точно не стоит. Меньшего просто не хватит для достижения хоть какого-то результата. Ожидание мгновенной отдачи часто является главной причиной сворачивания этой деятельности еще до того, как тесты станут приносить пользу.

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

Запуск кода в произвольном месте

При отсутствии тестов в проекте единственным способом запуска является поднятие приложения целиком. Хорошо, если на это будет уходить секунд 15–20, но далеко не редки случаи больших проектов, в которых полноценный запуск может занимать от нескольких минут. Что же это означает для разработчиков? Существенную часть их рабочего времени будут составлять эти короткие сессии ожидания, на протяжении которых нельзя продолжать работать над текущей задачей, но при этом времени на переключение на что-то другое слишком мало. Многие хотя бы раз сталкивались с такими проектами, где написанный за час код требует многочасовой отладки из-за долгих перезапусков между исправлениями. В тестах же можно ограничиться запуском маленьких частей приложения, что позволит значительно сократить время ожидания и повысит продуктивность работы над кодом.

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

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

Повторный запуск тестов

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

Во-первых, каждый новый пришедший на проект разработчик сможет легко запустить имеющиеся тесты, чтобы разобраться в логике приложения на примерах. К сожалению, важность этого сильно недооценена. В современных условиях одни и те же люди редко работают над проектом дольше 1–2 лет. А так как команды состоят из нескольких человек, то появление нового участника каждые 2–3 месяца — типичная ситуация для относительно крупных проектов. Особо тяжелые проекты переживают смены целых поколений разработчиков! Возможность легко запустить любую часть приложения и посмотреть на поведение системы в разы упрощает погружение новых программистов в проект. Кроме того, более детальное изучение логики кода уменьшает количество допущенных ошибок на выходе и время на их отладку в будущем.

Во-вторых, возможность легко убедиться в том, что приложение работает корректно, открывает дорогу для непрерывного рефакторинга (Continuous Refactoring). Этот термин, к сожалению, гораздо менее популярен, чем CI. Он означает, что рефакторинг можно и нужно делать при каждой доработке кода. Именно регулярное следование небезызвестному правилу бойскаута «оставь место стоянки чище, чем оно было до твоего прихода», позволяет избегать деградации кодовой базы и гарантирует проекту долгую и счастливую жизнь.

Отладка

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

Эффективность

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

От теории к практике

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

Задача

В качестве шаблонной задачки рассмотрим небольшой фрагмент бэкенда интернет-магазина. Напишем типовой API для работы с продуктами: создание, получение, редактирование. А также пару методов для работы с клиентами: смена «любимого продукта» и расчет бонусных баллов по заказу.

Доменная модель

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

У клиента (Customer) есть логин, ссылка на любимый продукт и флаг, указывающий на то, является ли он премиальным клиентом.

У продукта (Product) — название, цена, скидка и флаг, указывающий на то, рекламируется ли он в данный момент.

Структура проекта

Структура основного кода проекта выглядит следующим образом.

Model — доменная модель проекта;
Jpa — репозитории для работы с БД на основе Spring Data;
Service — бизнес-логика приложения;
Controller — контроллеры, реализующие API.

Структура юнит-тестов.

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

Удобно разделять юнит-тесты и интеграционные тесты. Они зачастую имеют разные зависимости, и для комфортной разработки должна быть возможность запустить либо одни, либо другие. Этого можно добиться разными способами: конвенции именования, модули, пакеты, sourceSets. Выбор конкретного способа — исключительно вопрос вкуса. В данном проекте интеграционные тесты лежат в отдельном sourceSet — integrationTest.

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

Интеграционные тесты

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

Для начала надо определиться, на каком конкретно уровне будут выполняться интеграционные проверки. Spring Boot предоставляет полную свободу выбора: можно поднимать часть контекста, весь контекст и даже полноценный сервер, доступный из тестов. При увеличении размера приложения этот вопрос становится все более сложным. Часто приходится писать разные тесты на разных уровнях.

Хорошей точкой старта будут тесты контроллеров без запуска сервера. В относительно небольших приложениях вполне приемлемо поднимать весь контекст целиком, так как по умолчанию он переиспользуется между тестами и инициализируется только один раз. Рассмотрим основные методы класса ProductController :

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

Репозиторий ProductRepository вообще не содержит собственных методов:

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

Для удобства выделим базовый класс BaseControllerIT , который содержит конфигурацию Spring и пару полей:

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

Основная конфигурация Spring задается следующими строчками:

@SpringBootTest — используется для того, чтобы задать контекст приложения. WebEnvironment.NONE означает, что веб-контекст поднимать не надо.

@Transactional — оборачивает все тесты класса в транзакцию с автоматическим откатом для сохранения состояния базы.

Перейдем к минималистичному набору тестов для класса ProductController — ProductControllerIT .

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

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

В другом тесте на обновление информации о продукте ( updateProduct ) видно, что создание данных стало немного сложнее и для сохранения визуальной целостности трех частей теста они отделены двумя переводами строк подряд:

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

Тестовые билдеры заслуживают отдельного внимания. Инкапсуляция логики создания объектов упрощает сопровождение тестов. В частности, заполнение не релевантных данному тесту полей модели можно скрыть внутри билдера. Для этого нужно не создавать его напрямую, а использовать статический метод, который заполнит недостающие поля значениями по умолчанию. Например, в случае появления новых обязательных полей в модели их можно будет легко добавить в этот метод. В ProductBuilder он выглядит так:

Крайне важно понимать, что конкретно проверяется в данном тесте. Для наглядности лучше всего дать ответ на этот вопрос в его названии. На примере тестов для метода getProduct рассмотрим используемую конвенцию именования:

В общем случае заголовок тестового метода состоит из трех частей, разделенных подчеркиванием: имя тестируемого метода, сценарий, ожидаемый результат. Однако здравый смысл никто не отменял, и вполне оправданным может быть опускание каких-то частей названия, если они не нужны в данном контексте (например, сценарий в единственном тесте на создание продукта). Цель такого именования — добиться того, чтобы суть каждого теста была понятна без изучения кода. Это делает окошко результатов прохождения тестов максимально наглядным, а именно с него обычно и начинается работа с тестами.

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

Стоит обратить внимание, что такие тесты не проверяют веб-слой приложения, однако зачастую этого и не требуется. При необходимости можно написать отдельные тесты для веб-слоя с заглушкой вместо базы ( @WebMvcTest , MockMvc , @MockBean ) или использовать полноценный сервер. Последнее может затруднить отладку и усложнить работу с транзакциями, поскольку транзакцию сервера тест уже контролировать не сможет. Пример такого интеграционного теста можно посмотреть в классе CustomerControllerServerIT .

Юнит-тесты

Юнит-тесты имеют ряд преимуществ перед интеграционными:

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

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

Единственный класс в данном примере, который заслуживает юнит-тестирования, — это BonusPointCalculator . Его отличительная особенность — большое количество ветвлений бизнес-логики. Например, предполагается, что покупатель получает бонусами 10 % от стоимости продукта, помноженные на не более чем 2 мультипликатора из следующего списка:

Продукт стоит больше 10 000 (× 4);
Продукт участвует в рекламной кампании (× 3);
Продукт является «любимым» продуктом клиента (× 5);
Клиент имеет премиальный статус (× 2);
В случае, если клиент имеет премиальный статус и покупает «любимый» продукт, вместо двух обозначенных мультипликаторов используется один (× 8).

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

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

Соответствующий набор тестов можно посмотреть в классе BonusPointCalculatorTest . Вот некоторые из них:

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

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

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

Первые тесты написаны, что дальше?

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

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

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

Заключение

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

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

Источник статьи: http://habr.com/ru/company/custis/blog/427603/

Как провести модульное тестирование бизнес-правил?

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

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

Мой вопрос: как правильно изменять бизнес-правила модульного тестирования?

5 ответов

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

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

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

У меня аналогичная настройка – однако мои бизнес-правила скомпилированы, но имеют настраиваемые параметры (ваши могут отличаться). Когда бизнес-правило меняет основной способ своей работы, мои модульные тесты ломаются. Это действительно ожидаемо – и хорошо! Это означает, что я могу изолировать любые неожиданные колебания в моей системе и обновить тесты, чтобы они соответствовали изменениям.

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

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

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

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

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

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

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

Кажется правильным, что тест не проходит, если правила меняются – этого и следовало ожидать.

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

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

Я думаю это неправильный вопрос Бизнес-правило и модульный тест находятся на разных уровнях абстракции. Бизнес-правило находится на верхнем уровне абстракции (бизнес-моделирование), но модульный тест предназначен для тестирования модуля кода, который находится на самом низком уровне абстракции, поэтому вы не можете использовать модульный тест для проверки или подтверждения бизнеса. правило. Кроме того, бизнес-правило после анализа и разработки может повлиять на несколько единиц кода, поэтому вы снова не можете использовать модульный тест для проверки или проверки бизнес-правила . Я думаю, вы можете использовать тестовый пример или сценарий BDD для проверки и проверки бизнес-правила.

Источник статьи: http://question-it.com/questions/5223416/kak-provesti-modulnoe-testirovanie-biznes-pravil

unit-тестирование здорового человека ч.1

Вступление

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

Я считаю, что такой пример опасен и ведет лишь к ложным ориентирам.

Часто это говорят те, кто вместо полноценной разработке и последующей поддержки, пишет код сразу в прод и забывает о нем навсегда.

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

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

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

Я собрал здесь множество советов и практик, которые юзал много лет на проектах разных масштабов и технологий. Будь это аутсорс или продукт. Mobile или front-end.

В гугле есть 2 термина для таких спецов:

кодеры, кто наклепал и забыл

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

Программная инженерия охватывает не только написание кода, но и все инструменты и процессы создания и дальнейшей поддержки этого кода (с) “Делай как в Google. Разработка программного обеспечения”

Содержание:

Кто это такой ваш юнит-тест?

Проверка только самых важных частей кода

Свойства идеальных тестов

Когда не стоит проводить unit-тестирование

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

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

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

Хороший тестировщик учит и менторит всех в команде как следить за качеством.

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

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

Если рассматривать программирование как жизнь на земле, то TDD окажется аналогом квантовой механики . Рефакторинг будет соответствовать химии, а простота проектирования — микробиологии . На уровне физиологии у нас окажутся принципы SOLID, объектно-ориентированное проектирование и функциональное программирование, а на уровне экологии — архитектура. Соответственно, получить чистый код без TDD сложно или невозможно. (c) Роберт Мартин

Недостатки e2e и интеграционных тестов

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

Автоматизированные тесты не должны осуществлять проверку бизнес-правил через пользовательский интерфейс. (c) Роберт Мартин

Это очень распространенная проблема, когда клиентские приложения проверяют корректность бизнес-логики через UI пользователя. Почему это плохо?

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

Некоторая бизнес-логика не зависят от View слоя или имеют его по-минимуму.

Дорого для корнер-кейсов. Создавать e2e или компонентные тесты дорого по времени для всех состояний. Часто пишут только один успешный сценарий

Долгий запуск других тестов. Обычно е2е запускаются рано утром и могут достигать 20-40 часов ожидания.

Часто дорогие тесты детектят только факт падения, но не дают причины

Чем полезны unit-тесты

Модульное тестирование (unit testing) — тесты, задача которых проверить каждый класс системы по отдельности. Желательно, чтобы это были минимально делимые кусочки системы, например, модули. Unit-тесты — это тесты для одного класса. Такие тесты используют для тщательной проверки сложной логики и алгоритмов, инкапсулированных в одном классе. Желательно, чтобы у таких классов не было изменяемых зависимостей.

Зачем нужны юнит-тесты?

цель — обеспечение стабильного роста программного проекта. Ключевым словом здесь является «стабильный». В начале жизни проекта развивать его довольно просто. Намного сложнее поддерживать это развитие с прошествием времени.

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

Плюсы юнит-тестов:

Выгода на долгой дистанции.

Рефакторинг. Огромные главы у того же Мартина о бесполезности рефакторинга без юнит-тестов

Скорость поддержки. Намного легче находить дефекты, баги, браки

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

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

Юнит-тест позволяет найти баги на этапе разработки. Зафиксировать поведение и гарантировать, что этот кейс был проверен

Рефакторинг — это практика, позволяющая писать чистый код . Она трудно реализуема, а порой и невозможна без TDD. Соответственно, получить чистый код без TDD сложно или невозможно. (с) все тот же дядька Мартин

Проверка только самых важных частей кода

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

Тестирование бизнес-логики обеспечивает тестам наилучшую эффективность.

Все остальные части можно разделить на три категории:

внешние сервисы и зависимости — например, базы данных и сторонние системы;

код, связывающий все компоненты воедино.

Метрики

Code Coverage: наиболее часто используемая метрика покрытия — code coverage, также известная как test coverage. Эта метрика равна отношению количества строк кода, выполняемых по крайней мере одним тестом, к общему количеству строк в основном коде проекта.

Code coverage (test coverage) = Количество выполненных строк кода / Общее количество строк кода

Покрытие в этом примере вычисляется легко. Общее количество строк в методе равно 5. Количество строк, выполняемых в тесте, равно 4 — тест проходит все строки кода, кроме команды return true. Таким образом, покрытие равно 4/5 = 0,8 = 80 %.

Что будет, если отрефакторить этот метод и убрать избыточную команду if?

Изменился ли процент покрытия? Да, изменился. Покрытие кода увеличилось до 100 %. Но улучшилось ли качество тестов с таким рефакторингом? Конечно же, нет. Тест по-прежнему проверяет то же количество ветвлений в коде. Этот простой пример показывает, как легко подтасовать процент покрытия. Чем компактнее ваш код, тем лучше становится этот процент, потому что в нем учитывается только количество строк. В то же время попытки втиснуть больше кода в меньший объем не изменяют общую эффективность тестов.

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

Branch coverage:

Другая метрика покрытия называется branch coverage (покрытием ветвей).

Branch coverage показывает более точные результаты, чем code coverage. Вместо того чтобы использовать количество строк кода, эта метрика ориентируется на управляющие структуры — такие как команды if и switch. Она показывает, какое количество таких управляющих структур обходится по крайней мере одним тестом в проекте

Branch coverage = Количество покрытых ветвей / Общее количество ветвей

Чтобы вычислить метрику branch coverage, необходимо подсчитать все возможные ветви (branches) в коде и посмотреть, сколько из них выполняются тестами. Вернемся к предыдущему примеру со строкой.

Метод IsStringLong содержит две ветви: одна для ситуации, в которой длина строкового аргумента превышает пять символов, и другая для строк, длина которых менее или равна 5 символам. Тест покрывает только одну из этих ветвей, поэтому метрика покрытия составляет 1/2 = 0,5 = 50 %. При этом неважно, какое представление будет выбрано для тестируемого кода — будете ли вы использовать команду if, как прежде, или выберете более короткую запись. Метрика branch coverage принимает во внимание только количество ветвей; она не учитывает, сколько строк кода понадобилось для реализации этих ветвей.

Свойства идеальных тестов:

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

объем кода, выполняемого тестом

важность этого кода с точки зрения бизнес-логик

Как правило, чем больше кода тест выполняет, тем выше вероятность выявить в нем баг

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

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

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

простота поддержки — оценивает затраты на сопровождение кода. Метрика состоит из двух компонентов:

Насколько сложно тест понять. Этот компонент связан с размером теста. Чем меньше кода в тесте, тем проще он читается.

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

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

Когда не стоит проводить unit-тестирование

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

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

отсутствии четких результатов — например, в математическом моделировании природных процессов, настолько сложных, что их «выход» невозможно спрогнозировать, а можно только описать в виде интервалов вероятных значений;

тестировании кода, взаимодействующего с системой, — например, модуля, связанного с портами, таймерами и другими «нестабильными» компонентами, от которых его сложно изолировать;

проверке всего приложения — модульное тестирование не покажет ошибки интеграции, баги ядра и другие аспекты, не относящиеся непосредственно к конкретному модулю;

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

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

Антипатерны

Тестовый код не должен дублироваться.

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

Не ориентируйтесь ни на какую конкретную реализацию при написании тестов. Проверяйте рабочий код с точки зрения «черного ящика»

Закомментированные или выключенные тесты. Тесты всегда должны находиться в рабочем и актуальном состоянии.

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

Изоляция теста

Вопрос изоляции — это корень различий между классической и лондонской школой юнит-тестирования

Что же означает «изоляция кода» в юнит-тестировании? Есть 2 школы тестирования: лондонская и классическая.

Лондонская школа описывает это как изоляцию тестируемого кода от его зависимостей. Это означает, что если класс имеет зависимость от другого класса или нескольких классов, все такие зависимости должны быть заменены на тестовые заглушки (test doubles). Это позволит вам сосредоточиться исключительно на тестируемом классе, изолировав его поведение от внешнего влияния

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

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

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

Источник статьи: http://habr.com/ru/post/709228/

А/В-тестирование: зачем нужно и как помогает бизнесу

Давайте разберёмся, что такое A/B-тестирование, какие бизнес-задачи решает, а также рассмотрим примеры тестов для разных отраслей. Адаптированный перевод гайда по A/B-тестам от компании VWO.

Куратор факультета «Аналитика и Data Science» Нетологии

Что такое A/B-тестирование

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

Компании заинтересованы в том, чтобы посетители совершали на сайте целевые действия. То, насколько это удаётся, измеряется коэффициентом конверсии.

Чем лучше оптимизирована воронка, тем выше конверсия.

A/B-тестирование — это способ оптимизации воронки сайта. Иногда его называют сплит-тестированием. Вы показываете два варианта одной веб-страницы разным сегментам посетителей и анализируете, какой вариант приводит к наилучшей конверсии. Выигрышный вариант поможет оптимизировать сайт и достичь лучших результатов.

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

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

Какие задачи бизнеса решают A/B-тесты

Электронная коммерция борется с брошенными корзинами, b2b страдают от некачественных лидов, а СМИ и издательства наблюдают низкую вовлечённость читателей. На показатели конверсии влияют распространённые проблемы: «утечки конверсии», потеря клиента на этапе оплаты и другие.

Давайте посмотрим, как A/B-тестирование поможет избавиться от этих проблем.

Решают проблемы пользователей

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

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

Это актуально для всех сфер, будь то электронная коммерция, туризм, SaaS, образование, СМИ или издательский бизнес.

Обеспечивают лучшую окупаемость инвестиций (ROI)

Маркетологи знают, каким дорогим бывает качественный трафик. A/B-тестирование позволяет эффективно использовать существующий трафик и помогает повысить конверсию без затрат на привлечение нового. Иногда даже незначительные изменения влияют на конверсию.

Уменьшают показатель отказов

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

Но решение есть: в каждом случае поможет A/B-тестирование. Можно протестировать несколько вариантов расположения элементов на сайте и найти оптимальное решение.

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

Снижают риски при изменениях

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

A/B-тесты позволяют получать хороший результат и при этом вносить лишь небольшие изменения, что приводит к увеличению ROI.

В качестве примера приведём изменения в описании продукта. Вы можете сделать A/B-тест, когда нужно удалить или обновить описание продукта и не знаете, как посетители будут реагировать на это.

Другой пример модификации с низким риском — добавление новой функции. A/B-тест поможет сделать результат внедрения более предсказуемым.

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

Обеспечивают статистически значимые улучшения

A/B-тестирование полностью основано на данных и не оставляет места для догадок. Поэтому можно легко определить «победителя» и «проигравшего» на основе статистически значимых улучшений: показателей времени на странице, число запросов пробников, количество брошенных корзин, CTR.

Помогают улучшить дизайн

Редизайн может быть разным: от небольших изменений цвета до полного изменения сайта. Решение об изменениях важно принимать на основании данных A/B-тестов.

Улучшение дизайна — непрерывный процесс. Если что-то изменили на сайте, протестируйте элементы, которые остались нетронутыми, и убедитесь, что используете лучшую версию ✌

Примеры A/B-тестов

Медиа и издательское дело

Издания стремятся увеличивать количество читателей, подписчиков, проведённое время на сайте, количество просмотров на самом сайте и в соцсетях.

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

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

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

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

Электронная коммерция

A/B-тестирование помогает интернет-магазинам повысить средний чек, оптимизировать воронку заказа, уменьшить количество брошенных корзин.

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

Amazon — лидер по оптимизации конверсии. И дело не только в масштабе, но и в стремлении предоставить клиентам удобный сервис.

В конце 90-х после длительных испытаний компания запустила опцию «Заказ в один клик», которая позволяет делать покупки без добавления товара в корзину. Пользователю достаточно всего один раз ввести данные карты и адрес доставки. Для заказа останется нажать на кнопку и ждать доставку. Заказ в один клик оказался настолько удобен, что у клиентов пропало желание заказывать товары на других сайтах.

Это изменение так сильно повлияло на бизнес, что в 1999 году Amazon запатентовала опцию «Заказ в один клик». К слову, в 2000 году лицензию купила компания Apple для своего интернет-магазина.

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

Давайте рассмотрим пример с корзиной для покупок.

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

Продолжить покупки (если в корзину не добавлено ни одного товара).
Узнать об актуальных предложениях (если в корзину не добавлено ни одного товара).
Вишлист (также если в корзину не добавлено ни одного товара).

Перейти к оформлению заказа (когда в корзине есть товары).
Авторизоваться, чтобы оформить заказ в один клик (когда в корзине есть товары).

Один клик мыши по крошечному значку открывает доступ к нескольким вариантам развития событий. Это помогает снизить когнитивную нагрузку на пользователя ⟶ отличный клиентский опыт благодаря A/B-тестированию ?

A/B-тестирование

Научитесь проводить A/B-тестирование и анализировать результаты
Получите пошаговый алгоритм по проведению A/B-тестов
Сможете оптимизировать силы и деньги ?

Туризм

С помощью A/B-тестирования можно увеличить количество заказов, дополнительных покупок и других позиций.

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

Источник статьи: http://netology.ru/blog/05-2020-a-b-testirovanie

Написать черновик: как тестировать бизнес-идеи

Вы придумали интересный продукт, собрали стартовый капитал и даже разработали стратегию развития на несколько лет вперёд. Но, как любой человек, вы хотите застраховать себя от провала и убытков. Попробуйте отложить полноценный старт и запустить черновую версию продукта. Редакция «Своего дела» вместе с экспертами разобралась, что такое MVP и почему это полезно малому бизнесу

Что такое MVP

Минимально жизнеспособный продукт (MVP, от англ. Minimum Viable Product) — продукт с ограниченным набором функций, но достаточным для проверки его работоспособности. С помощью MVP предприниматель может протестировать свою идею до запуска бизнеса или отдельного направления: оценить востребованность, проанализировать спрос, изучить обратную связь от клиентов. Это один из способов минимизировать риск провала и убытков. Такой тест можно провести с минимальными и даже нулевыми затратами.

Виды MVP

Консьерж

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

Так поступила Марика Чусова, основательница сервиса по подбору психотерапевтов «Новая практика». В мае 2017 года, перед запуском, она опросила потенциальных клиентов на личных страницах в соцсетях и в тематических группах, а также опубликовала два платных поста за полторы тысячи рублей. Благодаря ответам она поняла, что людей, желающих получить помощь психотерапевта, интересует услуга по поиску специалиста.

Чусова договорилась с несколькими экспертами и подготовила анкету для клиентов. О своей идее она рассказала в соцсетях. В ответ подписчики заполнили анкету. После этого Марика направила их к нужному специалисту.

В марте 2018 года Чусова запустила сайт. В его разработку она вложила 80 тысяч рублей. По её словам, опыт общения с клиентами помог разработать алгоритм, который подбирает специалистов. Сейчас в базе проекта их больше 70. Выручка «Новой практики» формируется благодаря комиссии, которую психотерапевты платят за каждого привлечённого клиента.

MVP Флинстоуна

С помощью этой модели можно протестировать спрос на онлайн- или офлайн-продукт. Такой тип MVP подойдёт интернет-магазинам, платформам с онлайн-курсами и т. д. В конце 2019 года компания PAD Team, которая занимается созданием MVP, тестировала идею по производству и продаже полезных снеков.

Предприниматели разработали рецептуру, подготовили дизайн и описание продукта. Сотрудники PAD Team запустили лендинг, где пользователь мог оставить заявку и заполнить анкету. На основе этих данных клиенту составляли рацион. «Мы получили заявки от 138 пользователей, из них 32 заполнили анкету. Заказчик сделал вывод, что на его продукт есть спрос, и запустил первую тестовую партию», делится Андрей Григорьев, основатель PAD Team.

Разрозненный MVP

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

Основательница сети заведений Poke House Екатерина Серебро решила открыть собственный бизнес после того, как попробовала гавайское блюдо поке (блюдо из сырой нарезанной рыбы с гарниром или овощами) во время поездки в США в 2018 году. Вернувшись в Москву, она изучила меню американских ресторанов, наняла повара и вместе с ним начала готовить поке на домашней кухне. Девушка проводила дегустации среди своих знакомых и корректировала продукт. По её словам, поке пришлось адаптировать к российской культуре — подавать менее острые соусы и привычные местным жителям сорта рыбы.

Перед запуском первой точки на фуд-корте Серебро протестировала идею проекта на временной кухне ресторана «Обед Буфет». В 2018 году руководство заведения приглашало гастроэнтузиастов, которые могли открыть там свой корнер. Начинающие предприниматели не платили за аренду, отдавали только процент с оборота.

Серебро закупила минимальный набор оборудования: холодильную камеру за 50 тысяч рублей, две рисоварки и посуду. Также она потратила 20 тысяч рублей на изготовление вывески. Всё это время Серебро напрямую общалась с поставщиками ингредиентов и тестировала продукты: небольшие партии она получила бесплатно. За два месяца проект вышел в ноль. В день предпринимательница обслуживала 50–70 клиентов.

На втором месяце работы Серебро решила открыть первую точку на Усачёвском рынке. Стартовые инвестиции составили 2,5 миллиона рублей. По словам девушки, главная сложность — высокая себестоимость блюда. Так как ингредиенты для поке не подвергаются тепловой обработке, продукты должны быть высокого качества и долго оставаться свежими. Чтобы окупить такой проект, точки нужен постоянный поток клиентов. Благодаря тестированию MVP Серебро убедилась, что спрос на поке есть.

Консьерж

MVP Флинстоуна

Разрозненный MVP

Как создать MVP

У этого процесса есть несколько подготовительных этапов. Задача предпринимателя — проверить жизнеспособность бизнес-идеи ещё до запуска MVP и рассчитать хотя бы примерную финансовую модель. Что нужно сделать:

Изучите конкурентов.

Составьте список критериев, по которым вы будете их оценивать. Так вы поймёте сильные и слабые стороны своего продукта.

Сформулируйте задачу продукта.

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

Спрогнозируйте прибыльность единицы товара.

Посчитайте, сколько вам нужно продать, чтобы окупить вложения и получить желаемую прибыль. Это позволит рассчитать, какой должна быть прибыль с продажи одного товара или услуги. Зная себестоимость продукта, вы поймёте, сколько должно стоить привлечение одного клиента. По опыту генерального директора PAD Team Андрея Георгиева, 8 из 10 идей не проходят этот этап, потому что финансовая модель проекта не складывается.

Сформулируйте гипотезы для проверки.

Георгиев советует в первую очередь тестировать спрос, стоимость привлечения аудитории и каналы продаж. К примеру, вы планируете выпускать футболки со смешными надписями и принтами про айтишников. Гипотезы могут звучать так: 1) товар в основном будут покупать специалисты по IT, так как они лучше всех понимают эти шутки; 2) стоимость привлечения одного клиента составит 500 рублей; 3) основной канал продаж — интернет-магазин, потому что айтишники чаще покупают вещи в онлайне.

Выберите способ тестирования гипотез.

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

Определите набор функций MVP.

После того как вы проверили гипотезы и выявили запрос клиента, переходите к разработке минимального продукта. Сосредоточьтесь только на основных функциях. Например, если вы хотите протестировать MVP интернет-магазина футболок, сделайте сайт с базовыми функциями: просмотр каталога, возможность добавить товар в корзину и оплатить. Разработку онлайн-конструктора, с помощью которого клиент сам создаст дизайн футболки, отложите до полноценного запуска.

Проведите тестирование.

MVP должен пройти как минимум два тестирования: альфа-тестирование внутри команды и бета-тестирование среди сторонних пользователей. После каждого этапа нужно анализировать обратную связь от клиентов, их поведение и статистику посещений. Главное — исправляйте ошибки, которые удастся обнаружить.

Что делать после запуска MVP

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

Изучите конкурентов.

Сформулируйте задачу продукта.

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

Спрогнозируйте прибыльность единицы товара.

Сформулируйте гипотезы для проверки.

Выберите способ тестирования гипотез.

Определите набор функций MVP.

Проведите тестирование. MVP должен пройти как минимум два тестирования: альфа-тестирование внутри команды и бета-тестирование среди сторонних пользователей. После каждого этапа нужно анализировать обратную связь от клиентов, их поведение и статистику посещений. Главное — исправляйте ошибки, которые удастся обнаружить.

Что делать после запуска MVP

Источник статьи: http://sberbusiness.live/publications/napisat-chernovik-kak-testirovat-biznes-idei

Тестирование бизнес-идеи

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

Но вы как рациональный человек не даете этой чертовке вскружить вам голову и мыслите как настоящий бизнесмен: «А что если прогорит?».

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

Чтобы выявить ее недостатки без потери времени и что важнее — денег. Тестирование — это и есть ответ на вопрос: «А что если не зайдет?». После анализа результатов вы можете внести разработать сильный бизнес-план или провести еще несколько бессонных ночей, разрабатывая очередную идею.

Сайт, магазин, регистрация ИП и ООО, наличие договорённости с поставщиком, договор… Все это нам не понадобится. Мы будем действовать быстро, дерзко и дешево — использовать лид-форму Facebook.

Подробную инструкцию о том, как настраивать рекламную кампанию с помощью этого плейсмента читайте на официальном сайте ФБ: https://www.facebook.com/business/help/leads

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

Сколько денег потратить на тестирование, вы определяете сами: 300 или 50 000 рублей. Советую начать с 2 000 рублей в день.

Он вам не нужен. На финальной стадии настройки лид-формы вместо ссылки на сайт, укажите номер телефона отдела продаж (или свой).

Медиаплан — это план проведения рекламных кампаний: сроки, бюджеты, площадки

А зачем он нужен? Чтобы выяснить, насколько интересна ваша идея (тест) с точки зрения продаж и будет ли она продаваться и окупаться.

Составляем табличку. Вот пример.

Продукт — услуга, продукт, товар

Источник — откуда мы получаем заявки

Лид — потенциальный клиент, который отреагировал на маркетинговую коммуникацию

Конверсия — процент сделок (продаж) от общего количества лидов

Выручка — прибыль с рекламного канала

ROMI — Return on Marketing Investment (рентабельность инвестиций в маркетинг), считаем по формуле:

Если в результате показатель ROMI — 0%, это значит, что с реализации идеи вы получили столько же денег, сколько потратили на рекламу. Для теста нормально! Теперь понятно, что идея пользуется спросом, на нее есть интерес и с этим можно работать. Но в жизни я рекомендую держать ROMI на уровне +200%.

Упс, что-то пошло не так, и ROMI в минусе… Почему?

Может, вы неправильно собрали рекламную кампанию: ошиблись в логике таргетинга, криво написали объявление, подобрали уродливую картинку (да они просто ничего не поняли!)
Идея не канает. Такое тоже бывает.
Вашу идею сложно реализовать через соцсети, возможно, больше подойдет контекстная реклама (Яндекс. Директ или GA)

Если ROMI — 0% и выше, танцуем. Ваша бизнес-идея имеет право на жизнь: она интересна ЦА, и кто-то уже готов отдавать за нее деньги. После теста можете начать составлять стратегию реализации, почва прощупана!

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

Источник статьи: http://vc.ru/marketing/69779-testirovanie-biznes-idei

Пишем максимально эффективный тест-кейс

Что такое тест-кейс?

Зачем нужны тест-кейсы?

Атрибуты тест-кейса

Что еще необходимо знать, перед созданием тест-кейса?

Чего не должно быть в тест-кейсе

Тестирование требований: как я нахожу ошибки в бизнес-логике фичи прежде, чем их закодят

Введение

Зачем и для кого фича?

Какую проблему решает фича?

Конфликт интересов

Как пользователь будет использовать эту фичу?

Варианты использования (Use cases)

Основное направление варианта использования

Альтернативные направления

Исключения

От входных/выходных данных к тест-кейсам

Пишите в сценариях смысл действия без опоры на внешний вид

Общий алгоритм применения подхода

Профит от подхода для тестировщика

Заключение

Тестирование программного обеспечения — тестирование бизнес-аналитики (BI) с примерами тестовых случаев

События в бизнес-аналитике

Последовательность тестирования бизнес-аналитики

Этапы бизнес-аналитики

Тестовые примеры бизнес-аналитики

Стратегия тестирования бизнес-аналитики

Фундаментальная теория тестирования

Перейдем к основным понятиям

Принципы тестирования

Этапы тестирования:

Требования

Жизненный цикл бага

Severity vs Priority

Тестовые среды

Основные фазы тестирования

Основные виды тестирования ПО

Методы тестирования

Тестовая документация

Как наконец-то начать писать тесты и не пожалеть об этом

Тесты vs скорость разработки

Запуск кода в произвольном месте

Повторный запуск тестов

Отладка

Эффективность

От теории к практике

Задача

Доменная модель

Структура проекта

Интеграционные тесты

Юнит-тесты

Рекомендации по внедрению

Первые тесты написаны, что дальше?

Заключение

Как провести модульное тестирование бизнес-правил?

5 ответов

unit-тестирование здорового человека ч.1

Вступление

Содержание:

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

Недостатки e2e и интеграционных тестов

Чем полезны unit-тесты

Метрики

Свойства идеальных тестов:

Когда не стоит проводить unit-тестирование

Антипатерны

Изоляция теста

А/В-тестирование: зачем нужно и как помогает бизнесу

Что такое A/B-тестирование

Какие задачи бизнеса решают A/B-тесты

Решают проблемы пользователей

Обеспечивают лучшую окупаемость инвестиций (ROI)

Уменьшают показатель отказов

Снижают риски при изменениях

Обеспечивают статистически значимые улучшения

Помогают улучшить дизайн

Примеры A/B-тестов

Медиа и издательское дело

Электронная коммерция

A/B-тестирование

Консьерж

MVP Флинстоуна

Разрозненный MVP

Консьерж

MVP Флинстоуна

Разрозненный MVP