QAA Spells — Mastering the Art of Automation

Недавно открыл для себя очень банальную вещь, которая помогла нам отказаться от полного регресса на проекте — полу-автоматическое тестирование 😋 🗣Краткий экскурс: наше приложение (расширение) интегрируется с большим количеством других приложений и автоматизирует работу юзера В идеале — перед каждым релизом делать полный регресс во всех системах, с которыми мы интегрируемся В реальности — делать это, конечно же, мы не будем 🤣 😱 Я пробовал писать авто-тесты на чужие сервисы. Всё шло даже очень бодро, но случился нюанс: учётка, которую нам выдали для тестирования, благополучно улетела в бан из-за «подозрительной активности». После этого идея была успешно заброшена на год Спасением стало подключение к текущей сессии браузера с помощью Playwright — Connect over CDP Банально запускаем браузер специальной командой, указывая открытый порт и... подключаемся к этом браузеру! Заранее авторизуемся, делаем все прекондишены руками и не боимся получить бан, проверено Все настройки, расширения, куки сохраняются после перезапуска — для меня это было очень важно 📶 Важно соблюдать принцип восстановление системы после запуска каждого теста. Во время дебага тест может упасть в любом моменте сценария. Чтобы не закрывать какие-то окна руками — нужно хорошо продумать, как тест сам вернётся в начальное состояние, чтобы дебаг был быстрее

Продолжаем углубляться туда, откуда больше нет выхода... 🚬 🛏 Какие бывают фреймворки? 🔸 RPA фреймворки: Robot framework Роботизированная автоматизация процессов (RPA) используется для автоматизации повторяющихся и рутинных задач, которые обычно выполняются вручную. Она позволяет программным роботам (ботам) имитировать действия человека при взаимодействии с различными цифровыми системами и приложениями. Звучит хорошо, выглядит хорошо, красиво смотрится в коде (привет, BDD), но есть нюансы: ⏺Роботы замечательно подходят только для простых приложений с очевидной логикой уровня пет-проектов: заметки, калькулятор, todo-lists и прочее ⏺Роботы плохо дружат с локаторами в DOM'е приложений, если он не имеет нужного атрибута для робота, то... adiós! ⏺Роботы могут взаимодействовать с ОС, но есть нюанс. Только с помощью других фреймворков. Из коробки робот может взаимодействовать только с текущим приложением 🔸 Image recognition фреймворки: Sikulix Распознавание скриншотов — модно и молодёжно. В текущий момент времени делается скриншот экрана и AI парсит почти всё, что происходит на экране. ⏺Проблема в том, что распознавание картинок работает очень долго, сложно автоматизируется и тащит кучу библиотек (например, модели). Главный минус — это стабильность, точнее её отсутствие. Неправильно распознавание экрана влечёт за собой неправильное выполнение тестов. НО! 👀 Думаю, что будущее автоматизации десктопа за этими фреймворками, но пока еще рано 🔸 Тестовые фреймворки: Appium, WinAppDriver, Pywinauto, FlaUI, Winium Думаю, что этот раздел достоин отдельного поста, но кратко опишу в текущем. Все фреймворки из списка действительно делают то, для чего они создавались — автоматизируют тестирование. Что-то удобнее, что-то быстрее, что-то универсальнее, что-то используется только потому, что не получится использовать другое Выбор достаточно сложный, т.к. под каждый проект подойдут свои решения. Причём фреймворки не взаимозаменяемые, начать с одного фреймворка и перейти на другой почти невозможно. Каждый из них построен на своей платформе и даёт разные инструменты для работы с процессами 🔸 UI рекордеры, Nocode решения и прочее... Мы рассматривать, конечно же, не будем 😂 😱 Итак, мы подошли к самому главному! Что общего между всеми возможными подходами к автоматизации тестирования на десктопе? Общими в данном случае могут быть только... проблемы ❌ всё заброшено и не обновляется. То, что мертво, умереть не может ❌ нулевая база знаний и нулевое комьюнити. Здесь нет энтузиастов. Это пустынное поле. IT-Сахара Какой итог? Десктоп — это весело. Иногда 😢

