Подпишитесь на наш ТЕЛЕГРАМ КАНАЛ ПО АВТОМАТИЗАЦИИ ТЕСТИРОВАНИЯ
Сегодня автоматизированное тестирование воспринимается неотъемлеммой частью процесса разработки программ, но так было не всегда. Оно зародилось в условиях ограниченных ресурсов мейнфреймов 50-х годов. История тестирования во многом отражает развитие всего ПО.
Ранние годы
До спринтов и DevOps тестирование выполнялось вручную. Вычислительные мощности были дефицитом, а память использовалась только для «важных» задач, к которым тесты не относились.
Разработка велась на централизованных системах, которыми пользовались сразу несколько команд. Машинное время бронировали заранее, и каждая секунда была на счету, поэтому тестирование считалось роскошью.
Некоторая автоматизация существовала, но в основном в крупных компаниях, которые могли позволить себе собственные инструменты. О модульных тестах знали лишь в научных кругах и отдельных больших корпорациях, но стандартов и широкого применения не было — тестирование носило разовый, неформальный характер.
Неправильно понятая «водопадная» модель
В 1970 году инженер Уинстон Ройс опубликовал статью «Управление разработкой больших программных систем» (Managing the Development of Large Software Systems.) В ней он описал последовательную схему разработки: анализ → проектирование → реализация → тестирование → внедрение.
Однако Ройс не продвигал жёсткий линейный подход, а критиковал его. Он предупреждал, что отложенное тестирование ведёт к позднему обнаружению ошибок и дорогой переделке. Рекомендовал итеративную разработку, например, сначала сделать прототип, а потом финальный продукт.
Но большинство читателей запомнило лишь диаграмму на второй странице, проигнорировав предупреждения. Так «водопад» на десятилетия стал мнимым стандартом, хотя изначально был предостережением.
Ройс пошёл дальше, предложив более итеративный подход к разработке. Он рекомендовал пройти процесс дважды: сначала в меньшем масштабе для создания прототипа, а затем для создания финального продукта. Ирония в том, что немногие прочли его работу целиком. Большинство просто увидели диаграмму на второй странице, проигнорировали предупреждения и приняли линейную модель за лучший практический стандарт. Десятилетиями команды следовали этому плану, считая его проверенным и эффективным, хотя на самом деле это было предупреждение.
Появление Agile
К 1990-м недостатки водопада стали очевидны: проекты срывали сроки, перерасходовали бюджеты, не соответствовали ожиданиям пользователей.
В 2001-м 17 специалистов подписали Agile Manifesto, провозгласивший следующие ценности:
- Люди и взаимодействие важнее процессов и инструментов
- Рабочее ПО важнее документации
- Сотрудничество с заказчиком важнее контрактов
- Готовность к изменениям важнее следования плану
Agile и XP (Extreme Programming) ввели итеративную разработку, постоянную обратную связь и частые релизы. Тестирование стало частью цикла разработки, а не отдельным этапом. Появились Test-Driven Development (TDD) и Behavior-Driven Development (BDD), побуждающие разработчиков писать тесты до кода и проверять поведение, а не реализацию.
SUnit и тестовые фреймворки
Agile изменил подход к тестированию. С переходом на короткие итерации и непрерывную обратную связь командам потребовались инструменты, способные идти в ногу с быстрыми циклами разработки. Так появилось семейство фреймворков xUnit.
Всё началось с SUnit, созданного Кентом Беком в 1989 году для языка Smalltalk. SUnit ввёл базовые элементы модульного тестирования: тестовые случаи, утверждения, процедуры подготовки и очистки окружения, а также наборы тестов.
Десять лет спустя, в 1999 году, Бек и Эрих Гамма выпустили JUnit для Java. Это был первый широко используемый open-source фреймворк модульного тестирования. Он вывел автоматизацию тестирования в мейнстрим, плотно интегрировавшись с инструментами сборки Java и обеспечивая разработчикам быстрый цикл обратной связи.
Системы контроля версий и непрерывная интеграция
По мере того как тестирование становилось всё более автоматизированным, происходил ещё один фундаментальный сдвиг — появление систем контроля версий (VCS) и практики непрерывной интеграции (CI).
CVS (Concurrent Versions System) была выпущена в ноябре 1990 года и стала одной из первых централизованных систем контроля версий. Она позволяла нескольким разработчикам работать с одной кодовой базой и отслеживать изменения в общем репозитории. До появления CVS контроль версий обычно был локальным, что затрудняло обмен изменениями, их отслеживание и слияние.
Однако одного контроля версий оказалось недостаточно. В 2001 году компания ThoughtWorks выпустила CruiseControl — первую открытую систему непрерывной интеграции.
CruiseControl внедрила концепцию цикла сборки, автоматизированное тестирование (с интеграцией JUnit) и панели мониторинга.
Вместе контроль версий и CI заложили основу для современного DevOps-стека, где изменения в коде постоянно интегрируются, тестируются и доставляются пользователям.
Золотой век тестирования
2000-е годы стали периодом бурных инноваций в области автоматизированного тестирования. В 2004 году появился Selenium, который позволил разработчикам писать сквозные (end-to-end) тесты и тесты UI. Он быстро стал основным инструментом для автоматизации тестирования фронтенда.
На стороне CI в 2005 году был представлен Hudson — более удобная для разработчиков альтернатива CruiseControl. Hudson предлагал современный интерфейс, архитектуру плагинов и простую настройку, что сделало его более доступным. Позднее он был клонирован в Jenkins, который стал доминирующим инструментом CI на следующее десятилетие.
В том же 2005 году появился RSpec, упростивший разработчикам переход к BDD. А в 2008 году Cucumber поднял BDD на новый уровень, введя язык Gherkin — синтаксис на простом английском для описания поведения программного обеспечения.
Бум тестирования на JavaScript
К 2010-м годам JavaScript превратился из языка сценариев, работающего только в браузере, в ключевую технологию для всего веба.
В 2011 году вышел Mocha — один из первых гибких фреймворков для тестирования JavaScript в среде Node.js. Mocha предложил простой, но мощный интерфейс для написания асинхронных тестов, а его модульная архитектура позволяла разработчикам выбирать удобные библиотеки утверждений (assertion libraries) и репортеры.
С ростом сложности фронтенд-приложений вырос и спрос на end-to-end тестирование. В 2014 году появился Nightwatch.js, основанный на Selenium, который позволял автоматизировать браузер прямо из Node.js. Он отличался простой установкой и синтаксисом, ориентированным на JavaScript-разработчиков, что сделало тестирование UI доступнее.
В том же году Facebook открыл исходный код Jest. Этот инструмент объединил всё необходимое в одном пакете, устранив лишние сложности для разработчиков и по умолчанию внедрив лучшие практики.
Стремление к улучшению end-to-end тестирования продолжилось в 2017 году с релизом Cypress. В отличие от инструментов на основе Selenium, Cypress работал прямо в браузере вместе с тестируемым приложением, обеспечивая более точное и надёжное тестирование.
В 2020 году на сцене появился Playwright, созданный бывшими участниками команд Selenium и Puppeteer. Он предложил современный подход к автоматизации браузеров, поддерживал несколько браузеров «из коробки», позволял запускать тесты в headless- и headful-режиме, а также имитировал реальные условия работы пользователя, включая сетевые задержки и геолокацию.
ИИ меняет все
Искусственный интеллект изменил подход к разработке ПО. Если отбросить весь хайп, крупные языковые модели (LLM) вполне способны писать код и выступать в роли партнёров в процессе тестирования. Они могут выполнять рутинные задачи и генерировать шаблонный код.
С помощью ИИ разработчики могут использовать новые подходы к работе:
- Описать функциональность на естественном языке и мгновенно получить набор тестов
- Автоматически обновлять тесты при изменении кода
- Привлекать ИИ как ревьюера тестов, который предложит недостающие проверки или укажет на лишние
Кроме того, появляются тест-раннеры с поддержкой LLM, встроенные прямо в инструменты разработки. Один из ярких примеров — Playwright MCP. MCP действует как своего рода USB-мост между Playwright и LLM, позволяя управлять автоматизацией браузера с помощью инструкций на естественном языке.
Заключение
История автоматизированного тестирования тесно связана с развитием разработки программного обеспечения. В первые годы тестирование было ручным и дорогостоящим. Модель водопада отодвигала его на конец процесса, воспринимая как отдельный этап, а не как непрерывную практику.
Появление Agile, систем контроля версий и непрерывной интеграции привело к бурному росту инструментов тестирования на всех уровнях технологического стека. Тестирование стало неотъемлемой частью жизненного цикла разработки. Оно перестало быть запоздалой мерой и превратилось в ключевой элемент для быстрой и надёжной поставки поддерживаемого ПО.
Дальнейшая задача — интегрировать новые технологии, такие как ИИ, не утратив отработанных на практике подходов, которые делают тестирование действительно эффективным.
Перевод статьи «Automated Testing: From Mainframes to ChatGPT».