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

1. Эквивалентное разбиение Разбиваем диапазон на классы и проверяем числа по одному представителю из каждой группы Пример: поле Возраст от 18 до 65 лет (включительно) Разобьем на классы эквивалентности: - < 18 - ошибка тк Слишком молод - 18-65 - ок - 66 - ошибка тк Слишком стар Нам не нужно проверять 18, 19, 20, …, 64, 65 - это все один класс, мы проверим по одному числу из каждой группы - 17, 30, 66

2. Граничные значения Тут мы проверяем границы тех классов что мы выделили ранее Пример: продолжим с возрастом Выделим границы: 17, 18, 19 и 64, 65, 66 Проверяем: - 17 и 64(ниже границы) - 18 и 65(граница) - 19 и 66(выше выше) Часто именно 18 и 65 или 17 и 66 ломаются из-за ошибок ≥ и > или n+1 //+ Эту технику разделяют на into value и full value, в зависимости сколько границ мы хотим проверить (into - проверяем ниже границы и границу, full - добавляем еще и выше границы и рандомное среднее число которое не является границей)

3. Попарное тестирование Когда много параметров (например множество фильтров) проверяем не все комбинации, а все возможные уникальные пары Пример: поиск вакансий с 4 фильтрами: - Город: Москва/СПб/Удаленно - Зарплата: от 50к/от 100к/не указано - Опыт: без опыта/1-3 года/3+ года - График: полный день/сменный/гибкий Если учесть все комбинации 3×3×3×3 получим 81 тест Если попарно то всего 9 тестов покрывают все пары значений (тут можно сгенерировать https://pairwise.teremokgames.com/)

4. Диаграмма пользовательских ролей Описываем какой функционал нашего приложения доступен каждой группе (роли) пользователей Пример: Маркетплейс - Роль: Покупатель | Доступно: Листать каталог, Добавлять в корзину, Оплачивать - Роль: Продавец | Доступно: Добавлять товар, Изменять/Удалять товар - Роль: Админ | Доступно: Банить юзеров, Менять возможности продавцов

5. Причина-следствие Определяем комбинации входных условий (причин), которые приводят к определенным результатам системы (следствиям). Если условий и действий много, мы формируем Таблицу принятия решений: Пример: форма логина - Условия: логин заполнен? логин заполнен корректно? почта указана? почта указана корректно? пароль заполнен? пароль заполнен корректно? - Действия: успешный ввод, Укажите оба поля, укажите пароль, укажите почту или логин, неверно указана почта или пароль Далее выстраиваем таблицу где каждый столбец будет отдельным тест-кейсом (см в прикрепленных картинках результат)

6. Исследовательское тестирование Тут ты просто начинаешь пользоваться приложением как обычный пользователь и ищешь, где может сломаться. Можно добавить параллельно monkey-testing на эмуляторах (через встроенные инстурменты типа Monkey в Android SDK (adb shell monkey -p com.example.app -v 500 или фреймворки типа SwiftMonkey) 7. Предугадывание ошибок Здесь мы стараемся подумать где разраб мог налажать и проверяем именно эти места Примеры: - Поле не принимает спецсимволы (@#$%) - Отрицательное количество товаров - Дата рождения в будущем - Пробелы в начале/конце логина - Очень длинный/короткий пароль - Дважды нажать кнопку “Оплатить” Тут играет роль интуиция и опыт

Удачи! :)