Библиотека тестировщика

Сегодня хочу поговорить про одну из самых неприятных вещей в автоматизации — flaky-тесты. Вы наверняка сталкивались с ситуацией, когда тесты то проходят, то падают без видимых причин. Это не только портит отчёты, но и подрывает доверие к автоматизации в целом. Что такое flaky-тесты? Flaky-тест — тест, результат которого непредсказуем: он проходит один раз, а при повторном запуске падает, хотя код приложения не менялся. Основные причины flaky-тестов и способы борьбы с ними: 1. Ожидания и тайминги. * Слишком жёсткие таймауты и неявные ожидания приводят к «гонкам» между тестом и приложением. * Решение: используйте явные ожидания (Explicit Wait) и проверяйте не просто элемент, а его состояние (видимость, кликабельность). 2. Нестабильные селекторы. * Тест «теряет» элемент из-за меняющихся атрибутов. * Решение: отдавайте предпочтение стабильным атрибутам (data-test-id) или XPath с привязкой к контексту, а не позициям. 3. Зависимости между тестами. * Один тест «готовит» среду для другого, и при сбое первого последующие падают. * Решение: делайте каждый тест независимым: создавайте и очищайте тестовые данные в рамках одного теста. 4. Параллельные запуски и состояние окружения. * Тесты конфликтуют друг с другом при одновременном доступе к ресурсам. * Решение: разделяйте окружения или используйте изолированные тестовые стенды. 5. Нестабильность тестовых данных. * Используются одни и те же данные, которые меняются в процессе тестирования. * Решение: генерируйте уникальные данные или делайте «rollback» после каждого теста. Попробуйте проанализировать свои автотесты по этим пунктам, и, скорее всего, количество флейков снизится в разы. А как вы боретесь с нестабильностью тестов? Делитесь в комментариях! #qa #testing Подпишись👉 @testlab_qa

🔧 Postman + JavaScript: быстрый старт в автоматизированном тестировании Хотите научиться уверенно тестировать API и запускать автоматизированные проверки с нуля? ⚡️19.06 апреля в 20.00 мск. приходите на бесплатный вебинар и разберите пошагово, как использовать Postman и JavaScript для автоматизации тестирования! На вебинаре вы узнаете: – Как создавать API-запросы в Postman с нуля – Как писать автотесты и работать с jwt-авторизацией – Как использовать коллекции, переменные и окружения – Как писать скрипты на JavaScript прямо в Postman Итог — вы: 💚Освоите автоматизацию в Postman 💚Научитесь работать с переменными и скриптами 💚 Поймёте лучшие практики API-тестирования 🚀Сделайте уверенный шаг в автоматизацию API! ➡️ Регистрация https://vk.cc/cMTNFa Урок приурочен к старту курса "JavaScript QA Engineer", на котором вы научитесь организовывать комплексное автоматизированное тестирование веб-приложений. Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

😂 #qa #testing Подпишись👉 @testlab_qa

Стратегии упрощения определений шагов BDD Как тестировщик, вы, возможно, слышали о разработке через поведение (BDD) и окружающих ее спорах о том, что это, как это использовать и для чего. Вне зависимости от личного мнения о предмете, нельзя отрицать, что инструменты автоматизации тестирования, поддерживающие BDD, уже с нами. Они широко распространены в отрасли, и пока не собираются никуда уходить. В ходе моей карьеры значительная часть моей тест-автоматизации включала применение какого-либо BDD-фреймворка – например, инструменты вроде Cucumber или JBehave. Как человек, который программирует, я всегда интересовался рефакторингом, сокращающим количество стандартного или дублирующего кода – кода становится меньше, и он становится понятнее. Это включает и сокращение стандартного кода в методах определения шагов и прочем связующем коде. Как их упростить? Или вообще от них избавиться? Возможно, вы недоумеваете, что такое связующий код. С одной стороны, он состоит из методов определения шагов – это методы, говорящие BDD-фреймворку автоматизации, что запускать, столкнувшись с шагом Given, When или Then в фича-файле Gherkin. По сути эти методы склеивают части текстовых Gherkin-файлов в выполнимый код тест-автоматизации. С другой стороны, это могут быть хуки – методы, выполняющиеся до или после фич/сценариев Gherkin. В этой статье я расскажу о различных способов упрощения связующего кода и его интеграции в язык ваших автотестов. В примерах я использую Cucumber и Java-код. https://www.ministryoftesting.com/articles/strategies-to-simplify-your-bdd-step-definitions #qa #testing Подпишись👉 @testlab_qa

💯 #qa #testing Подпишись👉 @testlab_qa

Отказаться от Postman, перейти на Bruno и жить счастливо Если вы работаете с API и вам надоело вручную протыкивать запросы в Postman, сталкиваться с платными ограничениями и невозможностью нормально делиться коллекциями с командой — вы не одиноки. Хватит это терпеть! Именно с этими проблемами я столкнулся как системный аналитик в банке. Postman оказался неудобным, закрытым и дорогим инструментом для командной работы. Это заставило меня искать альтернативу, и я нашёл её в бесплатном и открытом API-клиенте Bruno. В этой статье расскажу, как с ним работать и какие сценарии он закрывает в реальной проектной работе. https://habr.com/ru/companies/alfa/articles/915940/ #qa #testing Подпишись👉 @testlab_qa

Сегодня хочу рассказать про баги, которые «убегают» в прод, и почему это не всегда только вина тестировщика. Очень часто вижу, как в компаниях после релиза, где вылез критичный баг, начинается «охота на ведьм». Виноват тестировщик — не нашёл, не проверил, недоглядел. Но на практике баги попадают в прод по трём основным причинам: 1. Отсутствие чётких требований. Если спецификаций нет или они постоянно меняются, тестировщик проверяет «на глаз», а не по чётким критериям. Итог — разные ожидания у QA и у заказчика. 2. Сжатые сроки. Классика: дедлайн вчера, тестирование в два раза короче запланированного, при этом проверок меньше, автоматизация не прогоняется полностью. 3. Сложность воспроизведения. Есть баги, которые проявляются только при определённых нагрузках, конфигурациях или после долгой работы приложения. Их реально трудно найти до релиза. Поэтому важно не искать виноватого, а разбирать причины: - Улучшить требования. - Планировать время на тестирование. - Инвестировать в автоматизацию и нагрузочные проверки. А ещё полезно после каждого релиза проводить post-mortem — разбор инцидента без обвинений. Это помогает команде учиться, а не бояться. #qa #testing Подпишись👉 @testlab_qa

🚀 Первый нагрузочный тест в Apache Jmeter 📊 🔥 14 августа в 20:00 мск — открытый вебинар в OTUS. Что мы рассмотрим: – Почему Apache Jmeter — один из самых популярных инструментов для нагрузочного тестирования? – Как создать и настроить HTTPS-скрипт для тестирования? – Как провести итерацию нагрузочного тестирования и правильно анализировать результаты? – Как генерировать информативные HTML-отчёты для лучшего понимания производительности системы? 🎓После вебинара вы: ✔️ Освоите базовые принципы работы с Apache Jmeter ✔️ Научитесь создавать и отлаживать HTTPS-скрипты ✔️ Поймёте, как проводить нагрузочные тесты и что анализировать в отчётах ✔️ Сможете генерировать отчёты, которые помогут в улучшении производительности ваших веб-ресурсов Этот вебинар будет полезен всем, кто интересуется QA и тестированием, а также тем, кто хочет улучшить производительность своих веб-сайтов и приложений. Не пропустите! 🔥 👉 Регистрация https://vk.cc/cOvnn9 Занятие приурочено к старту курса “Нагрузочное тестирование”, на котором вы научитесь составлять методику, разрабатывать скрипты, запускать тесты и настраивать мониторинг нагрузочного тестирования. Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

Сейчас покажу приём, который спасает время при регрессионном тестировании больших проектов. Ситуация: Проект огромный, релизы частые, тест-кейсов — сотни. Каждый регресс гонять вручную — невозможно, автоматизация есть, но покрывает не всё. Решение — приоритизация тестов через "smoke + risk-based" подход. Как я делаю: 1. Составляю smoke-набор — минимальный список тестов, который проверяет, что система вообще жива (логин, основные функции, критичные интеграции). 2. Выделяю модули с высоким риском изменений — туда иду с расширенным тестированием. 3. Использую свежий git log — смотрю, какие файлы менялись, и беру тесты, связанные с этими зонами. 4. Подключаю автоматизацию на всё, что уже покрыто автотестами, и вручную иду только в непокрытые части. Плюс: - Быстрее получаем обратную связь о состоянии системы. - Меньше тратим время на очевидно стабильные зоны. - Концентрируем усилия там, где вероятность бага максимальна. Этот подход особенно полезен в стартапах или на проектах с частыми деплоями, где времени на полный регресс просто нет. А вы в регрессе — бежите всё подряд или используете приоритизацию? #qa #testing Подпишись👉 @testlab_qa

#qa #testing Подпишись👉 @testlab_qa