Комментарии 10
Добрый день. Очень интересная статья, но не все термины ясны. Подскажите, какими минимальными знаниями необходимо обладать, чтобы попасть в вашу команду тестировщиков? Хотелось бы подтянуть свои знания перед тем, как идти на собеседование.
Добрый. В первую очередь понимание принципов ООП - без этого никуда. Также я бы рекомендовал изучить самостоятельно или пройти курсы по Selenium, освоить основы C#, включая отладку и разобраться с шаблонами проектирования PageObject и PageElement. Ну и конечно же знания по HTTP request'ам для взаимодействия с API. Теория без практики не работает, поэтому, можете сами придумать себе тесты любых интернет-ресурсов и реализовать их., или попробовать попасть к нам на стажировку.
Нет у нас код находится в отдельном репозитории. Есть репозиторий для общих компонентов (работа с Excel, разными БД, TestRail, сбор логов, классами расширений Selenium, FlaUI и т.д) и под каждый тестовый проект свой персонализированный репозиторий, содержащий непосредственно тестовые классы и методы.
Мы разрабатываем в первую очередь регрессионные E2E тесты и исправление по ним вносятся при получении первой сборки от разработчиков. В отличии от жестко структурированных API, в интерфейсе, заранее знать какие компоненты и как будет использовать разработчик, а также продумать методы взаимодействия с ними сложно, и как правило не эффективно, поэтому процесс именно такой.
Ветки у нас обычно делятся по тестовым контурам, на которых проводится тестирование и при попадании тестируемого проекта на предпоставочный контур или прод, сливаются в master. Ну и понятно, что под каждую задачу на автоматизацию есть своя ветка, которая проходит ревью перед слиянием, и анализ SonarQube в процессе сборки . Процесс очень схож с процессом разработки самих проектов. Есть сервер сборки тестового проекта и публикации выбранной ветки с трансформацией конфигов для нужной среды через Azure DevOps.
Если конкретно по вашему примеру, то по шагам так:
1.Кнопка синяя в проекте и в тестах мастер ветке.
2.Разработчики сделали изменения в новой ветке и изменили цвет на красную, после чего опубликовали проект на тест среду.
3.Мы сделав прогон регресса увидели упавший тест и сравнили результат с требованиями.
4.Так как это не баг создали ветку тестового проекта для соответствующего контура и выполнили доработки.
5.Запустили регресс на новой ветке и получили успешные результаты.
6.После переноса проекта на предпромышленный среду слили в мастер ветку тестового проекта.
Цена регресса. Как мы организовали инфраструктуру для Е2Е-тестов