Артефакты тестирования

1.

Артефакты
тестирования

2.

Артефакты
Что такое артефакты и кому они нужны?
Тестовые артефакты — это документы и материалы, которые создаются и используются в процессе
тестирования программного обеспечения. Они помогают организовать, планировать и отслеживать процесс
тестирования, а также обеспечивают прозрачность и качество работы команды на всех этапах жизненного
цикла тестировании
Кому нужны тестовые артефакты?
1.
2.
3.
Тестировщикам: Для планирования и выполнения тестирования, а также для документирования
результатов и обнаруженных ошибок.
Разработчикам: Для понимания требований и условий, при которых были обнаружены ошибки, а также
для получения информации о том, что нужно исправить.
Менеджерам проектов: Для отслеживания прогресса тестирования, оценки рисков и принятия решений о
сроках и ресурсах.
4.
Заказчикам и заинтересованным сторонам: Для получения информации о качестве
продукта и статусе тестирования, что помогает в принятии решений о запуске или доработке
продукта.
Тестовые артефакты играют важную роль в обеспечении качества программного обеспечения
и помогают всем участникам процесса тестирования работать более эффективно и слаженно.
2

3.

Артефакты
Какие бывают артефакты тестирования?
Основные, которые создаются или используются ежедневно:
Баг-репорт
Тест-кейс / Чек-лист
QA sign-off (ежедневный / еженедельный отчет о тестировании)
Тест-сьют
Тест-план
Дополнительные (могут быть полезны при погружении в проект или к которым мы можем
обращаться с определенной периодичность):
Чит-листы
Тестовые сценарии
Проектные инструкции
Проектный он-бординг
Метрики тестирования
Описание тестовой среды
Отчет о тестировании сборки / Статус-отчет
3

4.

Баг-репорт
Что такое баг-репорт?
Баг — это несоответствие между фактическим поведением системы и ее ожидаемым поведением,
которое может негативно повлиять на функциональность и/или пользовательский опыт.
Основой для ожиданий могут служить:
функциональные и нефункциональные требования, спецификации, макеты, выполнение условий
консистентности системы. При отсутствии документации допускается определять дефект ориентируясь на
личный опыт инженера, “good practice” или текущие тренды UX.
Баг-репорт - это технический документ, для фиксирования и подробного описания
ошибок в работе ПО. Его основная цель — предоставить команде разработчиков четкую и
понятную информацию о проблеме, чтобы они могли ее воспроизвести и исправить
Баг-репорт должен быть написан четко и лаконично, чтобы любой член команды мог
быстро понять суть проблемы. Хорошо составленный, правильно локализованный и четко
описанный баг-репорт помогает ускорить процесс исправления ошибок и улучшает
качество конечного продукта
4

5.

Баг-репорт
Требования к баг-репортам
Заголовок (Summary) - это Краткое и ясное описание проблемы
Заголовок должен последовательно отвечать на эти вопросы «Что? Где? При каких условиях?». Часто в
заголовок так-же добавляют информацию о фиче или системе, в которой обнаружен дефект
Описание (Description) - это подробное объяснение проблемы, включая контекст и важные детали.
Основные атрибуты, содержащиеся в описании
Предусловия. Это условия или состояния, которые должны быть выполнены или установлены
перед началом тестирования конкретного функционала или перед воспроизведением бага.
Шаги воспроизведения. Это последовательность действий, которые необходимо выполнить,
чтобы воспроизвести обнаруженный баг. Важно четко и последовательно описывать конкретные
действия
Фактический результат. Описание ответа системы при выполнении предусловий и шагов
Ожидаемый результат. Описание ответа системы заложенное в постановке на разработку
(требования, спецификации, макеты)
Окружение (Environment) - это информация о среде, в которой была обнаружена ошибка и
которые влияют на воспроизведение бага: версия программного обеспечения, операционная
система, браузер и его версия, аппаратное обеспечение, сетевые условия и пр.
5

6.

