Qa(тестеры)

Мы — игровая студия Force Work, дружная команда, которая состоит из креативных единомышленников и наша главная цель - это игроки, ради которых мы каждый день стараемся сделать свой проект всё более интереснее и лучше!

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

Итак, какая главная цель тестирования?

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

Согласен, сказано это достаточно замысловато. Сейчас всё объясню. При тестирование продукта, вы должны сверить ожидаемый результат с реальным, например:

Рассмотрим ситуацию. Вы тестируете новый билд и при заходе на карту вы спавнитесь за карту.

Ожидаемый результат: При заходе на карту персонаж должен заспавнится на своём спавне.

Реальный результат: При заходе на карту персонаж спавнится за пределы карты и падает вниз.

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

Задачи:

• подготовка документации, тестового окружения и данных;
• тестирование;
• анализ результатов тестирования, а также составление отчетов и других документов.

Сейчас мы рассмотрим каждый пункт.

1) подготовка документации, тестового окружения и данных.

Для более комфортного тестирования создаём чек-листы. Что-же это такое? Это перечень, состоящий из пунктов, которые нужно выполнить либо проверить. То-есть мы сразу делаем себе какие-либо пометки на то, что хотим уделить большее внимание и т.д.

2) тестирование.

Думаю здесь всё понятно. Нам дают билд и мы тестируем его на работоспособность. Но тут я хотел-бы выделить методы тестирования, которые облегчат вам работу.

• Системное тестирование — это проверка как функциональных, так и не функциональных требований в системе в целом. При этом выявляются дефекты, такие как неверное использование ресурсов системы, непредусмотренные комбинации данных пользовательского уровня, несовместимость с окружением, непредусмотренные сценарии использования и т.д., и оцениваются характеристики качества системы — ее устойчивость, надежность, безопасность и производительность.
• Повторное тестирование -тестирование, во время которого исполняются тестовые сценарии, выявившие ошибки во время последнего запуска, для подтверждения успешности исправления этих ошибок, т.е. проверяется исправление багов.
• Регрессионное тестирование — это тестирование после внесения изменений в код приложения, для подтверждения того факта, что эти изменения не внесли ошибки в областях, которые не подверглись изменениям, т.е. проверяется то, что исправление багов, а также любые изменения в коде приложения, не повлияли на другие модули ПО и не вызвали новых багов.
• Тестирование удобства использования — это метод тестирования, направленный на установление степени удобства использования, понятности и привлекательности для пользователей разрабатываемого продукта в контексте заданных условий.
• Тестирование интерфейса (GUI/UI testing) — проверка требований к пользовательскому интерфейсу.
• Инсталляционное тестирование — тестирование, направленное на проверку успешной установки и настройки, обновления или удаления приложения.
• 
  

Основные фазы тестирования:

• Pre-Alpha: прототип, в котором всё ещё присутствует много ошибок и наверняка неполный функционал. Необходим для ознакомления с будущими возможностями программ.
• Alpha: является ранней версией программного продукта, тестирование которой проводится внутри фирмы-разработчика.
• Beta: практически готовый продукт, который разработан в первую очередь для тестирования конечными пользователями.
• Release Candidate (RC): возможные ошибки в каждой из фичей уже устранены и разработчики выпускают версию на которой проводится регрессионное тестирование.
• Release: финальная версия программы, которая готова к использованию.

Градация Серьезности дефекта (Severity):

• Блокирующий (S1 – Blocker)
• тестирование значительной части функциональности вообще недоступно. Блокирующая ошибка, приводящая приложение в нерабочее состояние, в результате которого дальнейшая работа с тестируемой системой или ее ключевыми функциями становится невозможна.
• Критический (S2 – Critical)
• критическая ошибка, неправильно работающая ключевая бизнес-логика, дыра в системе безопасности, проблема, приведшая к временному падению сервера или приводящая в нерабочее состояние некоторую часть системы, то есть не работает важная часть одной какой-либо функции либо не работает значительная часть, но имеется workaround (обходной путь/другие входные точки), позволяющий продолжить тестирование.
• Значительный (S3 – Major)
• не работает важная часть одной какой-либо функции/бизнес-логики, но при выполнении специфических условий, либо есть workaround, позволяющий продолжить ее тестирование либо не работает не очень значительная часть какой-либо функции. Также относится к дефектам с высокими visibility – обычно не сильно влияющие на функциональность дефекты дизайна, которые, однако, сразу бросаются в глаза.
• Незначительный (S4 – Minor)
• часто ошибки GUI, которые не влияют на функциональность, но портят юзабилити или внешний вид. Также незначительные функциональные дефекты, либо которые воспроизводятся на определенном устройстве.
• Тривиальный (S5 – Trivial)
• почти всегда дефекты на GUI — опечатки в тексте, несоответствие шрифта и оттенка и т.п., либо плохо воспроизводимая ошибка, не касающаяся бизнес-логики, проблема сторонних библиотек или сервисов, проблема, не оказывающая никакого влияния на общее качество продукта.

3)анализ результатов тестирования, а также составление отчетов и других документов.

Тут я хотел бы выделить правильное заполнения тест-кейса.

тест-кейс – это сценарий, по которому проверяются программные продукты.

Отчёт о дефекте/баге:

1. Уникальный идентификатор (ID) — присваивается автоматически системой при создании баг-репорта.
2. Тема — кратко сформулированный смысл дефекта, отвечающий на вопросы: Что? Где? Когда(при каких условиях)?
3. Подробное описание — более широкое описание дефекта (указывается опционально).
4. Шаги для воспроизведения — описание четкой последовательности действий, которая привела к выявлению дефекта. В шагах воспроизведения должен быть описан каждый шаг, вплоть до конкретных вводимых значений, если они играют роль в воспроизведении дефекта.
5. Фактический результат — описывается поведение системы на момент обнаружения дефекта в ней. чаще всего, содержит краткое описание некорректного поведения(может совпадать с темой отчета о дефекте).
6. Ожидаемый результат — описание того, как именно должна работать система в соответствии с документацией.
7. Вложения — скриншоты, видео или лог-файлы.
8. Серьёзность дефекта (важность, Severity) — характеризует влияние дефекта на работоспособность приложения.
9. Приоритет дефекта — указывает на очерёдность выполнения задачи или устранения дефекта.
10. Окружение – окружение, на котором воспроизвелся баг.

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