Альфа- и бета- тестирование (Alpha Testing and Beta Testing)

Альфа- и бета-тестирование - это Customer Validation methodologies (Acceptance Testing types) которые помогают укрепить веру в запуске продукта и, таким образом, привести к успеху продукта на рынке. Несмотря на то, что они оба полагаются на реальных пользователей и обратную связь разных команд, ими движут разные процессы, стратегии и цели. Эти два типа тестирования вместе увеличивают успех и продолжительность жизни продукта на рынке. Эти этапы можно адаптировать к продуктам Consumer, Business или Enterprise. Этапы альфа- и бета-тестирования в основном сосредоточены на обнаружении ошибок в уже протестированном продукте и дают четкое представление о том, как продукт на самом деле используется пользователями в реальном времени. Они также помогают получить опыт работы с продуктом перед его запуском, а ценные отзывы эффективно используются для повышения удобства использования продукта. Цели и методы альфа- и бета-тестирования переключаются между собой в зависимости от процесса, которому следуют в проекте, и могут быть изменены в соответствии с процессами.

Альфа-тестирование - это форма внутреннего приемочного тестирования (internal acceptance testing), выполняемого, в основном, собственными командами по обеспечению качества и тестированию ПО. Альфа-тестирование - это последнее тестирование, проводимое группами тестирования на месте разработки после приемочного тестирования и перед выпуском программного обеспечения для бета-тестирования. Альфа-тестирование также может быть выполнено потенциальными пользователями или клиентами приложения. Но все же это форма внутреннего приемочного тестирования.

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

Alpha Testing	Beta Testing
Testing environment	Real environment
Functional, usability	Functional, Usability, Reliability, Security
White box and / or Black box testing	Black box testing
На найденные дефекты создаются баг-репорты с high priority, после чего они немедленно исправляются	Дефекты собираются из обратной связи от пользователей и записываются как улучшения для будущей версии
Цели: ● Оценить качество продукта; ● Убедиться в готовности к бета-тестированию; ● Фокус на поиске ошибок; ● Работает ли ПО?	Цели: ● Оценить удовлетворенность клиентов; ● Убедиться в готовности к релизу (в прод); ● Фокус на сборе отзывов и предложений; ● Нравится ли заказчикам (customers) продукт?
Когда? ● Обычно после System testing phase или когда продукт готов на 70-90%; ● Фичи почти заморожены, и нет возможности для серьезных улучшений; ● Сборка должна быть стабильной для технического пользователя;	Когда? ● Обычно после альфа-тестирования и продукт готов на 90-95%; ● Фичи заблокированы и улучшения уже не принимаются; ● Сборка должна быть стабильной для реальных пользователей;
Продолжительность теста: ● Проведение множества циклов испытаний; ● Каждый цикл тестирования длится 1-2 недели; ● Продолжительность также зависит от количества обнаруженных проблем и количества добавленных новых функций;	Продолжительность теста: ● Проведение всего 1 или 2 цикла испытаний; ● Каждый цикл тестирования длится 4-6 недель; ● Циклы тестирования могут увеличиваться в зависимости от отзывов / предложений реальных пользователей;
Stakeholders: Engineers (in-house developers), Quality Assurance Team, and Product Management Team	Stakeholders: Product Management, Quality Management, and User Experience teams
Участники: ● Технические эксперты, специализированные тестировщики с хорошими знаниями предметной области (новые или уже участвовавшие в фазе тестирования системы), предметная экспертиза (Subject Matter Expertise); ● В некоторых случаях клиенты и / или конечные пользователи могут участвовать в альфа-тестировании;	Участники: ● Конечные пользователи, для которых предназначен продукт; ● Customers также обычно участвуют в бета-тестировании;
Ожидания: ● Приемлемое количество ошибок, которые были пропущены при предыдущих тестовых мероприятиях; ● Неполные функции и документация;	Ожидания: ● Почти готовый продукт с гораздо меньшим количеством ошибок и сбоев; ● Почти готовые функции и документация;
Критерии начала (Entry Criteria): ● Альфа-тесты, разработанные и проверенные с учетом требований бизнеса (Business requirements); ● Требования покрыты тестами в Traceability matrix; ● Команда тестирования со знанием предметной области (domain) и продукта; ● Настройка среды и сборка для выполнения (Environment setup and build for execution); ● Набор инструментов должен быть готов для регистрации ошибок и управления тестированием; ● Системное тестирование, в идеале, должно быть закончено;	Критерии начала (Entry Criteria): ● Бета-тесты, например, что тестировать, и процедуры, задокументированные для использования на проде; ● Нет необходимости в матрице прослеживаемости; ● Конечные пользователи и заказчик объединяются; ● Настройка среды конечного пользователя; ● Набор инструментов должен быть готов для сбора отзывов / предложений; ● Alpha Testing должно быть закончено;
Критерии окончания (Exit Criteria): ● Все альфа-тесты должны быть выполнены, и все циклы должны быть завершены; ● Critical / Major дефекты должны быть исправлены и повторно протестированы; ● Должен быть завершен эффективный анализ отзывов, предоставленных участниками; ● Alpha Test Summary report; ● Alpha Testing должно быть закончено;	Критерии окончания (Exit Criteria): ● Все циклы должны быть завершены; ● Critical / Major дефекты должны быть исправлены и повторно протестированы; ● Должен быть завершен эффективный анализ отзывов, предоставленных участниками; ● Beta Test Summary report; ● Beta Testing должно быть закончено;
Плюсы (Pros): ● Помогает обнаружить ошибки, которые не были обнаружены во время предыдущих тестовых мероприятий; ● Лучшее представление об использовании и надежности продукта; ● Анализ возможных рисков во время и после запуска продукта; ● Помогает подготовиться к будущей поддержке клиентов; ● Помогает укрепить доверие клиентов к продукту; ● Снижение затрат на обслуживание за счет выявления и исправления ошибок перед запуском бета-версии / production версии; ● Простое управление тестированием (Test Management);	Плюсы (Pros): ● Тестирование продукта не поддается контролю, и пользователь может протестировать любую доступную функцию любым способом - в этом случае угловые области (corner areas) хорошо протестированы; ● Помогает обнаружить ошибки, которые не были обнаружены во время предыдущих тестовых мероприятий (включая альфа-версию); ● Лучшее представление об использовании продукта, надежности и безопасности; ● Анализ точки зрения и мнение реального пользователя о продукте; ● Отзывы / предложения реальных пользователей помогают в дальнейшем импровизировать продукт; ● Помогает повысить удовлетворенность клиентов продуктом;
Минусы (Cons): ● Ожидается, что не вся функциональность продукта будет проверена; ● Ограничено только бизнес-требованиями;	Минусы (Cons): ● Определенный объем (Scope) может соблюдаться или не соблюдаться участниками; ● Документация больше и требует больше времени - требуется для использования инструмента регистрации ошибок (при необходимости), использования инструмента для сбора отзывов / предложений, процедуры тестирования (установка / удаление, руководства пользователя); ● Не все участники гарантируют, что проводят качественное тестирование; ● Не все отзывы эффективны - на рассмотрение отзывов уходит много времени; ● Управление тестированием слишком сложно;

 

