Тестирование часто воспринимают как финальную проверку перед релизом: найти баги, составить отчет, нажать готово. На практике QA — это скорее работа с неопределенностью. Проверить всё невозможно: даже у простой формы регистрации будут тысячи комбинаций поведения, а в сложных системах количество сценариев становится бесконечным. Поэтому хороший тестировщик думает не о том, как охватить каждый сценарий, а о том, где система сломается и какие риски команда готова принять перед релизом.
В статье Артём Хюппенен, старший инженер по разработке ПО в YADRO, рассказывает, зачем QA подключается еще до появления кода, какие риски ищет в первую очередь и почему даже идеальный набор проверок не гарантирует идеальное качество продукта.
- почему тестирование не гарантирует идеального качества продукта
- как тестировщики работают с рисками и приоритетами
- как выглядит хороший баг-репорт и зачем он нужен разработчикам
Почему тестирование начинается еще до появления кода
Одна из самых дорогих ошибок — обнаружить проблему после релиза. Чем раньше найден дефект, тем дешевле его исправить. В YADRO процесс разработки СХД выглядит так:
- разработчики, тестировщики и менеджеры обсуждают требования;
- разработчики начинают писать код;
- тестировщики проверяют функциональность;
- продукт выходит в релиз.
Если ошибка обнаружена еще на этапе требований, ее исправление занимает буквально несколько минут обсуждения. Но если проблема всплывает после релиза, последствия могут быть намного серьезнее: срочные hotfix-релизы, потеря времени команды, репутационные риски, проблемы у клиентов и финансовые потери бизнеса.
Поэтому QA-инженеры часто подключаются еще до появления рабочего кода. Они участвуют в обсуждении требований, помогают находить логические противоречия и заранее думают о сценариях использования. В некоторых командах тестировщики даже начинают писать автотесты еще до того, как разработчик закончил реализацию функции.
Что такое QA, QC и Testing
Если упростить, то тестирование отвечает на несколько вопросов одновременно:
- работает ли система так, как задумано;
- не ломаются ли важные сценарии;
- выдержит ли продукт реальные условия использования;
- не создают ли изменения новые риски для пользователей и бизнеса.
Разберем основные термины в тестировании: их часто путают, хотя задачи у них разные.
QC (Quality Control) — контроль качества. Его задача — убедиться, что результат соответствует требованиям и ожиданиям.
QA (Quality Assurance) — обеспечение качества. Оно охватывает весь процесс разработки: работу с требованиями, процессы и коммуникацию между командами, автоматизацию тестирования и подходы к релизам.
Если упростить, эти термины можно объяснить на примере ресторана. QA — это правила и процессы на кухне, которые помогают избежать проблем: санитарные нормы, рецептуры и организация работы. QC — контроль качества готового блюда перед подачей: шеф-повар проверяет, соответствует ли оно стандартам ресторана и ожиданиям гостей. А Testing — это конкретные способы такой проверки: например, попробовать блюдо на вкус или измерить его температуру.
Именно поэтому QA-инженер не просто ищет баги после написания кода. Во многих командах он участвует еще на этапе обсуждения будущей функциональности.
Главная задача тестирования — не выпустить идеальный продукт, а снизить риски
Существует фундаментальный принцип тестирования — проверить всё невозможно. Даже простая форма создания пользователя включает десятки тестовых сценариев: проверку пустых и заполненных полей, разных форматов логинов, спецсимволов, символов разных алфавитов, некорректных значений и попыток SQL-инъекций.
Опытный QA-инженер оценивает несколько факторов одновременно: что вероятнее всего сломается, какие ошибки нанесут наибольший ущерб, какие сценарии критичны для пользователя и какие изменения затрагивают больше всего частей системы. На основе этого он формирует приоритеты тестирования — что проверять в первую очередь, где нужна более глубокая проработка, а где достаточно точечной проверки или базового покрытия.
Приоритизация дефектов напрямую зависит от того, насколько сильно проблема влияет на работоспособность системы. Наивысший приоритет получают ошибки в core-функционале — возможностях, без которых система не может нормально функционировать. Например, если нарушается создание или удаление RAID-массива, то это критический дефект, поскольку основная логика системы становится недоступной.
Средний приоритет обычно присваивается ошибкам, при которых система продолжает работать, но с определенными ограничениями. Например, невозможность изменить название RAID-массива не блокирует основную функциональность, однако ухудшает удобство работы и управление системой.
Низкий приоритет получают дефекты, которые не влияют на функциональность системы. К таким проблемам относятся, например, опечатки, неточности в интерфейсе или другие косметические недочеты.
Пирамида тестирования: как распределяются проверки по уровням системы
Не получится одинаково проверять кнопку в интерфейсе, работу серверной логики и взаимодействие железа с системой. Поэтому в разработке используют пирамиду тестирования — модель, которая показывает, какие проверки нужны продукту и на каком этапе они выполняются.
Обычно всё начинается с unit-тестов — самых маленьких и быстрых проверок, которые пишут сами разработчики. Они проверяют отдельные функции: что подали на вход и что получили на выходе.
Например, в системе хранения данных есть функция, которая должна корректно обработать ситуацию, когда один из дисков RAID-массива внезапно перестал отвечать во время записи данных.
Unit-тест здесь проверяет конкретную логику: получает ли система сигнал об ошибке, переводится ли диск в нужный статус, запускается ли процесс восстановления. То есть тестируется не вся система целиком, а отдельный кусок кода.
Следующий уровень — интеграционные тесты. Здесь уже проверяют, как между собой взаимодействуют разные компоненты системы.
На том же примере тестировщик смотрит шире: что произойдет после отказа диска не только внутри одного модуля, а во всей цепочке. Корректно ли система передаст событие дальше? Обновится ли информация в мониторинге? Не потеряется ли связь между сервисами? Продолжится ли запись данных на оставшиеся диски?
А на уровне end-to-end тестирования проверяют уже полноценный пользовательский сценарий — максимально близкий к реальной эксплуатации.
Например, тестировщик создает RAID-массив через web-интерфейс, запускает запись данных и прямо во время нагрузки извлекает один из дисков. После этого он проверяет уже поведение всей системы целиком: не завис ли интерфейс, пришло ли уведомление администратору, сохранился ли доступ к данным, началось ли восстановление массива после возврата диска.
На практике это обычно выглядит как конвейер:
- разработчики прогоняют unit-тесты;
- QA запускает smoke-тесты, чтобы быстро проверить базовую работоспособность;
- затем идут sanity- и интеграционные проверки;
- а перед релизом — полноценное регрессионное тестирование.
Инструменты тестирования: тест-кейс, чек-лист и тест-план
В тестировании есть несколько базовых инструментов, с которыми тестировщики работает практически каждый день. Сначала QA-инженер формирует тест-план — он определяет стратегию тестирования.
Тест-план
В документе описывают тестирование не на уровне отдельных проверок, а на уровне всей стратегии и организации процесса. Например, для тестирования функционала RAID общий тест-план может включать:
Тест-кейс
Подробный сценарий проверки. Обычно содержит: шаги, входные данные, ожидаемый результат. Например:
- Открыть форму создания RAID-массива.
- Ввести имя.
- Выбрать уровень RAID, выбрать диски, на которых будет создан RAID.
- Нажать Create.
- Проверить, что массив создался без ошибок.
Чек-листы используют уже там, где нужна повторяющаяся проверка.
Чек-лист
Короткий список того, что нужно проверить. Без детальных шагов — скорее памятка для QA-инженера. Например:
- создание RAID;
- удаление RAID;
- изменение параметров RAID;
- инициализация RAID;
- выгрузка и загрузка RAID;
- производительность RAID;
- проверка логирования;
- проверка прав доступа.
Парадокс пестицида возникает не потому, что тесты сами по себе «плохие», а потому, что они остаются статичными в постоянно меняющейся среде. Программное обеспечение развивается: добавляется новый функционал, изменяется существующая логика, перерабатываются отдельные компоненты. При этом тесты остаются такими же, какими были созданы месяцы или даже годы назад.
Как выглядит хороший баг-репорт
Найти проблему — только половина работы. Важно помочь разработчику быстро ее воспроизвести и исправить. Для этого тестировщик оформляет баг-репорт — документ с описанием ошибки, условий ее появления и всей информации, которая поможет быстрее найти причину проблемы. Хороший баг-репорт должен содержать:
- шаги воспроизведения,
- ожидаемый результат,
- фактический результат,
- информацию об окружении,
- логи, скриншоты или видео,
- дополнительные детали, которые ускорят поиск причины ошибки.
Чем лучше QA понимает архитектуру продукта, тем точнее он описывает контекст проблемы — и тем проще команде разработки воспроизвести и локализовать баг. Хорошему тестировщику приходится постепенно разбираться в устройстве всей системы, понимать, как взаимодействуют разные компоненты и постоянно держать контакт с разработчиками.
Причем в каждой сфере разработки это погружение будет своим. Где-то достаточно понимать логику web-приложения, а где-то — разбираться в сетях, железе, дисковых подсистемах или особенностях инфраструктуры. Поэтому важно не бояться задавать вопросы, уточнять детали и постепенно расширять технический кругозор.
Где тестирование может быть бесполезным
Интуитивно кажется, что чем больше тестирования, тем лучше продукт. Но на практике даже сильная QA-команда не спасет проект, если тестирование превращается в формальную проверку или существует отдельно от разработки. В таких случаях большое количество проверок не повышает стабильность системы, а только создает иллюзию качества.
Ниже — ситуации, когда тестирование может быть малоэффективным.
Формальное тестирование «для галочки»
Это ситуация, когда главная цель команды не найти риски и проблемы, а отметить в отчете, что проверку провели. Формально чек-листы пройдены, тесты зеленые, релиз выпущен, но реальное качество продукта от этого не обязательно становится лучше.
Проблема в том, что тестирование — это всегда исследование системы. Если инженер перестает думать о поведении продукта и механически выполняет набор шагов, часть ошибок он неизбежно пропустит.
Даже хорошее тестирование не спасает плохие процессы
Качество тестирования сильно зависит от того, насколько хорошо разработчики, тестировщики, аналитики и менеджеры понимают систему и обмениваются информацией между собой. QA участвует не только в проверках, но и в обсуждении требований, оценке рисков и анализе архитектуры. При этом даже сильная команда тестирования не может компенсировать слабые процессы в команде. Например, если:
- требования постоянно меняются;
- команда не фиксирует договоренности;
- разработка и тестирование работают разрозненно;
- релизы собираются в последний момент;
- у команды нет времени на полноценную проверку.
Хорошее тестирование — это не количество проверок
Количество тест-кейсов или автоматических тестов само по себе ничего не гарантирует. Можно покрыть систему сотнями проверок и всё равно пропустить критическую ошибку, если команда:
- не понимает реальные пользовательские сценарии;
- не анализирует риски;
- не думает о поведении системы вне «идеального» пути.
Полезно начинать не со списка, что надо протестировать, а с понимания, как пользователи будут работать с продуктом и где возможны отклонения от идеального сценария. Поэтому нужно смотреть на тестирование не как на механическое прохождение пунктов, а как на попытку смоделировать реальную работу системы:
- Как пользователь будет вести себя в обычной задаче.
- Что произойдет, если он ошибется, прервет действие или нарушит ожидаемый порядок шагов.
- От каких внешних условий зависит система: сети, оборудования, нагрузки, других сервисов или состояния данных.
Один и тот же сценарий глазами разработчика и тестировщика
Может показаться, что разработчик и тестировщик делают примерно одно и то же — проверяют, работает ли функция. На практике они смотрят на систему по-разному. Разработчик обычно мыслит через позитивный сценарий: функциональность должна выполнять бизнес-требования так, как задумано. Тестировщик почти всегда думает через риски и нестандартные ситуации.
Например, есть система хранения данных, в которой пользователь создает RAID-массив и записывает туда данные.
Разработчик проверит:
- создается ли RAID;
- начинается ли запись данных;
- появляются ли ошибки при штатной работе.
Если все соответствует требованиям — задача считается выполненной. Тестировщик же постоянно задает вопрос: «А что если?..» Вариантов продолжения может быть множество:
- выдернуть диск во время записи данных;
- отправить пустое значение;
- оборвать соединение;
- вернуть некорректный ответ;
- нажать кнопку десять раз подряд.
Именно поэтому тестирование почти всегда занимает больше времени, чем первичная проверка со стороны разработки. А если хочется глубже разобраться в том, как устроено тестирование на практике, можно продолжить изучение темы в других материалах «Истового инженера» или попробовать себя в профессии на практическом курсе по ручному тестированию.