Привет! 🎩 С последнего поста прошло больше года... Были интересные темы, но никак не мог найти в себе силы что-то написать 🚬 Так вышло, что в прошлом году я неожиданно погрузился в тестирование десктопа, что заставило меня радикально пересмотреть весь свой опыт и образ мышления в автоматизации Что такое автоматизация десктоп приложений? Выглядит просто: открываешь exe-шник, нажимаешь на кнопки, всё, как на вебе, да? Ведь так? Ну, почти 🔫 Самое сложное — выбрать фреймворк. ЯП — это второстепенный атрибут, который прилагается к фреймворку. В ЧЁМ СЛОЖНОСТЬ? Сложность заключается в том, каким именно способом каждый фреймворк взаимодействует с ОС/приложением. Давайте разбираться! To be continued...

Небольшое пояснение к плану выше Зачем чистить данные, если БД/ветка свежие? 💬 Слепок данных мог получиться с тестовыми данными 💬 Какой-то тест может случайно использовать данные из другого (копипаста, к примеру), при его запуске он может упасть, т.к. данные уже существуют в БД Зачем чистить данные 2 раза? Представим ситуацию, что нельзя построить тесты без уникальных данных. Если тест не дошёл до конца, то данные он не почистит, поэтому правило хорошего тона: почисти данные до теста и после, хуже и дольше от этого никому не станет, но добавит буст к стабильности

Привет! Давненько не было постов, пора исправлять 📞 😴 Гигиена авто-тестов 😴 Почему я затронул эту тему? Часто сталкиваюсь с проблемой подготовки тестовой среды. Обычно этот процесс отнимает много времени: 🔊 архивация/разархивация образа ОС 🔊 установка ОС 🔊 установка нужных библиотек/приложений 🔊 перенос тестовых файлов и прочее Сборка идеального образа с нуля — это процесс, который может отнять месяцы работы. Одно дело собрать образ, другое — сделать так, чтобы тесты во время их выполнения не ухудшили работу образа. В этом нам поможет соблюдение гигиены во время выполнения тестов. Зачем её соблюдать? 🔄Тестовые данные могут мешать другим тестам 🔄 Хранилище может переполниться (диск, например) 🔄 Тестовые данные засоряют аналитику 🔄 Среду можно использовать повторно для выполнения новых тестов 🔄 Сокрытие конфиденциальной информации Итак, план подготовки окружения к тестам и самих тестов к выполнению: 😀Подготовь окружение 💬 выкатилась нужная ветка (или билд) 💬 подготовлены все данные для тестирования (бд, моки и прочее) 😀Почисти данные 💬 удали все данные, которые задействуются в тесте, например, в тесте создаётся пользователь с 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/ Приятного чтения 🥔 Отдельное спасибо Саше Ермолаеву, руководителю отдела тестирования, и Татьяне Карпенко, крутому проектному менеджеру, за ревью ❤️

Всем привет! Я немного успел исписаться, поэтому сделал небольшой перерыв. Но сейчас нашёл в себе силы рассмотреть какую-то из тем ниже. Что вам было бы интересно? 🥰 (опрос ниже)

