Какие сценарии нужно в первую очередь проверять при тестировании приложения

Обновлено: 05.01.2025

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

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

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

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

Функциональное тестирование

Обязательно нужно тестировать приложение на пограничных состояниях.

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

Тестирование удобства пользования

Как обозначены обязательные и необязательные поля для заполнения? Можно ли их отличить друг от друга?
Понятно ли, как действовать дальше и куда нажимать? Если вы всматриваетесь в экран в поисках следующего шага или кнопки, зафиксируйте этот момент. Интерфейс должен быть интуитивно понятен, вести пользователя по конкретному маршруту в назначенную точку. Важную роль в этом играют как расположение элементов на экране, так и их стиль.
Можно ли продолжить работу в приложении после того как свернул и обратно развернул его? Не выкидывает ли пользователя?
Цвет кнопок с одинаковой функцией совпадает.
Как воспринимается текст на экране: заголовок заметнее всех, шрифт не напрягает, текст читается легко, смысл понятен, поля учтены.
Звук в приложении: что с ним происходит и как он звучит в разных состояниях приложения. Например, как работает приложение, когда подключена гарнитура или включается сторонний проигрыватель либо при сворачивании приложения.
Сколько времени и шагов понадобилось для завершения основных задач приложения? Можно ли упростить этот путь?

Оформляем и передаем информацию разработчикам

Включаем режим «бюрократии», потому что правильно оформленная ошибка сэкономит вам и разработчикам часы работы.

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

Дайте название ошибке. Будет легче ориентироваться по списку и в разговоре с командой.
Опишите ошибку. Что конкретно не так? Как задумывалось и должно быть?
Приложите скриншот или запись экрана, если ошибка происходит при конкретной последовательности действий.
Какая версия: десктоп или мобильная?
Какая платформа: iOS или Android?
Какой браузер и какая версия браузера?
Дайте подробный путь к странице/экрану с ошибкой.

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

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

Что такое тестирование сценария?

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

Давайте изучим это с помощью видео ниже —

Зачем создавать тестовые сценарии?

Тестовые сценарии создаются по следующим причинам:

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

Когда не создать тестовый сценарий?

Тестовые сценарии не могут быть созданы, когда

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

Как написать тестовые сценарии

Как тестер, вы можете выполнить следующие пять шагов для создания тестовых сценариев:

Шаг 1 : Прочтите документы с требованиями, такие как BRS, SRS, FRS, тестируемой системы (SUT). Вы также можете сослаться на примеры использования, книги, руководства и т. Д. Приложения, подлежащего тестированию.
Шаг 2 : Для каждого требования определите возможные действия и цели пользователей. Определить технические аспекты требования. Определите возможные сценарии злоупотребления системой и оцените пользователей с менталитетом хакера.
Шаг 3: После прочтения Документа с требованиями и проведения надлежащего анализа перечислите различные сценарии тестирования, которые проверяют каждую функцию программного обеспечения.
Шаг 4: После того, как вы перечислили все возможные сценарии тестирования, создается матрица отслеживания, чтобы убедиться, что каждому требованию соответствует соответствующий сценарий тестирования.
Шаг 5: Созданные сценарии проверяются вашим руководителем. Позже они также рассматриваются другими заинтересованными сторонами в проекте.

Советы по созданию тестовых сценариев

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

Пример 1. Сценарий тестирования для приложения электронной коммерции

Для приложения электронной коммерции несколько тестовых сценариев

Тестовый сценарий 1: проверка функциональности входа

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

Введение в тестирование мобильных приложений Интервью Вопросы и ответы

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

Ниже приведены самые лучшие вопросы для интервью:

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

Часть 1 - Вопросы по тестированию мобильных приложений (базовый уровень)

В этой первой части рассматриваются основные вопросы и ответы по тестированию мобильных приложений.

Q1. Какие существуют виды тестирования для мобильных приложений?

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

Q2. Объясните проблемы при тестировании мобильных приложений?

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

Q3. Объясните типы мобильных приложений?

