Раздел 12 — Итоговый проект

Всё, что было в курсе, — на программе, которую вы знаете лучше всех и поэтому хуже всех видите

Прогресс курса Раздел 12 из 12

Что вы делаете в этом разделе

Выбираете проект и описываете, что в нём тестировать
Восстанавливаете требования, если их никто не записал
Проходите весь цикл: тест-план, чек-лист, тест-кейсы, прогон, баг-репорты, тест-отчёт
Защищаете результат: что проверено, что найдено, можно ли выпускать

6 академических часов практики. Теории в разделе нет: всё нужное — в разделах 03–11. Шаблоны — тест-план, чек-лист, тест-кейсы, баг-репорт, тест-отчёт.

Какой проект тестировать

Лучше всего — свой: сайт, веб-приложение, бот, курсовая или дипломная работа, проект из другого курса nevabit. Подойдёт проект одногруппника, если он согласен отвечать на вопросы о требованиях и принимать баг-репорты. Если своего проекта нет — «Задачник» 1.1.

Проект подходит, если в нём есть:

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

Если проект — одна статичная страница, для итоговой работы его мало: техникам из разделов 05–06 не на чем работать.

Тестируйте свою копию — локально или на своём стенде. Рабочий сайт с настоящими пользователями, чужие сервисы и проверки доступа к чужим данным на них — без письменного разрешения владельца нельзя: это может быть расценено как неправомерный доступ к компьютерной информации (ст. 272 УК РФ). Персональные данные в тестовой базе — только придуманные (раздел 10).

Если требований нет

У «Задачника» были требования Т1–Т9. У студенческого проекта их обычно нет: автор держит всё в голове. Тестировать «на глаз» нельзя — без ожидаемого результата нет дефекта, есть только мнение. Требования восстанавливают:

Карта функций. Пройдите все экраны и запишите, что программа умеет: список функций, у каждой — поля, кнопки, сообщения.
Источники. Задание на курсовую, описание в README, документация API (если есть), подписи и подсказки в интерфейсе, сообщения об ошибках, ограничения в базе данных (длина столбца, NOT NULL, уникальность).
Требования-ориентиры. Запишите правила в том же виде, что Т1–Т9: номер, одна проверяемая фраза, конкретные числа. Где источники молчат, предложите разумное правило и пометьте «предложено».
Согласование. Покажите список автору проекта (или себе в роли заказчика — тогда запишите решения письменно). Вопросы к требованиям — как в разделе 03.

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

Образец: «Домашняя библиотека»

Вымышленный студенческий проект: веб-приложение для учёта своих книг, Python и SQLite, есть JSON API. README: «Добавляйте книги, отмечайте прочитанные, ищите по названию и автору». Других документов нет. Ниже — фрагменты итоговой работы по нему. Ваша задача — сделать то же для своего проекта, а не повторить образец.

Карта функций (фрагмент):

Функция	Поля и действия	Источник правил
Добавить книгу	Название, автор, год издания, статус «Хочу прочитать / Читаю / Прочитана»	Подсказки формы, столбцы базы
Поиск	Строка поиска по названию и автору	README
Статусы	Кнопки «Начать», «Прочитана»	Интерфейс
API	`GET/POST /api/books`, `PATCH/DELETE /api/books/{id}`	Код сервера, описания нет

Требования-ориентиры (фрагмент):

Б1.1. Название — от 1 до 200 символов; пробелы по краям обрезаются. Источник: столбец VARCHAR(200) NOT NULL; обрезка — предложено.
Б1.2. Год издания — целое число от 1450 до текущего года, поле необязательное. Предложено, согласовано с автором.
Б2.1. Поиск находит книгу по части названия или автора без учёта регистра. Источник: README; регистр — предложено.
Б3.1. Переходы статуса: «Хочу прочитать» → «Читаю» → «Прочитана»; из «Прочитана» — «Читаю» (перечитать). Согласовано с автором.

Тест-кейс по технике граничных значений для Б1.2:

Поле	Значение
ID, название	TC-BOOK-06. Год издания: нижняя граница 1450 принимается, 1449 — нет
Требование, техника, приоритет	Б1.2; граничные значения; средний
Предусловия	Пользователь вошёл; база после сброса
Шаги	1. «Добавить книгу»: название «Тест год 1449», год 1449, «Сохранить». 2. То же с названием «Тест год 1450» и годом 1450.
Ожидаемый результат	1. Сообщение «Год издания — от 1450 до …», книга не добавлена. 2. Книга добавлена, в списке год 1450.

Баг-репорты (заголовки — по правилу «что — где — при каком условии»):

«Книга с годом 3000 сохраняется: нет проверки верхней границы года» — средняя;
«Поиск не находит „Мастер“ по запросу „мастер“: поиск учитывает регистр кириллицы» — средняя;
«API: DELETE /api/books/{id} удаляет книгу другого пользователя» — критическая;
«Кнопка „Сохранить“ уходит за край экрана на ширине 360 px» — серьёзная.

Итог тест-отчёта: «Не выпускать: через API любой пользователь может удалить чужие книги. После исправления — выпускать, остальные дефекты на удобство».

Порядок работы на трёх парах

Пара	Что делаете	Разделы
1	Карта функций, требования-ориентиры, вопросы автору; тест-план; чек-лист	03, 04, 11
2	Тест-кейсы техниками тест-дизайна; прогон в браузере, через API, по базе; баг-репорты	05–10
3	Повторная проверка, если автор успел исправить; тест-отчёт; защита	07, 11

Между парами работа продолжается дома. Если тестируете проект одногруппника — отдавайте баг-репорты сразу, не копите к концу: на третьей паре он успеет исправить, а вы — перепроверить.

Свой проект глазами тестировщика

Автор знает, как программой «правильно» пользоваться, и бессознательно обходит её слабые места. Несколько приёмов против этого:

Сначала требования, потом проверки. Ожидаемый результат берите из требований-ориентиров, а не из того, как программа ведёт себя сейчас. Иначе любой дефект станет «так задумано».
Не открывайте код во время прогона. Код подсказывает, где всё в порядке. Чёрный ящик — пока не найден дефект; код и журнал — потом, для баг-репорта.
Негативные проверки — не меньше половины. Автор почти всегда проверял только позитивные.
Чужие глаза. Дайте одногруппнику 15 минут исследовательского прохода по вашему проекту и запишите, что он нашёл.
Дефект в своём коде — тоже баг-репорт. Исправить на ходу хочется, но тогда в отчёте не будет ни дефекта, ни проверки исправления.

Типичные ошибки итоговых работ

Ошибка	Как должно быть
Чек-лист из пунктов «Проверить форму», «Проверить поиск»	Одна проверка — одно действие и один ожидаемый результат: «Поиск по части фамилии автора находит книгу»
Все тест-кейсы позитивные	Классы и границы, таблица решений, переходы состояний — у каждого тест-кейса указана техника
Ожидаемый результат «работает корректно»	Конкретно: текст сообщения, число в списке, состояние в базе
Баг-репорт «не работает поиск»	Шаги с данными, факт и ожидание, требование, окружение, серьёзность
Тест-отчёт — пересказ того, что делали	Рекомендация в начале, числа прогона, открытые дефекты, что не проверено и чем это грозит
Статусы прогона расходятся с трекером	У каждого «не прошла» — номер баг-репорта, числа отчёта сходятся с таблицей

Ключевые выводы курса

Запомните главное

Без ожидаемого результата нет дефекта — сначала требования, хотя бы восстановленные
Проверки придумывают техниками тест-дизайна, а не по вдохновению
Интерфейс — только одна сторона: API, база и журнал показывают то, что экран скрывает
Баг-репорт воспроизводится без автора; тест-отчёт ведёт к решению о выпуске
Тестируют свою копию; чужие системы — только с разрешения владельца
Дальше — курс QA: автоматизация тестирования: те же проверки, но выполняет их программа

Практические задания — на учебном портале. Задания, критерии оценивания, сдача работ и оценки преподавателя — в курсе на portal.nevabit.ru. Учётную запись выдаёт преподаватель.

Раздел 11: Тестовый процесс Все разделы Все курсы