Привет! ?

С последнего поста прошло больше года... Были интересные темы, но никак не мог найти в себе силы что-то написать ?

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

Что такое автоматизация десктоп приложений? Выглядит просто: открываешь exe-шник, нажимаешь на кнопки, всё, как на вебе, да? Ведь так? Ну, почти ?

Самое сложное — выбрать фреймворк. ЯП — это второстепенный атрибут, который прилагается к фреймворку.

В ЧЁМ СЛОЖНОСТЬ?

Сложность заключается в том, каким именно способом каждый фреймворк взаимодействует с ОС/приложением.

Давайте разбираться! To be continued...

Привет! Давненько не было постов, пора исправлять ?

? Гигиена авто-тестов ?

Почему я затронул эту тему? Часто сталкиваюсь с проблемой подготовки тестовой среды. Обычно этот процесс отнимает много времени:
? архивация/разархивация образа ОС
? установка ОС
? установка нужных библиотек/приложений
? перенос тестовых файлов и прочее

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

Зачем её соблюдать?
?Тестовые данные могут мешать другим тестам
? Хранилище может переполниться (диск, например)
? Тестовые данные засоряют аналитику
? Среду можно использовать повторно для выполнения новых тестов
? Сокрытие конфиденциальной информации

Итак, план подготовки окружения к тестам и самих тестов к выполнению:
?Подготовь окружение
? выкатилась нужная ветка (или билд)
? подготовлены все данные для тестирования (бд, моки и прочее)
?Почисти данные
? удали все данные, которые задействуются в тесте, например, в тесте создаётся пользователь с Full name: Test Testovy. Перед началом теста удаляем эти данные из БД, чтобы тест точно прошёл
? убедись, что во всех тестах используются разные тестовые данные, (при параллельном запуске тесты могут работать нестабильно)
?Подготовь данные
? выполни preconditions: создай тестовый объект - компанию, урок, юзера и прочее, чтобы тест начинался уже с взаимодействия с данными
?Запусти тесты
?Почисти данные (выполни п.2 повторно)

? Тест-кейсы: делаем их полезными, чтобы не сгореть ?

Привет! Хочу затронуть больную для меня тему. Сейчас я пишу тест-кейсы и мне очень больно, потому что:
?это огромный набор шагов, артефактов и прочего. 5 минут/1 тест-кейс * 40 кейсов...
?кейсы быстро становятся неактуальными
?кейсов становится много. СЛИШКОМ МНОГО
?менеджерам чаще всего важно не качество кейсов, а их количество во время регресса
?не все умеют писать кейсы, читать их часто бывает больно

В общем, думали мы с моим замечательным коллегой Денисом, думали и... решили попробовать гибридный формат! ?

Сначала мы пишем чек-лист для задачи. Потом мы преобразовываем некоторые пункты в полноценные тест-кейсы по критериями ниже:
? кейс является частью приёмочного тестирования (UAT)
? кейс является частью smoke-тестирования

Оставшиеся пункты чек-листа остаются и служат вспомогательным помощником при тестировании

Мы работаем с кейсами следующим образом:
?Пишем чек-лист всех проверок для любой задачи
?Расставляем приоритеты этих проверок по степени их влияния на продукт. Обязательно ставим приоритет и северити в TMS на каждый пункт чек-листа: от тривиального до блокирующего.
Влияние приоритетов на набор тест-кейсов:
1. Blocker - UAT ?
2. Critical - UAT ?
3. Major - Smoke 4. Minor/Trivial - Regression?Отмечаем все Blocker и Critical атрибутом To automate?Преобразовываем все пункты чек-листа с важными приоритетами в полноценные тест-кейсы
?Отправляем кейсы на кейс-ревью

? На что следует обратить внимание в процессе кейс-ревью:
? заполнены все необходимые поля: название и шаги
? тест-кейсы должны быть простыми, читабельными и понятными для любого пользователя
? тест-кейсы имеют необходимые атрибуты: приоритет и северити
? мы используем shared steps везде, где их можно использовать
? все кейсы должны быть связаны с задачами в Jira
? соблюдается структура размещения кейсов
? Blocker и Critical содержат атрибут To automateИспользуя такой формат я горю меньше, чем раньше, а это уже хорошо ?

??? BDD или не BDD? Вот в чём вопрос

Спасибо за вопрос из чатика, отвечаю в большом посте ниже!

https://telegra.ph/BDD-ili-ne-BDD-Vot-v-chyom-vopros-03-28

Огурчики для привлечения внимания (ведь речь пойдёт о Cucumber'е)!

Что-то с новым постом перебрал...

Хочу порекомендовать вакансию у моего друга и наставника Сергея Никифорова, Lead QA в Яндекс-Маркете.

Далее уже будет с его слов ?:

Нужен middle?-Middle+??‍♀️-senior??‍♀️ QA в команду, **проактивный, готовый работать с продуктом в полях.

Продукт: Яндекс-маркет?** , ПО для пунктов выдачи заказов и маркета и постаматы для получения заказов+ весь процессинг доставки к ним.

Где работать: есть офисы в разных точках, но приоритет на человеков из Москвы, БЦ Лотте Плаза прямо в центре, чай, кофе, печеньки, пафосные лица людей из других компаний в лифтах - всё есть.Цель минимум: Я в ПВЗ и мне довольные люди выдают быстро мои вещи без боли и "мы не видим этот заказ"?

Цель максимум: Из-за качественного сервиса в ПВЗ Маркета очередь как в Союзе за колбасой, конкуренты же испытывают проблемы ?

Ссылка на hh.ru для отклика:)Резюме и рекомендации можно закидывать в личные сообщения Сергею, туда же можно заходить по вопросам

Доброй ночи всем, кто не спит ?

Написал статью на Habr по теме сравнения стеков:
https://habr.com/ru/post/724176/

Приятного чтения ?

Отдельное спасибо Саше Ермолаеву, руководителю отдела тестирования, и Татьяне Карпенко, крутому проектному менеджеру, за ревью ❤️

Хабр

Фантастические стеки автоматизации тестирования, и где они обитают. Есть ли среди них лучший?

Всем привет! С вами снова я, Иван Шевелёв, QA Lead в компании Denti.AI. Сегодня хотел обсудить наболевшую тему — лучший стек для автоматизации тестирования. Эта тема о‑о-очень...