Перейти к основному содержимому

Ручной QA — учебный «Конвертер файлов»

НЕ ОБЯЗАТЕЛЬНОДЛЯ НОВИЧКОВ

Учебное консольное приложение «Конвертер файлов»: администратор указывает каталоги и журнал, программа перекодирует текстовые файлы в UTF-8. На этом объекте отрабатывают требования, чек-листы, тест-кейсы, границы, доменные матрицы и pairwise. Здесь — бумажная (или табличная) практика: реальный converter.php не обязателен.

Зачем этот кейс​

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

Ориентир по времени: 3–6 часов суммарно, можно разбить на два занятия.

Условная спецификация (для работы)​

Ниже — сжатая выжимка учебных требований. В заданиях можно ссылаться на идентификаторы ПТ, БП, АК.

Назначение​

Инструмент для автоматического приведения кодировок текстовых документов в локальном хранилище к UTF-8. Пользователи документов приложение не открывают — им пользуется администратор сервера.

Запуск и параметры​

Консольная утилита (в учебнике — PHP), кроссплатформенная (как минимум Windows и Linux):

php converter.php SOURCE_DIR DESTINATION_DIR [LOG_FILE_NAME]
ПараметрНазначение
SOURCE_DIRКаталог с исходными файлами
DESTINATION_DIRКаталог для результата
LOG_FILE_NAMEПуть к журналу (опционально; иначе журнал дописывается по умолчанию)

Бизнес-правила​

  • БП-1.1: SOURCE_DIR и DESTINATION_DIR не совпадают.
  • БП-1.2: DESTINATION_DIR не может быть подкаталогом SOURCE_DIR.

Обработка файлов​

ФорматКодировки входа
TXT, HTML, MDCP1251, UTF-8, CP866, KOI8R
  • Целевая кодировка: UTF-8.
  • Размер входного файла: до 50 МБ включительно (АК-2.1).
  • Производительность (ориентир): 5 МБ/с (АК-1.1).

Поведение при ошибках (из учебных сценариев)​

  • Запуск без параметров или с неверными путями — сообщение в консоль, подсказка по использованию, указание проблемного параметра.
  • Недоступный входной файл (нет прав, файл занят, только чтение) — сообщение в консоль и журнал, файл пропускается, обработка остальных продолжается.
  • Остановка: Ctrl+C.
Намеренно «сырые» места в ТЗ

В учебной спецификации часть требований намеренно сформулирована неидеально (например, неясность «обработать» не-текстовый файл). В шаге 1 ищите противоречия, неоднозначности и пропуски — как в свойствах качественных требований.

Шаг 1 — Ревью требований (статика)​

Цель: проверить ТЗ до кода.

  1. Пройдитесь по таблице выше и выпишите 5–10 вопросов заказчику (формат, граница 50 МБ, поведение при пустом каталоге, смешанные кодировки в одном файле, одновременный запуск двух копий и т.д.).
  2. Отметьте нарушения свойств качества: неполнота, неоднозначность, неверный уровень детализации, требования «к пользователю», а не к приложению.
  3. Предложите одну переформулировку для АК-2.2 (не-текстовый файл), чтобы требование стало проверяемым.

Результат: документ на 0,5–1 стр. (вопросы + таблица «проблема → свойство → как исправить»).

Теория: Статическое тестирование требований, Аналитика — свойства требований.

Шаг 2 — Дымовой чек-лист​

Цель: минимальный набор, без которого продукт «не существует».

Составьте чек-лист из не более 15 пунктов, сгруппированных так:

  1. Конфигурирование и запуск (хотя бы один успешный запуск с валидными путями).
  2. Обработка файлов (матрица формат × кодировка — хотя бы по одной ячейке «+» на формат).
  3. Остановка (Ctrl+C).

Не включайте пока экзотику (файлы 4+ ГБ, UNC, две копии приложения) — это уровень расширенного тестирования.

Результат: чек-лист в Markdown или таблице.

Шаг 3 — Три тест-кейса на SOURCE_DIR​

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

Оформите три кейса по шаблону из Документации тестировщика:

