Есть довольно неприятная проблема с тестовой документацией: тест работает, успешно проходит и при этом уже проверяет не совсем то, что нужно.

Например, несколько месяцев назад поменяли бизнес-логику. Требование обновили в трекере, разработку сделали, а связанный тест-кейс никто не пересмотрел.

На очередном регрессе он снова зелёный.

Формально всё хорошо. Но зелёный результат подтверждает старую проверку, а не обязательно текущее требование.

На небольшом проекте такие связи ещё можно частично держать в голове. Когда требований и тестов становятся тысячи, появляется отдельная задача: как понять, какие требования какими проверками покрыты и актуальны ли эти проверки сейчас?

Для этого и нужна трассировка требований.

Сейчас TMS на рынке условно можно разделить на два подхода.

Первый — классический. Система работает как слой управления ручным тестированием: хранит тест-кейсы, формирует прогоны, фиксирует статусы и результаты. Вся логика выполнения при этом остается за пределами TMS.

Второй — с поддержкой автотестов. Здесь появляются интеграции с CI: система умеет связывать автотесты с тест-кейсами, подтягивать результаты запусков, отображать историю и статусы. Иногда добавляется возможность инициировать запуск, но фактическое выполнение и управление пайплайнами по-прежнему остаются в CI.

В новом релизе DoQA 4.0 как раз добавили сценарий с запуском автотестов прямо внутри TMS. Давайте разберем, как это ребята реализовали.

После ухода с российского рынка популярных систем вроде TestRail, Qase и Zephyr у команд появился запрос на отечественные TMS с удобным интерфейсом, различными интеграциями и встроенной аналитикой.

В статье разберём топ-3 отечественных TMS: сильные стороны, функциональность для ручных и автоматизированных тестов, интеграции, аналитику, AI и стоимость.

Тестирование кода, особенно в сложных системах, зачастую затруднено из-за зависимости от реальных баз данных, внешних сервисов или действий пользователей. Чтобы упростить тестирование, используют заглушки — это упрощенные версии реальных компонентов, которые помогают проверить работу системы без необходимости запускать всё "по-настоящему".

Процесс погружения в автоматизацию волнует и начинающих специалистов, и опытных инженеров по тестированию. Одни считают, что автоматизация не их конёк, другие — что это трудозатратный процесс, который стоит отложить. В этой статье расскажем, как погрузиться в автоматизацию новичку, а также дадим совет, как начать автоматизировать на проекте.

Рассмотрим две отправные точки погружения в автоматизацию: 1) когда начинающий специалист задумался о переходе на этапе обучения или выбрал путь автоматизатора изначально; 2) опытный инженер в роли Manual QA на проекте.

Многие, кто приходил в любую новую сферу, задавались вопросами: «какими инструментами необходимо владеть, чтобы…», «а точно ли это весь перечень?», «а какие навыки необходимы, чтобы пройти собеседование?». Таких вопросов больше у новичков, которые уже начали обучение или только в поисках обучения, пытаются понять минимум необходимый для старта.

Давайте разберёмся с вопросами по ручному и автоматизированному тестированию, которые задают в том числе и студенты курса «Инженер по тестированию».
В статье мы пройдём по нужным навыкам, инструментам. Дадим полезные ссылки для углубления в темы и составим карту компетенций.

Всем привет! Меня зовут Стас, и я Senior QA в компании inDrive и наставник на курсе «Инженер по тестированию» в Яндекс Практикуме. Ещё веду телеграм-канал «Тестировщики нужны».

Многие начинающие автоматизаторы задаются вопросом: «Как же написать свой первый автотест на мобильное приложение?». В данной статье я и хотел бы ответить на этот вопрос. На самом деле, статей на эту тему написано довольно большое количество. Подробно рассказывается применение паттерна PageObject в написании тестов и многое другое. Но наша с вами задача — написать наш первый простенький тест на экран авторизации на языке Java. Поэтому давайте решим эту задачу вместе!