β Что такое бета-тестирование?

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

Характеристики

1. Выполняется клиентами/пользователями/всеми желающими, а не сотрудниками компании.
2. Качественная проверка надёжности, безопасности, и общей пригодности приложения.
3. Выполняется в окружении пользователя, то есть на его компьютере (смартфоне).
4. Не требует создания и настройки сложного тестового окружения.

Типы бета-тестирования

• Стандартное. Продукт передают определенному (как правило, не очень большому) количеству пользователей и собирают их отзывы (фидбек) плюс сопутствующие данные (в первую очередь условия возникновения ошибок), затем продукт корректируют/улучшают на основе фидбека.
• Публичное. Публичный (широко объявляемый) релиз продукта в онлайн-каналах корпорации, продукт доступен любому желающему и желающих обычно много. Публичное бета-тестирование проводят крупнейшие ИТ-компании.
• Техническое. Продукт передают выделенной группе сотрудников внутри компании и получают квалифицированный фидбек плюс упорядоченные дополнительные данные.
• Фокусное. Сбор фидбека по отдельным функциям.
• Пост-релизное. С целью собрать идеи улучшения «на будущее».

Критерии начала бета-тестирования

• Завершение «альфа» тестирования
• Готова бета-версия
• Готовность к сбору фидбека
• Наличие и готовность инструментов регистрации дефектов

Инструменты для бета-тестирования

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

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

❌ Недостатки бета-тестирования

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

Разница между альфа- и бета-тестированием кратко

Альфа	Бета
Выполняется сотрудниками ИТ-компании	Выполняется пользователями
В тестовом окружении компании	В их реальном окружении
Применяют методики черного и белого ящика	Только методика черного ящика
Продукт готов на 70-90%	Продукт готов на 90-95%
Цель: оценить общее качество	Цель: получить оценку пользователей
Требует сложного тестового окружения	Не требует сложного тестового окружения
Выполняется до выхода на рынок	Выполняется на этапе маркетингового продвижения

Альфа и бета-тестирование: цели, важные моменты, таймлайн, участники и стейкхолдеры

Альфа-тестирование	Бета-тестирование
Основные моменты	Этапы валидации пользователями	Первый этап	Второй этап
Место проведения	Внутри компании, в специальном тестовом окружении	У пользователей, в реальном окружении
Возможности контроля	Хорошие	Слабые
Области тестирования	Только функциональность и юзабельность; безопасность и надежность обычно нет	Функциональность, юзабельность, надежность и безопасность в равной степени
Применяются техники	Черного и белого ящика	Только черного ящика
Название билда	Альфа-билд	Бета-билд
Что команда делает, когда обнаружены баги и проблемы	Регистрирует баги и фиксит с высоким приоритетом	Реальные пользователи сообщают о багах, баги устраняются; дополнительно общие впечатления и идеи по улучшению
Польза	Разные точки зрения на качество продукта от участников	Оценка будущей успешности продукта на основе фидбека
Цели
Оценить	Качество продукта	Удовлетворение пользователей
Гарантировать	Готовность к бете	Готовность к релизу
Сосредоточиться на	Поиске багов и проблем	Собрать фидбек и впечатления
Ответить на вопросы	Рабочий ли продукт?	Пользователям нравится?
Таймлайн	Тестирование начинается:	После завершения системного тестирования	После завершения альфа-тестирования
Завершенность проекта	70-90%	90-95%
Стабильность билда	Стабильный с точки зрения разработчиков	Стабильный с точки зрения пользователей
Длительность	Сколько тестовых циклов	Много	1 или 2
Длительность каждого цикла	1-2 недели	4-6 недель
Прочие факторы	Длительность зависит от количества найденных багов и добавленных новых функций	Тестовый цикл может затягиваться после фидбека пользователей
Стейкхолдеры	Разработчики, лиды QA-команды, менеджмент проекта	Менеджмент проекта, QA-менеджеры, менеджеры по User Experience

Личный опыт проведения бета-тестирования

Мы делаем приложение по обучению дизайну в формате игры.

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

Что такое бета-тестирование?

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

Зачем все это нужно?

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

Зачем тогда бета? Бери и запускайся!

Попробую объяснить причину.

