Trust no one, even yourself
С таким лозунгом приходится жить любому тестировщику.
📅 Буквально вчера вечером нужно было написать простенький парсер с сайта. Решил выбрать Selenide и по мере написания тестов столкнулся с необработанным исключением:
А мне там нужно было до последнего кликать на "Show more", а потом эта кнопка уже всё, либо могла случайно не прогрузиться за таймаут.
🔄 Пару десятков раз перезапустив тесты, которые идут до падения около 20 минут, а на часах уже 2 часа ночи, я в очередной раз не понял, почему у меня тест падает, не обрабатывая исключения. Для простоты использовал просто catch (Exception e). Каково же было мое удивление, что оказывается все эти ElementNotFoundException и StaleElementException в Selenide, в отличие от Selenium, не наследуются от Exception, а наследуются от Error. А еще и логи непонятно зачем выводят мне исключения Selenium, вместо Selenide.
🚫 Не доверяйте никому, даже логам, даже себе! Всегда всё перепроверяйте.
С таким лозунгом приходится жить любому тестировщику.
📅 Буквально вчера вечером нужно было написать простенький парсер с сайта. Решил выбрать Selenide и по мере написания тестов столкнулся с необработанным исключением:
Caused by: org.openqa.selenium.NoSuchElementException: no such element: Unable to locate element: {"method":"xpath","selector":"//span[text() = 'Show more results']"}
А мне там нужно было до последнего кликать на "Show more", а потом эта кнопка уже всё, либо могла случайно не прогрузиться за таймаут.
🔄 Пару десятков раз перезапустив тесты, которые идут до падения около 20 минут, а на часах уже 2 часа ночи, я в очередной раз не понял, почему у меня тест падает, не обрабатывая исключения. Для простоты использовал просто catch (Exception e). Каково же было мое удивление, что оказывается все эти ElementNotFoundException и StaleElementException в Selenide, в отличие от Selenium, не наследуются от Exception, а наследуются от Error. А еще и логи непонятно зачем выводят мне исключения Selenium, вместо Selenide.
🚫 Не доверяйте никому, даже логам, даже себе! Всегда всё перепроверяйте.
👍14🤯5
Хочу порекомендовать вам подборку телеграм каналов о QA и тестировании
Все каналы прошли экспертный отбор, с прошлого раза в список добавились как и новые авторы, так и убрали заброшенные каналы.
Ссылка на добавление: https://news.1rj.ru/str/addlist/PNmSaWa9ktw2YjRi 🔍
Все каналы прошли экспертный отбор, с прошлого раза в список добавились как и новые авторы, так и убрали заброшенные каналы.
Ссылка на добавление: https://news.1rj.ru/str/addlist/PNmSaWa9ktw2YjRi 🔍
Telegram
QA Лучшее
Anton Duenin invites you to add the folder “QA Лучшее”, which includes 45 chats.
🔥8👍1
Замечали как ваши друзья и коллеги постоянно используют иностранные слова в своей речи, даже не задумываясь об этом? В итоге часто получается такой же диалог как знаменитый мем: Смотря, какой fabric, смотря, сколько details
Вот несколько фраз, которые я подметил за собой за последнее время:
1. Я закомитился за результат.
2. Чекни плиз этот баг.
3. Я пошарю экран.
4. Можем сделать апойнтмент на завтра?
5. Я забукаю отель.
6. Будет вообще дизастер.
Если вы говорите the same, и вам интересно study английский язык, то рекомендую вам подписаться на канал Across English for IT People и прокачать свой английский very well.
#партнерскийпост
Вот несколько фраз, которые я подметил за собой за последнее время:
1. Я закомитился за результат.
2. Чекни плиз этот баг.
3. Я пошарю экран.
4. Можем сделать апойнтмент на завтра?
5. Я забукаю отель.
6. Будет вообще дизастер.
Если вы говорите the same, и вам интересно study английский язык, то рекомендую вам подписаться на канал Across English for IT People и прокачать свой английский very well.
#партнерскийпост
👍9
Рекомендую вам гайд от ментора Надежда Дудник
Мои материалы по теме тоже туда вошли, например:
1. Чек-лист оформления резюме
2. Видео разбора резюме Manual и Automation со мной и рекрутером
3. Плейлист мок собеседования по автоматизации Java на русском
4. Плейлист мок собеседования по автоматизации Java на английском
Также по теме советую посмотреть мои другие посты:
1. Тренажер для отработки вопросов для собеседований
2. Шаблон резюме
3. Как отвечать на вопрос "Расскажите о себе" с помощью STAR и презентация о себе (такое точно впечатлит на собеседовании)
4. Список русскоязычных компаний на мировом рынке и ресурсы для поиска работы в 70 странах
Успехов!
Мои материалы по теме тоже туда вошли, например:
1. Чек-лист оформления резюме
2. Видео разбора резюме Manual и Automation со мной и рекрутером
3. Плейлист мок собеседования по автоматизации Java на русском
4. Плейлист мок собеседования по автоматизации Java на английском
Также по теме советую посмотреть мои другие посты:
1. Тренажер для отработки вопросов для собеседований
2. Шаблон резюме
3. Как отвечать на вопрос "Расскажите о себе" с помощью STAR и презентация о себе (такое точно впечатлит на собеседовании)
4. Список русскоязычных компаний на мировом рынке и ресурсы для поиска работы в 70 странах
Успехов!
🔥18
Forwarded from 📚 ProTestingInfo 🔷 Канал по тестированию 📚
ГАЙД_успешное_резюме,_собеседование_и_поиск_работы_protestinginfo.pdf
2 MB
Сделала супер полезный гайд по составлению резюме, подготовке на собеседование, поиску работы с рекомендациями от себя и коллег. Указала все мной собранные полезные ссылки в одном месте! Уверена, что он должен вам помочь в достижении вашей цели.
👍13
Думаю, будет полезно. Советую записаться! Тоже планирую в записи посмотреть
👍5
Forwarded from QA.GURU | Автоматизация, ручное тестирование, карьера в QA
🦸♂️ На нашем открытом уроке “Запускаем автостесты и Allure отчеты в Gitlab-CI” не хватает только вас!
26 июля в 20:00 по МСК вместе с Александром Котляром, QA Lead, вы научитесь легко запускать автотесты на разных системах и управлять этим процессом из консоли, разберетесь в крутых фичах CI в GitLab и узнаете все лайфхаки по написанию скриптов и использованию Docker в CI. А еще – мы научим вас автоматизировать процессы с помощью триггеров и подключать красивые Allure-отчеты на GitLab Pages.
👉 Регистрация тут: ссылка
🎁 Специальный бонус для участников: приятная цена со скидкой на предстоящий курс!
Ссылка на занятие появится в чате 26 июля в 19:50 МСК.
Не пропустите!
26 июля в 20:00 по МСК вместе с Александром Котляром, QA Lead, вы научитесь легко запускать автотесты на разных системах и управлять этим процессом из консоли, разберетесь в крутых фичах CI в GitLab и узнаете все лайфхаки по написанию скриптов и использованию Docker в CI. А еще – мы научим вас автоматизировать процессы с помощью триггеров и подключать красивые Allure-отчеты на GitLab Pages.
👉 Регистрация тут: ссылка
🎁 Специальный бонус для участников: приятная цена со скидкой на предстоящий курс!
Ссылка на занятие появится в чате 26 июля в 19:50 МСК.
Не пропустите!
❤4🔥1
Наконец-то это свершилось, у QA Guru вышел курс по автоматизации на JS. А то знаю тех кто этого долго ждал, а тут еще и скидки
🔥6
Forwarded from QA.GURU | Автоматизация, ручное тестирование, карьера в QA
🚀 Летняя новинка: крутые технологии JavaScript + Playwright по супер цене!
Готовы погрузиться в мир автоматизированного тестирования с использованием современного стека технологий? Мы запускаем новый курс “Автоматизация тестирования на JavaScript + Playwright”, который изменит ваш подход к QA и научит создавать надежные автоматизированные тесты для веб и мобильных приложений!
💡 Программа курса включает:
• Современные технологии и мобильную автоматизацию: JavaScript, Playwright, Appium, REST, SQL.
• Инфраструктуру и CI/CD: Git/Github/GitLab, Docker/Docker-compose, Jenkins, Selenoid, Browserstack, Allure TestOps.
🔥 Чему вы научитесь?
• Освоите JavaScript и Playwright: научитесь писать код для автоматизированного тестирования веб и мобильных приложений, а также API.
• Познакомитесь с лучшими практиками QA: будете управлять процессами авто-тестирования согласно лучшим практикам в этой сфере.
• Построите инфраструктуру: станете с инфраструктурой на “ты”, научитесь её строить и поддерживать.
🎓 Что нужно, чтобы обучаться на курсе?
• Операционная система: Windows, Mac, Linux.
• 8 ГБ ОЗУ, процессор i3 2,8 GHz или лучше.
• Минимум 8 свободных часов в неделю.
🎭 А Javanoscript/Playwright нужно знать?
Не нужно! На курсе вас ожидают более 20 онлайн-видео занятий и 35 часов лайв кодинга, после которых вы с легкостью напишете дипломный проект!
⌛️ Продолжительность: 3 месяца.
📅 Вводное занятие: 22 августа в 20:00 по МСК.
🔥 До 1 августа включительно на все тарифы курса действует скидка 20%.
➡️ Купить курс со скидкой
💳 На все тарифы курса действует рассрочка на 3/4/6/10 месяцев.
Успейте стать той самой early bird и купить курс по супер-цене!
#JavaScript
#Playwright
Готовы погрузиться в мир автоматизированного тестирования с использованием современного стека технологий? Мы запускаем новый курс “Автоматизация тестирования на JavaScript + Playwright”, который изменит ваш подход к QA и научит создавать надежные автоматизированные тесты для веб и мобильных приложений!
💡 Программа курса включает:
• Современные технологии и мобильную автоматизацию: JavaScript, Playwright, Appium, REST, SQL.
• Инфраструктуру и CI/CD: Git/Github/GitLab, Docker/Docker-compose, Jenkins, Selenoid, Browserstack, Allure TestOps.
🔥 Чему вы научитесь?
• Освоите JavaScript и Playwright: научитесь писать код для автоматизированного тестирования веб и мобильных приложений, а также API.
• Познакомитесь с лучшими практиками QA: будете управлять процессами авто-тестирования согласно лучшим практикам в этой сфере.
• Построите инфраструктуру: станете с инфраструктурой на “ты”, научитесь её строить и поддерживать.
🎓 Что нужно, чтобы обучаться на курсе?
• Операционная система: Windows, Mac, Linux.
• 8 ГБ ОЗУ, процессор i3 2,8 GHz или лучше.
• Минимум 8 свободных часов в неделю.
🎭 А Javanoscript/Playwright нужно знать?
Не нужно! На курсе вас ожидают более 20 онлайн-видео занятий и 35 часов лайв кодинга, после которых вы с легкостью напишете дипломный проект!
⌛️ Продолжительность: 3 месяца.
📅 Вводное занятие: 22 августа в 20:00 по МСК.
🔥 До 1 августа включительно на все тарифы курса действует скидка 20%.
💳 На все тарифы курса действует рассрочка на 3/4/6/10 месяцев.
Успейте стать той самой early bird и купить курс по супер-цене!
#JavaScript
#Playwright
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3
💬 Вопрос от QA сообщества:
🛠 Кейс: рефакторинг существующего фреймворка
1. Создать POC (proof of concept)
🔹 Проверьте, что изменение работает
🔹 Определите, сколько времени уходит на исправление одного теста/класса/метода
2. Анализ POC
🔹 Оцените необходимость и объем изменений
🔹 Соберите статистику, факты и примеры для согласования изменений с командой, менеджментом, клиентом
3. Разбивка изменений
🔹 Если изменения большие, разбейте их на мелкие подзадачи
🔹 Вносите изменения постепенно
Пример: Переход с TestNG на AssertJ, используя SoftAssertions:
🔸 Покрыт один класс автотестами в рамках POC
🔸 Написана инструкция по использованию AssertJ
🔸 Проведено демо, команда согласилась использовать AssertJ
🔸 Договоренность переписывать автотесты на AssertJ при внесении изменений в тесты или при недостатке данных в отчетах
4. Внесение небольших изменений
🔹 Внесите сразу в рамках одной задачи, чтобы было легко отменить при необходимости
5. Обратная совместимость
🔹 Используйте feature flag для возможности включать/выключать новую фичу
🔹 Откатитесь на предыдущий функционал при необходимости
Пример: Добавление предварительной генерации тестовых данных:
🔸 Создайте переменную isTestDataGenerationEnabled со значением false по умолчанию
🔸 Запустите тесты с false, затем с true и сравните результаты
🔸 При появлении новых падений, связанных с новой функциональностью, верните флаг на false и исправьте фреймворк
🔸 После успешного покрытия всех кейсов, установите флаг на true по умолчанию или уберите его
🏗 Кейс: использование шаблонов проектирования
1. Определение проблемы
🔹 Определите, какие части вашего фреймворка требуют улучшения
🔹 Решите, какой шаблон проектирования подойдет для решения проблемы (например, Factory, Singleton, Strategy)
2. Создание POC
🔹 Реализуйте небольшой пример с использованием выбранного шаблона
🔹 Убедитесь, что новый подход решает проблему и не нарушает существующую функциональность
3. Внедрение шаблона
🔹 Постепенно рефакторьте существующий код, используя новый шаблон
🔹 Обучите команду работе с новым шаблоном, предоставив инструкции и примеры
Пример: Использование шаблона Factory для создания объектов тестовых данных:
🔸 Создайте фабрику, которая будет отвечать за создание и настройку объектов
🔸 Проведите демо для команды, объяснив преимущества и особенности нового подхода
🔸 Постепенно заменяйте старый способ создания объектов на новый, используя фабрику
📅 В следующий раз я напишу про переход с одного фреймворка на другой на примере своего опыта.
Может кто-то поделиться своим опытом по рефакторингу тестового фреймворка с использованием шаблонов проектирования или по миграции с одного тестового фреймворка на другой? Как сделать это менее болезненно?
🛠 Кейс: рефакторинг существующего фреймворка
1. Создать POC (proof of concept)
🔹 Проверьте, что изменение работает
🔹 Определите, сколько времени уходит на исправление одного теста/класса/метода
2. Анализ POC
🔹 Оцените необходимость и объем изменений
🔹 Соберите статистику, факты и примеры для согласования изменений с командой, менеджментом, клиентом
3. Разбивка изменений
🔹 Если изменения большие, разбейте их на мелкие подзадачи
🔹 Вносите изменения постепенно
Пример: Переход с TestNG на AssertJ, используя SoftAssertions:
🔸 Покрыт один класс автотестами в рамках POC
🔸 Написана инструкция по использованию AssertJ
🔸 Проведено демо, команда согласилась использовать AssertJ
🔸 Договоренность переписывать автотесты на AssertJ при внесении изменений в тесты или при недостатке данных в отчетах
4. Внесение небольших изменений
🔹 Внесите сразу в рамках одной задачи, чтобы было легко отменить при необходимости
5. Обратная совместимость
🔹 Используйте feature flag для возможности включать/выключать новую фичу
🔹 Откатитесь на предыдущий функционал при необходимости
Пример: Добавление предварительной генерации тестовых данных:
🔸 Создайте переменную isTestDataGenerationEnabled со значением false по умолчанию
🔸 Запустите тесты с false, затем с true и сравните результаты
🔸 При появлении новых падений, связанных с новой функциональностью, верните флаг на false и исправьте фреймворк
🔸 После успешного покрытия всех кейсов, установите флаг на true по умолчанию или уберите его
🏗 Кейс: использование шаблонов проектирования
1. Определение проблемы
🔹 Определите, какие части вашего фреймворка требуют улучшения
🔹 Решите, какой шаблон проектирования подойдет для решения проблемы (например, Factory, Singleton, Strategy)
2. Создание POC
🔹 Реализуйте небольшой пример с использованием выбранного шаблона
🔹 Убедитесь, что новый подход решает проблему и не нарушает существующую функциональность
3. Внедрение шаблона
🔹 Постепенно рефакторьте существующий код, используя новый шаблон
🔹 Обучите команду работе с новым шаблоном, предоставив инструкции и примеры
Пример: Использование шаблона Factory для создания объектов тестовых данных:
🔸 Создайте фабрику, которая будет отвечать за создание и настройку объектов
🔸 Проведите демо для команды, объяснив преимущества и особенности нового подхода
🔸 Постепенно заменяйте старый способ создания объектов на новый, используя фабрику
📅 В следующий раз я напишу про переход с одного фреймворка на другой на примере своего опыта.
👍4🔥4👏1
🔧 Дополнение к предыдущему посту про feature-flag
Понятие "feature flag" (или "feature toggle") используется в разработке программного обеспечения и может применяться в различных контекстах, включая тестовые фреймворки. Feature flag — это техника, которая позволяет включать или отключать функции приложения без необходимости изменения кода и перезапуска приложения, то есть в runtime.
📈 В контексте тестирования и тестовых фреймворков feature flags могут быть полезны для:
1️⃣ Инкрементального развертывания
Постепенное введение новых тестов или изменений в тестовых фреймворках, чтобы проверить их влияние и убедиться в их стабильности перед полным развертыванием.
2️⃣ А/Б тестирования
Включение или отключение определенных функций тестового фреймворка для разных групп тестов или тестируемых компонентов для оценки их влияния на качество и стабильность.
3️⃣ Обратной совместимости
Позволяет разработчикам и тестировщикам легко откатить изменения, если они вызывают проблемы, что особенно важно при внесении значительных изменений в тестовый фреймворк.
💡 Пример использования FeatureFlag в виде системной переменной на Java проекте с использованием библиотеки Owner (также можно использовать property файлы):
🔹 Шаг 1: Добавьте библиотеку Owner в ваш проект.
🔹 Шаг 2: Настройте системную переменную.
Запустите автотесты с системной переменной
Чтобы включить фичу, или без нее, чтобы оставить фичу выключенной.
📝 Итог:
Feature flags позволяют гибко управлять функциями вашего приложения или тестового фреймворка, снижая риски и упрощая процесс развертывания новых функций.
Понятие "feature flag" (или "feature toggle") используется в разработке программного обеспечения и может применяться в различных контекстах, включая тестовые фреймворки. Feature flag — это техника, которая позволяет включать или отключать функции приложения без необходимости изменения кода и перезапуска приложения, то есть в runtime.
📈 В контексте тестирования и тестовых фреймворков feature flags могут быть полезны для:
Постепенное введение новых тестов или изменений в тестовых фреймворках, чтобы проверить их влияние и убедиться в их стабильности перед полным развертыванием.
Включение или отключение определенных функций тестового фреймворка для разных групп тестов или тестируемых компонентов для оценки их влияния на качество и стабильность.
Позволяет разработчикам и тестировщикам легко откатить изменения, если они вызывают проблемы, что особенно важно при внесении значительных изменений в тестовый фреймворк.
💡 Пример использования FeatureFlag в виде системной переменной на Java проекте с использованием библиотеки Owner (также можно использовать property файлы):
import org.aeonbits.owner.Config;
import org.aeonbits.owner.ConfigFactory;
public class FeatureToggleExample {
public interface FeatureConfig extends Config {
@Key("feature.test.data.generation.enabled")
@DefaultValue("false")
boolean isTestDataGenerationEnabled();
}
public static void main(String[] args) {
FeatureConfig config = ConfigFactory.create(FeatureConfig.class);
if (config.isTestDataGenerationEnabled()) {
System.out.println("Test data generation is enabled.");
// Код для генерации тестовых данных
} else {
System.out.println("Test data generation is disabled.");
// Обычный код без генерации тестовых данных
}
}
}
🔹 Шаг 1: Добавьте библиотеку Owner в ваш проект.
<dependency>
<groupId>org.aeonbits.owner</groupId>
<artifactId>owner</artifactId>
<version>1.0.12</version>
</dependency>
🔹 Шаг 2: Настройте системную переменную.
Запустите автотесты с системной переменной
-Dfeature.test.data.generation.enabled=true
Чтобы включить фичу, или без нее, чтобы оставить фичу выключенной.
📝 Итог:
Feature flags позволяют гибко управлять функциями вашего приложения или тестового фреймворка, снижая риски и упрощая процесс развертывания новых функций.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4🔥2
Миграция с одного тестового фреймворка на другой
📌 Кейс 1: Выбор фреймворка
1. Собрать текущие боли и плюсы/минусы текущего фреймворка, если он есть и объем работы
2. Найти фреймворки на рынке 🔍
3. Составить таблицу сравнения по ключевым показателям всего множества фреймворков 📊
🔸 Ключевым может быть, например, что у вас уже есть множество инженеров на Java, вы тестируете в основном UI, вам нужна возможность автоматизации мобилок, и какое-то новомодное решение с AI, чтобы можно было продать фичу руководству.
4. Определите финалистов для детального сравнения 🏁
🔸 Финалистов можно установить, попробовать на практике, запросить trial, демо от создателей и т.д.
5. Составьте итоговый отчет с цифрами: стоимостью (покупки, внедрения, использования, поддержки тестов и т.д.), рисками (что если фреймворк не взлетит, инженеры не обучатся, повысится стоимость и т.д.). 📑
6. Получите разрешение на использование, согласуйте план работ и внедряйте ✅
🔗 Пример: сравнение Playwright vs Cypress -> см. ссылку на Google Sheet таблицу.
Мой личный кейс:
📌 Кейс 1: Выбор фреймворка
1. Собрать текущие боли и плюсы/минусы текущего фреймворка, если он есть и объем работы
2. Найти фреймворки на рынке 🔍
3. Составить таблицу сравнения по ключевым показателям всего множества фреймворков 📊
🔸 Ключевым может быть, например, что у вас уже есть множество инженеров на Java, вы тестируете в основном UI, вам нужна возможность автоматизации мобилок, и какое-то новомодное решение с AI, чтобы можно было продать фичу руководству.
4. Определите финалистов для детального сравнения 🏁
🔸 Финалистов можно установить, попробовать на практике, запросить trial, демо от создателей и т.д.
5. Составьте итоговый отчет с цифрами: стоимостью (покупки, внедрения, использования, поддержки тестов и т.д.), рисками (что если фреймворк не взлетит, инженеры не обучатся, повысится стоимость и т.д.). 📑
6. Получите разрешение на использование, согласуйте план работ и внедряйте ✅
🔗 Пример: сравнение Playwright vs Cypress -> см. ссылку на Google Sheet таблицу.
Мой личный кейс:
Мне нужно было сравнить обычные фреймворки с no-code/low-code решениями. В рамках discovery-фазы я составлял таблицы сравнений, а когда мы определились с финалистами, попробовал реализовать наши основные тестовые сценарии на двух фреймворках: Playwright и Functionize. Менеджмент даже уговорил разработчиков Functionize провести демо и тренинги, а также исправить возникающие дефекты.
История закончилась трагично: мне Functionize не понравился, но менеджмент все равно купил его и начал внедрение 🥲. В итоге, из-за этого инструмента я решил уйти с проекта.
Google Docs
Playwright vs Cypress
🔥4👍2
🚀 Кейс 2: Шаги по миграции тестового фреймворка
1. Создание базовой инфраструктуры 📦
🔸 Настройка нового фреймворка: Установите и настройте все необходимые инструменты и зависимости.
🔸 Написание базовых тестов: Создайте несколько простых тестов для проверки работоспособности нового фреймворка.
2. Идентификация тестовых наборов 🔍
🔸 Определите приоритеты: Нужно понять, какие тестовые наборы нужно перенести в первую очередь.
🔸 Решение о текущих тестах: Важно решить, что будет с текущими тестами. Будете ли вы их временно запускать и поддерживать? Или вообще их не переносить, законсервировать и использовать новый фреймворк только для новых тестов?
3. Тренинги и документация 📚
🔸 Проведение тренингов: Если нужно, проведите тренинги команды для эффективной работы с новым фреймворком.
🔸 Создание документации: Опишите документацию, гайдлайны по работе и типовые кейсы для команды.
4. Мониторинг и показатели 📊
🔸 Установите метрики: У вас должны быть показатели по срокам перехода и качеству тестов на новом фреймворке, которые нужно соблюдать.
5. Пошаговая миграция 🛠
🔸 Перенос общих утилит и хелперов: Начните с переноса утилит и вспомогательных классов, которые используются в ваших тестах.
🔸 Пошаговая миграция тестов: Переносите тесты поэтапно, начиная с наиболее простых. Тестируйте каждый этап миграции.
6. Подготовка инфраструктуры 🧑💻
🔸 Подготовьте фреймворк: До переноса тестов или в параллель нужно также подготовить фреймворк для полноценной работы, например, проверить интеграцию с CI/CD
✅ Валидация и тестирование
🔸 Сравнение результатов: Сравните результаты тестов на старом и новом фреймворке, убедитесь, что они совпадают. А новый фреймворк в чем то лучше, иначе зачем было его внедрять 🤔
🔸 Рефакторинг: После успешной миграции проведите рефакторинг, чтобы оптимизировать тесты и код.
🔄 Постоянное улучшение
🔸 Обратная связь: Собирайте отзывы от команды, выявляйте проблемы и решайте их.
🔸 Мониторинг и поддержка: Регулярно обновляйте фреймворк и следите за его развитием.
Мой личный кейс:
✨ Пишите в комментариях про свой опыт по рефакторингу тестового фреймворка или по миграции с одного тестового фреймворка на другой.
❓ Или если у вас есть вопросы или сомнения по смене фреймворка - смело задавайте!
1. Создание базовой инфраструктуры 📦
🔸 Настройка нового фреймворка: Установите и настройте все необходимые инструменты и зависимости.
🔸 Написание базовых тестов: Создайте несколько простых тестов для проверки работоспособности нового фреймворка.
2. Идентификация тестовых наборов 🔍
🔸 Определите приоритеты: Нужно понять, какие тестовые наборы нужно перенести в первую очередь.
🔸 Решение о текущих тестах: Важно решить, что будет с текущими тестами. Будете ли вы их временно запускать и поддерживать? Или вообще их не переносить, законсервировать и использовать новый фреймворк только для новых тестов?
3. Тренинги и документация 📚
🔸 Проведение тренингов: Если нужно, проведите тренинги команды для эффективной работы с новым фреймворком.
🔸 Создание документации: Опишите документацию, гайдлайны по работе и типовые кейсы для команды.
4. Мониторинг и показатели 📊
🔸 Установите метрики: У вас должны быть показатели по срокам перехода и качеству тестов на новом фреймворке, которые нужно соблюдать.
5. Пошаговая миграция 🛠
🔸 Перенос общих утилит и хелперов: Начните с переноса утилит и вспомогательных классов, которые используются в ваших тестах.
🔸 Пошаговая миграция тестов: Переносите тесты поэтапно, начиная с наиболее простых. Тестируйте каждый этап миграции.
6. Подготовка инфраструктуры 🧑💻
🔸 Подготовьте фреймворк: До переноса тестов или в параллель нужно также подготовить фреймворк для полноценной работы, например, проверить интеграцию с CI/CD
✅ Валидация и тестирование
🔸 Сравнение результатов: Сравните результаты тестов на старом и новом фреймворке, убедитесь, что они совпадают. А новый фреймворк в чем то лучше, иначе зачем было его внедрять 🤔
🔸 Рефакторинг: После успешной миграции проведите рефакторинг, чтобы оптимизировать тесты и код.
🔄 Постоянное улучшение
🔸 Обратная связь: Собирайте отзывы от команды, выявляйте проблемы и решайте их.
🔸 Мониторинг и поддержка: Регулярно обновляйте фреймворк и следите за его развитием.
Мой личный кейс:
Мне нужно было перейти от старого фреймворка на Java 8/11 с BDD (JBehave) на что-то более новое и удобное. Заказчику было легко продать тот же BDD, а вот многие инженеры, наоборот, не любят BDD подход. Моим решением было создать базовый фреймворк на Rest Assured + BDD (Cucumber) сначала для API тестирования. Базовый фреймворк включал утилиты, хелперы и базовые шаги. Эту библиотеку можно было добавить как зависимость и переиспользовать базовые шаги как BDD методы, так и обычные JUnit/TestNG, что позволило решить проблему с противниками BDD подхода.
После этого я реализовал основные сценарии для одного из новых проектов, написал гайдлайны, собрал команду и обучил ее работе с фреймворком. В дальнейшем я практически не занимался самими автотестами, а больше работал как SDET, улучшая фреймворк, реализуя новые идеи, исправляя дефекты и внедряя фреймворк в других командах. В конечном итоге фреймворком пользовались порядка 10 инженеров из 5 команд.
✨ Пишите в комментариях про свой опыт по рефакторингу тестового фреймворка или по миграции с одного тестового фреймворка на другой.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥4
📢 6 сентября я выступаю на круглом столе в рамках онлайн-конференции Podlodka QA Crew 🚀
🎯 Тема сезона — «Развитие QA-инженера». А я, как инженер с более чем 2-летним опытом работы за рубежом (🇵🇱 Польша, 🇷🇸 Сербия), расскажу о специфике развития QA-инженера за границей на круглом столе с другими инженерами.
🗓 Мое выступление состоится 6 сентября с 19:00 до 20:30 (Мск). Сама конференция Podlodka QA Crew стартует 2 сентября.
🎟 А еще у меня есть приятный бонус для вас — разыграю один билет на конференцию среди подписчиков моего канала! Чтобы принять участие, напишите в комментариях:
1️⃣ Что бы вы хотели услышать в моем докладе?
2️⃣ Либо какой еще доклад из списка вас интересует?
🥇 Победителя определю и свяжусь с ним 26 августа. А всем остальным можно еще будет успеть купить билеты по early bird скидке до ночи 27 августа.
Буду рад вас видеть на онлайн-конференции! 🌟
🎯 Тема сезона — «Развитие QA-инженера». А я, как инженер с более чем 2-летним опытом работы за рубежом (🇵🇱 Польша, 🇷🇸 Сербия), расскажу о специфике развития QA-инженера за границей на круглом столе с другими инженерами.
🗓 Мое выступление состоится 6 сентября с 19:00 до 20:30 (Мск). Сама конференция Podlodka QA Crew стартует 2 сентября.
🎟 А еще у меня есть приятный бонус для вас — разыграю один билет на конференцию среди подписчиков моего канала! Чтобы принять участие, напишите в комментариях:
1️⃣ Что бы вы хотели услышать в моем докладе?
2️⃣ Либо какой еще доклад из списка вас интересует?
🥇 Победителя определю и свяжусь с ним 26 августа. А всем остальным можно еще будет успеть купить билеты по early bird скидке до ночи 27 августа.
Буду рад вас видеть на онлайн-конференции! 🌟
1🔥16