Евгений Гусинец, Middle+ QA Engineer, автор телеграмм канала о тестировании QA❤️Life https://t.me/QA4Life
На связи Евгений Гусинец — Middle+ QA Engineer из Минска, ментор и автор ТГ‑канала QA❤️4Life. Добро пожаловать в мою небольшую подборку «тестировочной рутины» и советов, как с ней справляться! Наверняка, многие из вас узнают себя в этих ситуациях. А может быть, вы даже сможете поделиться своими «любимыми» повторяющимися задачами в комментариях?
В любом случае, надеюсь, этот пост поднимет вам настроение и, возможно, даст пару полезных идей.
Ох, рутина… Это такое знакомое слово каждому, кто хоть раз окунался в мир IT, и тестировщики тут, поверьте, не исключение.
Казалось бы, каждый день что‑то новенькое, баги выискиваем, приложения ломаем по‑хорошему... Но если копнуть глубже, у каждого тестировщика найдется свой «день сурка» из повторяющихся задач. Давайте вместе посмеемся (или погрустим?) над этими моментами, разбавив это дело мудростью из книжек, которые не раз помогали мне и моей команде.
Вот сижу я сейчас, четверг, почти полночь, а в голове крутится не только как бы половчее протестировать вот этот хитрый кейс, но и ворох тех самых рутинных дел.
Автор: Дэн Бурлаку (Dan Burlacu) Оригинал статьи Перевод: Ольга Алифанова
Зачем тестировать в Kubernetes?
Мне, как инженеру-тестировщику, поставили задачу разработать автоматизированные UI-тесты (пользовательского интерфейса) для сложного веб-приложения с динамически генерируемым содержимым. Это означает, что у веб-элементов, с которыми мне нужно взаимодействовать, зачастую отсутствуют статические атрибуты, на которые можно легко сослаться. В результате нужно использовать более сложные стратегии поиска и взаимодействия с этими элементами. Попрыгав через ряд колец локализации веб-элементов и убедившись, что я кликаю по нужным кнопкам и имею доступ к правильным встроенным фреймам, я закончил работу над тестами.
Веб-приложение запускается, как отдельная K8S (Kubernetes) копия для каждой клиентской компании, на отдельном кластере K8S, где ресурсы этой конкретной копии сгруппированы в пространства. UI-тесты автоматически запускаются перед крупными обновлениями версий веб-приложения, а также сразу после, чтобы проверить, что обновление не повредило работе приложения. Это было достигнуто через контейнеризацию кода UI-тестов в образ Docker, его отправку в репозиторий организации и использование задачи K8S для деплоя тестов в конкретном пространстве копии перед обновлением и сразу после него.
Образ Docker, разворачивающийся на сотнях ресурсов, должен быть легким, поэтому тесты запускались в окружении Linux. Запуск в Linux без поддержки дисплея означал, что тесты не могли открыть обычны браузер и вынуждены были использовать режим без графического интерфейса. Вся разработка и тестирование в компании проводятся в Chrome, и поэтому я, естественно, использовал ChromeDriver для запуска настройки Chromium в деплое контейнера. Сервер, отслеживающий расписание обновлений, использовался для запуска тестов в конкретной копии веб-приложения, а тесты возвращали на сервер JSON-отчет о результатах.
В этой статье я хочу поделиться взглядом на то, каким может быть оптимальный процесс автоматизации тестирования. Мы разберём, зачем он нужен, почему именно такой подход может считаться эффективным, а также какие плюсы и минусы он несёт. Важной частью статьи станет анализ рисков, к которым может привести нарушение или игнорирование этих процессов. Кроме того, мы ответим на частый вопрос: когда и какие тесты стоит запускать на CI/CD, чтобы это было максимально эффективно и стабильно.
Сразу хочу подчеркнуть: в этой статье мы будем говорить исключительно о концепции процесса, а не о технической реализации. Здесь не будет примеров кода, конфигураций CI/CD, или привязки к конкретным инструментам и фреймворкам. Цель статьи — описать качественную архитектуру процесса автоматизации, которая может быть адаптирована под любой технологический стек.
Ведь в каждой компании свои инструменты, процессы, команды и особенности CI/CD. Универсального "рецепта" не существует — но существует направление движения и принципы, к которым стоит стремиться. Если же вас интересуют технические детали, реализация автотестов или настройка пайплайнов, рекомендую ознакомиться с другими моими статьями:
Также важно отметить, что описанный здесь процесс — это обобщённая концепция. В зависимости от специфики проекта, команды или компании он может меняться. Это не жёсткий шаблон, а скорее ориентир, позволяющий построить стабильную, понятную и эффективную систему автоматизации. Подходите к нему критически и адаптируйте под свои условия — но старайтесь двигаться в этом направлении.
Почитываю книжку Искусство Agile-тестирования и наткнулся в ней на такую штуку как "компонентное тестирование" (КТ). Я уже не первый раз натыкаюсь на этот термин, в первый раз я поискал инфу об этом, как то не очень понял и забил. Но с каждой последующей встречей у меня все больше подгорало.
В пирамиде тестирования, КТ стоит сразу после модульного. И если unit-тесты это участь разработчиков, то КТ это уже, якобы, зона ответственности тестировщика, отсюда необходимость хоть как то в этом разобраться.
Начнем с определений. Самое крутое (тут сарказм), которое я нашел это - "Компонентное тестирование программного обеспечения - это тестирование отдельных компонентов программного обеспечения". Да и вообще, во многих статьях определение пропускается и пишется, что-то вроде "компонентное тестирование это вид тестирования который следует сразу после модульного и до интеграционного". Еще варианты:
