Автор: Эди Стоукс (Ady Stokes) Оригинал статьи Перевод: Ольга Алифанова
Почему я это пишу
Если вы какое-то время работаете тестировщиком ПО или в разработке, вы, скорее всего, сталкивались с термином «ручное тестирование». Это выражение может вызывать бурные споры.
И дело не только в разных мнениях. Сам термин часто искажает суть тестирования. В худшем случае «ручное тестирование» создает вредный водораздел, обесценивая вклад человека и чрезмерно возвышая автоматизацию. В лучшем — умаляет значимость вдумчивых усилий тестирования.
В этой статье хочу обсудить, почему этот термин может быть вреден для ремесла тестирования, и предложить, как сместить фокус к более инклюзивному и точному пониманию того, что на самом деле делают тестировщики. Кто знает, исчезнет ли когда-нибудь термин «ручное тестирование», но попытаться мы можем и должны.
Полезные навыки тестировщиков, юз-кейсы внедрения ИИ и TestContainers, принципы и инструкции для успешной автоматизации, и многое другое: самые интересные новости тестирования за февраль-май 2026
Меня зовут Анатолий Бобунов, и в EXANTE я SDET — Software Development Engineer in Test. В последние несколько лет я развивал тестовую архитектуру для бэкенд‑сервисов компании.
Наш тестовый фреймворк изначально создавался как единая платформа для тестирования нескольких backend‑сервисов. По мере роста системы увеличивалось и количество сервисов, каждый из которых приносил свою специфичную логику, требования к клиентам, данным и подготовке окружения. Эти требования не всегда укладывались в существующую архитектуру. В результате появлялись локальные обходные решения, которые решали конкретную задачу, но обходили архитектурные ограничения.
Со временем такие решения начали накапливаться. Разные сервисы использовали разные паттерны для HTTP‑клиентов, ретраев, подготовки данных и валидации ответов. Общие абстракции постепенно размывались, а направление зависимостей становилось менее очевидным. Дополнительно ситуацию усиливали срочные задачи, которые требовали быстрых изменений без полноценного архитектурного пересмотра. Это приводило к появлению временных решений, которые затем становились постоянными.
Фреймворк продолжал работать и покрывал сценарии тестирования, но его развитие замедлялось. Добавление нового сервиса требовало всё больше исключений, интеграция новых инструментов становилась сложнее, а изменения в базовых компонентах затрагивали несвязанные части системы. В какой‑то момент стало очевидно, что текущая архитектура перестала масштабироваться вместе с количеством сервисов.
В этой статье я расскажу, почему мы решили создать новую архитектурную модель, какие принципы легли в её основу и как мы подготовили фреймворк к работе с SDK и AI‑инструментами.
Автор: Ужвал Кумар Сингх (Ujjwal Kumar Singh) Оригинал статьи Перевод: Ольга Алифанова
Сигнал к пробуждению
Я занимаюсь тестированием программного обеспечения уже три года. Тестировал разные типы приложений, следовал всем профессиональным практикам, выполнял тест-кейсы и отмечал все пункты.
Но иногда я не думал о том, что делаю. Я просто механически проходил шаги, выполняя тесты как машина. И именно так пропустил критический баг, который заблокировал доступ к платформе как новым, так и существующим пользователям. Этот баг попал в продакшен, и по мере развития ситуации стало понятно, что процессом тестирования и выбранными стратегиями недовольны. Через пару дней почта каждого члена команды взорвалась жалобами клиентов, и менеджер посмотрел тем самым взглядом. Все знают этот взгляд. Он не злой. Просто… разочарованный.
Следующие несколько дней я прокручивал всё это в голове, пытаясь понять, где ошибся. Все сценарии были протестированы правильно, все шаги выполнены. И всё же я полностью упустил, как реальный пользователь мог бы взаимодействовать с системой.
Тогда ко мне пришло осознание: тестирование велось мной механически. Но программное обеспечение создаётся для людей.