Ответ:
Существуют различные типы приложений: веб-приложения, гибридные приложения и собственные приложения. Веб-приложения используются для запуска из мобильных браузеров, таких как Chrome, Firefox, Opera, Safari и т. Д. Эти приложения начинаются с «m». Гибридные приложения представляют собой комбинацию нативных и веб-приложений. Эти приложения могут работать на любых устройствах. Его также можно использовать в автономном режиме, и они разработаны с использованием веб-технологий HTML5 и CSS. Собственные приложения, которые можно установить на устройство из магазина игр Android и магазина приложений Apple, например, что такое приложение.

Давайте перейдем к следующему Вопросу интервью по тестированию мобильного приложения.

Q4. В чем разница между эмулятором и симулятором?

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

Q5. Объясните ошибки, которые в основном обнаруживаются при тестировании на мобильных устройствах?

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

Часть 2. Вопросы для интервью по тестированию мобильных приложений (Advanced)

Давайте теперь посмотрим на расширенные вопросы интервью для тестирования мобильных приложений.

Q6. На каком основании будет использоваться инструмент автоматизации тестирования для тестирования мобильного приложения на устройстве?

Ответ:
Чтобы выполнить мобильное тестирование с помощью инструмента автоматизации, у него должно быть следующее:

Поддержка нескольких платформ: инструмент автоматизации должен поддерживать несколько платформ. Это означает текущую платформу, а также будущие целевые платформы или платформы.
Версия ОС: инструмент должен поддерживать различные операционные системы, такие как IOS, Android или любая другая версия.
Сценарии: какой тип сценария будет поддерживаться, и в основном объектно-ориентированные инструменты обеспечивают высокую степень удобства использования сценария.
Побег из тюрьмы: когда инструмент использует рутированное устройство, из-за чего он может не поддерживать последнюю версию операционной системы.
Исходный код: обмен исходным кодом не всегда возможен, когда были внесены изменения в исходный код.

Q7. Каковы преимущества автоматизации тестирования?

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

Давайте перейдем к следующему Вопросу интервью по тестированию мобильного приложения.

Q8. Что можно рассмотреть для тестирования разработки мобильных приложений с помощью метода черного ящика?

Ответ:
Следующие вещи должны быть рассмотрены:

Q9. В чем разница между приоритетом и серьезностью?

Ответ:
Это популярное мобильное приложение, тестирующее интервью. Вопросы, задаваемые в интервью. Приоритет относится к тому, насколько важна функциональность и должна быть исправлена раньше или позже. Серьезность относится к последствиям ошибки или проблемы в приложении означает, насколько серьезной является эта проблема. Приоритет обозначается в следующей последовательности P1, P2, P3, P4 и P5. P1 называется критическим, P2 - средним, P3 - низким и так далее. Серьезность называется Sev5, Sev4, Sev3 и так далее. Сев5 самый высокий.

В10. Какие инструменты используются для тестирования мобильных приложений?

Ответ:
Этими различными инструментами являются Appium, Selen, Robotium, JMeter, Load runner и другие инструменты для отслеживания, такие как JIRA, Bugzilla, Rally, HP QC и т. Д.

Тестирование установки версии

В любом случае, даже если приложение совсем новое и ставится (деплоится) впервые, нужно проверить, как оно взлетело: запускается ли, можно ли начать с ним работать. Будь то мобильное приложение, десктопное или веб.

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

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

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

Тестирование производительности

На решение будут влиять такие факторы: сколько пользователей будет работать в системе, какой объем данных будет обрабатываться.

Дано	Решение
Мы знаем, что продуктом будет пользоваться 10 человек. И знаем, что они будут ворочать таблицами по несколько тысяч записей.	Имеет смысл запланировать volume-тестирование с большими объёмами данных.
Мы знаем, что в процессе использования продукта пользователи будут загружать много медиафайлов на сервер заказчика.	Необходимо выяснить, на какую нагрузку рассчитан этот сервер, и иметь эти данные в виду.
Приложением пользуется несколько человек в неделю, объём данных минимален.	Тестирования производительности не требуется.

Регрессионное тестирование

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

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

Интеграционное тестирование

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

Дано	Решение
Данные по продажам из портала передаются в аналитическую систему.	Важно не только проверить, что продажи ушли, ушли в корректном формате, но и то, что пришли в корректном формате — ничего не потерялось по дороге.

Тестирование локализации

Здесь важно ответить на вопросы о проекте:

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

Кроссбраузерность и кроссплатформенность