#ТипИдея
1ПозитивныйСуществующий каталог, Windows-стиль пути, кириллица и пробелы в имени
2НегативныйНесуществующий или недоступный SOURCE_DIR
3НегативныйDESTINATION_DIR внутри SOURCE_DIR (БП-1.2)

В каждом кейсе обязательны: предусловия, шаги, ожидаемый результат, данные (конкретные пути-примеры).

Вопрос для размышления (задание 2.7.a из книги): почему в «раннем» чек-листе книги могли не включить БП-1.2, хотя оно есть в требованиях? Запишите ответ в 3–5 предложениях (подсказка: уровни тестирования, риск, детализация чек-листа vs кейса).

Шаг 4 — Граница размера файла​

Цель: классы эквивалентности и граничные значения.

Для АК-2.1 (максимум 50 МБ):

  1. Назовите классы эквивалентности по размеру.
  2. Выберите граничные значения (включая 0 байт и 50 МБ + 1 байт).
  3. Составьте два тест-кейса с ожидаемым поведением (успех / отказ или пропуск — зафиксируйте своё ожидание явно, если в ТЗ пробел).

Теория: Тест-дизайн — границы.

Шаг 5 — Мини pairwise​

Цель: сократить число прогонов при нескольких параметрах.

Возьмите три параметра:

ПараметрЗначения
ОСWindows, Linux
Тип пути SOURCE_DIRЛокальный, сетевой (UNC / smb)
Имя каталогаОбычное, зарезервированное системой (CON, NUL на Windows)
  1. Полный перебор: сколько комбинаций?
  2. Постройте набор из 4–6 строк, где каждая пара значений разных параметров встречается хотя бы один раз.
  3. Укажите одну комбинацию, которую pairwise может не покрыть (тройка взаимодействий) — и нужно ли её добавить вручную.

Шаг 6 — Баг-репорт по учебному дефекту​

Цель: качество отчёта о дефекте.

Выберите одну найденную на шагах 1–5 проблему (противоречие в ТЗ, нереализуемое ожидание при «битом» HTML, падение при совпадении каталогов — если тестируете живую сборку).

Оформите баг-репорт с полями:

  • заголовок (суть в одной строке);
  • окружение (ОС, версия PHP при наличии);
  • шаги воспроизведения;
  • фактический и ожидаемый результат;
  • вложения (скрин консоли, фрагмент лога).

Сверьте с разделом «типичные ошибки» в Документации тестировщика.

Критерии «сделано»​

АртефактГотово, если
Ревью ТЗЕсть вопросы заказчику и правка хотя бы одного требования
Дымовой чек-лист≤ 15 пунктов, покрыты запуск, конвертация, остановка
Тест-кейсы3 на SOURCE_DIR + 2 на границу размера, у всех есть ожидаемый результат
PairwiseТаблица 4–6 строк + комментарий про ограничение метода
Баг-репортВоспроизводим посторонним по шагам

Куда читать в энциклопедии​

ТемаМатериал
Термины, мифы, ревью ТЗОсновы тестирования
Чек-листы, кейсы, багиДокументация тестировщика
EQ, границы, pairwise, root causeТест-дизайн
Маршрут раздела QAТестирование — о разделе
Самопроверка999 — вопросы
TDD (другая лаборатория)Кейс 7 — TDD

Дополнительно — таблица решений (скидка в корзине)​

Цель: закрепить таблицы решений на типовом сценарии интернет-магазина.

Условия: пользователь авторизован, есть активная подписка, сумма корзины > 5000 ₽. Действие: какая скидка применяется.

  1. Заполните таблицу «условие → да/нет → скидка» минимум для 4 правил (не обязательно все 8 комбинаций).
  2. Выберите одно правило, где в ТЗ двусмысленность («скидка 10 % или 15 % при подписке») — сформулируйте вопрос аналитику.
  3. Превратите два столбца таблицы в черновики тест-кейсов.

Теория и развёрнутый пример — в 127.

Связанные темы

См. также

Другие статьи этого же раздела в боковом меню (как на странице "О разделе").

Последнее обновление
Освоение главы0%