тест план приложения план тестирования
Чек-лист тестирования мобильных приложений
У многих начинающих специалистов в области тестирования возникает вопрос: «А как же протестировать мобильное приложение. С чего начать, какие проверки стоит осуществить?» Данный вопрос актуален, когда они приходят в компанию, где нет документации на проекте, либо это только что появившийся стартап. Чтобы ответить на эти вопросы была подготовлена универсальная шпаргалка, которую можно использовать при тестировании практически любого приложения.
В данный чек-лист вошли только общие характеристики. Естественно, в тестируемом приложении может быть функциональность, для которой нужно применять отдельный подход и создать отдельные сценарии. То же самое верно для производительности, удобства использования, безопасности и прочего тестирования, которое необходимо вашему приложению.
Чек-лист для тестирования мобильных приложений состоит из восьми разделов:
Функциональное тестирование
В данном пункте нам важно убедиться, что наш продукт соответствует нужной функциональной спецификации, упомянутой в документации по разработке.
Что проверяем?
1. Установка/удаление/накатка версий
2. Запуск приложения (отображение Splash Screen)
3. Работоспособность основного функционала приложения
3.1 Авторизация (по номеру телефона/через соц. сети/e-mail)
3.2 Регистрация (по номеру телефона/через соц. сети/e-mail)
3.3 Онбординг новых пользователей
3.4 Валидация обязательных полей
3.5 Навигация между разделами приложения
3.6 Редактирование данных в профиле пользователя
3.7 Проверка оплаты
3.8 Тестирование фильтров
3.9 Бонусы
4. Корректное отображение ошибок
5. Работа с файлами (отправка/получение/просмотр)
6. Тестирование тайм-аутов
7. Тестирование заглушек (не соединения с интернетом/нет, например, товаров и т.д)
8. Тестирование pop-up, алертов
9. Тестирование WebView
10. Скролл/свайп элементов
11. Тестирование PUSH уведомлений
12. Сворачивание/разворачивание приложения
13. Разные типы подключений (сотовая связь/Wi-Fi)
14. Ориентация экрана (альбомная/портретная)
15. Темная/светлая темы
16. Реклама в приложении
17. Шаринг контента в соц. сети
18. Работа приложения в фоне
19. Пагинация страниц
20. Политики конфиденциальности и прочие ссылки на документы
Тестирование совместимости
Тестирование совместимости используется, чтобы убедиться, что ваше приложение совместимо с другими версиями ОС, различными оболочками и сторонними сервисами, а также аппаратным обеспечением устройства.
Что проверяем?
1. Корректное отображение гео
2. Информации об операциях (чеки и т.д.)
3. Различные способы оплаты (Google Pay, Apple Pay)
4. Тестирование датчиков (освещенности, температуры устройства, гироскоп и т.д.)
5. Тестирование прерываний (входящий звонок/смс/push/будильник/режим «Не беспокоить» и т.д.)
6. Подключение внешних устройств (карта памяти/наушники и т.д.)
Тестирование безопасности
Данная проверка нацелена на поиск недостатков и пробелов с точки зрения безопасности приложения.
Что проверяем?
1. Тестирование разрешений (доступ к камере/микрофону/галерее/и т.д.)
2. Данные пользователя (пароли) не передаются в открытом виде
3. В полях, с вводом пароля и подтверждением пароля, данные скрываются астерисками
Тестирование локализации и глобализации
Тестирование интернационализации/глобализации приложения включает тестирование приложения для различных местоположений, форматов дат, чисел и валют, а также замену фактических строк псевдостроками. Тестирование локализации включает тестирование приложения с локализованными строками, изображениями и рабочими процессами для определенного региона.
Что проверяем?
1. Все элементы в приложении переведены на соответствующий язык
2. Тексты зашиты внутри приложения и пользователь в настройках приложения может выставить необходимый язык
3. Тексты зависят от языка в системных настройках
4. Тексты приходят с сервера
5. Корректное отображение форматов дат (ГОД — МЕСЯЦ — ДЕНЬ или ДЕНЬ — МЕСЯЦ — ГОД.)
6. Корректное отображение времени в зависимости от часового пояса
Тестирование удобства использования
Тестирование удобства использования помогает удостовериться в простоте и эффективности использования продукта пользователем, с целью достижения поставленных целей. Иными словами, это не что иное, как тестирование дружелюбности приложения для пользователя.
Что проверяем?
1. Корректное отображение элементов на устройствах с различными разрешениями экранов
2. Все шрифты соответствуют требованиям
3. Все тексты правильно выровнены
4. Все сообщения об ошибках верные, без орфографических и грамматических ошибок
5. Корректные заголовки экранов
6. В поисковых строках присутствуют плейсхолдеры
7. Неактивные элементы отображаются серым
8. Ссылки на документы ведут на соответствующий раздел на сайте
9. Анимация между переходами
10. Корректный возврат на предыдущий экран
11. Поддерживаются основные жесты при работе с сенсорными экранами (swipe back и т.д.)
12. Пиксель-перфект
Стрессовое тестирование
Стрессовое тестирование направлено на определение эффективности производительности приложения в условиях повышенной нагрузки. Стресс-тест в этом контексте ориентирован только на мобильные устройства.
Что проверяем?
1. Высокая загрузка центрального процессора
2. Нехватка памяти
3. Загрузка батареи
4. Отказы
5. Низкая пропускная способность сети
6. Большое количество взаимодействий пользователя с приложением (для этого может понадобиться имитация реальных условий состояния сети)
Кросс-платформенное тестирование
Важный вид тестирования, который необходимо проводить для понимания того, будет ли должным образом отображаться тестируемый продукт на различных платформах, используемых целевой аудиторией.
Что проверяем?
— Работоспособность приложения на различных устройствах разных производителей
Тестирование производительности
Если пользователь устанавливает приложение, и оно не отображается достаточно быстро (например, в течение трех секунд), оно может быть удалено в пользу другого приложения. Аспекты потребления времени и ресурсов являются важными факторами успеха для приложения, и для измерения этих аспектов проводится тестирование производительности.
Что проверяем?
1. Время загрузки приложения
2. Обработка запросов
3. Кэширование данных
4. Потребление ресурсов приложением (например расход заряда батареи)
Александр Александров про тренды и технологии тестирования, про влияние Covid19 на рынок QA
Продолжу хвастаться статусом книги.
• Почему хуки – это лучшее что произошло в развиии Октябрьская лента: лучшее за месяц
Онлайн-тренинги
Что пишут в блогах (EN)
Разделы портала
Про инструменты
Автор: Ричард Патерсон (Richard Paterson)
Перевод: Ольга Алифанова
Писать тест-план или не писать – вот в чем вопрос! Этот вопрос регулярно поднимается в обсуждениях на Software Testing Clinic. Положительный ответ на этот вопрос, в свою очередь, породит множество новых вопросов. Вот некоторые из них, которые стоит задать себе или команде:
Это ценные вопросы, заслуживающие подробных и взвешенных ответов. Их задают очень часто, и их необходимо задавать, чтобы убедиться, что план дает внятные ответы на различные вопросы бизнеса – к примеру, связанные с наглядностью, контролируемостью, передачей знаний или управлением изменениями.
Нужен ли вам тест-план?
Документация как коммуникационное средство существует в первую очередь потому, что стороны, нуждающиеся в доступе к знаниям, разделены временными или пространственными рамками и неспособны синхронно делиться информацией.
Если все вы находитесь в одном пространстве, и вам не требуется долгоживущее подтверждение результатов ваших переговоров, то ценность документации сомнительна. Как гласит манифест Agile, люди и взаимодействия важнее полной документации. Не то чтобы у документации не было права на жизнь, но нужно тщательно выбирать, что и когда документировать. Очень важно соблюсти грамотный баланс, а также регулярно пересматривать его, дабы убедиться, что нужды всех заинтересованных сторон эффективно удовлетворены.
Я не собираюсь указывать вам, писать вам тест-план или не писать. Только вы можете определить, требуется ли вам этот документ в вашем конкретном контексте. Я лишь хочу, чтобы вы честно спросили себя, нужен ли вам этот тест-план?
Если вам кажется, что план вам нужен, то ниже – ряд вопросов, которые стоит задать, и несколько неплохих возможных ответов на них:
Вопрос: Кто запрашивает этот документ?
Ответ: заказчик, мы обязаны предоставить его по контракту.
Вопрос: Кто будет читать этот документ?
Ответ: Менеджер проекта, которому нужно убедиться, что я собираюсь протестировать продукт как минимум на удовлетворительном уровне.
Вопрос: Что читатель получит от этого документа?
Ответ: Вместе с прочей информацией – достаточную уверенность для релиза.
Вопрос: Что может улучшиться, если я прекращу писать тест-план?
Ответ: У меня будет больше времени для действительно ценной для проекта работы, потому что я не трачу время на то, что никто не будет читать.
Вопрос: Что может ухудшиться, если я прекращу писать тест-план?
Ответ: В проекте никто не будет иметь ни малейшего понятия, что именно я тестирую.
Вопрос: Кто заметит, если я прекращу писать тест-план?
Использование тест-плана как можно раньше в жизненном цикле проекта для поиска ответов на эти вопросы – это разновидность тестирования. Вы можете, например, спросить, есть ли критерии производительности, которые можно оценить и использовать для тестирования? Будет ли продукт выходить в интернет? Какие сценарии восстановления/избегания проблем должен поддерживать продукт? Задавая эти вопросы, вы подводите заинтересованных лиц к размышлениям о производительности, безопасности и устойчивости, и они займутся этим раньше, чем могли бы, не спроси вы их об этом.
Возможно, вы обязаны предоставить тест-план по контракту. В этом случае работайте совместно с заказчиком, чтобы уточнить, что он хочет узнать, и посредством какого механизма он хочет получить эту информацию.
Глаголы, а не существительные
«Планы бесполезны, но планирование бесценно» – Дуайт Эйзенхауэр.
Тест-планы статичны по своей природе, а планирование тестирования – динамический, дискурсный процесс обучения и переговоров. Документ, который никто не читает, бессмысленен. Создание того, что не принесет пользы проекту или его заинтересованным лицам, стоит денег и времени. План начнет приносить ценность только тогда, когда вы будете его использовать. Тест-план, который никто не читает, и который не информирует никого о тестировании – это трата вашего ценного времени, которое уместнее потратить на что-то более полезное.
Сбалансируйте создание подробного тест-плана и деятельность по планированию реального тестирования на период, покрытый этим планом. Если детальный план необходим, убедитесь, что вы учитываете риски, что что-то может остаться непокрытым или непротестированным. Тест-планы можно использовать как для информирования о том, что вы собираетесь тестировать, так и для того, чтобы сообщить, что вы, возможно, протестировать не сможете, если времени на это не хватит.
Заинтересованные лица – кто они?
Документы создаются для коммуникаций между людьми. Вам нужно понимать, кто эти люди в контексте связанной с тестированием информации. Кто ваши заинтересованные лица?
Если вы не уверены в ответе, определитесь, на какие вопросы о тестировании вам нужно получить ответ, а затем выясните, кто может ответить на них наилучшим образом, и спросите их об этом. Они должны быть задействованы в тестировании продукта или приложения. Объясните, почему вы задаете эти вопросы, и расскажите им, как их ответы улучшат ваше тестирование.
Тест-планом также могут пользоваться те, кому полезна информация, полученная в ходе запланированного тестирования. Найдите их, спросите, какая информация им требуется, и планируйте соответственно. Ниже – примеры заинтересованных лиц:
Тестировщики, которые хотят знать, что им предстоит тестировать в проекте. Тест-план может дать им подробную информацию об окружениях, версиях, или исходных данных. Тестировщики могут помочь вам улучшить план, основываясь на своем опыте, и добавить в него недостающую информацию и тест-подходы, о которых вы не подумали.
Менеджеры проекта хотят знать, что вы собираетесь тестировать, дабы быть уверенными в решении о выходе в релиз.
Техподдержка может рассказать об окружениях пользователей, о том, как они используют систему, и с какими проблемами сталкиваются. Эта информация может послужить основой для тестирования, покрывающего эти трудности.
Продакт-оунеры расскажут, как планируется использовать продукт, и, возможно, о случаях, когда пользователи используют его иначе. Эта информация полезна для создания профилей пользователей, помогающих в тестировании.
Продажники сообщат, какие продукты наиболее популярны, и как именно они применяются.
Если вы сомневаетесь, принадлежит ли человек к группе заинтересованных лиц, то всегда лучше включить его в процесс, нежели исключить. Никогда не знаешь, кто владеет информацией, которая может перевернуть подход к тестированию, или повлиять на его специфику. Со временем люди поймут механизмы сбора информации для тест-плана и то, как они могут помочь в его создании.
Как написать хороший тест-план: форма, структура и содержание
Тест-планы могут принимать какую угодно форму, например:
Хороший способ начать тест-план – это одностраничный план. Он поможет вам создать краткий и информативный документ.
С точки зрения содержания тест-планы обычно создаются, чтобы зафиксировать базовые ответы на «пять почему и как» тестирования. Содержание ваших планов может меняться по ряду причин (к примеру, от релиза к релизу или от спринта к спринту). Обновляйте ваш тест-план на основании полученной от релиза к релизу (или от продукта к продукту) информации.
Используйте ваши планы эффективно, чтобы улучшить процесс тестирования. Пусть он станет репозиторием для знаний организации. Сделали ошибку в релизе? Определите, как выловить ее в следующий раз, и добавьте в шаблон плана. Обычно забываете про какой-то тип тестирования? Отметьте, что это необходимо покрыть. Добавьте заметки о бедах и горестях пользователя, а также о том, что может дать вам полезную для тестирования информацию. Тест-план может стать основой для непрерывного совершенствования планирования и стратегии тестирования.
Со временем обновляйте шаблон, чтобы поддерживать и улучшать свое планирование. Пусть тетс-план работает на вас и формой, и структурой, и содержанием. Если он не работает – меняйте его.
Как оценивать тест-план
Когда ваш план готов, пересмотрите его. Оценка тест-плана может проводиться по-разному – лично я рекомендую личную встречу для его обсуждения. Такие встречи могут дать информацию о том, что еще необходимо добавить или покрыть. Они также делают тестирование продукта, приложения или релиза прозрачным для вас и вашей команды.
Пригласите на ревью заинтересованных лиц. Максимально сократите количество участников, но убедитесь, что все нужные роли присутствуют. Предположительный кворум может состоять из четырех человек или ролей – автор тест-плана (как правило, тестировщик), другой тестировщик, менеджер проекта, и представитель техподдержки. Однако для более крупных релизов можно подключать и других заинтересованных лиц – все зависит от вашей специфики.
Пройдитесь по каждому аспекту тест-плана и обсудите все его разделы. Выслушайте обратную связь, учтите информацию, которой делятся участники встречи.
Если план одобрен необходимым большинством, он не должен оставаться статичным. Когда тестирование начнется, используйте план для отслеживания усилий команды по достижению указанных в плане целей.
«Ни один план не выдерживает встречи с противником» – Хельмут фон Мольтке Старший.
«Только изменчивость постоянна» – Гераклит.
Как обновлять тест-план
Все меняется, и ваш план должен быть открыт переменам. Подход к планированию тестирования должен позволять справляться с изменениями, разъяснять, что вы будете делать иначе, какая информация вам необходима, и какую новую информацию (и кому) вы должны предоставить.
Договоритесь о подходящей частоте пересмотра тест-плана, или же используйте для этого любой достаточно весомый повод. Пересмотры не должны быть глобальными – пусть они соответствуют масштабу перемен. Это необязательно личные встречи: попросите людей просмотреть изменения и отправить вам комментарии по почте. Пусть всем будет легко помогать вам в поддержании плана в актуальном и рабочем состоянии.
Тест-планы работают на вас
Если ваше тестирование совсем не документируется, это может вызывать вопросы, на которые трудно найти ответ. Если вы способны показать ваш одобренный, обновляющийся, регулярно пересматриваемый тест-план вместе с результатами тестирования – у вас есть куда более солидная база для обсуждения тестирования, повышающая прозрачность того, что вы делаете для улучшения качества продукта.
Тест-план может помочь вам обдумать, какая подготовительная работа вам нужна. Это особенно важно, если вы не контролируете то, что может вам понадобиться в процессе тестирования. Если вам нужны серверы, данные или доступ к инструментам, то с шансами вы будете во всеоружии, как только они будут доступны – если вы заранее все спланируете. Очень важно быть готовым к действиям, как только появится что-либо, что можно тестировать.
Эта информация также полезна во время ретроспектив и пост-мортемов, позволяя лучше принимать решения и обсуждать, как можно улучшить тестирование.
Полезный тест-план
Используйте тест-план с пользой – как механизм для поиска ответов, как катализатор обмена информацией и достижения консенсуса, и для самоподготовки. Пусть он приносит ценность вам и остальным участникам проекта. Он должен работать на вас, а не против вас, а если он этого не делает – избавьтесь от него.
Об авторе
Ричард Патерсон руководит тестированием и безопасностью приложений в SAS R&D (Шотландия). Он считает себя не только тестировщиком, но и дизайнером, лидером и создателем.
Тест план
ТЕСТ ПЛАН (Test Plan) — это документ, в котором описывается планирование процесса тестирования. Он содержит рекомендации для процесса тестирования, такие как подход, задачи тестирования, потребности в окружающей среде, требования к ресурсам, график и ограничения.
Как только вам поручат протестировать новый продукт, вы должны подумать о том, как написать тест план проекта. Что входит в созданный тест план для тестирования? Какие шаги нужны, чтобы составить тест план? Мы поговорим в данной статье! Здесь мы обсудим ответы на эти вопросы, а также предоставим для скачивания образец тест плана.
Содержание
Разработка тест плана: кто отвечает за создание?
План тестирования создается для организации проверки соответствия продукта, установленным стандартам. Как правило, составление тест плана делает Test lead, но при взаимодействии с другими членами команды.