Баг-репорт
Требования к баг-репортам
Приоритет (Priority)— это оценка важности и срочности исправления обнаруженного бага
На данный момент в Jira используется градация: Lowest - Low - Medium - High - Highest
Серьезность (Severity) — это оценка уровня воздействия обнаруженного бага на
функциональность системы или приложения.
В настройках Jira для баг-репортов используется градация: Trivial - Minor - Major - Critical Blocker
Вложения (Attachments) — это поле в баг-репорте, которое позволяет добавлять
дополнительные файлы или документы, связанные с обнаруженной ошибкой
Важно! При оформлении дефекта локализовать ошибку и сформировать документ с
данными локализации
6

7.

Баг-репорт
Наглядный пример баг-репорта
7

8.

Тест-кейс
Что-такое тест-кейсы?
Тест-кейс - это документ, который содержит последовательность действий, которая описывает конкретный
набор условий, действий и ожидаемых результатов, необходимых для проверки определенной
функциональности или характеристики ПО.
Как писать хорошие тест-кейсы?
1 Четкость и простота
Шаги должны быть понятными и лаконичными.
2 Один тест-кейс — одна проверка
Не стоит объединять несколько проверок в один тест-кейс.
3 Актуальность
Тест-кейсы должны соответствовать текущим требованиям.
4 Покрытие всех сценариев
Убедись, что тест-кейсы покрывают все возможные сценарии (позитивные, негативные,
граничные случаи).
8

9.

Атрибуты тест-кейса
Название (Title). Должно быть четким, кратким, понятным и однозначно характеризующим суть тест-кейса.
Название тест-кейса может содержать в себе “путь” в декомпозиции до проверяемой элементарной
системы/сущности элементарной и/или действие с ней.
Шаги (Steps to reproduce). Шаги тест-кейса должны быть четкими, понятными и последовательными, без
лишних (не несущих смысловую нагрузку) слов.
Предусловие (Preconditions). Необходимые условия системы для прохождения тест-кейса.
Приоритет (Priority) - это оценка важности и срочности выполнения данного теста в контексте общего
процесса тестирования. Другими словами, Priority - это насколько сильно будет бомбить у пользователя,
если функциональность проверяемая тестовым артефактом будет не работать/работать не ожидаемо
Behavior (Поведение) - это описание того, как система должна реагировать на определенные действия или
входные данные в рамках тестируемого сценария
-
-
Позитивные кейсы - ожидаемое пользователем поведение системы, на валидных
входных данных
Негативные кейсы - неожидаемое пользователем поведение системы, на валидных
входных данных, обработка которого указана в требованиях
Деструктивные кейсы - неожидаемое пользователем поведение системы, на
невалидных данных, обработка которого не указана в требованиях
9

10.

Атрибуты тест-кейса
Qase io
Zephyr Scale
10

11.

Чек-лист
Что-такое чек-листы?
Чек-лист - это инструмент, представляющий собой список элементов, задач или критериев, которые
необходимо проверить или выполнить в процессе тестирования, контроля качества или выполнения других
операций. Чек-листы помогают обеспечить систематический подход к выполнению задач, минимизируя
вероятность пропуска важных шагов или деталей
При составлении чек-листа для проверки какого-либо функционала, хорошей практикой считается, чтобы
название каждой проверки в чек-листе соответствовало формату “Действие/состояние - результат”
Основные характеристики чек-листа
1 Простота: Чек-лист — это не подробная инструкция, а краткий перечень пунктов для проверки.
2 Гибкость: Чек-лист можно быстро адаптировать под новые требования или изменения в продукте.
3 Универсальность: Чек-листы можно использовать для любых типов тестирования: функционального,
регрессионного, smoke-тестирования и т.д.
4 Наглядность: Чек-лист позволяет легко отслеживать, что уже проверено, а что ещё нет.
Чек-листы должны покрывать все позитивные и негативные пути использования
элементарной системы, указанные в требованиях, а также те, которые видит QA на
основании своего опыта и чит-листов.
11

12.

Чек-лист
Как создать хороший чек-лист?
1 Определи цель
Чётко сформулируй, что именно нужно проверить (например, функциональность авторизации).
2 Составь список ключевых пунктов
Включи в чек-лист все важные аспекты, которые нужно проверить.
3 Сделай его понятным
Пункты должны быть краткими и легко интерпретируемыми.
4 Регулярно обновляй
Чек-лист должен отражать актуальные требования и изменения в продукте.
Чем чек-лист отличается от тест-кейса?
Чек-лист
Тест-кейсы
Краткий список пунктов для проверки
ожидаемыми результатами.
Не содержит шагов выполнения
действия
Гибкий и легко адаптируемый
формализованный
Подходит для smoke-тестирования и
/ Подробная инструкция с шагами и
/ Содержит пошаговые
/ Более строгий и
12

13.

Чек-лист
Наглядный пример чек-листа
Qase io
Zephyr Scale
13

14.

Классификация тестов
Позитивные проверки - это тесты, которые проверяют, как система работает при корректных
входных данных или в штатных условиях. Цель таких проверок — убедиться, что система
выполняет свои функции так, как задумано.
Примеры:
Ввод правильного логина и пароля для авторизации.
Добавление товара в корзину с корректными данными.
Отправка формы с заполненными обязательными полями.
Ключевая фраза: "Проверка, что система работает правильно, когда всё в порядке."
14

15.

Классификация тестов
Негативные проверки - это тесты, которые проверяют, как система обрабатывает некорректные
данные или нестандартные ситуации. Цель таких проверок — убедиться, что система корректно
обрабатывает ошибки и не ломается.
Примеры:
Ввод неправильного пароля при авторизации.
Попытка отправить форму с пустыми обязательными полями.
Ввод букв в поле, где ожидаются только цифры.
Ключевая фраза:
"Проверка, что система правильно реагирует на ошибки и некорректные данные."
15

16.

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

17.

Техники тест-дизайна
Тест-дизайн (Test Design) — это процесс создания тестовых сценариев (тест-кейсов, чек-листов) на основе
анализа требований, функциональности системы и возможных рисков. Основная цель тест-дизайна — обеспечить
максимальное покрытие тестами при минимальных затратах времени и ресурсов.
Основные задачи тест-дизайна
1 Определение что тестировать:
Выбор функциональности, которая будет проверяться.
2 Определение как тестировать:
Выбор техник и подходов для создания тестов.
3 Определение когда тестировать:
Планирование последовательности тестов (например, сначала smoke-тестирование, потом регрессионное).
4 Оптимизация тестов:
Сокращение количества тестов без потери качества покрытия.
17

18.

Техники тест-дизайна
1. Эквивалентное разделение (Equivalence Partitioning): Входные данные делятся на классы эквивалентности, где данные внутри одного
класса ведут себя одинаково
Пример: Поле "Возраст" принимает значения от 18 до 60.
Валидный класс: 18–60 / Невалидный класс: меньше 18 или больше 60
2. Анализ граничных значений (Boundary Value Analysis): Проверка значений на границах допустимого диапазона.
Пример: Поле "Количество товаров" принимает значения от 1 до 10.
Граничные значения: 1, 10 / За границами: 0, 11
3. Таблицы решений (Decision Tables): Используется для проверки комбинаций входных данных и условий
Пример: Логика скидки
Если сумма > 1000 и клиент постоянный → скидка 10% / Если сумма > 1000, но клиент не постоянный → скидка 5%
4. Попарное тестирование (Pairwise Testing): Проверка всех возможных пар значений параметров
Пример: Тестирование формы с полями: браузер (Chrome, Firefox), ОС (Windows, macOS).
5. Причинно-следственный анализ (Cause-Effect Graphing): Анализ причин (входных данных) и их эффектов (результатов)
Пример: Логика авторизации:
Если логин и пароль верные → успешная авторизация / Если логин неверный → ошибка "Неверный логин".
6. Предугадывание ошибок (Error Guessing): Использование опыта и интуиции для предположения, где могут возникнуть ошибки
Пример: Поле "Email"
Ввод email без "@" / Ввод email с пробелами
7. Сценарии использования (Use Case Testing):Тестирование на основе реальных сценариев использования системы
Пример: Сценарий "Оформление заказа":
Добавить товар в корзину > Перейти в корзину > Оплатить заказ
18

19.

