Что именно ищет тестировщик и почему «всё проверить» невозможно
В разговоре всё называют «багом», но в работе различают три вещи — у каждой своя причина и свой способ найти.
| Термин | Что это | Пример: скидка в интернет-магазине |
|---|---|---|
| Ошибка (error) | Действие человека: неверно понял, опечатался, забыл случай | Аналитик написал «скидка 10% от 5000 ₽», программист понял как «больше 5000» |
| Дефект (defect, bug) | Результат ошибки в коде, требованиях или документации | В коде условие sum > 5000 вместо sum >= 5000 |
| Отказ (failure) | Видимое поведение, которое расходится с ожидаемым | Покупатель с корзиной ровно на 5000 ₽ не получает скидку и пишет в поддержку |
Дефект может годами не проявляться отказом: если никто не набирает корзину ровно на 5000 ₽, программа «работает». Тестировщик не ждёт случайного покупателя, а сам создаёт условия, при которых дефект превращается в отказ. Поэтому тестирование — это поиск таких условий, а не «потыкать и посмотреть».
Качество — степень, в которой программа соответствует требованиям и ожиданиям пользователей. «Программа плохая» — не описание качества; «список задач открывается 8 секунд при 50 задачах» — описание. Чтобы говорить конкретно, используют характеристики из стандарта ГОСТ Р ИСО/МЭК 25010 (международный ISO/IEC 25010).
| Характеристика | Вопрос тестировщика |
|---|---|
| Функциональная пригодность | Делает ли программа то, что требуется, и правильно ли? |
| Производительность | Сколько времени и ресурсов уходит на операцию? |
| Совместимость | Работает ли в нужных браузерах и рядом с другими программами? |
| Удобство использования | Понятно ли без инструкции, есть ли подписи и подсказки, доступно ли людям с ограничениями зрения? |
| Надёжность | Что происходит при сбое, теряются ли данные? |
| Защищённость | Видит ли пользователь только своё, хранятся ли пароли безопасно? |
| Сопровождаемость | Легко ли исправить и изменить код? |
| Переносимость | Запускается ли на другой ОС, легко ли установить? |
Ручное тестирование в этом курсе в основном проверяет первые шесть. Сопровождаемость и переносимость оценивают разработчики и администраторы.
Тестирование даёт команде сведения о качестве: какие дефекты есть, насколько они серьёзны, можно ли выпускать версию. Решение «выпускать или нет» принимает не тестировщик, а руководитель продукта, — но на основании того, что нашёл тестировщик.
Цена исправления растёт с каждым этапом. Проследим один дефект — неоднозначное требование «скидка от 5000 ₽»:
Поэтому тестирование начинается не с готовой программы, а с требований — этому посвящён раздел 03.
Принципы собраны международной программой ISTQB (в России её экзамены принимает RSTQB). Это не правила оформления, а наблюдения, которые помогают принимать решения.
Три понятия вложены друг в друга. Вакансия «QA-инженер» на практике часто означает тестировщика, но разница пригодится, когда речь пойдёт о процессе (раздел 11).
| Понятие | На что направлено | Пример |
|---|---|---|
| Обеспечение качества (QA, quality assurance) | Процесс: чтобы дефекты не появлялись | Правило «каждое изменение кода смотрит второй программист», шаблон требований с критериями приёмки |
| Контроль качества (QC, quality control) | Продукт: соответствует ли он требованиям | Решение «версию 1.1 выпускаем: критических дефектов нет» |
| Тестирование (testing) | Конкретные проверки | Прогон 40 тест-кейсов, 5 баг-репортов |
Жизненный цикл программы — требования, проектирование, разработка, тестирование, выпуск, сопровождение. В каскадной модели этапы идут друг за другом, и тестирование стоит в конце. В гибких подходах (Scrum, Kanban) работа идёт короткими итерациями по 1–4 недели, и тестирование есть в каждой: задача не считается сделанной, пока не проверена.
| Этап | Что делает тестировщик |
|---|---|
| Требования | Читает, задаёт вопросы, ищет противоречия (раздел 03) |
| Проектирование и разработка | Пишет чек-листы и тест-кейсы, готовит тестовые данные (разделы 04–06) |
| Тестирование | Проверяет интерфейс, API, данные; оформляет дефекты (разделы 07–10) |
| Перед выпуском | Регресс, тест-отчёт, рекомендация «выпускать или нет» (раздел 11) |
| Сопровождение | Воспроизводит дефекты из обращений пользователей |
Рядом с тестировщиком работают аналитик (пишет требования), разработчик (пишет и исправляет код, пишет модульные тесты), руководитель продукта (решает, что и когда выпускать). Хороший баг-репорт пишется так, чтобы каждый из них понял его без устных пояснений.
Исследовательское тестирование — изучение программы без заранее написанных шагов: тестировщик одновременно узнаёт программу, придумывает проверки и выполняет их. Оно хорошо подходит для первого знакомства и находит дефекты, о которых никто не подумал. Чтобы проход не превратился в хаотичные щелчки, ему задают рамки:
Наблюдение — не обязательно дефект. Это всё, что удивило или вызвало вопрос. Запись должна позволять повторить: что сделали, на каких данных, что ожидали, что получили. Пример записи о вымышленном интернет-магазине:
| № | Что сделал | Ожидал | Получил | Вопрос или дефект? |
|---|---|---|---|---|
| 1 | Положил в корзину товары на 5000 ₽ ровно | Скидку 10% («скидка от 5000 ₽») | Скидки нет, итог 5000 ₽ | Дефект или «от» значит «больше»? — уточнить требование |
| 2 | Ввёл в поле количества «-1» | Сообщение об ошибке | Количество стало 1 без сообщения | Вопрос: так задумано? |
| 3 | Обновил страницу корзины | Товары на месте | Товары на месте | — (записано, что проверено) |
Строка 3 тоже нужна: по ней видно, что проверено и не дало отказа. Такие записи потом станут чек-листом (раздел 04).
py tasker.py --reset (в Linux — python3 tasker.py --reset): тогда ваши наблюдения можно сравнить с наблюдениями одногруппников — у всех одинаковые исходные данные.