🚀 Первое нагрузочное тестирование: минимум для старта
Хочешь разобраться в нагрузочном тестировании, но не знаешь, с чего начать?
Этот вебинар — идеальная отправная точка. Без лишней теории, с упором на практику.
🔥13 мая в 20:00 мск. приглашаем на открытый вебинар «Минимум для старта: как провести своё первое нагрузочное тестирование»
Что будет:
🔹 выберем удобный для вас инструмент
🔹 определим, какие запросы стоит нагружать
🔹 настроим базовый мониторинг
🔹 разберём, как анализировать полученные результаты
📌 Узнаешь, что делать, если НТ нужно «ещё вчера», и в какие направления копать дальше.
👉 Регистрируйся, чтобы старт был уверенным: https://vk.cc/cLEixW
Занятие приурочено к старту курса “Нагрузочное тестирование”, на котором вы научитесь составлять методику, разрабатывать скрипты, запускать тесты и настраивать мониторинг нагрузочного тестирования.
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576
Хочешь разобраться в нагрузочном тестировании, но не знаешь, с чего начать?
Этот вебинар — идеальная отправная точка. Без лишней теории, с упором на практику.
🔥13 мая в 20:00 мск. приглашаем на открытый вебинар «Минимум для старта: как провести своё первое нагрузочное тестирование»
Что будет:
🔹 выберем удобный для вас инструмент
🔹 определим, какие запросы стоит нагружать
🔹 настроим базовый мониторинг
🔹 разберём, как анализировать полученные результаты
📌 Узнаешь, что делать, если НТ нужно «ещё вчера», и в какие направления копать дальше.
👉 Регистрируйся, чтобы старт был уверенным: https://vk.cc/cLEixW
Занятие приурочено к старту курса “Нагрузочное тестирование”, на котором вы научитесь составлять методику, разрабатывать скрипты, запускать тесты и настраивать мониторинг нагрузочного тестирования.
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576
👍1
Сегодня я покажу, как сэкономить кучу времени при проверке багов.
Сценарий знакомый каждому: разработчик пофиксил баг, ты идёшь перепроверять. А фикса нет. Начинаешь дергать: “Ты точно запушил?”, “А релиз был?”, “А ты на нужной ветке?”
Чтобы не попадать в такие ситуации, я завел себе простой чеклист на проверку фиксов:
1. Убедиться, что билд обновлён (номер версии, дата сборки и т.п.)
2. Проверить, что фиксы действительно попали в сборку (по changelog или по тикету в трекере)
3. Перепроверить окружение (может, ты на staging, а фиксы на dev)
4. Только после этого начинать ручную проверку
Идея в том, чтобы минимизировать потери времени — и свои, и команды.
А как ты проверяешь фиксы? Поделись своим методом в комментариях👇
#qa #testing
Подпишись👉 @testlab_qa
Сценарий знакомый каждому: разработчик пофиксил баг, ты идёшь перепроверять. А фикса нет. Начинаешь дергать: “Ты точно запушил?”, “А релиз был?”, “А ты на нужной ветке?”
Чтобы не попадать в такие ситуации, я завел себе простой чеклист на проверку фиксов:
1. Убедиться, что билд обновлён (номер версии, дата сборки и т.п.)
2. Проверить, что фиксы действительно попали в сборку (по changelog или по тикету в трекере)
3. Перепроверить окружение (может, ты на staging, а фиксы на dev)
4. Только после этого начинать ручную проверку
Идея в том, чтобы минимизировать потери времени — и свои, и команды.
А как ты проверяешь фиксы? Поделись своим методом в комментариях👇
#qa #testing
Подпишись👉 @testlab_qa
👍4
Сегодня покажу вам один простой, но очень полезный подход для ручного тестирования — чек-листы по сценариям использования (use case-based checklists).
Когда у нас нет времени на полноценные тест-кейсы или документация страдает, чек-листы спасают. Но не любые, а ориентированные на реальные сценарии.
Вместо сухих "Открыть страницу – проверить отображение блока", я пишу так:
* Пользователь заходит на сайт впервые: что он должен увидеть?
* Пользователь добавляет товар в корзину и уходит — что произойдёт через 24 часа?
* Пользователь вводит неправильный пароль 3 раза — как реагирует система?
Такой подход:
✅ Помогает мыслить как пользователь
✅ Выявляет граничные и забытые кейсы
✅ Делает тестирование осмысленным, а не механическим
Попробуйте сделать такие чек-листы для своей фичи — удивитесь, сколько нюансов всплывёт.
А вы используете чек-листы или сразу пишете тест-кейсы?
#qa #testing
Подпишись👉 @testlab_qa
Когда у нас нет времени на полноценные тест-кейсы или документация страдает, чек-листы спасают. Но не любые, а ориентированные на реальные сценарии.
Вместо сухих "Открыть страницу – проверить отображение блока", я пишу так:
* Пользователь заходит на сайт впервые: что он должен увидеть?
* Пользователь добавляет товар в корзину и уходит — что произойдёт через 24 часа?
* Пользователь вводит неправильный пароль 3 раза — как реагирует система?
Такой подход:
✅ Помогает мыслить как пользователь
✅ Выявляет граничные и забытые кейсы
✅ Делает тестирование осмысленным, а не механическим
Попробуйте сделать такие чек-листы для своей фичи — удивитесь, сколько нюансов всплывёт.
А вы используете чек-листы или сразу пишете тест-кейсы?
#qa #testing
Подпишись👉 @testlab_qa
👍7
⏳Осталось всего 1 день до закрытия приема заявок на стажировку по направлению QA в Cloud.ru!🚀
Любишь находить ошибки и стремишься к качеству? Тогда эта стажировка для тебя🤩
Старт: июнь 2025
Длительность: 6 месяцев
Формат: очно в офисе в Москве или удаленно
Занятость: от 20 часов в неделю
Cloud.ru — ведущий провайдер облачных сервисов и AI-технологий, предлагающий простые и удобные решения для задач любой сложности: от размещения сайтов до запуска ML-моделей.
Что тебя ждёт?
- оплачиваемая стажировка;
- работа с реальными проектами;
- поддержка наставников и экспертов;
- регулярная обратная связь;
- возможность стать частью команды Cloud.ru.
Кого мы ждём?
✔️ Студентов старших курсов и выпускников.
✔️ Тех, кто знает основы виртуализации и контейнеризации.
✔️ Имеющих опыт работы с linux, bash, python и фреймворками тестирования.
✔️ Готовых работать от 20 часов в неделю.
👉 Успей подать заявку до 16 мая 23:59 мск по ссылке.
Ждём тебя в команде Cloud.ru💪
Любишь находить ошибки и стремишься к качеству? Тогда эта стажировка для тебя🤩
Старт: июнь 2025
Длительность: 6 месяцев
Формат: очно в офисе в Москве или удаленно
Занятость: от 20 часов в неделю
Cloud.ru — ведущий провайдер облачных сервисов и AI-технологий, предлагающий простые и удобные решения для задач любой сложности: от размещения сайтов до запуска ML-моделей.
Что тебя ждёт?
- оплачиваемая стажировка;
- работа с реальными проектами;
- поддержка наставников и экспертов;
- регулярная обратная связь;
- возможность стать частью команды Cloud.ru.
Кого мы ждём?
✔️ Студентов старших курсов и выпускников.
✔️ Тех, кто знает основы виртуализации и контейнеризации.
✔️ Имеющих опыт работы с linux, bash, python и фреймворками тестирования.
✔️ Готовых работать от 20 часов в неделю.
👉 Успей подать заявку до 16 мая 23:59 мск по ссылке.
Ждём тебя в команде Cloud.ru💪
🧪 Сегодня я покажу вам, как можно быстро находить баги даже в самой, казалось бы, идеальной фиче.
Когда фича уже ушла в прод или передаётся на регрессионное тестирование, часто кажется: "Ну тут уже всё проверено". Но именно в этот момент важно включать режим "сомневающегося".
Я использую подход "мышления вразрез". Вот пример:
1. Беру требования и задаю себе вопрос: а что будет, если сделать наоборот?
2. Смотрю на граничные значения — например, минимальные и максимальные допустимые числа, даты и длины строк.
3. Пробую вводить данные, которые не соответствуют ожиданиям, но формально допустимы (например, пробелы, нули, emoji).
4. Проверяю, что произойдёт, если действия пользователя будут слишком быстрыми (клики подряд) или слишком медленными (таймауты).
⚠️ Особенно часто проблемы всплывают в казалось бы простых элементах: кнопках, выпадающих списках, фильтрах.
Мой любимый трюк — тестирование без мышки. Если ты не можешь пользоваться системой с клавиатуры, это почти всегда указывает на проблемы с доступностью и взаимодействием.
Попробуй сегодня потестировать фичу "вразрез". Гарантирую, баг найдёшь 😉
#qa #testing
Подпишись👉 @testlab_qa
Когда фича уже ушла в прод или передаётся на регрессионное тестирование, часто кажется: "Ну тут уже всё проверено". Но именно в этот момент важно включать режим "сомневающегося".
Я использую подход "мышления вразрез". Вот пример:
1. Беру требования и задаю себе вопрос: а что будет, если сделать наоборот?
2. Смотрю на граничные значения — например, минимальные и максимальные допустимые числа, даты и длины строк.
3. Пробую вводить данные, которые не соответствуют ожиданиям, но формально допустимы (например, пробелы, нули, emoji).
4. Проверяю, что произойдёт, если действия пользователя будут слишком быстрыми (клики подряд) или слишком медленными (таймауты).
⚠️ Особенно часто проблемы всплывают в казалось бы простых элементах: кнопках, выпадающих списках, фильтрах.
Мой любимый трюк — тестирование без мышки. Если ты не можешь пользоваться системой с клавиатуры, это почти всегда указывает на проблемы с доступностью и взаимодействием.
Попробуй сегодня потестировать фичу "вразрез". Гарантирую, баг найдёшь 😉
#qa #testing
Подпишись👉 @testlab_qa
👍2
🔧 API-тестирование: оптимальные библиотеки для вашего проекта
Не можете выбрать подходящую библиотеку для автоматизации тестирования API?
⏺ 29 мая в 20.00 мск присоединяйтесь к нашему вебинару и узнайте, как сделать правильный выбор, используя лучшие инструменты для тестирования API !
Что вас ждёт на вебинаре:
– Обзор топовых библиотек для работы с API: Axios, GOT, SuperTest, Fetch API
– Разбор конфигурации и переменных окружения, их грамотное использование
– Создание фикстур для тестов и организация тестового проекта
🔥 После вебинара вы научитесь выбирать правильную библиотеку под конкретную задачу, разберётесь, как настроить тестовую среду, освоите практические навыки организации API-тестирования.
➡️ Регистрация https://vk.cc/cM8AJP
Урок приурочен к старту курса "JavaScript QA Engineer", на котором вы научитесь организовывать комплексное
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576
Не можете выбрать подходящую библиотеку для автоматизации тестирования API?
Что вас ждёт на вебинаре:
– Обзор топовых библиотек для работы с API: Axios, GOT, SuperTest, Fetch API
– Разбор конфигурации и переменных окружения, их грамотное использование
– Создание фикстур для тестов и организация тестового проекта
Урок приурочен к старту курса "JavaScript QA Engineer", на котором вы научитесь организовывать комплексное
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576
Please open Telegram to view this post
VIEW IN TELEGRAM
Media is too big
VIEW IN TELEGRAM
Погладить, нажать, автотест погонять: тесты приложения Apple TV
Даниил Курпаченко, Михаил Гамаюнов
ВКонтакте — платформа из множества сервисов, доступная пользователям на разных девайсах. В их числе и приставки Apple TV, для них мы разрабатываем сервис VK Видео.
Достаточно ли нативных возможностей платформы для комфорта пользователей? Есть ли разница в автоматизации для tvOS и iOS/iPadOS? Как ведут себя автотесты в интерфейсе приложения? На эти и другие вопросы ответили спикеры.
Будет интересно тем, кто тестирует стриминговые сервисы и приложения на разных типах платформ.
источник
#qa #testing
Подпишись👉 @testlab_qa
Даниил Курпаченко, Михаил Гамаюнов
ВКонтакте — платформа из множества сервисов, доступная пользователям на разных девайсах. В их числе и приставки Apple TV, для них мы разрабатываем сервис VK Видео.
Достаточно ли нативных возможностей платформы для комфорта пользователей? Есть ли разница в автоматизации для tvOS и iOS/iPadOS? Как ведут себя автотесты в интерфейсе приложения? На эти и другие вопросы ответили спикеры.
Будет интересно тем, кто тестирует стриминговые сервисы и приложения на разных типах платформ.
источник
#qa #testing
Подпишись👉 @testlab_qa
👍2
Не знаешь на кого пойти учиться ?💥
🛑 Пройди бесплатные онлайн-курсы
🛑 Узнай о самых востребованных профессиях
🛑 Получи уникальную возможность поступить в «Алабуга Политех» после 9 или 11 класса
ПРОЙДИ КУРС ПРЯМО СЕЙЧАС!
ПРОЙДИ КУРС ПРЯМО СЕЙЧАС!
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2❤🔥1🔥1
CSS и XPath — отстой. Секрет стабильных автотестов в test-id
По фактам: почему CSS и XPath — путь в ад, а test-id — спасение. В статье — реальные советы, как договориться с командой, внедрить test-id и писать автотесты, которые не разваливаются каждую пятницу.
https://habr.com/ru/articles/910984/
#qa #testing
Подпишись👉 @testlab_qa
По фактам: почему CSS и XPath — путь в ад, а test-id — спасение. В статье — реальные советы, как договориться с командой, внедрить test-id и писать автотесты, которые не разваливаются каждую пятницу.
https://habr.com/ru/articles/910984/
#qa #testing
Подпишись👉 @testlab_qa
👍2👎1
Сегодня хочу поговорить о том, почему баг-репорты часто игнорируют разработчики и как этого избежать.
Каждый тестировщик сталкивался с ситуацией, когда, казалось бы, критичная ошибка просто зависает в Jira или другом трекере. Почему так происходит? Причин может быть несколько:
* Некорректное или неполное описание бага.
* Отсутствие шагов воспроизведения.
* Неясная или «размытая» ожидаемая/фактическая часть.
* Отсутствие приоритетов и меток.
* Перегруз у разработчиков или у команды.
Что делать?
Я всегда придерживаюсь простого правила: чем проще и структурированнее баг-репорт — тем выше шанс, что им займутся быстро. Использую чек-лист:
1. Четкое название (что, где, когда сломалось).
2. Шаги для воспроизведения (кратко, по пунктам).
3. Ожидаемый результат.
4. Фактический результат (со скриншотами, если есть).
5. Окружение (браузер, версия приложения и т.д.).
6. Приоритет и ярлыки (если есть такая практика).
Попробуй завтра оформить баг именно по такому шаблону — и посмотри, изменится ли скорость его обработки!
Делись своим опытом: часто ли твои баги игнорируют? Как борешься с этим? Пиши в комменты👇
#qa #testing
Подпишись👉 @testlab_qa
Каждый тестировщик сталкивался с ситуацией, когда, казалось бы, критичная ошибка просто зависает в Jira или другом трекере. Почему так происходит? Причин может быть несколько:
* Некорректное или неполное описание бага.
* Отсутствие шагов воспроизведения.
* Неясная или «размытая» ожидаемая/фактическая часть.
* Отсутствие приоритетов и меток.
* Перегруз у разработчиков или у команды.
Что делать?
Я всегда придерживаюсь простого правила: чем проще и структурированнее баг-репорт — тем выше шанс, что им займутся быстро. Использую чек-лист:
1. Четкое название (что, где, когда сломалось).
2. Шаги для воспроизведения (кратко, по пунктам).
3. Ожидаемый результат.
4. Фактический результат (со скриншотами, если есть).
5. Окружение (браузер, версия приложения и т.д.).
6. Приоритет и ярлыки (если есть такая практика).
Попробуй завтра оформить баг именно по такому шаблону — и посмотри, изменится ли скорость его обработки!
Делись своим опытом: часто ли твои баги игнорируют? Как борешься с этим? Пиши в комменты👇
#qa #testing
Подпишись👉 @testlab_qa
👍2❤1
Сегодня хочу поговорить про одну из самых неприятных вещей в автоматизации — flaky-тесты. Вы наверняка сталкивались с ситуацией, когда тесты то проходят, то падают без видимых причин. Это не только портит отчёты, но и подрывает доверие к автоматизации в целом.
Что такое flaky-тесты?
Flaky-тест — тест, результат которого непредсказуем: он проходит один раз, а при повторном запуске падает, хотя код приложения не менялся.
Основные причины flaky-тестов и способы борьбы с ними:
1. Ожидания и тайминги.
* Слишком жёсткие таймауты и неявные ожидания приводят к «гонкам» между тестом и приложением.
* Решение: используйте явные ожидания (Explicit Wait) и проверяйте не просто элемент, а его состояние (видимость, кликабельность).
2. Нестабильные селекторы.
* Тест «теряет» элемент из-за меняющихся атрибутов.
* Решение: отдавайте предпочтение стабильным атрибутам (data-test-id) или XPath с привязкой к контексту, а не позициям.
3. Зависимости между тестами.
* Один тест «готовит» среду для другого, и при сбое первого последующие падают.
* Решение: делайте каждый тест независимым: создавайте и очищайте тестовые данные в рамках одного теста.
4. Параллельные запуски и состояние окружения.
* Тесты конфликтуют друг с другом при одновременном доступе к ресурсам.
* Решение: разделяйте окружения или используйте изолированные тестовые стенды.
5. Нестабильность тестовых данных.
* Используются одни и те же данные, которые меняются в процессе тестирования.
* Решение: генерируйте уникальные данные или делайте «rollback» после каждого теста.
Попробуйте проанализировать свои автотесты по этим пунктам, и, скорее всего, количество флейков снизится в разы. А как вы боретесь с нестабильностью тестов? Делитесь в комментариях!
#qa #testing
Подпишись👉 @testlab_qa
Что такое flaky-тесты?
Flaky-тест — тест, результат которого непредсказуем: он проходит один раз, а при повторном запуске падает, хотя код приложения не менялся.
Основные причины flaky-тестов и способы борьбы с ними:
1. Ожидания и тайминги.
* Слишком жёсткие таймауты и неявные ожидания приводят к «гонкам» между тестом и приложением.
* Решение: используйте явные ожидания (Explicit Wait) и проверяйте не просто элемент, а его состояние (видимость, кликабельность).
2. Нестабильные селекторы.
* Тест «теряет» элемент из-за меняющихся атрибутов.
* Решение: отдавайте предпочтение стабильным атрибутам (data-test-id) или XPath с привязкой к контексту, а не позициям.
3. Зависимости между тестами.
* Один тест «готовит» среду для другого, и при сбое первого последующие падают.
* Решение: делайте каждый тест независимым: создавайте и очищайте тестовые данные в рамках одного теста.
4. Параллельные запуски и состояние окружения.
* Тесты конфликтуют друг с другом при одновременном доступе к ресурсам.
* Решение: разделяйте окружения или используйте изолированные тестовые стенды.
5. Нестабильность тестовых данных.
* Используются одни и те же данные, которые меняются в процессе тестирования.
* Решение: генерируйте уникальные данные или делайте «rollback» после каждого теста.
Попробуйте проанализировать свои автотесты по этим пунктам, и, скорее всего, количество флейков снизится в разы. А как вы боретесь с нестабильностью тестов? Делитесь в комментариях!
#qa #testing
Подпишись👉 @testlab_qa
👍1
Оплачиваемая стажировка и трудоустройство без опыта — ну ничего себе 😳
Всё возможно с Добровольным квалификационным экзаменом! Это бесплатный проект Правительства Москвы, в котором можно принять участие из любого региона России. Это честная альтернатива классическим откликам и реальный шанс получить оффер в компанию мечты.
Как это работает?
1. Пройди тест
Выбираешь профессию, проходишь онлайн-тест. Если набираешь 55 баллов и выше — попадаешь в базу соискателей, которую смотрят рекрутеры топовых компаний.
2. Загрузи резюме
Просто честное резюме. Без пафоса. Работодатели посмотрят на результат теста и примут решение.
3. Получи стажировку или оффер
Это может быть стажировка. Может быть полноценная работа. Список компаний внушительный — среди них Лукойл, Сбер, Норникель, Мосэнерго, Росатом и другие.
Да, это возможно. Даже если ты только начинаешь карьерный путь.
Готов? Жми: dke.moscow
Всё возможно с Добровольным квалификационным экзаменом! Это бесплатный проект Правительства Москвы, в котором можно принять участие из любого региона России. Это честная альтернатива классическим откликам и реальный шанс получить оффер в компанию мечты.
Как это работает?
1. Пройди тест
Выбираешь профессию, проходишь онлайн-тест. Если набираешь 55 баллов и выше — попадаешь в базу соискателей, которую смотрят рекрутеры топовых компаний.
2. Загрузи резюме
Просто честное резюме. Без пафоса. Работодатели посмотрят на результат теста и примут решение.
3. Получи стажировку или оффер
Это может быть стажировка. Может быть полноценная работа. Список компаний внушительный — среди них Лукойл, Сбер, Норникель, Мосэнерго, Росатом и другие.
Да, это возможно. Даже если ты только начинаешь карьерный путь.
Готов? Жми: dke.moscow
❤2
Отказаться от Postman, перейти на Bruno и жить счастливо
Если вы работаете с API и вам надоело вручную протыкивать запросы в Postman, сталкиваться с платными ограничениями и невозможностью нормально делиться коллекциями с командой — вы не одиноки.Хватит это терпеть!
Именно с этими проблемами я столкнулся как системный аналитик в банке. Postman оказался неудобным, закрытым и дорогим инструментом для командной работы. Это заставило меня искать альтернативу, и я нашёл её в бесплатном и открытом API-клиенте Bruno.
В этой статье расскажу, как с ним работать и какие сценарии он закрывает в реальной проектной работе.
https://habr.com/ru/companies/alfa/articles/915940/
#qa #testing
Подпишись👉 @testlab_qa
Если вы работаете с API и вам надоело вручную протыкивать запросы в Postman, сталкиваться с платными ограничениями и невозможностью нормально делиться коллекциями с командой — вы не одиноки.
Именно с этими проблемами я столкнулся как системный аналитик в банке. Postman оказался неудобным, закрытым и дорогим инструментом для командной работы. Это заставило меня искать альтернативу, и я нашёл её в бесплатном и открытом API-клиенте Bruno.
В этой статье расскажу, как с ним работать и какие сценарии он закрывает в реальной проектной работе.
https://habr.com/ru/companies/alfa/articles/915940/
#qa #testing
Подпишись👉 @testlab_qa
👍1
Стратегии упрощения определений шагов 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
Как тестировщик, вы, возможно, слышали о разработке через поведение (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
👍1