В книге "Гибкое тестирование. Практическое руководство для тестировщиков ПО и гибких команд" Лайзы Криспин и Джанет Грегори рассказывается о пирамиде автоматизации тестирования в agile. Эта пирамида показывает идеальный вариант распределения количества автотестов по категориям. Вот что пишется об этой пирамиде в книге:
Каждый
уровень характеризует количество тестов на уровне.
Unit tests
– пишутся разработчиками, таких тестов самое большое количество.
API Layer - на нем происходит тестирование
бизнес-логики. Тестируется функциональность не через пользовательский
интерфейс, а через API. Эти тесты пишутся на языке предметной области
(domain-specific), чтобы они были понятны и разработчикам, и заказчикам. Можно использовать различные таблицы для формирования входных
данных. Функциональные тесты работают
напрямую с продакшн кодом, без GUI или какого-то другого слоя между ними.
GUI
тесты – пишутся, когда код уже написан. В общей массе
тестов их должно быть меньше остальных ( тестов нижних двух уровней пирамиды).
Тестируется тонкий GUI с малым количеством или отсутствием бизнес-логики. На этом уровне не надо тестировать бизнес-функциональность. Например, можно
проверить, что кнопки работают, выполняют ожидаемые действия, появляются
корректные сообщения об ошибках. Какие-либо тесты, где необходимо тестировать
именно пользовательский интерфейс, или когда без пользовательского интерфейса
не обойтись.
Ручное тестирование (manual testing) – usability и exploratory testing. Проводится при
наличии пакета регрессионных автоматизированных тестов.
На
мой взгляд, это очень правильная и наглядная пирамида, но удается ли этого
добиться на практике? Если мы только начинаем разрабатывать новый продукт, то
такую пирамиду несомненно можно получить, если мы внедряем автоматизацию на уже
существующем продукте, у которого выпущен релиз (а возможно и не один) и
происходит доработка нового функционала, то скорее всего второй уровень
пирамиды перейдет в третий, и станет тестами через UI.
Очень
интересен второй уровень пирамиды, а точнее, кем эти тесты должны писаться.
Тесты второго уровня (тесты через API) на мой взгляд должны осуществляться
программистами. Потому что тестировщик-автоматизатор все таки работает на
уровне пользовательского интерфейса. Несомненно он должен уметь читать код, но
чтобы написать тесты на уровне API, ему придется постоянно отвлекать
программистов.
В
любом случае, такая пирамида отлично поможет нам в нахождении того места, где
засел баг - он находится либо в каком-то модуле, либо в реализации
бизнес-логики, либо в UI приложения.