Хорошие тесты в пайплайне — какие они? Загадка от Жака Фреско 🤨 Отчасти это продолжение темы с докером. От идеально собранного образа толку не сильно много, весь смысл в запуске тестов на нужные триггеры. Когда лучше запускать тесты? 😀на каждый коммит 😀на каждый МР 😀после создания RC-билда (который будет тестироваться руками со всеми задачами из релиза) 😀пред-деплой 😀пост-деплой 😀по расписанию 😀На каждый коммит: юниты, интеграционные, функциональные API-тесты, максимум — e2e (UAT) 😀На каждый МР: юниты, интеграционные, e2e (UAT) 😀После создания RC-билда: e2e (full regression) 😀Пред-деплой: функциональные API-тесты, e2e (uat), т.к. багфиксы могли сломать критичный функционал 😀Пост-деплой: e2e (uat), проверяем, что всё корректно собралось 😀По расписанию: любой сьют по необходимости, в основном — e2e по каким-то определенным компонентам системы (или проектам) В целом, принцип следующий: на самом раннем этапе — быстрые и эффективные проверки, на среднем — всего и побольше, на последнем — только по верхам, чтобы убедиться, что основные сценарии работают 🍷

🏆 Трофей тестирования По запросу сэра Туана дополню пост про пирамиду тестирования. Есть ещё один слой, как правило самый низкоуровневый — статическое тестирование. В 2023 году сложно выделить его в отдельный этап, т.к. его использование уже подразумевается инженерами (в том числе и автоматизаторами) Что можно отнести к статическому тестированию? 😀линтеры 😀тулзы для форматирования кода 😀проверки типизации 😀компилятор Какие ошибки можем найти? 😀неиспользуемый код 😀ошибки в синтаксисе кода 😀плохие паттерны в коде (например, return await подсветится красным) 😀дублирование кода Основная цель таких тестов — поимка багов еще до запуска кода. Сложно сказать, сколько должно быть таких тестов, обычно мы об этом не задумываемся, т.к. за нас это всё делают инструменты: IDE, среда выполнения, компилятор и прочие тулзы. Но подразумевается, что их будет меньше, чем юнит-тестов. 😀Данный вид тестов по большей части появляется автоматически во время использования инструментов выше. Максимум, что требуется с нашей стороны — это настроить линтер, правила, правила оформления кода и прочие штуки UPD: в отличии от пирамиды, в трофее больше внимания уделяется интеграционным тестам

Dockerfile для тестов 💡 Теория — это конечно хорошо, но лучше закреплять её на практике. Dockerfile — это файл, в котором содержится набор инструкций для создания докер-образа. Т.е. в нём мы указываем: 😀FROM: image — базовый образ (очень грубо говоря ядро, которое будет запускать наш код — nodejs/python/linux и пр.) 😀WORKDIR /tests — директория, в которой будет происходить наша магия. Ядро всегда имеет кучу директорий, поэтому для удобства лучше в нём создавать папочку /tests 😀COPY file|directory — файлы наших тестов, которые копируем в образ (и побочные файлы: PO, config и всё, что используется в рантайме тестов) 😀ENV var="value" — переменная окружения 😀RUN command — команды, которые нужно запустить при сборке образа. Например, yarn install или pip install -r requirements, чтобы установить библиотеки (это не совсем оптимально, но для старта более чем) 😀ENRTYPOINT [command, params] — команда, которая будет выполняться при запуске образа А теперь на примере: FROM FROM node:18.14.2-alpine3.16 -- базовый образ на основе nodejs WORKDIR /tests -- определяем директорию для тестов tests COPY ["tsconfig.json", "start.sh", "./"] -- копируем файлы из корня в ./ (т.е. в наш WORKDIR) COPY test /tests -- копируем директорию test в наш WORKDIR /tests ENV SUITE="" ENV ENV="" ENV THREADS="" -- определяем переменные окружения, которые сами задаём при запуске образа RUN yarn install -- выполняем установку зависимостей (загрузку node_modules) ENTRYPOINT ["node", "config.js"] -- при старте образа выполняется команда node config.js Для начала образ нужно собрать: docker build --rm -f deploy/Dockerfile -t e2e-tests --platform linux/amd64 . 😀--rm удаляет контейнер после успешной сборки 😀--f определяет, в какой директории лежит Dockerfile, в моём случае deploy/Dockerfile 😀-t e2e-tests — название тега образа, грубо говоря, название образа --platform linux/amd64--platform linux/amd64 — этот параметр нужен для того, чтобы образ можно было запускать на разных платформах (по крайней мере актуально для M1) 😀. — директория, в которой будет произведена сборка (т.е. текущая) После успешной сборки образ можно запустить: docker run -e SUITE=smoke -e END=prod -e THREADS=3 e2e-tests После этого контейнер запустится вместе с тестами 🖐 К сожалению, это только базовый пример, в реальности может быть куча нюансов: не хватает каких-то библиотек в базовом образе для установки зависимостей или запуска тестов, конфиг должен смотреть на оркестратор браузеров (т.к. браузеры запускаются в другом контейнере, не текущем) и прочее. Часто фреймворки могут облегчить вам жизнь следующей докой, где сборка готова из коробки (часто даже с запуском драйверов браузеров в нём), вот пример: https://playwright.dev/docs/docker Полезные ссылки: https://tproger.ru/translations/top-10-docker-commands/ https://www.andreyolegovich.ru/dvps/docker/build/ https://habr.com/ru/company/ruvds/blog/439980/ Если будут уточняющие вопросы — пишите 👇🏻