Помимо альфа- и бета-тестирования, существуют еще гамма-тестирования и пилотное.

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

Pilot testing определяется как тип тестирования программного обеспечения, который проверяет компонент системы или всю систему в режиме реального времени. Целью пилотного теста является оценка осуществимости, времени, стоимости, риска и эффективности исследовательского проекта. Это тестирование проводится точно между UAT и Production. В пилотном тестировании выбранная группа конечных пользователей пробует тестируемую систему и предоставляет обратную связь до полного развертывания системы. Другими словами, это означает проведение генеральной репетиции для последующего теста на удобство использования. Пилотное тестирование помогает в раннем обнаружении ошибок в Системе. Пилотное тестирование связано с установкой системы на площадке заказчика (или в среде, моделируемой пользователем) для тестирования на предмет постоянного и регулярного использования. Выявленные недостатки затем отправляются команде разработчиков в виде отчетов об ошибках, и эти ошибки исправляются в следующей сборке системы. Во время этого процесса иногда приемочное тестирование также включается как часть тестирования на совместимость. Это происходит, когда система разрабатывается для замены старой.

Источник:

Alpha Testing And Beta Testing (A Complete Guide)

 

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

Продукта без требований не существует, просто они могут быть не формализованы и не записаны. Если вам дали протестировать какое-то готовое решение, к которому нет документации, то нужно попытаться восстановить все явные и неявные требования: изучив функционал (какую проблему решает продукт? для чего его создали?), целевую аудиторию (для кого его создали?), попытаться найти тех, кто мог знать что-то и уже не в команде; список источников получения неявных требований вообще огромен. На основе всего этого уже как минимум можно составить user stories для покрытия основными тестами.

