Друзья, поделитесь опытом организации авто тестов?
В частности, подходом к организации тэгов.
У нас в текущем test suite около 900 тестов (в этом посте речь о UI) и набор не очень продуманных тэгов (добавляли, как и что получалось, в итоге их никто не поддерживает, некоторые тесты отмечены, некоторые - нет, некоторые - неправильными тэгами). Поэтому, на сегодняшний день, надежнее всего - запускать всё, что есть.
И это:
1. Долго (ну... относительно... у нас хороший Grid, но хотелось бы сделать прогоны более полезными). Кроме того, набор тестов растет каждый день.
2. Часто ломаются тесты, которые точно не имеют отношения к твоей текущей фиче и это блокирует релиз (или по крайней мере его замедляет).
Хотелось бы сделать организацию тэгов более грамотно - в частности, чтобы можно было запускать только необходимые для определенной функциональной области тесты, сократив время прогона, но главное - увеличив стабильность и прозрачность.
К сожалению, мне пока не удалось найти материалы по этой теме.
Из очевидных стратегий:
- По фазе тестирования (Smoke, Full Regression) - предполагаю, поделить будет довольно легко, но это не решает проблему тестирования только необходимых компонент.
- По приоритетам (Critical, Major, Medium, Minor) - думаю, это может быть слишком субъективный критерий. Кроме того, это не решает проблему тестирования только необходимых компонент.
- По функционалу (User profile, Search, Checkout, etc.) - это решает проблему тестирования только необходимых компонент, но думаю, будет очень сложно четко определить границы разделения функционала и правильно его назвать, ведь один тест может относиться к нескольким областям, также есть зависимые области (придётся создавать и поддерживать ручную матрицу зависимости компонент???)
- Комбинация из пары стратегий - скорее всего более точная, но команда может быть не в восторге от сложности определения к какому (-им) тэгу отнести тест.