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

В моей практике есть пару ярких примеров. Давайте их рассмотрим.

Несколько лет назад мы разрабатывали фичу для звонков с локальной АТС на мобильные устройства. Идея заключалась в том, чтобы наш заказчик получал доступ к функциональности АТС со своего мобильного устройства посредством IVR меню. Времени и сил мы потратили прилично. После официального релиза мы были уверены, что заказчик всплакнёт от умиления. Каково же было узнать, что наша реализация ему показалась слишком сложной. Ну не хотел он ждать по 40 секунд пока «железная» леди пояснит ему, что следующим нажимать — 1, 2 или 3. В результате этот функционал дорабатывался и не стал популярен у заказчика.

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

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

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

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

Под Альфа-тестированием принято понимать имитацию реальной работы с системой штатными разработчиками или тестировщиками, либо реальная работа с системой потенциальными пользователями/заказчиком. Чаще всего альфа-тестирование проводится на ранней стадии разработки продукта, но в некоторых случаях может применяться для законченного продукта в качестве внутреннего приёмочного тестирования. Хочу сразу оговориться, я разделяю QA тестирование и Альфа тестирование. У меня в проекте есть программисты, тестеры, техническая поддержка, архитекторы, и есть отдельная команда по альфа тестированию. Фокус этой команды — это нахождение багов во время ежедневного использования нашей системы. Этой команде не нужно делать по 100 тестов в день. Они думают про качество продукта, а не про метрики.

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

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

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

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

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

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

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

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

Шаг 7. У вас появился прайм, пора подумать о тестовой стратегии и тестах. Используйте стандартные темплейты. Обязательно нужно подумать над: техническими рисками, активностями, фичами для тестирования, инструментарием, сроками.

Шаг 8. Вот мы и подошли к выполнению тестов. Проведите этот тестовый прогон как можно эффективней. Я рекомендую использовать всевозможные техники тестирования. Например, specification-based, usage-based, fault-based techniques.

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

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

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

В общем, мы попробовали и всем советуем. Дерзайте!