Мы не можем проверить корректность работы мобильного приложения на вообще всех девайсах. В случае с веб-приложением сразу возникает вопрос: а IE9 будем поддерживать? Перед тем, как вписать этот вид тестирования в стратегию, анализируем (если решение уже работает) или предполагаем (если еще не работает), на чём им будут пользоваться.

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

Подобным образом необходимо разобрать все остальные типы тестирования:

Функциональное (проводим или нет),
Приёмочное (кто его проводит и каким образом),
UX/UI (каковы объективные критерии хорошего интерфейса)
Модульное и юнит (кто пишет контракт-тесты, кто пишет юнит-тесты и пишем ли их вообще),
Тестирование безопасности (кто гарантирует безопасность данных, и насколько система устойчива ко взлому),
Отказ и восстановление (как поведет себя система в экстренных обстоятельствах)

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

В штатном режиме осмысленные приоритеты также важны. Например, разработку автотестов стоит планировать с учетом приоритетов: в первую очередь автоматизируется проверка наиболее критичных сценариев (smoke-тестирование).

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

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

Дано	Решение
На проекте CD/CI, написаны smoke-автотесты для первичной проверки функциональности.	Нужно окружение для первичной сборки кода в одной ветке, прогона smoke-тестов, где внешние системы закрыты заглушками. Также нужно окружение для ручного и интеграционного тестирования с сервисами заказчика (QA).
Регулярно проводятся сессии бета-тестирования.	Нужно окружение, которое будет видно «снаружи», более стабильное, чем QA-окружение.

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

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

Например, это могут быть:

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

Нужно договориться на берегу, а возможно, дальше и регулярно пересматривать формат ведения тестовой документации:

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

Условия и сценарии эксплуатации зависят от конкретного решения, поэтому обязательно нужно обсудить:

какими техниками тест-дизайна имеет смысл пользоваться. В рамках этого пункта полезно составить список объектов, с которыми работает приложение, и их классы эквивалентности.
какие эвристики и банальный жизненный опыт помогают придумать сценарии тестирования для конкретного проекта. Для мобильных приложений удобно использовать стандартные эвристики, например, “I SLICED UP FUN”.

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

Проговорите с командой ключевые моменты:

Как мы будем отличать ошибки, найденные нами, от ошибок, найденными заказчиками (и надо ли нам их различать),
Как оформлять доработки,
Надо ли отличать доработки, которые мы придумали сами, от тех, которые попросил сделать заказчик. Каким образом?
В какой статус ставить ошибку, если она не повторилась,
Какой статус считать конечным.

(Подробнее о способах описывать баги и userstory мы писали в этой статье).

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

На ранних этапах развития проекта готовность задачи/версии определяется на глаз.
С ростом самосознания мы понимаем, что нужны четкие критерии того, что задача/версия готова. Чтобы это решение было прозрачным для всех, а не «тестер попой чует, что всё норм». Например, в условиях настроенного CD мы считаем, что задача готова к тестированию, как только она вдеплоена на окружение QA и имеет статус Resolved.

Дано	Решение
На проекте поставлен процесс, что для каждой доработки составляется чек-лист для тестирования.	Считаем задачу проверенной, если мы прошли все пункты чек-листа.
На проекте ведется работа по спринтам.	Спринт считается готовым, если все доработки находятся в статусе Closed и нет ошибок с приоритетом Normal и выше.
На проекте составлен список функциональности по приоритетам.	Считаем, что версия готова к релизу, если успешно работает функциональность из первых пунктов списка.
На проекте написаны тест-кейсы и проводится регресионное тестирование перед релизом.	Версия считается готовой к релизу, если по итогам регресионного тестирования не было найдено ошибок с приоритетом Normal и выше (либо процент неудачных сценариев не выше 5).

Раздел полезен затем, чтобы уже на этапе планирования тестирования поставить задачи ответственным (админу и менеджеру) и к началу работ получить все необходимые инструменты.

Стоит обсудить такие вопросы:

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

В этом разделе предлагаем договориться о том, каковы KPI для оценки работоспособности приложения (помимо очевидного подсчета покрытия тестами). Этот показатель должен быть измеримым и достижимым. В частности, понять и ответить на следующем вопросы:

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

Единой и универсальной стратегии тестирования, подходящей каждому, не существует. Её составляют индивидуально под каждый проект.

Читайте также: