Перевод статьи «If It’s Not Written Down, Did You Really Test It?».
Я видела, как в суете agile-разработки многие команды пренебрегают некоторыми «официальными практиками QA». У них нет планов тестирования, нет выполнения тестов. Порой они даже не прописывают тест-кейсы, а просто проводят тестирование на релизной неделе.
Легко убедить себя в том, что это рационально, эффективно или «зрело», поскольку мы привыкли доверять своим знаниям. Но на самом деле мы как бы берем качество в долг у будущего, и однажды этот долг придется вернуть.
Давайте поговорим о том, что происходит, когда команды не работают в системах управления тестированием (Jira Xray, TestRail, Zephyr и т.д.), и как избежать возникающего при этом хаоса.
Тихий хаос в QA без инструментов
Если вы не пишете тест-кейсы и не пользуетесь планами тестирования, то по-началу чувствуете себя как-то свободнее. Меньше непроизводительных издержек. Меньше разного «сопровождения». Все просто тестируют: очень быстро и, в основном, руками. Но вот в чем подвох: то чувство легкости, которое вы ощущаете сегодня, выльется в уязвимость в будущем. Подумайте сами:
- Сможете ли вы перечислить все, что протестировали в последнем релизе?
- Показать стейкхолдерам, какой функционал проверили, а какой – нет?
- Если на проде заметят критическую ошибку, сможете ли точно определить, как она туда просочилась?
- Предположим, ваш самый опытный QA уходит. Уйдет ли вместе с ним большая часть ваших знаний о тестировании?
Когда мы не записываем, что тестируем, и не следим, как это делаем, то всецело полагаемся только на коллективные знания. Все хорошо до тех пор, пока не сломается. Но если что-то идет не так, то первым трещит по швам именно доверие. Не только в QA, но и внутри команды.
Как эта проблема проявляется в реальном мире
Вот, что я заметила в разных командах:
1. Ударное тестирование в последнюю минуту
Нет никакой структуры, поэтому QA проверяют только после «готовности» функционала. И внезапно тестирование становится похожим на беготню по кругу. Регрессионное тестирование проводят в спешке; тестовое покрытие лишь предполагается, но не измеряется.
2. Неуверенность с собственных силах
Менеджеры проектов и стейкхолдеры спрашивают: «Все ли готово?», а QA отвечает расплывчатым: «Вроде как, да». Но конкретика отсутствует. Ни отчетов, ни итогов тестирования, ни регистраций. Только интуитивное чутье.
3. Пропущенные баги и эффект дежавю
Вы исправляете баг на десятом спринте, а на двенадцатом он возвращается снова. Почему? Потому что никто не задокументировал регрессионный тест для предотвращения этого самого бага. У вас как будто день сурка с багами на проде.
4. Проблемы и сложности с адаптацией новых сотрудников
У новых QA и разработчиков нет структурированной базы о том, что тестируется и как. Они перенимают опыт более старших коллег, либо пытаются догадаться самостоятельно. Затратно по времени и весьма рисково.
Что можно сделать (без лишней бюрократии)
Давайте проясним: чтобы стать профессионалом в QA, вам не нужна стратегия тестирования на 400 страниц или тысячи тест-кейсов. А вот определенная структура – да, нужна. Иначе QA станет невидимкой и, в конечном итоге, окажется ненадежным. Вот, как исправить положение, не превращаясь в перегруженный процессами архаизм.
Шаг 1. Начните с целенаправленных тест-кейсов
Не нужно записывать каждый клик или валидацию поля. Зафиксируйте только критически важные пути:
- Какие бизнес-процессы должны работать всегда и без сбоев?
- Какие сценарии очень сложные, сопряжены с высоким риском или часто забываются?
- Какие есть пограничные случаи?
Начните с пунктов выше. Простое название, шаги и ожидаемый результат – этого вполне хватит. Чтобы упорядочить тест-кейсы и связать из пользовательскими stories или функционалом, пригодятся инструменты управления тестированием (Jira Xray и т.д.).
Почему это важно: таким образом команда будет думать не только о скорости, но и о покрытии. Плюс у вас в «памяти» всегда будет храниться все самое важное.
Шаг 2. Отслеживайте то, что тестируется
План тестирования не обязательно делать многостраничным. Можно ограничиться довольно простыми правилами: «Чтобы зарелизить этот функционал, нужно пройти вот эти 15 тестов».
Когда вы создаете план тестирования и отмечаете выполнение тестов, то получаете следующее:
- Четкие записи о том, что тестировалось
- Конкретика и доказательства, которые можно показать стейкхолдерам
- Возможность отслеживать недостающее покрытие
- Цепочка шагов для отладки, если что-то пойдет не так
- Регистрация обнаруженных багов, чтобы исправлять их и показывать стейкхолдерам. Тогда все будут в курсе сопутствующих рисков.
Суть в том, чтобы не винить друг друга, а учиться, поскольку нельзя улучшить то, что невозможно отследить.
Шаг 3. Пользуйтесь исследовательскими заметками и сохраняйте их
Вам нравится исследовательское тестирование? Мне тоже. Но не позволяйте этим ценным открытиям оставаться только у вас в голове. Зафиксируйте их. Сеансы исследовательского тестирования можно регистрировать в системах управления тестированием, добавляя к ним скриншоты, заметки или найденные ошибки. Тем самым вы сочетаете гибкость с отслеживаемостью – лучшим из обоих миров.
Шаг 4. Сделайте тестирование доступным для других
Вам совершенно не нужно готовить красочные отчеты для каждого спринта. Но все же покажите команде, чем занимается QA.
- Добавьте короткое описание: что протестировали, что прошло успешно, а что выдало сбой
- Привяжите выполнение теста к тикету
- Сразу отмечайте недостающие тесты и обсуждайте это внутри команды
Когда тестирование становится прозрачным, оно перестает быть просто «работой QA» и переходит в зону коллективной ответственности. Осведомленность порождает ответственность, а ответственность ведет к качеству.
Шаг 5. Сохраняйте легкость и последовательность
Используйте теги, папки или метки, чтобы группировать тесты по рискам, областям продукта или релизам. Для каждого релиза создавайте простой план тестирования. Пусть даже на каких-то 10 тестов. Задавайте ритм на неделю или на спринт: проверяйте, какие из тест-кейсов по-прежнему актуальны. Старые тест-кейсы переносите в архив, и текущие – обновляйте по мере доработки функционала. Структурность – это не про неизменность, а про понятность.
Реальные плюсы, которые вы быстро почувствуете
Стоит только систематизировать тесты в несложную структуру, как вас ждут следующие изменения:
- Ваша команда будет знать, что протестировали, а что – нет
- Вы сможете масштабировать QA, не запутываясь в разных нюансах
- Релизы начнут выходить более слаженно, а не хаотично
- Баги будут отлавливаться раньше; регрессионное тестирование станет более надежным
- QA получит право голоса, а не только груз ответственности за возможные неполадки
И самое приятное: относясь к QA как к системе, а не к чему-то второстепенному, вы создаете уверенность, а не просто покрытие тестами.
Важные советы по дополнительным уровням умного QA
Как только ваша команда внедрит упрощенную структуру и прозрачность, вы перейдете на следующий уровень – малозаметный, но мощный этап, когда хорошее QA становится лучшим QA. Я видела, как эти советы преображали команды не только в плане самого тестирования, но и подхода к нему.
Мыслите тестами, а не их типами
Мы зацикливаемся на типах тестирования: функциональное, регрессионное, исследовательское и т.д. Но гораздо эффективнее мыслить специальными установками:
- Взглянуть на продукт с позиции оценки рисков. Что с наибольшей долей вероятности сломается и нанесет нам вред? В первую очередь тестируем именно это.
- Мыслить как пользователь. Что такого неожиданного может сделать пользователь? Взглянуть на продукт глазами пользователя.
- Провести исследование. Предположим, что-то сломалось. Чему эта ошибка учит нас касательно продукта?
Мотивируйте QA переключаться между этими типами мышления. Такие установки, в отличие от обычного выполнения тест-кейсов, дают более точные результаты.
Ведите «журнал изменений» тестирования – пусть даже для себя
Бывало ли у вас такое: нашли странный граничный кейс, решили проблему, а через пол года напрочь забыли, как и зачем что-то делали?
Ведите простой журнал изменений QA-тестирования. Расшарьте страницу или документ и записывайте туда все про QA:
- Неожиданные баги
- Необычные сценарии или ловушки
- «То, что мы вечно забываем проверить»
- Регрессии, от которых вы страдали в прошлом
Не нужно ничего навороченного. Со временем такой журнал станет мощным центром коллективных знаний – чем-то вроде закладок для самих себя в будущем (и для будущих товарищей по команде).
Перед крупными релизами используйте метод премортема
Перед выходом рисковой версии соберите команду и задайте вопрос: «Допустим, завтра мы выкатываем этот релиз, и ломается что-то серьезное. Как считаете, что может сломаться и почему?».
Такой премортем выявляет скрытые сценарии тестирования, забытые зависимости и потенциальные слепые зоны. Он переводит тестирование из реактивного в стратегическое.
Журналы автоматизации – это тоже результаты тестирования
Прозрачность важна не только при ручном тестировании. Автотесты нужно рассматривать как главные фигуры в документации тестирования:
- Свяжите наборы автотестов с планами тестирования
- Экспортируйте журналы в инструменты управления тестированием или вики
- Кратко обозначьте покрытие автотестами на демо спринтах или в QA-отчетах
Таким образом, вы добавите автоматизацию к надежности QA не только на уровне кода из пайплайна, но и в виде визуально заметной и проверенной работы.
Добавьте в планы тестирования красные флаги
Добавляйте раздел с красными флагами и краткими пометками в каждый план или набор тестирования:
- «Этот модуль всегда ломается на мобильных»
- «Вот здесь был рефакторинг на скорую руку»
- «В этом алгоритме много логики if-else – возможны ошибки»
Это не тесты, а контекстные предупреждения. Благодаря им, новые тестировщики и менеджеры проектов сразу увидят, на что обратить особое внимание.
Сопоставляйте тесты не только с функционалом, но и с рисками
Не надо группировать тесты только по функционалу или эпикам; постарайтесь скомпоновать их по уровню риска:
- Самые важные и высокорисковые процессы: оформление заказа, оплата, аутентификация
- Средний уровень риска: уведомления, дашборды
- Низкий уровень риска: изменение текста, доработки интерфейса
Это поможет вашей команде задать приоритетность тестовых прогонов, понять компромиссы и обсудить со стейкхолдерами важные темы: риски для бизнеса.
Создавайте повторно используемые, а не дублирующие тест-кейсы
Отличный способ – использовать модульную организацию тест-кейсов:
- Выведите общие шаги в повторно используемые блоки (например, «Войти как администратор», «Создание нового клиента»)
- Ссылайтесь на них в разных процессах
Так вы сможете избежать дублирования, упростите сопровождение и будете с уверенностью запускать частичные регрессионные тесты.
Сведите все воедино
Для этого не нужны дополнительные инструменты; потребуется лишь более целенаправленный подход. С ними ваш QA станет:
- Более предсказуемым, без излишней жесткости
- Более заметным, без лишнего шума
- Более стратегическим, без лишних непроизводительных нагрузок
Если ваш QA-процесс задокументирован, учитывает риски и доступен для других, то вы перестаете реагировать на баги и начинаете их предотвращать. Вы создаете доверие не только к качеству релиза, но и к качеству самого процесса. Так что, да: а вы точно протестировали то, что не записали? Но что еще более важно: какой смысл в QA, если вы не учитесь на ошибках?
Заключение
Тестирование без структуры – как езда без карты. Пока вы едете по знакомой дороге, все хорошо. Но стоит отклониться от маршрута, и вы сразу теряетесь. Не нужно выстраивать целую империю QA за одну ночь. Просто начните. Продумайте структуру, чтобы ваша работа была прозрачной, отслеживаемой и результативной. Ведь ваша цель – не только проверить функционал, но и укрепить доверие к каждому релизу. Именно так вы создадите команду с истинным QA-мышлением.