Доп. материал:

Тестирование без требований. Где искать требования к продукту, если отсутствует ТЗ?

Роли/должности в команде

 

 

Роли в тестировании ПО:

● Software Test Engineer: тестирует всю систему, используя соответствующие методы и инструменты тестирования;

● Test Analyst: определяет test conditions and features для тестирования, разрабатывает тестовые сценарии и документацию;

● Test Automation Engineer: разрабатывает сценарии для запуска автоматизированных тестов;

● SDET (Software Development Engineer in Test) - это специалист, который может одинаково эффективно работать в сфере разработки и тестирования и принимает участие в полном процессе разработки ПО, в т.ч. в его обязанности может входить разработка внутренних инструментов для поддержки тестирования или других функций, написание тестового фреймворка, фикс найденных дефектов за разработчика, unit/integration testing и т.п.;

● Test Architect: проектирует комплексную инфраструктуру тестирования, выбирает инструменты для реализации;

● Test Manager: подготавливает стратегию тестирования, контролирует процесс тестирования и членов команды;

Источники:

● Куда идти в IT. Подробная инструкция от Project Manager

● QA Engineering Roles: Skills, Tools, and Responsibilities in a Testing Team

Доп. материал:

● Product Owner vs Product Manager или Product Owner/Product Manager

● Business Analyst, Requirement Specialist, Product Owner и другие. Чем отличаются схожие на первый взгляд роли?

● Роль QA Lead в продуктовой компании: особенности и зоны ответственности

● Продакт-менеджмент как профессия: востребованность, зарплата и другие нюансы

● Кто такой продакт-менеджер? Или не все PM’ы — проджект-менеджеры

● Project Management in QA and Testing

● Knowledge management: как перестать изобретать велосипеды

● Заметки knowledge manager'a. Как работает управление знаниями в Exness

● Профессия СТО

● Кто такой DevOps-инженер, что он делает, сколько зарабатывает и как им стать

● Гайд по DevOps для начинающих

● Распространенные поисковые запросы, часть 3: когда должно начинаться тестирование?

● «Вам звонок». Как выстроить отношения между QA и техподдержкой

Тестовая среда и тестовый стенд (Test Environment/Test Bed)

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

● Среда разработки (Development Env) – в ней разработчики пишут код, проводят отладку, исправляют ошибки, выполняют Unit-тестирование. За эту среду отвечают также разработчики.

● Среда тестирования (Test Env) – в этой среде работают тестировщики. Тут тестируют новые билды: проверяют функционал, проводят регрессионные проверки, воспроизводят ошибки. Эта среда появляется во время начала динамического тестирования;

● Интеграционная среда (Integration Env) – иногда реализована в рамках среды тестирования, а иногда в рамках превью среды. В этой среде собрана необходимая для end-to-end тестирования схема взаимодействующих друг с другом модулей, систем, продуктов. Собственно, необходима она для интеграционного тестирования. Поддержка среды – также, как и в случае со средой тестирования

● Превью среда (Preview, Preprod Env) – в идеале, это среда идентичная или максимально приближенная к продуктивной: те же данные, то же аппаратно-программное окружение, та же производительность. Она используется, чтобы сделать финальную проверку ПО в условиях максимально приближенным к «боевым». Здесь тестировщики проводят заключительное end-to-end тестирование функционала, бизнес и/или пользователи проводят UAT, а команды поддержки L3 и L2 выполняют DryRun (пробную установку релиза). Как правило за эту среду отвечает группа L3 поддержки.

● Продакшн среда (Production Env) – среда, в которой работают пользователи. С этой средой работает команда L2 поддержки устанавливая поставки ПО или патчи с исправлениями, выполняя настройки, отвечая за работоспособность всех систем. Инциденты и проблемы требующие исправления ПО передаются в работу команде на L3

Испытательный стенд (Test Bed) – более глобальная сущность и включает в себя operating system, configuration management for the products, hardware, network topology и т. д. Настраиваются в соответствии с требованиями тестируемого приложения. В некоторых случаях испытательный стенд может представлять собой комбинацию тестовой среды и тестовых данных, которые он использует.

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

Доп. материал:

● Тестовая среда

● STLC — настройка тестовой среды

Тестовые данные (Test Data)

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

Доп. материал:

What Is Test Data? Test Data Preparation Techniques With Example

Бизнес-логика

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

Источники:

● Что такое бизнес-логика

● Бизнес-логика