Автор: Ужвал Кумар Сингх (Ujjwal Kumar Singh)
Оригинал статьи
Перевод: Ольга Алифанова

Сигнал к пробуждению

Я занимаюсь тестированием программного обеспечения уже три года. Тестировал разные типы приложений, следовал всем профессиональным практикам, выполнял тест-кейсы и отмечал все пункты.

Но иногда я не думал о том, что делаю. Я просто механически проходил шаги, выполняя тесты как машина. И именно так пропустил критический баг, который заблокировал доступ к платформе как новым, так и существующим пользователям. Этот баг попал в продакшен, и по мере развития ситуации стало понятно, что процессом тестирования и выбранными стратегиями недовольны. Через пару дней почта каждого члена команды взорвалась жалобами клиентов, и менеджер посмотрел тем самым взглядом. Все знают этот взгляд. Он не злой. Просто… разочарованный.

Следующие несколько дней я прокручивал всё это в голове, пытаясь понять, где ошибся. Все сценарии были протестированы правильно, все шаги выполнены. И всё же я полностью упустил, как реальный пользователь мог бы взаимодействовать с системой.

Тогда ко мне пришло осознание: тестирование велось мной механически. Но программное обеспечение создаётся для людей.

Проблема «чек-листового тестирования»

Следовать структурированным тест-кейсам важно, но полагаться только на них и не делать ничего сверх этого — значит создавать слепые зоны. Вот что стало понятно:

• При многократном повторении одних и тех же шагов мозг начинает отключаться.
• Реальные пользователи не следуют тестовым сценариям. Они ошибаются, сокращают путь и делают неожиданные вещи.
• Чем больше спешки и отвлечения, тем меньше замечаются мелкие и странные проявления поведения тестируемого приложения.

Нужно было перестать работать на автопилоте.

Смена подхода: тестирование по-человечески

После того продакшен-багa я пересмотрел свой подход к тестированию – стал меньше фокусироваться на «выполнены ли все шаги?» и больше — на «понимаю ли, что тестируется?»

Вот три вещи, которые полностью изменили мой подход к работе:

1. Подход «а что, если»

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

• Что, если кто-то вставит целый роман в это поле ввода?
• Что, если пользователь очень быстро переключается между двумя аккаунтами?
• Что, если соединение обрывается сразу после нажатия «отправить»?

Эти небольшие мысленные эксперименты помогли находить баги, которые скриптовые тест-кейсы пропустили бы. Ниже приведена блок-схема, отражающая этот новый процесс мышления.

Эта блок-схема «что, если» отражает типичный путь исследовательского тестирования. Всё начинается с «Начать тестирование», затем идет переход к Спросить «Что, если?». Здесь начинается настоящая исследовательская работа. Далее идёт разветвление на пять сценариев из реальной жизни:

• Что будет, если ввод слишком длинный? Здесь тестируются длинные строки.
• Что будет, если пользователь быстро переключает аккаунты? Это ведёт к симуляции быстрого переключения.
• Что будет, если сеть отключается? Проводится симуляция сетевого сбоя.
• Что будет, если пользователь отправляет некорректные данные? Проверяется обработка ошибок.
• Что будет, если одновременно заходит много пользователей? Проводится симуляция множественного доступа.

Все эти ветки сходятся на этапе «Наблюдать и фиксировать проблемы». Здесь внимательно отслеживается поведение системы и фиксируются любые неожиданные проявления.

Затем мы переходим к «Завести баги и улучшить тесты». И процесс заканчивается этапом «Улучшить тестовую стратегию», где полученный опыт используется для улучшения будущего тестирования.

2. Объяснение багов вслух, хотя бы своей кофейной кружке

Я начал проговаривать проблемы вслух — не коллеге, а комнатному растению (которое, если честно, может быть искусственным). Звучит странно, но это реально помогает.