Первое впечатление — это навсегда! Я не хочу, чтобы мой продукт ассоциировался с «забаговано-косым» интерфейсом. Вернуть пользователя будет сложнее, чем привлечь в первый раз, если он получил негативный опыт. Конечно все мы не исправим, и до идеала не дойдем, но это и не нужно. Главное, чтобы все работало стабильно и не было критических ошибок.

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

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

И в целом мне было интересно пощупать и пройти весь путь разработки продукта, в том числе бета-тестирование. Это увлекательное путешествие!

Как проходила бета

Этот блок будет интересно почитать тем, кто хочет увидеть, что под капотом. Честно, я не знаю «как правильно». Прочитал пару статей, но они не особо мне помогли. Действовал из соображения логики.

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

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

Я прислал им инструкцию, что нужно делать.

Инструкция включала в себя несколько важных блоков:

• Описание, что конкретно нужно делать. Это важно!
• Как установить приложение.
• Поблагодарить, и подчеркнуть, как важна их помощь! Это реально так: )

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

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

Что по результатам?
Парочка комментариев

Комментарии поделились на четыре типа:

• Баги. Текст вылезает за пределы экрана, нажатие на подсказку приводит к серому экрану и прочее.
• Орфография. Мы получили большое кол-во комментариев, связанных с орфографическими ошибками.
• Что-то не понятно / неудобно. Кому-то было тяжело читать текст, кто-то не понял, что делать в уроке и прочее.
• Предложения. Добавить прогресс бар, возможность увеличивать фото и прочее.

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

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

Люди, из бета-тестирования поделились на две группы:

• Те, кто ничего не написали. Ожидаемо, и нормально.
• Те, кто написали много, и сильно нам помогли. Это крутые ребята! Спасибо вам!

Я понял простую истину

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

Интересно пообщаться с ребятами из сфер игр, образования, геймификации. Напишите мне в телеграм @gaugash

Какими бывают версии программ. Жизненный цикл

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

Стадии разработки

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

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

Основная «классификация» стадий разработки программ:

• Pre-Alpha;
• Alpha;
• Beta;
• вечная бета-версия;
• Release candidate.

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

Pre-Alpha

Этапы разработки (стадии) программы делятся на несколько «шагов». Первая – это начальная. Она характеризуется периодом времени от начала работы над проектом до выхода первой альфа версии.

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

В Pre-Alpha версии подразумеваются все действия, выполняемые при проектировании приложения:

• формирование дизайна;
• анализ выдвинутых требований;
• непосредственное написание программа;
• отладка конкретных модулей.

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

Alpha

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

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

Beta

Бета – это «общественная разработка». Стадия активного тестирования широким кругом лиц, а также отладки программы. Приложения такого уровня могут использоваться другими разработчиками для проверки совместимости. Подобное программное обеспечение может содержать достаточно большое количество ошибок.

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

Вечная бета

Есть отдельная категория программ – «вечная бета». Данное понятие было введено Тимом О’Райли. Оно характеризует ситуацию, когда приложение находится в бета-стадии неопределенное количество времени.

Механизм уместен в интернете, где у ПО имеются следующие свойства:

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

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

Release Candidate

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

Release Candidate не исключает наличие багов. Если в течение некоторого времени масштабные недоработки не обнаруживаются, проект переходит в RTM-тип.

Выпуск

Что такое альфа версия программы, теперь понятно. Когда проект прошел все «предварительные» этапы, начинается его выпуск. Процесс носит название «стабильный выпуск». Это формальный термин, который обычно зависит от способа реализации: физический носитель, онлайн или веб-приложение.

Здесь выделяют несколько вариантов:

1. Выпуск в производство. Ситуация, когда проект готов к тиражированию. Стабильная версия (не альфа и не candidate) программы, прошедшая предыдущие этапы. Это и есть RTM. Термин используется тогда, когда нужно указать, что проект соответствует определенному уровню качества и готов для «выпуска в массы».
2. Общедоступность или GA. Маркетинговая стадия. Во время нее проводятся мероприятия, связанные с коммерциализацией. Программный продукт становится доступным для приобретения.
3. Веб-релиз. Это – выпуск в интернет (RTW). Средство доставки ПО, использующее для распространения интернет. Наиболее распространенная концепция в 21 веке.

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

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

При подготовке материала использовались источники:

β Что такое бета-тестирование?

https://vc.ru/life/502654-lichnyy-opyt-provedeniya-beta-testirovaniya
https://otus.ru/journal/kakimi-byvajut-versii-programm-zhiznennyj-cikl/