И да, кстати, большое спасибо всем, кто пришёл в этот канал за чем-то новым или просто поддержать ❤️ Никогда бы не подумал, что мой опыт, личные мысли и наблюдения могут быть кому-то интересны и полезны, а сейчас нас уже больше 100 человек. Надеюсь, что дальше будет больше и круче (а по-другому просто никак 😎)!

Docker для автоматизатора тестирования — как, зачем и почему 🍿 К сожалению, про докер я узнал достаточно поздно, когда занимал менеджерскую позицию в одной из прошлых компаний и думал, что всё знаю. Я даже прошёл все этапы собеседования в одну классную европейскую компанию, но меня не взяли просто потому, что был такой же кандидат, только с опытом работы в Докере. С этого момента началось моё погружение в Docker... Пожалуй, не буду рассказывать, что такое докер, для чего он используется и прочие общие банальные вещи (их можно загуглить), но расскажу, как автоматизатор сталкивается с докером в работе: 😀докеризация тестов: самый банальный пример — нужно запускать тесты в CI на каждое изменение: коммит, МР, мерж. Раннеры по большей части работают только с готовыми образами. Пишем Dockerfile, описываем откуда берём базовый образ, копируем туда наши тесты, определяем переменные окружения и команду запуска тестов (и да, не забудьте выгрузить логи/отчёты, если они остаются в образе) 😀поднять полное окружение (или один сервис) для интеграционного/компонентного, а иногда даже и ручного тестирования. Например, поднимаем сервис проекта в докере (бэк/фронт) и имеем доступ ко всем "возможностям" проекта 😀кросс-браузерное тестирование: можно создавать образы различных платформ с различными браузерами, чтобы запускать на них свои тесты (я сейчас так делаю с Desktop e2e-тестами) 😀сохранение текущего состояние системы (snapshot). Например, баг воспроизводится при определённом состоянии системы или нужно собрать проект с подготовленными данными и так далее Так что же требуют в итоге? 🤨 Всё чаще и чаще я замечаю в вакансиях "хорошее знание докера". Скорее всего от вас не потребуют чего-то на уровне DevOps, как оркестрация, виртуализация, настройка деплоев и т.д., но могут спросить (а в итоге и пригодится на практике) следующие знания: 😀терминология и описание Docker, Docker Swarm, Kubernetes. Также нужно понимать, где хранятся образы, как их спуллить к себе и запустить (развернуть) 😀Dockerfile: разбираться в командах и синтаксисе, умение написать простой докерфайл для своего проекта, закинуть в него тесты и т.д. 😀встроить образ тестов в пайплайн деплоя (про пайплайн, скорее всего, будет похожий пост, но немного позже) Делитесь, как вы используете докер у себя в компании в треде! 🕺 И спасибо @SweeRoll за классную идею для поста ❤️ Полезные материалы: https://habr.com/ru/company/domclick/blog/566224/