• Проговаривание помогает лучше структурировать мысли.
• Становятся заметны пробелы в понимании требований и подходе к тестированию.
• Баг-репорты становятся гораздо яснее, потому что объяснение уже отработано заранее.

3. Осознание, что мозг перегружен

Раньше казалось, что чем дольше тестируешь без остановки, тем лучше результат. Поэтому я продолжал работать даже в состоянии усталости. Это было ошибкой.

• Теперь при ощущении усталости делается пауза.
• Пяти минут достаточно, чтобы перефокусироваться.
• Отход от экрана помогает увидеть вещи по-другому при возвращении.
• Самые странные баги чаще всего находятся свежим взглядом.

Выход за рамки: продвинутые техники

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

1. Риск-ориентированное тестирование

Вместо попытки протестировать всё, приоритезация идёт по влиянию и вероятности. Я спрашиваю себя:

• Какие области приложения наиболее критичны для пользователей?
• Какие изменения в релизе с наибольшей вероятностью приведут к багам?
• Если что-то сломается, каковы худшие последствия?

Такой подход помогает сосредоточиться на зонах высокого риска, а не тратить часы на малозначимые проверки.

2. Сессионное исследовательское тестирование

Вместо хаотичного исследования используются ограниченные по времени сессии с чёткими чартерами. Я ставлю конкретную цель:

• Исследовать поведение системы при одновременных действиях нескольких пользователей.
• Проверить все возможные сценарии отказа для критичных модулей, влияющих на пользовательский путь.

Это делает мое исследовательское тестирование более структурированным, сохраняя гибкость.

3. Использование ИИ и автоматизации как помощников, а не замены мозга

Раньше я опасался, что автоматизация сделает тестировщиков ненужными. Теперь я смотрю на ситуацию иначе. Автоматизации передаются повторяющиеся задачи, чтобы я мог сосредоточиться на непредсказуемом.

• Автоматизация используется для быстрого выполнения регрессионных тестов.
• Инструменты с ИИ применяются для анализа логов и поиска аномалий.
• Скрипты используются для генерации тестовых данных, чтобы больше времени уделять исследованию.

Эти инструменты не заменяют, а освобождают время для главного — задавать «почему» и «что если?».

4. Тестирование после деплоя

Теперь продукт тестируется и после деплоя. Используется подход «grandfathering»: тест-кейсы создаются до релиза, а затем после деплоя я прохожу полный пользовательский путь, чтобы убедиться, что существующие функции работают корректно.

Почему это полезно:

• Некоторые проблемы проявляются только в продакшене из-за реальных условий.
• Гарантируется, что старый функционал не ломается незаметно из-за новых изменений.
• Я получаю полное представление о пользовательском опыте от начала до конца.

Вместо предположения «всё работает, потому что тесты прошли на стенде», этот подход помогает находить проблемы, которые традиционное предрелизное тестирование может пропустить.

Результаты: что изменилось

С переходом к более осознанному тестированию многое для меня изменилось. Баг-репорты стали более подробными и содержательными, разработчикам стало проще разбираться в проблемах. Критические баги начали находиться раньше, а обратная связь между тестированием и разработкой улучшилась.

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

И результат очевиден:

• Меньше проблем, обнаруженных клиентами.
• Критические баги находятся раньше.
• Тестирование стало больше про исследование, а не про проставление галочек.

Но самое важным для меня было осознание, что происходит не просто тестирование продукта — происходит реальное улучшение его качества.

Заключение

Если ощущается, что тестирование превратилось в механический цикл, попробуйте завтра следующее:

• Закройте лишние вкладки и сосредоточьтесь на приложении.
• Задайте вопрос: «Что самое странное может сделать пользователь здесь?»
• Проговорите баг вслух перед тем, как записать его.

Это небольшое изменение, но оно всё меняет. Тестирование — это не про идеальность. Это про умение видеть по-другому. И как только это получилось, прежним способом тестировать уже не получится.

Обсудить в форуме