Зачем нужна система управления тестированием?tadетали

Зачем создавать тест план?

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

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

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

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

Почему исчерпывающее тестирование нецелесообразно и невозможно

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

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

Краудтестинговые платформы — «ясли для тестировщика»

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

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

А «доход» обычно начисляется в английских тугриках. И в принципе он достаточно неплохой.

Да. Помните. Чем «крупнее» ошибки Вы находите, тем выше Ваше вознаграждение!

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

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

test.io— одна из старейших платформ краудтестинга

www.testbirds.com — есть вариант для русскоязычных пользователей.

www.passbrains.com — еще один сайт для тестирования ПО

www.globalapptesting.com — еще краудтестинговый сайт

ubertesters.com — еще одна (немецкая) платформа для тестирования

testlio.com — еще ловите сайтик для тех, кто ищет работу тестировщика ПО без опыта

www.crowdtesting.ru — и еще. Это уже на русском языке, что является редкостью в мире тестировочных платформ.

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

С чего начать

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

Создайте план действий

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

Создайте сценарии тестирования

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

Решите, какие тестеры понадобятся

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

Создайте план

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

Набор тестеров

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

Создайте окончательный план

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

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

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

Сформируйте итоговый отчет

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

Нужны ли дополнительные исследования?

На основе полученных результатов решите, нужно ли проводить дополнительное исследование.

Поделитесь результатами и реализуйте улучшения

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

Что такое исчерпывающий тест?

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

Развитие TDD

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

1976 год. Публикация Гленфорда Майерса «Надежность программного обеспечения», которая определяет, как аксиому то, что программист никогда не должен тестировать свой собственный код (Dark Age of Developer Testing).

1990 год. В дисциплине тестирования преобладают методы «черного ящика», в частности, в форме инструментов тестирования «поймай и повтори».

1991 год. Независимое создание тестовой среды в Taligent поразительно похожей на SUnit.

1994 год. Кент Бек пишет тестовый скелет SUnit для Smalltalk.

1998 год. Статья об экстремальном программировании упоминает, что «мы обычно пишем тест в первую очередь».

С 1998 по 2002 год. Test First преобразован в Test Driven.

2000. Автоматизированные тесты – инновационные методы, разработанные в этот период.

2003 год. Публикация Кента Бека «Разработка через тестирование: на примере».

В 2006 году TDD превратился в признанную технику, которая стала поощрять дальнейшие инновации, такие как разработка на основе приемочных испытаний (ATDD) и развитие на основе поведения (BDD).

Как обычно проходит тестирование

Как правило, тестировщики начинают работать с программой сразу после начала проекта:

• Составляют тест-план, где описан весь объём работ по тестированию и определено, когда их можно закончить. Это примерный документ — в процессе разработки в него не раз внесут изменения: уточнят стратегию и виды тестирования, расписание работ и так далее.
• Разрабатывают тест-кейсы — перечень конкретных действий и сценарии для проверки каких-то определённых функций программы.
• Решают, нужна ли автоматизация: стоит ли разрабатывать и запускать автоматические тесты или можно обойтись тестированием вручную.

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

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

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

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

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

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

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

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

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

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

Функциональное и нефункциональное

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

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

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

Кроме того, процедура классифицируется на подвиды в зависимости от уровня и этапа разработки ПО. Это может быть:

• модульное;
• интеграционное;
• системное;
• приемочное.

Инструменты

TDD должен сочетаться с хорошими инструментами. Необходима среда IDE, такая, как Eclipse с собственной поддержкой JUnit. Настоятельно рекомендуется использовать плагины для облегчения управления модульными тестами, такими как MoreUnit и Infinitest. Последний автоматически выполняет все модульные тесты при каждом изменении кода, что уменьшает циклы обратной связи, которые также закладывают основы для непрерывных модульных тестов

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

Примеры положительного влияния А/В-тестов в различных сферах бизнеса

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

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

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

Онлайн-бизнес

Лидер по оптимизации конверсии – Amazon. Речь идет не просто о самом масштабном бизнес- проекте в Интернете, но и о стремлении компании сделать сайт удобным абсолютно для всех пользователей. В конце 90-х гг. прошлого столетия компания запустила после серии испытаний опцию «Заказ в один клик». Покупатели получили возможность совершать заказы без добавления товара в корзину. Клиенту достаточно было всего один раз ввести данные карты и адрес доставки. После этого для оформления заказа требовалось только нажать на кнопку и ждать доставку по указанному ранее адресу. Пользователи настолько оценили простоту и удобство заказа, что у большинства пропало желание обращаться к конкурентам Amazon.

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

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

Booking.com. благодаря регулярным систематическим А/В-тестам наращивает обороты и превосходит конкурентов.

Компания практикует исследования в грандиозных масштабах. Даже сейчас, пока вы читаете нашу статью, на сайте Booking.com проводят почти тысячи А/В-тестов.

Booking.com ввели A/B-тестирование как повседневную рабочую задачу. Компания увеличила скорость тестирований до текущей, избавилась от влияния HiPPO (Highest paid person’s opinion) и отдала приоритет данным. Ради получения больших результатов все сотрудники Booking.com могут тестировать свои идеи при наличии таковых.

Booking.com готовы экспериментировать ради улучшения взаимодействия пользователей с сайтом. С 2017 г. фирма увеличила охваты, предлагая жилье в аренду для отдыха недалеко от отелей. Компания наладила партнерские отношения с нативной рекламной платформой Outbrain, чтобы помочь им расширить базу владельцев недвижимости по всей планете.

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

Команды объединились и создали три версии лендинга для Booking.com. Были включены дополнительные детали, такие как социальное доказательство, награды, оценки пользователей и т. д.

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

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

Получите персональный аудит отдела продаж от Сергея Азимова для 3-кратного роста продаж в 2021 году совершенно бесплатно

Проведем аудит Вашего отдела продаж по 24 пунктам и дадим четкий план по увеличению прибыли!

Задачи тестировщика

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

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

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

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

Пентест на аутсорсе

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

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

Что такое пентест и как он поможет компании сохранить деньги и репутацию, подробно расскажут эксперты МегаФона на онлайн-митапе 20 мая.

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

Если у вас больше двух вариантов, можно провести мультивариантное тестирование. 

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

Мультивариантным тестом лучше проверять несколько версий с незначительными изменениями. Например, можно протестировать четыре фразы call to action для одной кнопки. 

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

Эквивалентное разделение

Помогать использовать первую технику будет сайт Instagram, а начнем с техники «Эквивалентное разделение». В чем ее суть? Мы берем все возможные варианты ввода текста и разделяем их на валидные и невалидные. Давайте протестируем поле «мобильный телефон» или «электронный адрес» — валидные и невалидные варианты ввода.

Введем +380999999999 — номер засчитан, как правильный, потому мы можем считать его валидным:

Номер засчитан валидным

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

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

А что, если мы введем электронный адрес без символа «@»? Он считается неправильным:

А если вернуть символ собачки, но удалить точку? Он также считается невалидным:

Instagram тоже посчитал его верным. Итак, мы разделили все возможные вводы мобильного телефона или электронного адреса на валидные и невалидные группы. Вот результат:

Валидные	Невалидные
+380999999999	+38099999999999
	+38099999999л
	natash76554agmail.com

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

К невалидным будут относиться:

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

Изучение логов

Логи в стиле Матрицы. Фото: freepik.com

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

Что такое лог

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

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

Какие бывают логи

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

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

Один и тот же софт может иметь несколько режимов логирования. Режим задаётся
в настройках и отличается уровнем детализации.

Степень детализации может отличаться очень сильно. От никаких или минимальных записей вроде

2020-02-10-16-06-01T Включился

2020-02-10-16-08-23T Выключился

До записи каждого действия.

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

Типичные уровни логов — слева на право детализация растёт

OFF — FATAL — ERROR — WARN — INFO — DEBUG — TRACE — ALL

Распространённый приём в работе тестировщика — на время тестирования включать
подробное логирование — от DEBUG и выше.

Затем возвращать настройки в INFO или WARN для экономии места.

Для работы с логами может пригодится знание скриптовых языков программирования, или
текстовых препроцессоров
(sed,
grep,
awk)

Пример: показать только сегодняшние ERROR и WARNING строки из лога а также те, где
присутствует слово panic

grep ‘2022-01-25’ topbicycle.log | grep -E ‘ERROR|WARNING|*panic*’

Где лежат логи в Windows

Лог файл обычно называется по дате, например

2022-01-25-heiheiru-log.txt

или

2022-01-25-heiheiru.log

Расположение лог файла обычно зависит от конкретного проекта, например:

У одного клиента логи могут лежать в

а у другого в

Glassfish на Windows server может писать в

Где лежат логи в Linux

В

Linux

системные логи находятся в

Например, лог утилиты

cron

за сегодня находится в

Иногда проще спросить расположение логов у разработчика

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

Откройте логи с помощью

и сделайте поиск по слову POST

Советую не пренебрегать опцией Find All in Current Document.

Зачастую смотреть полный лог нет смысла. В нём может быть очень много мусора, который легко убрать с помощью
текстовых препроцессоров.

О том как это сделать Вы можете прочитать в статьях

sed

grep

awk

и как бонус —

«Комады Bash для тестировщика»

Кто должен читать логи: тестировщик или разработчик

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

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

Конечно, разработчик и сам может всё это сделать. Но его время стоит дороже и для бизнеса выгодно,
чтобы всё что может делать тестировщик делал тестировщик.

Для чего нужно тестирование?

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

В разработке и проверке гипотез A/B-тест позволяет решать следующие задачи:

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

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

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

Ожидания и реальность

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

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

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

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

Формулировка целей и задачи

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

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

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

Что такое тест

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

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

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

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

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

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

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

Угадывание ошибок

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

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

• Уменьшать ширину окна по чуть-чуть, чтоб отловить баги в User Interface
• Делить на ноль
• Ввести пустое значение в поле
• Ввести пробел в начало, в середину, в конец поля
• Негативное тестирование дат (30, 31 февраля, а также даты, которые еще не наступили)
• Ставить на аватарку текстовые файлы, музыку, пустые файлы

Это самые часто встречающиеся ошибки.