Билды QA Automation — Часть 3 😴 😀QAA в Lead Как я писал ранее, QAA — это прежде всего QA, который должен быть в контексте продукта и понимать свою роль на проекте. Почему бы не лидить команду QA одного/части проектов и не заниматься автоматизацией параллельно? Плюсы: 😀баланс между кодом и менеджментом 😀возможность управлять командой и заниматься попутными "лидскими" штуками — бюджет, найм, процессы, релизы 😀максимальное погружение в проект, всегда в курсе всех нововведений Минусы: 😀что-то постоянно тянет на себя одеяло: менеджмент или автоматизация, иногда не хватает времени красиво организовать автоматизацию и наоборот — эффективность менеджмента может теряться 😀большой расфокус, нужно уметь грамотно распоряжаться своими временными ресурсами 😀т.к. сферы довольно разные, то прокачиваться придётся в двух разных направлениях одновременно, если есть желание оставаться в тренде (востребованным) 😀QAA в TechLead/Head of QAA Для меня эта ступень развития стоит на вершине эволюции QAA как менеджера, т.к. появляется ответственность не только за то, какие тесты нужно писать, но и за способы написания, автоматизацию инструментов и прочее. Грубо говоря, это как СТО в автоматизации, который понимает, что делается, для чего делается, прогнозирует нагрузку, строит долгосрочные планы, следит за их выполнением и анализирует результат. Очень творческая работа на самом деле Плюсы: 😀творческая деятельность 😀бизнес-подход к задачам 😀планирование, создание долгосрочных и краткосрочных стратегий 😀высокоуровневое мышление: как лучше для компании, а не конкретного проекта 😀внедряешь и менеджеришь технические штуки в команды 😀расширяется круг общения (CEO, CTO, юнит-лиды и т.д.) 😀и кучу всего, связанного с менеджментом: также бюджеты, составление и апрув KPI для разработки и тестирования Минусы: 😀кода в жизни становится очень мало 😐 😀очень сложная и кропотливая работа (планирование может длиться месяцами с десятками апрувов от CEO до тим-лидов команд) 😀огромная цена ошибки 😀большие риски (одна ошибка и ты ошибся 😎) 😀обязанность драйвить команду и мотивировать их на новые свершения, все верят, что ты знаешь, как сделать тестирование great again 😀😀😀😀😀😀😀 Кажется, что основные билды точно рассмотрены, но есть еще очень много веток для развития, давайте поверхностно посмотрим на них. QAA в: 😀Perfomance 😀Security 😀AI 😀Full stack (QA & QAA) 😀PM (подходит для небольших команд, где нет лида, но есть один ведущий тестировщик-автоматизатор, который может влиять на процессы в том числе) Если есть ещё варианты — пишите в обсуждения 🐻