Примеры
Задача: протестировать форму регистрации с полем “Имя пользователя” (только буквы, от 3 до 15 символов)
1 Ввод "Anna" (корректное имя) - Имя принято
разделение)
2 Ввод "An" (2 символа) - Ошибка: "Минимум 3 символа
3 Ввод "Anna123" (содержит цифры) - Ошибка: "Только буквы"
4 Ввод "A" * 16 (16 символов) - Ошибка: "Максимум 15 символов"
(Позитивная / Эквивалентное
(Негативная / Анализ граничных значений)
(Негативная / Предугадывание ошибок)
(Негативная / Анализ граничных значений)
Задача: протестировать форму регистрации с полем “Пароль” (минимум 8 символов, должен содержать хотя бы одну цифру и
одну заглавную букву).
5 Ввод "Password1" (корректный пароль) - Пароль принят
(Позитивная / Эквивалентное разделение)
6 Ввод "pass" (7 символов) - Ошибка: "Минимум 8 символов"
(Негативная / Анализ граничных значений)
7 Ввод "password" (нет цифр и заглавных букв) - Ошибка: "Должна быть цифра и заглавная буква"
(Негативная / Предугадывание ошибок)
8 Ввод "PASSWORD1" * 100 (очень длинный пароль) - Ошибка: "Превышена длина"
(Деструктивная / Предугадывание ошибок)
19

20.

Примеры
Задача: протестировать форму регистрации с полями “Имя пользователя” и “Пароль”
1 Ввод всех корректных данных - Успешная регистрация
Сценарии использования)
2 Ввод некорректного имени и корректного пароля - Ошибка: "Неверное имя"
3 Ввод корректного имени и некорректного пароля - Ошибка: "Неверный пароль"
4 Ввод всех некорректных данных - Ошибки во всех полях
Сценарии использования)
5 Ввод очень длинных данных во все поля - Ошибка: "Превышена длина"
использования)
(Позитивная /
(Негативная / Сценарии использования)
(Негативная / Сценарии использования)
(Негативная /
(Деструктивная / Сценарии
Подход, основанный на классификации проверок (позитивные, негативные, деструктивные) и применении техник тест-дизайна
(эквивалентное разделение, анализ граничных значений, предугадывание ошибок и пр.), позволяет:
- Охватить все возможные сценарии:
Проверить как штатные ситуации (когда всё работает правильно), так и нестандартные (ошибки пользователя,
экстремальные условия).
- Минимизировать количество пропущенных дефектов:
Систематически выявлять ошибки, которые могли бы остаться незамеченными при случайном тестировании.
- Сделать тестирование более структурированным и эффективным:
Упорядочить процесс тестирования, сократить время на создание тестов и повысить их качество.
20

21.

Тест-план
Мастер тест-план (или репозиторий тест-кейсов) - это объединение всех
существующих тест-кейсов/чек-листов упорядоченных в рамках
декомпозиции приложения (каждому сьюту соответствует элемент уровня
декомпозиции) и/или упорядоченное по виду тестирования.
Сессионный тест-план - это выборочное объединение тест-сьютов и/или тесткейсов из мастер тест-палана, которое выполняют проверку
функционала в рамках задачи тестирования. Например, Smoke test-plan
Smoke testing - тестирование, при котором выполняется набор базовых, но очень
важных тестовых сценариев.
21

22.

Мастер тест-план
22

23.

Сессионный тест-план
23

24.

Тест-ран
Тест-ран - это сущность предназначенная для выполнения (прохождения) тесткейсов/чек-листов.
В него может быть включен один или несколько тест-планов, а также любые другие
тест-кейсы необходимые для проверки функционала в рамках сессии тестирования.
Smoke test-run - обычно формируется из приоритетных и типовых пользовательских
сценариев.
Regress test-run - формируется на основе smoke test-run с добавлением проверок по
затронутому в релизе функционалу, новой фиче и смежному функционалу
Run title - название тест-рана, желательно формировать по маске:
<Вид тестирования> <Версия приложения> <Дата> - <Устройство> - <Версия ОС>
Версия приложения, например, v3.36.2
24

25.

Тест-ран
25

26.

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

27.

Артефакты*
Чит-листы
Пример небольших чит-листов
для проверки времени, даты и
временного интервала
27

28.

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

29.

Декомпозиция
Представление декомпозиции
Декомпозиция системы чаще всего представляется в виде иерархического дерева,
вершина которого – сама система, а уровни – выделенные подсистемы.
Признаки декомпозиции
Для разделения одного и того же приложения на подсистемы могут использоваться
разные признаки декомпозиции.
В качестве примера для декомпозиции мы будем рассматривать приложение
“Браузер”.
Следует учесть, что во всех примерах, которые будут приведены
ниже, декомпозиция не полная. Показаны лишь некоторые из подсистем первого и
второго уровней.
29

30.

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

31.

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

32.

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

33.

Декомпозиция
Основные принципы декомпозиции
1.
Каждое разделение образует свой уровень
2.
Все подсистемы одного уровня, являющиеся подсистемами одной и той же
системы, должны разделяться по одному признаку.
3.
Отдельные подсистемы в сумме должны составлять всю систему.
4.
Компромисс между полнотой и простотой.
5.
Проводите критическую оценку декомпозиции для каждого из построенных
уровней и системы в целом.
https://www.software-testing.by/blog/dekompozicia/
33

34.

Декомпозиция
Часто декомпозиция одной и той же системы может осуществляться по нескольким
признакам, порядок их выбора зависит от квалификации и предпочтений
тестировщика.
Декомпозиция – задача очень субъективная. И самое главное, чтобы тестировщик
осознавал свой выбор принципа декомпозиции в каждый момент времени.
Системы нижнего уровня называются элементарными.
Элементарные системы – это системы с такой степенью детализации, которую
будет очевидно, как тестировать человеку,использующему эту схему в процессе
тестирования.
34

35.

Приложения
Дополнительные
данные
35

36.

Приложение
Подробнее о Классах эквивалентности
Эквивалентное разделение подразумевает разбиение тестовых данных на классы по какому-то
признаку. Этот метод имеет смысл только в том случае, если компоненты чем-то похожи и могут
войти в общую группу.
Если мы выбираем в качестве техники тест-дизайна эквивалентное разделение, это означает, что
мы будем тестировать только несколько значений из каждого класса элементов. Помните, что это не
гарантирует отсутствия ошибок в остальных значениях, не охваченных тестами. Мы лишь
предполагаем, что использование нескольких элементов из каждой группы будет достаточно
показательным.
Допустим, есть интернет-магазин, который предлагает разные тарифы на доставку в
зависимости от стоимости корзины. Например:
Стоимость доставки для заказов на сумму менее $100 составляет $15.
Стоимость доставки для заказов на сумму более $100 составляет $5.
При заказе от $300 долларов доставка бесплатна.
У нас есть следующие ценовые категории для работы:
от $1 до $100.
от $100 до $300.
$300 и выше.
36

37.

Приложение
Классы эквивалентности. Пример
При использовании техники эквивалентного разделения мы получаем три набора
данных для тестирования:
От $1 до $100:
допустимые значения: любая цена в диапазоне от 1 до 99,99
недопустимые значения: любая цена ниже 1 или выше 99,99
От $100 до $300:
допустимые значения: любая цена в диапазоне от 100 до 299,99
недопустимые значения: любая цена ниже 100 или выше 299,99
$300 и выше:
допустимые значения: любая цена выше 299,99
недопустимые значения: любая цена ниже 300.
37

38.

Приложение
Подробнее про Граничные значения
Анализ граничных значений в чем-то похож на эквивалентное разделение. Можно даже сказать, что оно
лежит в основе анализа граничных значений. Но есть некоторые отличия.
При анализе граничных значений мы тоже группируем данные по эквивалентным классам, но проверяем не
значения из определенного класса, а граничные значения — те, которые находятся на «границах» классов.
Возьмем предыдущий сценарий с различными тарифами на доставку. У нас те же данные, но другой подход к
их использованию. Предполагая, что ошибки наиболее вероятны на границах диапазонов, мы тестируем
только «граничные» числа:
От $1 до $100:
● допустимые граничные значения: 1,00, 1,01, 99,99
● недопустимые граничные значения: 0,99, 100,00, 100,01
От $100 до $300:
● допустимые граничные значения: 100,00, 100,01, 299,99
● недопустимые граничные значения: 99,99, 300,00
$300 и выше:
● допустимые граничные значения: 300,00, 300,01
● недопустимые граничные значения: 299,99
38

39.

Приложение
Подробнее про Попарное тестирование (pairwise
testing)
Попарное тестирование - техника тест-дизайна, в
которой тестовые сценарии разрабатываются таким
образом, чтобы выполнить все возможные отдельные
комбинации каждой пары входных параметров, что
позволяет нам сэкономить много времени.
Попарное тестирование - лучше всего применимо в
условиях ограниченности ресурсов и при огромном
количестве входных данных.
Предположим, что у нас есть задача протестировать сайт, где входные данные - 2 браузера
хром/фф, возможность проверки с авторизацией и без и проверка в темной и светлой теме.
Если бы мы перебирали все возможные варианты значений для всех столбцов, то получили бы
8 проверок.
39

40.

Приложение
Подробнее про Попарное тестирование (pairwise
testing)
А с помощью техники попарного
тестирования, количество проверок
сокращается до 4. Тут мы проверяем не все
возможные комбинации, а только все
отдельные комбинации для каждой пары
входных параметров.
Можно использовать раличные онлайн-тулзы для составления пар, например:
https://pairwise.teremokgames.com/
https://pairwise.yuuniworks.com/
40

41.

Приложение
Особенности тестирования мобильных приложений
Особенности тестирования мобильных приложений играют ключевую роль при составлении чеклистов и тест-кейсов.
Это связано с тем, что мобильные приложения обладают рядом уникальных характеристик, таких как
разнообразие платформ (iOS, Android), разные размеры экранов, разрешения и возможность работы в
офлайн-режиме. Эти факторы могут значительно влиять на пользовательский опыт и
функциональность приложения.
Пример тест-кейса с учетом специфического сценария:
1. Сценарий: Проверка работы приложения в условиях слабого соединения.
2. Действия:
- Включить режим "Авиарежим".
- Открыть приложение и попытаться выполнить действия, требующие подключения к
интернету (например, загрузка данных).
3. Ожидаемый результат: Приложение должно корректно отображать сообщение о
невозможности соединения и не зависать, а также сохранять данные для последующей
синхронизации, когда соединение восстанавливается.
41

42.

Приложение
Особенности тестирования мобильных приложений
Различные соединения: типы сети (Wi-Fi, EDGE, 3G, 4G, GSM/CDMA), offline
Различные типы устройств: от минимально поддерживаемой версии ОС до актуальной
Различные разрешения экрана, альбомная или портретная ориентация
GPS функциональность
Энергопотребление устройства и чувствительность к зарядке при работе с приложением
Акселерометр. Влияние поворотов устройства
Работа с жестами, мультитапами
Стабильность при входящих/исходящих звонках, получении/отправке SMS/MMS
Установка и восстановление приложений в фоновом режиме
Стабильность приложений в случае нехватки места на устройстве
Стабильность работы в стрессовых ситуациях после сбоев приложения
Синхронизация со сторонними сервисами и приложениями
Работа с Touch ID для iOS или FingerPrint для Android, FaceID
42

43.

Приложение
Ежедневный отчет о тестировании
Ежедневный отчет должен писать каждый Test-инженер.
По умолчанию, отчеты отправляются всем заинтересованным лицам (чаще всего это все члены команды тестирования на проекте, лид отдела тестирования и менеджер
проекта).
В отчете указывается информация, которая будет полезна людям, получающим его:
основные активности по проекту,
возможные риски и проблемы,
ссылки на заведенные, переоткрытые и закрытые задачи/баги.
Ценность отчета о тестировании - получение заинтересованными лицами информации о
работоспособности функционала или приложения в целом. Дать представление о слабых
местах системы.
Отчет о тестировании также может содержать рекомендации по выпуску, улучшению ПО.
43

44.

Приложение
Ежедневный отчет о тестировании
44

45.

Приложение
Полезные ссылки и литература
Пожалуй, лучшая книга о тест-дизайне - Lee Copeland, "A Practitioner's Guide to Software Test
Design"
Статья о тест-дизайне - https://habr.com/ru/post/462553/
Еще - https://quality-lab.ru/blog/roles-and-responsibilities-of-test-designer
Блог обо всем - http://okiseleva.blogspot.com/ и https://testengineer.ru/
Библия QA - https://vladislaveremeev.gitbook.io/qa_bible
Канал с полезными видео на любую тему - https://www.youtube.com/c/ArtsiomRusauQALife
Инструкция по работе с Qase.io для начинающих https://testgrow.ru/article11
[Бонус] Статья о методике туров - http://testbase.ru/bugs
45