«Я начинал карьеру в роли Embedded System Test Engineer. В то время я занимался тестированием программно-аппаратной интеграции и проверкой функциональности систем. Но по мере профессионального роста я начал искать другие карьерные пути, которые в большей степени соответствовали моей страсти к тестированию и написанию кода.
В середине своей карьеры я принял решение перейти на должность Software Development Engineer in Test (SDET). Переход дался мне нелегко – потребовалось освоить новые навыки, адаптироваться к новым рабочим процессам, и решать более сложные задачи.
В этой статье я поделюсь некоторыми мыслями и соображениями с людьми, которые увлекаются как программированием, так и тестированием, и которые, возможно, рассматривают аналогичный путь.
Переход от Embedded к Automation
Тестирование встраиваемых систем и автоматизация тестирования направлены на повышение качества продуктов. Они имеют схожие стратегии тестирования и требуют сотрудничества с кроссфункциональными командами. Однако они различаются наборами навыков, инструментами тестирования и тестовыми окружениями. Список сходств и различий в таблице:
Как я стал автоматизатором
Я начал свой путь в тестировании программного обеспечения с изучения основ с помощью сертификации ISTQB Certified Tester Foundation Level (CTFL). Она дала мне базовое понимание жизненного цикла разработки (SDLC), методов проектирования тестов, жизненного цикла дефектов, типов тестов и пирамиды тестов.
Независимо от того, ручное это или автоматизированное тестирование – понимание SDLC, Agile-методологии, веб-технологий и контейнеризации (например Docker и Kubernetes) имеет решающее значение. Четкое документирование планов тестирования, тест-кейсов, этапов тестирования, результатов тестирования и дефектов обеспечивает согласованность и информированность всей команды на протяжении всего процесса разработки. Если ваша компания работает в облаке, полезно получить практический опыт работы с такими платформами, как AWS или Azure.
Когда я перешел к автоматизированному тестированию, я быстро осознал важность кодирования. Python – отличная вещь для старта, но многие компании по-прежнему опираются на Java, JavaScript и TypeScript для автоматизации. Какой бы язык вы ни выбрали, инструменты контроля версий, такие как GitLab или GitHub, необходимы.
Компании выбирают фреймворки для тестирования в зависимости от своих потребностей. При выборе тестовых фреймворков и инструментов команда тестировщиков должна оценивать такие факторы, как предпочтительный язык команды, набор навыков команды, простота внедрения и отладки, функции отчетности, возможность настройки для различных окружений, роли пользователей, совместимость с браузерами и устройствами, возможность интеграции в пайплайн CI/CD, параллельное выполнение тестов и объем работы по обслуживанию. В таблице ниже я привожу различия между тестовыми фреймворками.
При разработке кода разработчики пишут юнит-тесты для проверки логики кода. Они могут использовать такие инструменты, как JUnit и PyTest, чтобы имитировать вводы и проверять, что выводы ведут себя так, как ожидается. Эти тесты выполняются быстро, изолированно, имея минимальные зависимости от других модулей.
Но юнит-тесты – это задача разработчиков; тестировщики же сосредоточены на проверке сквозных процессов и функциональности интегрированных систем с помощью тестирования пользовательского интерфейса, API и сквозного тестирования.
Для тестирования пользовательского интерфейса такие фреймворки, как Cypress, Selenium, Playwright, Cucumber (с Selenium) и Robot (с Selenium), предназначены для автоматизации взаимодействия с браузером. Для тестирования API подойдут Postman, Karate, Rest Assured, опять же Cucumber (с Rest Assured), TestNG (с Rest Assured или Karate). Тестировщики также проводят тесты производительности с помощью таких инструментов, как JMeter и Locust, для измерения времени отклика, частоты ошибок, задержек, пропускной способности, пропускной способности одновременных пользователей и поведения системы под нагрузкой. Эти тесты основаны на правильной работе внешних интерфейсов, внутренних сервисов и баз данных.
Типичный порядок выполнения тестов показан на диаграмме ниже. Сначала выполняются юнит-тесты, поскольку они быстрые и помогают выявить функциональные проблемы на ранней стадии. Затем следуют интеграционные и API-тесты, которые проверяют логику и взаимодействие с другими сервисами. Далее следуют тесты пользовательского интерфейса, которые проверяют поведение пользователей. Многие QA-команды также выделяют подмножество регрессионных тестов и выполняют их в качестве дымовых тестов, чтобы быстро убедиться в корректности основных функциональных возможностей. Наконец, проводятся тесты производительности, чтобы оценить, соответствует ли система требованиям к производительности и масштабируемости.
Хотя во многих организациях есть специальные выделенные команды, занимающиеся вопросами безопасности и тестирования на проникновение, все же полезно иметь базовое представление о распространенных уязвимостях – особенно о TOP 10 от OWASP. Такие инструменты, как Burp Suite, также можно использовать для проверки и анализа API в ходе исследовательского тестирования.
После того как тест-кейсы автоматизированы, следующим шагом будет их бесшовная интеграция в конвейер CI/CD. Такая интеграция позволяет ускорить цикл релизов и сократить время выхода на рынок, обеспечивая непрерывную, эффективную и согласованный с современными практиками DevOps контроль качества.
Плюсы роли Automation
Мы разрабатываем тест-кейсы на основе требований, пишем сценарии автоматизации для проверки того, что фичи реализованы так, как ожидалось, и помогаем обнаружить ошибки на ранних этапах разработки. Интегрируя регрессионные автотесты в конвейер CI/CD, мы обеспечиваем непрерывное тестирование и проверку каждого изменения кода, что позволяет оптимизировать процесс релиза.
Что мне особенно нравится в этой роли – ее динамичный характер. Постоянно появляются новые инструменты, фреймворки и методы тестирования, поэтому всегда есть чему учиться. Самое главное, я ценю коллаборативный аспект работы: сотрудничество с разработчиками, дизайнерами, владельцами продуктов и другими тестировщиками.
Появление искусственного интеллекта привело к изменениям в автоматизации тестирования. Генеративный ИИ может использоваться для генерации тест-кейсов и тестовых данных, повышения качества тестового кода, уточнения описаний багов, разработки предложений по более чистой реализации кода и рефакторингу, диагностике проблем, исследовании и внедрении новых технологий тестирования. Эти задачи проиллюстрированы в следующих примерах:
- Генерация тест-кейсов и тестовых данных
Промпт: создай положительные и отрицательные тестовые данные для поля ввода, принимающего буквенно-цифровые и специальные символы, включая тестовые данные для CSS и SQL-инъекций.
- Повышение качества тестового кода
GenAI помогает улучшить качество тестового кода несколькими способами: удалением дублирующейся тестовой логики, заменой жестко закодированных ожиданий на динамические, извлечением многократно используемых функций из повторяющегося кода, а также выявлением опечаток и нарушений стандартов кодирования, соблюдением правил стиля и поощрением лучших практик.
Промпт: улучши качество кода, приведенного ниже.
page.click("#login-button")
time.sleep(5)
page.fill("#username", "testuser")
time.sleep(5)
page.fill("#password", "password123")
time.sleep(5)
page.click("#submit")
Предложения GenAI по его улучшению:
def login(page, username, password):
page.click("#login-button")
page.wait_for_selector("#username")
page.fill("#username", username)
page.fill("#password", password)
page.click("#submit")
login(page, "testuser", "password123")
- Уточнение описаний багов (баг-тикетов)
GenAI структурирует описания багов в четком, стандартизированном формате, облегчая разработчикам понимание и решение проблем. Это помогает сократить количество опечаток и двусмысленностей, которые приводят к недопониманию.
Промпт: Уточни описание бага
- Предложи более чистую реализацию
Например, может потребоваться перехватить API и сымитировать ответы, чтобы проверить, что пользовательский интерфейс отображает правильные сообщения.
Промпт: Как использовать Playwright для перехвата API и имитации ответов для тестирования UI в различных сценариях?
from playwright.sync_api import sync_playwright
def test_ui_with_mocked_api_response():
with sync_playwright() as p:
browser = p.chromium.launch(headless=False)
context = browser.new_context()
page = context.new_page()
# Intercept and mock the API
def mock_user_api(route, request):
route.fulfill(
status=200,
content_type="application/json",
body='{"name": "John Doe", "role": "Admin"}'
)
# Register the mock before loading the page
page.route("**/api/user", mock_user_api)
# Navigate to your application
page.goto("https://your-app.com")
# Now you can assert that the UI shows "John Doe" or role
assert page.locator("#username").inner_text() == "John Doe"
browser.close()
- Устранение ошибок
GenAI может помочь в диагностике сбоев, проанализировав логи консоли и сообщения об ошибках, чтобы выявить возможные первопричины и предложить решения.
Промпт: устрани ошибку:
- Новые технологии тестирования
Например, Playwright MCP (Model Context Protocol) – это сервер, который позволяет большим языковым моделям (LLM) и ИИ-агентам автоматизировать взаимодействие с браузером через Playwright. Он интегрируется с Claude Desktop, Cursor IDE и VS Code (через GitHub Copilot), позволяя генерировать тестовые сценарии из промтов на обычном языке. Благодаря использованию таких функций, как режим скриншота, режим просмотра и изоляция контекста с учетом модели, Playwright MCP помогает снизить нестабильность тестирования и ускорить его выполнение.»