Билды QA Automation — Часть 2 🌭 😀QAA в Dev Классный билд, который позволяет заниматься своим любимым делом с двойной силой — кодом! Обычно автоматизатор пишет не только тесты, но и код продукта (и, естественно, пишет на него тесты). Даже иногда хочется назвать такого инженера "Super full-stack QA": 😀погрумил задачу с заказчиком 😀проработал требования 😀написал тест-кейсы/юз-кейсы/чек-листы, в общем, любую тестовую документацию 😀предусмотрел риски на тех. ревью 😀написал код 😀написал тесты 😀отревьюился 😀протестировал задачу (авторское + функциональное + нефункциональное тестирование) 😀выкатил в прод 😀помониторил выкатку и графики на проде Ну мечта, а не инженер! Также этот билд можно воспринимать и наоборот, как возможность для роста разработчика в область качества. Плюсы: 😀код, много кода 😀тестирование своего же кода 😀можно делать объективно качественный продукт 😀широкая и разносторонняя экспертиза в программировании 😀код тестов становится более грамотным и архитектурно зрелым, в т.ч. код продукта обрастает тестами на всех слоях Минусы: 😀мало общения (по крайней мере меньше, чем на менеджерских позициях) 😀высокий порог входа 😀нужна усидчивость, причём серьёзная 😀QAA в DevOps (моя самая любимая ветка 🍌) Инфраструктура и QA — неразрывно связанные вещи. DevOps участвует в разработке всех инструментов, задействованных в тестировании: окружения, деплои, CI/CD и прочие классные вещи! QA также принимают участие в улучшении инструментов DevOps — оркестрация драйверов для тестов, автоматизации для QA и главное — обратная связь о работе инструментов в компании В чём можно принимать участие? 😀настройка и улучшение CI/CD (как процессно, так и технически) 😀написание ботов, интеграций, обвязок и прочего софта 😀взятие ответственности за инфраструктуру тестов: оркестрация, докерфайлы, пайплайн 😀внедрение полезных практик разработки: рестрикты на минимальное покрытие кода тестами, линтеры, запуск всех тестов и рестрикты на деплой при упавших тестах Плюсы: 😀нестандартные задачи: скрипты, БД, архитектурные задачи в разных ОС, разные инструменты оркестрации и другое 😀экспертиза в разных языках: груви, питон, джава, пхп и _впиши сюда свой язык_ 😀улучшаешь и упрощаешь жизнь всех инженеров в компании, при этом улучшая качество продукта Минусы: В целом, минусы такие же, как и в пункте 😀. Добавить, к сожалению, нечего ☔️ 😀мало общения (по крайней мере меньше, чем на менеджерских позициях) 😀высокий порог входа 😀нужна усидчивость, причём серьёзная Но и это ещё не всё! В следующем посте напишу еще варианты развития автоматизатора в смежные сферы 🤯

Билды QA Automation 🫡 Представьте мир IT в стиле MMORPG, где можно выбрать расу и класс своему персонажу. Как я понял, большинство в канале выбрали имбовый класс — автоматизатора тестирования! (спойлер — точно не прогадали) И вот вы достигли 20-го уровня, научились писать тесты, лупить баги своими скиллами и тут у вас открывается ветка прокачивания персонажа... 🤨 Тогда давайте рассмотрим ветки прокачки себя в автоматизации! 😀QAA в... QAA? Или самый невостребованный персонаж в любой группе Это инженер, который приходит на работу к 9 утра, пишет тесты с 9 до 13, с 13 до 14 уходит на обед, в 14 возвращается на рабочее время и дорабатывает до 18:00. Часы пробили 18? "Коллеги, арривидерчи! Я домой". Это человек, который не хочет развиваться, выходить из зоны комфорта по тем или иным причинам. Его устраивает текущий скиллсет под названием "писать тесты". Новое учить нет мотивации, да и не требуют особо Плюсы: 😀он умеет в авто-тесты. Возможно, что даже неплохо 😀идеально подходит начинающим автоматизаторам, которые только вкатились в QA Automation 🏋️‍♀️ 😀плюсы закончились Минусы: 😀полное отсутствие развития 😀понижение своей ценности с ростом требований на рынке 😀полное отсутствие гибкости, переход на другую работу сопровождается болью под копчиком 😀первый кандидат на увольнение в "тяжелые времена" 😀инженер-сервис, воспринимается командой как какой-то человек, который что-то делает, но что — не понимает никто Итог: QAA в QAA — это хороший вариант только в одном случае, когда новичок пришёл в автоматизацию и набирается опыта. IT профессии подразумевают постоянное совершенствование своих скиллов, смежных сфер и направлений. Тэк, пост получился уже большой, поэтому скоро рассмотрим ещё кучу вариантов прокачки и развития себя в разных областях, смежных с автоматизацией. Инвестируя в себя — вы инвестируете в свой комфорт (нет, я не инфоцыган 🤣, курс по мотивации продавать не буду) Увидимся! 📞