Выявляет дефекты и ошибки компьютерной игры контролирует ее качество
Привет, Хабр! Да-да, про тестирование ПО тут уже куча статей. Здесь я просто буду стараться структурировать как можно более полный охват данных из разных источников (чтобы по теории все основное было сразу в одном месте, и новичкам, например, было легче ориентироваться). При этом, чтобы статья не казалась слишком громоздкой, информация будет представлена без излишней детализации, как необходимая и достаточная для прохождения собеседования (согласно моему опыту), рассчитанное на стажеров/джунов (как вариант, эта информация может быть для общего понимания полезна ИТ-рекрутерам, которые проводят первичное собеседование и попутно задают некоторые около-технические вопросы).
Типичные ошибки в мобильных играх
1. Пользовательский интерфейс
К наиболее частым ошибкам интерфейса относятся:
- отсутствие адаптации под различные экраны,
- отсутствие подсказок (при необходимости),
- замедленный отклик на действия пользователя,
- нелогичная структура,
- непредсказуемое поведение элементов интерфейса.
2. Графика и анимация
Визуальные баги встречаются часто: разрыв изображения на экране, отсутствие текстур, обрезание областей изображения.
При создании графики и анимации мобильных игр используются те же движки, что и для ПК, только они адаптированы под определённые платформы. Поэтому ошибки, встречающиеся в играх, схожи.
Яркой иллюстрацией служит игра The Witcher: Enhanced Edition. Текстуры лица Геральта поплыли, а топор начал крутиться вокруг него. Это происходит при частом сворачивании игры.
3. Физика игры
Физическое моделирование используется для того, чтобы максимально погрузить пользователя в игру и сделать её как можно более реалистичной. Важно не только передать свойства твёрдых тел, При нарушении физики объекты начинают без причины парить в воздухе или не могут остановиться после взаимодействия.
Скриншот игры Roblox
4. Нарратив
Игры с логическими ошибками приведут к потере интереса со стороны пользователей. Сюда же можно отнести и расхождения в описании и непосредственном выполнении заданий. К примеру, в последний момент выясняется, что вы искали не тот артефакт.
5. Оптимизация под разные платформы
Если игровой движок написан лишь под одну платформу, то сложностей не возникнет. Но разработчики часто прибегают к использованию движков, позволяющих портировать игру сразу на несколько платформ (Android и iOS).
Такой подход помогают сэкономить время на подготовку к релизу. Но он же служит причиной появления дефектов из-за того, что код не полностью оптимизирован для выбранной платформы.
Неоптимизированная игра может попросту не воспроизводиться на телефоне или искажать графические элементы.
6. Функционирование искусственного интеллекта
Как правило, игровой искусственный интеллект используется при управлении:
- персонажами, активируются не игроком,
- ботами (имитирующие поведение человека программы),
- мобами (подвижные объекты в игре, которые, как правило, враждебно относятся к пользователю).
Баги чаще всего меняют алгоритм поведения второстепенных персонажей, что влияет на нарратив, анимацию или физику игры.
7. Система оплаты
При появлении ошибок в процессе оплаты может произойти утечка личных данных пользователя. Такой сценарий не только серьезно скажется на продвижении игры, но и может привести к финансовым и репутационным потерям компании.
К типичным ошибкам в этой области относится невозможность произвести оплату/донат или повторное списание средств.
Чем занимается QA-специалист?
Каждый день на ИТ-рынок выходят новые приложения, которые упрощают и улучшают жизнь людей. Перед тем, как такие программные продукты попадут в руки конечных пользователей, они проходят тщательную проверку на качество.
Именно от тестировщика зависит качество ПО и, следовательно, успех проекта на рынке. Согласитесь, мало кто станет пользоваться приложением, если оно не в состоянии выполнить даже базовые функции. Кроме того, для пользователя важна безопасность личной информации, ввиду постоянного использования приложений, требующих ввода персональных данных.
Поэтому специалист по тестированию является связующим звеном между разработчиком и конечным пользователем и отвечает за полную проверку программного продукта. Однако суть его работы заключается не просто в выявлении и документировании всевозможных дефектов.
Кроме поиска ошибок, тестировщик проверяет работоспособность всей функциональности приложения. Выполняя стандартные и нетипичные действия пользователей, он контролирует, не появляются ли сбои в программе.
К основным обязанностям тестировщика ПО относятся:
Тест-кейсы и чек-листы — основные тестовые артефакты, которые помогают отслеживать процесс тестирования. Тест-кейсы содержат последовательность шагов для тестирования каждой функциональности, а в чек-листах содержится список всех необходимых проверок.
В зависимости от поставленных задач на проекте QA-специалист решает, какие виды тестов применить. Например, если необходимо проверить ответную реакцию приложения на большое количество одновременных пользователей, то QA-команда проведёт тестирование производительности. А если цель проекта — обеспечить удобный интерфейс, то тестировщик ПО выберет юзабилити- и UI-тестирование.
- Документирование и анализ найденных дефектов
После выявления ошибки тестировщики приступают к её описанию. Это нужно для того, чтобы разработчик смог быстро понять, в какой части кода приложения кроется дефект.
Сейчас QA-специалисты вносят все ошибки в баг-трекинговые системы, например, JIRA или Bugzilla, а результаты проверок — в системы управления тестированием, такие как TestRail. Для более подробного описания багов можно приложить скриншоты экранов или видео.
Каждому баг-репорту в системе присваивается степень серьёзности ошибки (от тривиальной до блокирующей) и статус в соответствии с этапом жизненного цикла бага (от нового до закрытого).
- Проверки воспроизведения багов после их устранения
За исправлением ошибок следит тестировщик, который непосредственно работает вместе с командой разработчиков, или ведущий QA-специалист. Устраняются ошибки по соответствующей отметке в баг-трекинговой системе — сначала блокирующие и далее по убыванию.
Если дефект снова воспроизводится, ему присваивается статус «переоткрыт». Бывают случаи, когда исправление бага необходимо отсрочить. Это может произойти, если данную функциональность планируют кардинально изменить в следующем релизе, или дефект не влияет критически на работу всей системы. Тогда баг-репорт будет отмечен как «отсрочен».
Для ускорения QA-процессов часто применяют автоматизированные тесты. На проект привлекаются специалисты по автоматизации тестирования, которые пишут код проверки и запускают его. А программа самостоятельно выполняет тысячи нужных тестов, что экономит время мануального тестировщика.
Что нужно, чтобы стать тестировщиком?
Несмотря на относительную молодость профессии тестировщика ПО (не более 20 лет), для трудоустройства в QA требуется определённый набор знаний и навыков.
Чтобы успешно справляться с рабочими задачами, тестировщику следует прочно владеть теоретической и практической базой.
Кроме того, необходимо обладать рядом специфических качеств. Например, любознательность, внимание к деталям, усидчивость, коммуникабельность и желание постоянно перепроверять себя.
Ещё один важный момент — стремление развиваться. Например, сейчас на ИТ-рынке акцент смещён в сторону автоматизации процессов. И тестировщики осваивают новые для себя аспекты, например, языки программирования.
ОСНОВНЫЕ ТЕРМИНЫ
Тестирование ПО (Software Testing) — проверка соответствия между реальным и ожидаемым поведением программы, проводится на наборе тестов, который выбирается некоторым образом. Чем занимаются в тестировании:
планированием работ (Test Management)
проектированием тестов (Test Design) — этап, на котором создаются тестовые сценарии (тест кейсы), в соответствии с определёнными ранее критериями. Т.е., определяется, КАК будет тестироваться продукт.
анализом результатов (Test Analysis)
Основные цели тестирования
техническая: предоставление актуальной информации о состоянии продукта на данный момент.
коммерческая: повышение лояльности к компании и продукту, т.к. любой обнаруженный дефект негативно влияет на доверие пользователей.
Верификация (verification)
Валидация (validation)
Соответствие продукта требованиям (спецификации)
Соответствие продукта потребностям пользователей
Дефект (баг) — это несоответствие фактического результата выполнения программы ожидаемому результату.
Следует уметь различать, что:
Bug (defect) — это ошибка программиста (или дизайнера или ещё кого, кто принимает участие в разработке), то есть когда в программе, что-то идёт не так, как планировалось. Например, внутри программа построена так, что изначально не соответствует тому, что от неё ожидается.
Failure — это сбой в работе компонента, всей программы или системы (может быть как аппаратным, так и вызванным дефектом).
Жизненный цикл бага
Серьезность (Severity) — характеризует влияние дефекта на работоспособность приложения. Выставляется тестировщиком.
Blocker - ошибка, приводящая приложение в нерабочее состояние, из-за которой дальнейшая работа с системой или ее ключевыми функциями становится невозможна, т.е. тестирование значительной части функциональности становится недоступно
Крит (Critical) - неправильно работающая ключевая бизнес-логика, дыра в системе безопасности, проблема, приведшая к временному падению сервера или приводящая в нерабочее состояние некоторую часть системы, без возможности решения проблемы, используя другие непрямые пути (workaround).
Значительный (Major) - часть основной бизнес логики работает некорректно, есть возможность для работы с тестируемой функцией, используя обходные пути (workaround); либо дефект с высоким visibility – обычно не сильно влияющие на функциональность дефекты дизайна, которые, однако, сразу бросаются в глаза.
Тривиальная (Trivial) - ошибка, не касающаяся бизнес-логики приложения, не оказывающая никакого влияния на общее качество продукта, например, опечатки в тексте, несоответствие шрифта и оттенка и т.д.
Приоритет (Priority) — указывает на очередность выполнения задачи или устранения дефекта. Чем выше приоритет, тем быстрее нужно исправлять дефект. Выставляется менеджером, тимлидом или заказчиком.
ДОКУМЕНТАЦИЯ
Требования — это спецификация (описание) того, что должно быть реализовано. Требования описывают то, что необходимо реализовать, без детализации технической стороны решения.
Основные атрибуты требований:
Полнота — в требовании должна содержаться вся необходимая для реализации функциональности информация.
Непротиворечивость — требование не должно содержать внутренних противоречий и противоречий другим требованиям и документам.
Недвусмысленность — требование должно содержать однозначные формулировки.
Проверяемость (тестопригодность) — формулировка требований таким образом, чтобы можно было выставить однозначный вердикт, выполнено все в соответствии с требованиями или нет.
Приоритетность — у каждого требования должен быть приоритет (количественная оценка степени значимости требования).
Тест план (Test Plan) — документ, описывающий весь объем работ по тестированию:
Что нужно тестировать?
Как будет проводиться тестирование?
Когда будет проводиться тестирование?
Критерии начала тестирования.
Критерии окончания тестирования.
Основные пункты из которых может состоять тест-план перечислены в стандарте IEEE 829.
Неотъемлемой частью тест-плана является Traceability matrix — Матрица соответствия требований (МСТ) — это таблица, содержащая соответствие функциональных требований (functional requirements) продукта и подготовленных тестовых сценариев (test cases). В заголовках колонок таблицы расположены требования, а в заголовках строк — тестовые сценарии. На пересечении — отметка, означающая, что требование текущей колонки покрыто тестовым сценарием текущей строки. МСТ используется для покрытия продукта тестами.
Много слышали о тестировании и хотите попробовать себя в этой области? Но пока не совсем понимаете, с чем придётся работать?
В этой статье мы расскажем, что представляет собой работа в QA, кто такой тестировщик ПО и какие задачи он выполняет.
Где и как работают тестировщики?
У специалистов в этой области есть много вариантов по трудоустройству. Многие выбирают работу в ИТ-компаниях, которые условно можно разделить на две основные группы:
Заказчики такой организации делегируют часть или все обязанности по тестированию программных продуктов сторонним QA-экспертам. Перед тестировщиками появляется возможность работы с иностранными клиентами из различных индустрий, например, электронная коммерция, образование, банки и финансы и многое другое.
Эти организации фокусируются на разработке собственного программного продукта, а тестировщики в таких компаниях обеспечивают качество разрабатываемого ПО.
Должность специалиста по тестированию не всегда является финальной точкой. Кроме традиционного пути развития в тестировании от младшего специалиста до QA-лида, есть и альтернативные варианты карьерного роста. Можно погрузиться в смежные области: программирование, бизнес-анализ, менеджмент.
ВИДЫ ТЕСТИРОВАНИЯ
Основные виды тестирования ПО
Классификация по целям
Функциональное тестирование (functional testing) рассматривает заранее указанное поведение и основывается на анализе спецификации компонента или системы в целом, т.е. проверяется корректность работы функциональности приложения.
Тестирование пользовательского интерфейса (GUI Testing) — проверка интерфейса на соответствие требованиям (размер, шрифт, цвет, consistent behavior).
Тестирование удобства использования (Usability Testing) — это метод тестирования, направленный на установление степени удобства использования, обучаемости, понятности и привлекательности для пользователей разрабатываемого продукта в контексте заданных условий. Состоит из: UX — что испытывает пользователь во время использования цифрового продукта, и UI — инструмент, позволяющий осуществлять интеракцию «пользователь — веб-ресурс».
Тестирование безопасности (security testing) — это стратегия тестирования, используемая для проверки безопасности системы, а также для анализа рисков, связанных с обеспечением целостного подхода к защите приложения, атак хакеров, вирусов, несанкционированного доступа к конфиденциальным данным.
Инсталляционное тестирование (installation testing) направленно на проверку успешной установки и настройки, а также обновления или удаления приложения.
Конфигурационное тестирование (Configuration Testing) — специальный вид тестирования, направленный на проверку работы программного обеспечения при различных конфигурациях системы (заявленных платформах, поддерживаемых драйверах, при различных конфигурациях компьютеров и т.д.)
Тестирование на отказ и восстановление (Failover and Recovery Testing) проверяет тестируемый продукт с точки зрения способности противостоять и успешно восстанавливаться, т.е. обеспечивать сохранность и целостность данных, после возможных сбоев, возникших в связи с ошибками программного обеспечения, отказами оборудования или проблемами связи (например, отказ сети).
Тестирование локализации (localization testing) — проверка адаптации программного обеспечения для определенной аудитории в соответствии с ее культурными особенностями.
Нагрузочное тестирование (load testing) — определение или сбор показателей производительности и времени отклика программно-технической системы или устройства в ответ на внешний запрос с целью установления соответствия требованиям, предъявляемым к данной системе (устройству).
Тестирование стабильности или надежности (Stability / Reliability Testing) — это проверка работоспособности приложения при длительном (многочасовом) тестировании со средним уровнем нагрузки.
Стрессовое тестирование (Stress Testing) позволяет проверить насколько приложение и система в целом работоспособны в условиях стресса (например, повышение интенсивности выполнения операций до очень высоких значений или аварийное изменение конфигурации сервера) и также оценить способность системы к регенерации, т.е. к возвращению к нормальному состоянию после прекращения воздействия стресса.
Объемное тестирование (Volume Testing) — тестирование, которое проводится для получения оценки производительности при увеличении объемов данных в базе данных приложения.
Тестирование масштабируемости (scalability testing) — тестирование, которое измеряет производительность сети или системы, когда количество пользовательских запросов увеличивается или уменьшается.
Классификация по позитивности сценария
Позитивное — тест кейс использует только корректные данные и проверяет, что приложение правильно выполнило вызываемую функцию.
Негативное — тест кейс оперирует как корректными так и некорректными данными (минимум 1 некорректный параметр) и ставит целью проверку исключительных ситуаций; при таком тестировании часто выполняются некорректные операции.
Классификация по знанию системы
Тестирование белого ящика (White Box) — метод тестирования ПО, который предполагает полный доступ к коду проекта, т.е. внутренняя структура/устройство/реализация системы известны тестировщику.
Тестирование серого ящика — метод тестирования ПО, который предполагает частичный доступ к коду проекта (комбинация White Box и Black Box методов).
Тестирование чёрного ящика (Black Box) — метод тестирования ПО, также известный как тестирование, основанное на спецификации или тестирование поведения — техника тестирования, которая не предполагает доступа (полного или частичного) к системе, т.е. основывается на работе исключительно с внешним интерфейсом тестируемой системы.
Классификация по исполнителям тестирования
Альфа-тестирование — является ранней версией программного продукта, тестирование которой проводится внутри организации-разработчика; может быть вероятно частичное привлечение конечных пользователей.
Бета-тестирование — практически готовое ПО, выпускаемое для ограниченного количества пользователей, разрабатывается в первую очередь для тестирования конечными пользователями и получения отзывов клиентов о продукте для внесения соответствующих изменений.
Классификация по уровню тестирования
Модульное (компонентное) тестирование (Unit Testing) проводится самими разработчиками, т.к. предполагает полный доступ к коду, для тестирования какого-либо одного логически выделенного и изолированного элемента (модуля) системы в коде, проверяет функциональность и ищет дефекты в частях приложения, которые доступны и могут быть протестированы по-отдельности (модули программ, объекты, классы, функции и т.д.).
Интеграционное тестирование (Integration Testing) направлено на проверку корректности взаимодействия нескольких модулей, объединенных в единое целое, т.е. проверяется взаимодействие между компонентами системы после проведения компонентного тестирования.
Снизу вверх (Bottom Up Integration) Все низкоуровневые модули, процедуры или функции собираются воедино и затем тестируются. После чего собирается следующий уровень модулей для проведения интеграционного тестирования. Данный подход считается полезным, если все или практически все модули, разрабатываемого уровня, готовы. Также данный подход помогает определить по результатам тестирования уровень готовности приложения.
Сверху вниз (Top Down Integration) Вначале тестируются все высокоуровневые модули, и постепенно один за другим добавляются низкоуровневые. Все модули более низкого уровня симулируются заглушками с аналогичной функциональностью, затем по мере готовности они заменяются реальными активными компонентами.
Большой взрыв («Big Bang» Integration) Все или практически все разработанные модули собираются вместе в виде законченной системы или ее основной части, и затем проводится интеграционное тестирование. Такой подход очень хорош для сохранения времени. Однако если тест кейсы и их результаты записаны не верно, то сам процесс интеграции сильно осложнится, что станет преградой для команды тестирования при достижении основной цели интеграционного тестирования.
Системное тестирование (System Testing) — это проверка как функциональных, так и не функциональных требований в системе в целом. При этом выявляются дефекты, такие как неверное использование ресурсов системы, непредусмотренные комбинации данных пользовательского уровня, несовместимость с окружением, непредусмотренные сценарии использования и т.д., и оцениваются характеристики качества системы — ее устойчивость, надежность, безопасность и производительность.
Операционное тестирование (Release Testing). Даже если система удовлетворяет всем требованиям, важно убедиться в том, что она удовлетворяет нуждам пользователя и выполняет свою роль в среде своей эксплуатации. Поэтому так важно провести операционное тестирование как финальный шаг валидации. Кроме этого, тестирование в среде эксплуатации позволяет выявить и нефункциональные проблемы, такие как: конфликт с другими системами, смежными в области бизнеса или в программных и электронных окружениях и др. Очевидно, что нахождение подобных вещей на стадии внедрения — критичная и дорогостоящая проблема.
Классификация по исполнению кода
Статическое тестирование — процесс тестирования, который проводится для верификации практически любого артефакта разработки. Например, путем анализа кода (code review). Анализ может производиться как вручную, так и с помощью специальных инструментальных средств. Целью анализа является раннее выявление ошибок и потенциальных проблем в продукте. Также к этому виду относится тестирование требований, спецификаций и прочей документации.
Динамическое тестирование проводится на работающей системе, т.е. с осуществлением запуска программного кода приложения.
Классификация по хронологии выполнения
Повторное/подтверждающее тестирование (re-testing/confirmation testing) — тестирование, во время которого исполняются тестовые сценарии, выявившие ошибки во время последнего запуска, для подтверждения успешности исправления этих ошибок, т.е. проверяется исправление багов.
Регрессионное тестирование (regression testing) — это тестирование после внесения изменений в код приложения (починка дефекта, слияние кода, миграция на другую операционную систему, базу данных, веб сервер или сервер приложения), для подтверждения того факта, что эти изменения не внесли ошибки в областях, которые не подверглись изменениям, т.е. проверяется то, что исправление багов, а также любые изменения в коде приложения, не повлияли на другие модули ПО и не вызвали новых багов.
Приёмочное тестирование проверяет соответствие системы потребностям, требованиям и бизнес-процессам пользователя.
Пример кейса по тестированию для новичков
Давайте взглянем на работу тестировщика своими глазами и разберём небольшую практическую задачу.
Необходимо протестировать форму регистрации в социальной сети LinkedIn.
Первое, что нужно сделать, — открыть сайт. Форма для регистрации выглядит следующим образом:
Далее необходимо провести набор тестов для того, чтобы понять, работает ли форма корректно. Существует определённая последовательность выполнения проверок, которые можно классифицировать по глубине тестирования:
- Дымовое (Smoke testing) — проверка базовых функций приложения, в нашем случае главное назначение формы регистрации.
- Критического пути (Minimal acceptance testing) — тестирование работы системы или её части только на корректных данных. Например, значение «Иван» в поле имени.
- Расширенное (Acceptance testing) — проверка функциональности, включая и положительные, и отрицательные сценарии. Например, блок номера телефона требует числительные значения, но при таком тестировании мы проверим и корректные символы «1234567», и некорректные «Иван Иванов».
Сначала необходимо провести дымовое и тестирование критического пути, проверив соответствие работы функциональности минимальным требованиям. Главная задача данной формы — сохранение данных и переход на следующий этап регистрации. Следуя стандартным действиям конечных пользователей, заполняем все поля соответствующей информацией. Давайте посмотрим, как поведёт себя форма при вводе корректного электронного адреса. Например:
Форма приняла адрес и инициировала проверку безопасности. Адрес был введён правильно, структура соблюдена, присутствует символ «@».
Так, форма прошла минимальное приёмочное тестирование, и пользователь перешёл на второй этап регистрации.
После этого следует приступить к расширенному тестированию, ведь как раз здесь может появиться большое количество дефектов.Самый простой тест этой формы — нажать кнопку «Согласиться и присоединиться» без ввода данных в поля. Это поможет убедиться, что они обязательны к заполнению и что дальнейшая регистрация невозможна. Форма сразу выдаёт ошибку и выделяет красным те поля, которые необходимо заполнить. В нашем случае — все:
Затем мы проверим, среагирует ли форма на небезопасный пароль. Для этого, обозначив наши данные во всех блоках, напишем пароль до 6 символов.
Сразу появилось предупреждение, что пароль слишком короткий. Теперь посмотрим, как приложение поведёт себя, если мы будем вводить в поля нехарактерные символы. Например, внесём в блоки «Имя» и «Фамилия» небуквенные значения.
Почему так происходит? Возможно, форма проверяет лишь первое поле в коде. Или же можно говорить о не совсем верной локализации. Ведь приложение изначально написано для англоязычных пользователей. На английском языке имя и фамилия звучит как name и last name. А на русском языке могли оставить лишь перевод имени.
В заключение
Тестирование мобильных игр ― достаточно сложный процесс, поскольку нужно учитывать механику, геймплей, игровой интерфейс и прочее. Это перспективная профессия, которая позволяет совместить карьерные амбиции и хобби.
Курс «Тестирование компьютерных игр» поможет разобраться в нюансах игровых механик. Наши опытные преподаватели-практики научат вас выявлять самые сложные дефекты мобильных игр.
В качестве предисловия скажу, что я пришла в Иннову чуть больше года назад, моей задачей было «сделать тестирование в компании». Мой отдел тестирования состоит из двух групп: группа тестирования веб-приложений и группа тестирования игровых приложений. Такое разделение сложилось потому, что у этих направлений разные задачи и разные требования к сотрудникам.
Дальше рассказ будет про направление игрового тестирования. Это рассказ про моих ребят, про наши процессы, про нашу организацию работы. Приглашаю на словесную экскурсию.
Внешняя среда
Начну с описания внешней системы. У нас 11 игровых проектов. Они разного размера, их разрабатывают разные компании (чаще всего корейские), у них разные процессы, разный жизненный цикл, разная частота обновлений, разное качество и разные изначальные требования к качеству.
На первый взгляд кажется, что Иннова занимается только локализацией, и, казалось бы, что тут тестировать? Нам же дают готовый продукт, тестируйте только локализацию. Но вот эти разные изначальные требования к качеству продуктов играют свою роль. Разные компании-разработчики считают нормальным выпускать продукт на свой (корейский) рынок с определенным количеством известных багов. И это количество у всех, как вы понимаете, разное.
Мы же стараемся свести это количество к минимуму во всех наших играх. Потому что как только мы выпускаем игру в России, она становится «нашей». Мы так считаем.
Процесс тестирования
Тем не менее, мы не тестируем всю игру. Это было бы неправильно. В идеальном случае мы действительно должны тестировать только локализацию и сборку. К этому мы добавляем ещё тщательное тестирование новой функциональности и бета-тестирование пользователями.
То есть, план тестирования обновления выглядит примерно так:
— тестирование локализации:
— — списки для проверки, сроки
— тестирование новой функциональности:
— — чек-листы для проверки, приоритеты, сроки
— тестирование сборки:
— — смоук-тесты, сроки
— бета-тестирование:
— — задание для игроков, сроки
Я рассказывала про полный цикл тестирования локализованной игры на примере Атлантики.
Процесс взаимодействия с разработчиками зависит от проекта и от компании-разработчика. Баг-репорты могут оформляться в BTS, на нашей или на их стороне, могут собираться в Excel или Google-docs. Взаимодействуют по их исправлению с разработчиками чаще всего тестировщики, но кое-где вся коммуникация проходит через руководителя проекта. Мы подстраиваемся под проект, но вносим в процессы изменения для их оптимизации.
Тестовая среда
Помимо боевых серверов (которых у разных игр от одного до тринадцати) есть система Публичный Тестовый Сервер (ПТС) и внутренний тестовый сервер (QA-стенд). На ПТС может зайти любой игрок при желании. Там проводятся все бета-тестирования. Для того, чтобы туда попасть, не нужно особых сложностей, даже не нужен отдельный аккаунт, подойдет тот, которым играешь на боевых серверах.
На QA-стенде проводится внутреннее тестирование, до того, как отдать игрокам на ПТС.
Не любое обновление игры проходит весь путь QA-стенд -> ПТС -> боевые сервера. Некоторые обновления невозможно поставить на ПТС, не задев боевую систему. Такие сразу идут в бой после внутреннего тестирования. Некоторые наоборот, не могут быть нормально протестированы на внутреннем стенде, и они сразу идут вовне к нашим бета-тестерам.
Качество боевого продукта
И все же, приходится выпускать продукты с известными багами. И – бывает, что с критичными. Например, последнее большое обновление легендарного проекта Lineage II High Five Part 3, установленное на сервера 28 декабря, принесло серьезный баг: случайным образом у пользователей клиент игры вылетал с критической ошибкой при телепорте.
Это может зависеть от того, что, например, этот баг проявляется при нагрузке на серверы. И тогда он всплывает только в боевой эксплуатации. Мы не воссоздаем нагрузку в нашем цикле тестирования, потому что это делает компания-разработчик. Но, не всегда результативно. Так как часто обновления запускаются в одно время с Кореей и часто раньше Европы, мы идем на риск запуска с неизвестными багами.
Это может зависеть, например, от запланированного срока запуска обновления, которого ждут все игроки.
Это может зависеть от неопределенных сроков по решению проблемы от разработчиков.
Я уверена, что если устроить опрос среди игроков, пострадавших от бага с телепортом в High Five, согласились бы они играть без обновления и по сей день, то они все равно выбрали бы предновогоднее обновление.
Организация команды
Почти у каждого проекта есть тест-менеджер. Это один из моих ребят, который лучше всех разбирается в этом проекте, который планирует тестирование проекта, участвует в планировании установки обновлений. Он знает слабые места в своем проекте, и знает, что самое важное для его аудитории.
В его задачи входит:
— планирование тестирования проекта (или его обновлений)
— организация тестирования проекта (или его обновлений)
— — внутреннее тестирование
— — внешнее тестирование (с помощью бета-тестеров)
— информирование всех заинтересованных лиц о статусе тестирования и состоянии продукта
Тест-менеджер взаимодействует по работе:
«Заводы стоят, одни менеджеры в стране», — скажете вы :) Конечно же, тест-менеджер – это не должность, а роль. В эту роль мой сотрудник входит тогда, как на его проекте есть активность по тестированию. В остальное время – он тестировщик. Он – «руки другой головы». Один человек никогда не справится в срок с тестированием большого обновления большой игры. Поэтому, когда ему нужно, вся команда к его услугам. В момент активности его проекта – он главный, он ставит задачи и собирает результат.
Кроме того, если требуется массированная атака (например, проверить сборку клиента на всех серверах проекта), то тут на помощь приходит команда поддержки пользователей: они знают контент игры и готовы помочь. Здесь тестировщик опять же выступает в роли постановщика задачи.
Планирование работы команды на день происходят на утренних стендапах. Основные вопросы, которые обсуждает команда, это:
— «Я сегодня буду заниматься этим»
— «Мне сегодня нужно 4 человека на тестирование этого»
— «Я сегодня не загружен, кому нужно помочь?»
Подход владельца
У нас в компании есть понятие «драйвер задачи». Это значит «быть её владельцем», быть самым заинтересованным в её решении. Понятно, что тестировщик многого не может сделать самостоятельно:
— он не может напрямую повлиять на скорейшее исправление бага разработчиками
— он не может напрямую повлиять на ускорение установки
— он не может управлять инженером
и т.д.
Но он является драйвером своих задач. Это ему в первую очередь нужно как можно скорее получить патч с исправлением. Это ему в первую очередь нужны релиз-ноты. Это ему нужно установить обновление на тестовый сервер в пятницу, чтобы на выходных бета-тестеры могли нам помогать. И это он добивается решения этих вопросов от руководителя проекта, от инженера, от меня, в конце концов.
Человек, который в случае возникновения трудности, просто напишет письмо, сложит руки и будет ждать – нам не подходит.
Мои тестировщики – это менеджеры своих проектов. Проектов по тестированию проектов. Владельцы процесса.
Из той информации, которую я почерпнула от ребят, которые приходят на собеседования на позицию игрового тестировщика, такой подход к работе, мягко говоря, очень редок в компаниях, локализующих игры. Чаще всего отделы тестирования состоят из исполнителей, которым ставятся четкие задачи и требуются четкие результаты. Все решения принимает руководитель, все планы пишет и утверждает руководитель.
Я считаю неправильным самой делать это за всех, поэтому я учу делать это своих ребят. Это развивает их, и это дает свободу мне как руководителю заниматься более стратегическими задачами.
Правда, side-effect у такого подхода тоже есть. Ребята видят все стороны проекта, общаются со всеми участниками проекта, с почти всеми отделами в компании. Их видят, за ними наблюдают. И они растут.
Некоторые растут в другие отделы. Двое из моих игровых тестировщиков ушли в младшие менеджеры проектов. При этом один из них – на том проекте, на котором работал, а второго цапнул руководитель соседнего проекта. Прямо сейчас он (мой бывший тестировщик) в Сеуле налаживает коммуникации с компанией-разработчиком. Ещё один уходит в отдел аналитики игровых продуктов, как раз сейчас ищу ему замену. Я радуюсь за них. Значит, я хорошо работаю.
И не меньше я радуюсь за тех, для кого тестирование – это та отрасль, где они хотят развиваться и приносить пользу. Они растут как тестировщики, как тест-менеджеры, и не собираются никуда вострить лыжи.
На уровне компании
Не все проекты тестируются отделом тестирования. У нас в Иннове полностью и целиком за свой проект отвечает его руководитель. В том числе и за его качество, и за его тестирование. Я как руководитель сервисного отдела, являюсь владельцем своего направления, и, чтобы оставаться конкурентоспособной, должна предоставлять проектам услугу тестирования с таким качеством, чтоб руководители у меня её заказывали. То есть, если вдруг мои тестировщики начнут лажать, то руководитель проекта вправе отказаться от услуг моего отдела и обустроить себе тестирование самостоятельно. Любыми методами.
Или он может не заказывать её по другим причинам. Например, в нескольких небольших проектах тестирование осуществляется самой командой проекта. Потому что цикл тестирования обновления очень небольшой (несколько часов), контента немного, и внутри команды проще выделить время «Вот прямо сейчас все сели и побежали», чем ставить задачу в мой отдел.
В другом проекте руководитель не отдает тестирование нам, потому что эта активность интересна его сотрудникам, и они справляются с ней, попутно изучая новый контент, знание которого им нужно для работы.
В таких проектах мы выступаем как носители экспертизы: можем подсказать, помочь написать тесты, подсказать, как правильно оформить артефакты.
У нас трудно, но интересно. Нас ругают, и нам говорят спасибо пользователи. Мы боремся с системой и дружим с разработчиками.
«Мы только прошли третий уровень, графику надо немного подтянуть», – отвечает один из парней. Затем, развернувшись к своему другу, он улыбается, как будто только что выиграл в лотерею: «Не могу поверить, что мы играем в игры, и нам еще за это платят».
«Знаю, – отвечает ему второй. – И моя мама говорила, что это мое увлечение видеоиграми ни к чему хорошему не приведет».
Именно так на протяжение долгого времени люди представляли себе жизнь тех, кто занимается тестированием компьютерных игр – не как работу по 5-9 часов в день, а как мечту всех подростков. Кто бы не хотел сидеть на комфортном диване и целый день играть в игры с небольшими перерывами на «подтягивание» графики в третьем уровне?
Реальность немного отличается от этой картины. Так называемая проверка качества компьютерных игр (QA), то есть их тестирование (здесь и далее автор смешивает в кучу составляющие процесса – тестирование (базовый уровень), контроль качества и обеспечение качества – прим. переводчика), часто воспринимается как «играешь в игры, и тебе еще за это платят», но на самом деле это можно было бы лучше описать как процесс «ломания» игр. Это низкооплачиваемая, редко приносящая удовлетворение и часто разочаровывающая работа, которая влияет – так или иначе – на качество современных игр, но не так, как вы бы могли того ожидать.
Профессиональный тестировщик не просто сидит перед телевизором и, попивая какой-нибудь энергетик наподобие Red Bull, проходит пятый уровень последнего шутера. Он (или она) проводит по 14 часов кряду, атакуя стены в этих уровнях для того, чтобы проверить их целостность. Хорошее тестирование видеоигр больше похоже на решение головоломки, чем на набивание нового рекорда в Donkey Kong, что бы нам ни показывали в рекламных роликах. «Для того чтобы хорошо выполнять работу в QA-мире, необходимы специфический подход и особое отношение к жизни», – сказал мне опытный тестировщик компьютерных игр. «Это выходит за рамки страсти к видеоиграм и уж точно не совпадает с представлениями о том, что ты играешь в видеоигры и получаешь за это зарплату».
Обычно тестировщиков недооценивают, вспоминая о них лишь тогда, когда что-то идет не так. QA-профессионалы утверждают, что работа эта скучная, напряженная и часто рассматривается как возможность пробраться в другие области разработки игр, нежели более традиционный карьерный путь. Часто тестировщики работают по временным контрактам или для аутсорсинговых компаний, которые препятствуют их прямому общению с разработчиками игр. И когда в игре особенно много багов или она вообще выходит в свет в сыром, практически неиграбельном виде – как многие из последних релизов – то обычно все винят в этом тестировщиков. Они же, кроме всего прочего, и те, кто должен гарантировать защиту, будучи последней стеной между ошибками программистов и деньгами покупателей. Всю суть передает название процесса: обеспечение качества (Quality Assurance). Иными словами, тестировщики должны обеспечить качество продукта.
Но действительно ли виноваты те, кто тестируют игры, в том, что те выходят на рынок сырыми? Как возможно то, что тестировщики не находят тех багов, которые мы видим в играх? Почему то и дело множество серверов лежат? Чем вообще занимаются эти люди на протяжении всего рабочего дня?
В попытках изучить мир тестирования компьютерных игр и попытаться объяснить, в чем заключается эта работа и какова она, я в течение нескольких последних месяцев активно общался с огромным количеством людей, которые в настоящее время занимаются тестированием или когда-то были тестировщиками. Многие из них предпочли не называть себя, чтобы защитить свою карьеру. Некоторые говорили, что ненавидят тестирование, другие же утверждали, что не могут себя представить за другим занятием. Практически все сходятся в том мнении, что лишь немногие понимают, в чем именно заключается работа по обеспечению качества.
Сколько существуют игры, столько в них живут и баги. Некоторые относительно безобидны и даже стали легендарными, как загадочный MissingNo в Покемонах. Другие же вошли в историю видеоигр: бесконечные уровни Minus World в игрушке Super Mario Bros., в который можно попасть, пройдя сквозь стену. Но неутомимые участники игрового сообщества не сидят на месте: новые баги постоянно находятся и поносятся, а также веселят игроков – глюков в Legend of Zelda: Ocarina of Time, например, хватило на 17-минутное забавное видео!
Все это скорее дружелюбные баги. Большинство глюков в видеоиграх в лучшем случае раздражают, а в худшем – стопорят игру. Поэтому каждая игра и проходит проверку качества – обширное тестирование, проводимое для того, чтобы удостовериться в правильности работы игрушки. Аббревиатура QA пришла в индустрию видеоигр из мира продукции – микроволновок, машин, конвейеров – и во многом тестирование игр не отличается от проверки продуктов. Работа проверяющего заключается в том, чтобы обстучать и обшарить каждый уголок игры и наиграться в нее до чертиков, пока не будут удалены все глюки – точь-в-точь как рабочий на фабрике, дорабатывающий последнюю игрушку.
Когда дело доходит до QA, то игровая индустрия не имеет здесь никаких стандартов: все игры разные, и у каждой компании свой подход к тестированию. Но тестер обычно проводит месяцы за игрой, проверяя текущие варианты создаваемого продукта самыми различными способами. Чем больше багов находит тестировщик, тем выше он ценится компанией. Это, конечно же, очень непросто: видеоигры – это сложные наборы взаимодействующих систем, которые должны быть аккуратно и методично протестированы на баги. А это может включать в себя многоразовое прохождение одного и того же уровня с небольшими изменениями (будь то использование нового героя, другого оружия или выбор новой дороги) и ведения записей всего того, что с вами приключилось.
Давайте для примера возьмем Grand Theft Auto V. В огромном открытом мире, созданном разработчиками из Rockstar Games, тестировщикам приходилось разделять и властвовать. «Во время тестов разные люди занимались определенными миссиями или задачами, мини-играми и т.д.», – говорит человек, который помогал тестировать игру. «Обычно работа шла от общего к частному. Сначала ты проходишь основные миссии по порядку, потом идут кражи, затем дополнительные миссии и проверка различных персонажей, затем ты продвигаешься к тестированию стриптиз-клуба и проституток».
Этот же тестировщик сказал, что иногда им также приходится тратить уйму времени на крошечные участки игры. Например, когда дизайнеры из Rockstar попросили группу тестировщиков проверить все, что игроки могли бы сделать со службой такси в игре. Они быстро нашли, что если взять такси для новой миссии, то миссия запускается еще до того, как игрок отпустит таксиста с миром, что приводило к забавным моментам, когда автомобиль кружил вокруг или пытался сдать назад во время внутриигровых кат-сцен.
«Я думаю, что такая работа над проектами делает их гораздо лучше благодаря тому, что мы находим такие моменты, когда происходит что-то действительно дурацкое», – сказал тестировщик. «Мы нашли множество багов: говорящие свиньи, то и дело по-человечески встающие на задние ноги и уходящие прочь, простые прохожие, которые неожиданно стремительно взлетают ввысь. Тревор, сняв штаны, так и не удосуживался их одеть обратно – всю оставшуюся игру он бегал с болтающимися где-то внизу брюками. Собака Франклина погибала, едва прикоснувшись к воде… пес просто падал в пруд и камнем шел на дно, стоило ему только намочить лапы».
Обычные рабочие дни тестировщика могут значительно изменяться в зависимости от проекта, роли и позиции в компании. Так, человек, получивший работу через аутсорсинговую компанию, может провести 10 часов, врезаясь в каждую стену в последней версии Call of Duty, чтобы выяснить, где конструкцию можно пробить (эдакий «ударный тест»). Штатный сотрудник, который занимается тестами, может работать с программистом, пытаясь разобраться, отчего в их мобильной игре уменьшается частота кадров на версии для Android. Непостоянная и, как правило, монотонная по своей природе работа в сфере QA может нести в себе некоторые неожиданные испытания. Например, тестировщики, работавшие над музыкальной игрой Rock Band, говорили, что звуки, выдаваемые «пластмассовыми» барабанами, до такой степени приводили их в бешенство, что им пришлось установить правило: никаких инструментов по вторникам и четвергам.
Во время игры тестировщики записывают отчеты, используя программное обеспечение типа Jira, для того, чтобы объяснить, что произошло, и как это произошло. Программисты, которые в идеале не работают в данный момент над новым контентом и занимаются исключительно исправлением багов, анализируют отчеты и отвечают, если есть такая необходимость, – иногда с вопросами, проблемами и язвительными комментариями.
«Я не играл в BioShock Infinite по меньшей мере два года после релиза», – недавно сказал мне один бывший тестировщик. Он работал для компании 2K и много времени потратил на тестирование этой игры, он остался разочарован тем, во что в итоге превратился продукт, который, как он заметил, недостоин оригинальной версии.
«Единственное, что снова заставило меня играть в игру – это наблюдение за скоростным прохождением BioShock. Мы провели множество ночей за быстрым прохождением игры. Интересно увидеть, что игроки делают, чтобы урезать уровни».
Одним вечером тестировщик увидел видео, в котором был побит мировой рекорд прохождения игры. На одиннадцатой минуте он просто вышел из себя.
«Я взбесился, потому что они используют баг, чтобы выбраться из уровня и автоматически продвинуться вперед. Я ДОЛЖЕН БЫЛ НАЙТИ ЭТОТ ГЛЮК!» – написал мне тестировщик по мылу.
В течение очень долгого времени индустрия видеоигр выставляла тестирование как работу мечты: эй, дети, играйте в игры целый день, и мы вам за это будем платить! Но в последние годы, на поверхность выползли различные «ужастики» об этой профессии мечты: тестировщики начали делиться историями о монотонной изматывающей работе и плохом отношении к ним со стороны компаний, которые воспринимают их как расходный материал в огромной развивающейся машине.
Это выражается также и в низких зарплатах. Такая работа не имеет высоких требований – обычно для того, чтобы получить позицию тестировщика начального уровня, не нужно обладать опытом или дипломом. В то же время многие хотят заполучить эту работу, оттого и зарплаты средние. В 2014 году были опубликованы результаты исследования по зарплатам среднестатистического начинающего тестировщика. Оказалось, что годовой оклад такого работника составил около 55 тыс. долларов (судя по всему, это зарплата до вычета налогов – прим. переводчика), но это зарплата штатных сотрудников, в то время как большинство тестировщиков – контрактники, работающие либо напрямую с разработчиком, либо на компании, которые принимают заказы на тесты от множества издателей. Многие из этих контрактников говорили мне, что их зарплаты варьируются от 10 до 15 долларов за час – это в среднем 21-30 тыс. долларов в год.
Также тестировщики говорят, что на рабочем месте они ощущают неуважение к себе. Многим из них (особенно контрактникам) запрещено напрямую общаться с разработчиками, и все общение осуществляется исключительно посредством письменных рапортов о выявленных багах. «Это было чем-то вроде неписанного правила – нам нельзя было напрямую контактировать с разработчиками», – сказал мне один тестировщик. – Вся коммуникация обычно осуществлялась через QA-лидов. Все общение с разработчиками сводилось к комментариям в базе данных об ошибках, что нельзя назвать идеальной формой взаимодействия, при которой легко неверно интерпретировать комментарий/вопрос разработчика об ошибке как колкость или раздраженное замечание».
«Те, кто тестируют игры, думают только о том, чтобы найти баги, разработчики думают только об исправлении этих ошибок», сказал мне один тестер: «Они не являются командой и не работают вместе. Это почти как игра в теннис. Тестеры вообще-то заинтересованы в том, чтобы игра была глючной, иначе им нечего будет делать. Поэтому две стороны в каком-то смысле работают в ущерб друг другу, что нельзя назвать здоровым рабочим процессом».
В некоторых игровых компаниях начальство устанавливает для тестеров нормы найденных ошибок, и если багов будет меньше, чем указано в норме, то тестерам может грозить сокращение. Это порождает странное напряжение, когда тестировщики начинают конкурировать за то, кто первый найдет самые большие ошибки. Иногда такие сотрудники проявляют изобретательность и находят пути для того, чтобы больше работать, больше получать и выглядеть более ценными сотрудниками для компании. «Были и такие тестеры, которые выявляли баги в такое время, чтобы иметь возможность поработать сверхурочно. Если на выходные не запланировано дополнительных часов, то они сообщают о множестве ошибок днем в пятницу. В некоторых случаях это повлечет за собой сверхурочные часы работы», – рассказал мне один тестировщик.
Тестировщикам приходится также иметь дело с другими не самыми приятными вопросами индустрии игр, связанными в основном с обязательствами и частыми увольнениями. Крупные разработчики обычно нанимают десятки тестировщиков перед окончанием крупного проекта и прощаются с ними, как только игра выходит в свет. Вместо того, чтобы отмечать успешное завершение проекта с разработчиками, они вынуждены искать новую работу.
Учитывая все вышеперечисленное, у стороннего человека может создаться впечатление, что это ужасная собачья работа, но у нее есть и позитивные аспекты. Многие тестировщики говорят мне, что, несмотря на многие проблемы в работе, тестирование видеоигр может быть приносящим удовлетворение и уникальным в своем роде познавательным занятием.
«Мне нравилось заниматься тестированием, и я бы повторил это снова, если бы потребовалось», – говорит Обед Навас (Obed Navas), бывший тестер, который работал над такими тайтлами, как BioShock и Call of Duty. «Несмотря на то, что тестировщик – это не самое гламурное звание, и с такой работой ты рискуешь потерять всякий интерес к видеоиграм в нерабочее время, в конце концов возможность увидеть свое имя в титрах дорогого стоит. Также круто иметь какие-то связанные с проектами вещи, которые нигде нельзя достать, и на вопросы знакомых о том, где я их взял, с гордостью отвечать «Я работал над этой игрой».
P.S. Сами работаете тестировщиком? Согласны с мнением автора оригинальной статьи? Расскажите нам, пожалуйста, о своей работе, ее плюсах и минусах – так, как видите это вы.
Подведём итоги
Мы посмотрели на специфику работы в QA со всех сторон. Разобрали практическую задачу и нашли малозначимый дефект.
Вы также хотите попробовать свои силы в тестировании, научиться безошибочно распознавать дефекты и правильно их документировать? Курс «Основы тестирования ПО онлайн» от QA Academy поможет вам погрузиться в профессию, получить необходимые практические и теоретические знания, а главное — сделать первый шаг к работе мечты.
Ведь хороший специалист по тестированию ПО всегда будет востребован как дома, так и за границей. Дерзайте!
Для пользователей мобильные игры ― это возможность нескучно провести время за головоломкой, стратегией или на арене битвы. Для разработчиков же они являются сложными программными продуктами, создание которых требует внимания к графике, логике сюжета и реалистичности игрового движка. А как на мобильные игры смотрят QA-специалисты?
Тестирование в GameDev ― это многоуровневый процесс, который позволяет выявить дефекты на разных уровнях от текстовых и звуковых модулей до физики персонажей.
Качество мобильной игры напрямую влияет на её оценку в Google Play и App Store, а также на пользовательские отзывы. Чем ниже рейтинг, тем реже игра будет скачиваться и приносить всё меньше денег компании, а это негативный вариант для бизнеса. Поэтому привлечение тестировщиков мобильных игр является неотъемлемым компонентом жизненного цикла разработки ПО.
С какими багами чаще всего встречаются QA-специалисты в GameDev и какие проверки они проводят? Об этом мы расскажем далее.
Особенности тестирования мобильных игр
QA-процесс начинается с изучения архитектуры игры и анализа требований ней. Важно выстроить иерархию требований и выявить противоречащие положения. На этой основе формируется стратегия тестирования, которая покрывает:
- графику,
- управление,
- игровой процесс,
- производительность
Стоит помнить, что внедрение обновлений или введение дополнительных функциональностей каждый раз требует повторного тестирования, чтобы исключить вероятность появления дефектов.
Основные подходы оценки качества
1. Функциональное тестирование
На этом уровне QA-специалисты выявляют общие ошибки в игре, которые связаны с контентом или графикой. Это тестирование помогает оценить соответствие программного продукта составленным требованиям.
Что проверяем?
- Структура меню
- Размер шрифта
- Разрешение экрана
- Качество звука
- Навигацию
2. Тестирование совместимости
Здесь оценивается играбельность на различных устройствах и платформах.
Что проверяем?
Как игра устанавливается/запускается/удаляется на разных моделях мобильных телефонов.
3. Тестирование производительности
QA-специалисты изучают с какой скоростью пользователь может выполнять те или иные действия в игре, что может её тормозить. Низкие показатели этой метрики формируют негативный опыт у игроков.
Что проверяем?
- Время отклика
- Скорость совершения транзакции
- Продолжительность загрузки
4. Тестирование соответствия
На данном этапе проверяется соответствие игрового контента политике платформы, например Google Play и App Store.
Что проверяем?
Соответствует ли игры правовым нормам региона и площадки.
5. Тестирование локализации
Важно проверить не только наличие перевода текстовых или аудиодорожек, но и корректность их отображения. Например, если графические элементы адаптированы под чтение слева направо для пользователей из Европы и США, то те же блоки должны быть изменены при локализации в арабских странах, где текст отображается справа налево.
Что проверяем?
- Соответствие написания специфике региона
- Местное время и дата
6. Тестирование безопасности
Это оценка защищённости персональных данных пользователя: его логин, пароль, внутриигровая переписка, данные платёжной карты.
Что проверяем?
- Доступность конфиденциальной информации
- Степень влияния внешних угроз
Какие виды тестирования ПО существуют?
Как и в любой сфере деятельности, в тестировании ПО есть узкие направленности. Чтобы понять, в чём бы вы хотели специализироваться, стоит узнать больше об основных видах тестирования. Все типы разделяют на две группы:
- Функциональные (проверки того, насколько хорошо система выполняет свои функции, если вообще выполняет).
- Нефункциональные (проверки пользовательского опыта, например, нагрузочное тестирование, тестирование безопасности).
Помимо видов, в тестировании выделяют ещё и уровни, которые показывают над чем ведётся работа: над системой в целом или только над каким-то определённым компонентом.
Всего существуют четыре таких уровня:
- Модульное, или юнит-тестирование, — проверка работы отдельных частей системы.
- Интеграционное — тестирование взаимодействия нескольких частей программного продукта.
- Системное — проверка программного продукта на соответствие заявленным требованиям.
- Приёмочное — финальное тестирование на определение уровня готовности ПО к использованию.
Подробнее о классификации видов тестирования мы рассказали в этой статье.
НЕКОТОРЫЕ ТЕХНИКИ ТЕСТ-ДИЗАЙНА
Эквивалентное Разделение (Equivalence Partitioning) — это техника, при которой функционал (часто диапазон возможных вводимых значений) разделяется на группы эквивалентных по своему влиянию на систему значений. ПРИМЕР: есть диапазон допустимых значений от 1 до 10, выбирается одно верное значение внутри интервала (например, 5) и одно неверное значение вне интервала — 0.
Анализ Граничных Значений (Boundary Value Analysis) — это техника проверки поведения продукта на крайних (граничных) значениях входных данных. Если брать выше ПРИМЕР: в качестве значений для позитивного тестирования берется минимальная и максимальная границы (1 и 10), и значения больше и меньше границ (0 и 11). BVA может применяться к полям, записям, файлам, или к любого рода сущностям имеющим ограничения.
Доменный анализ (Domain Analysis Testing) — это техника основана на разбиении диапазона возможных значений переменной на поддиапазоны, с последующим выбором одного или нескольких значений из каждого домена для тестирования.
Предугадывание ошибки (Error Guessing — EG). Это когда тестировщик использует свои знания системы и способность к интерпретации спецификации на предмет того, чтобы «предугадать» при каких входных условиях система может выдать ошибку.
Причина / Следствие (Cause/Effect — CE). Подразумевается ввод условий, для получения ответа от системы (следствие).
Сценарий использования (Use Case Testing) — Use Case описывает сценарий взаимодействия двух и более участников (как правило — пользователя и системы).
Исчерпывающее тестирование (Exhaustive Testing — ET) — подразумевается проверка всех возможные комбинации входных значений. На практике не используется.
Попарное тестирование (Pairwise Testing) — это техника формирования наборов тестовых данных из полного набора входных данных в системе, которая позволяет существенно сократить общее количество тест-кейсов. Используется для тестирования, например, фильтров, сортировок. Этот интересный метод заслуживает отдельного внимания и более подробно рассматривается в статье по ссылке (в конце которой упоминаются инструменты для автоматизации применения PT ).
Тестирование на основе состояний и переходов (State-Transition Testing) — применяется для фиксирования требований и описания дизайна приложения.
Таблица принятия решений (decision table) — инструмент для упорядочения бизнес-требований, которые должны быть реализованы в продукте. Применяется для систем со сложной логикой. В таблицах решений представлен набор условий, одновременное выполнение которых приводит к определенному действию.
Читайте также: