QA Dojo | Про управление качеством

ВЛИЯНИЕ DEVOPS НА ЗАДАЧИ QA ИНЖЕНЕРА DevOps – это больше, чем просто инструменты и пайплайны CI/CD. Это культура, в которой разработка, тестирование и развертывание объединены в единый поток. Это тренд, благодаря которому инфраструктура становится "как код" (IaC). Сейчас уже практически не встретишь компании, которые что-то деплоят или настраивают вручную, а не через bash-скрипты, Ansible или что-то подобное. 🔝 При этом скорость разработки привела к тому, что даже крупные клиенты переезжают в облака. Потому что нет времени ждать, когда привезут новый сервер. Для QA инженера это означает необходимость разбираться в IaC. Ведь без понимания, чем отличается тестовый контур от продового, вы не сможете обеспечить качественное тестирование. Или будете вынуждены после каждого релиза делать смоук-тестирование на проде. А в некоторых случаях тестирование на проде — единственное решение проблемы различия тестовых сред. Переходите по ссылке и читайте, какие скиллы нужны тестировщику, если он оказывается в среде, где активно внедряют Devops-практики и с какими задачами ему предстоит столкнуться. ➡️ Время чтения 5 мин. https://telegra.ph/Vliyanie-DevOps-na-zadachi-QA-inzhenera-09-20

Кстати, в прошлом году меня приглашали как гостью в подкаст Devone. Так как в моей жизни был непростой период, то я даже никому и не рассказала об этом подкасте. А между прочим там много полезностей. Как раз в тему моей вчерашней статьи. В этом подскасте 🎤:  - Причины недопониманий между тестировщиками и разработчиками (и что с ними делать)  - Agile-подходы и их влияние на качество разработки  - Как можно сократить расходы, если вкладываться в качество. А также, почему тестировщики не всегда доверяют результатам тестирования со стороны разработчиков, чем полезно системное мышление и почему всё популярнее становится роль QA-адвоката ⏳. Приятного прослушивания и давайте в комментариях обсудим, а как вы относитесь к качеству тестирования со стороны разработчиков. https://devone.mave.digital/ep-24

Сегодня разберем, как влияет на работу QA инженера такой фактор, как System complexity. Сегодня системы стали гораздо сложнее. Мы говорим уже не только про разработку фичей, а про работу с Big Data, глобальными продуктами и многоуровневыми архитектурами. Теперь QA должен уметь разбираться в сетевой архитектуре, понимать, как облачные технологии влияют на тестирование, и решать проблемы с данными в distributed systems. А о том, в какие задачи и соответственно требуемые навыки это выливается для тестировщика, читайте по ссылке. Время чтения 3 минуты. https://telegra.ph/Kak-System-compexity-vliyaet-na-QA-09-17

Итак, ребята, давайте начнём с того, что Agile так или иначе придёт в вашу компанию. Хотите вы этого или нет — это вопрос времени. Кому-то повезёт, и Agile внедрят как надо, с правильными принципами. Кого-то ждёт "фальшивый Agile" — когда вроде как Scrum, а на деле всё по-старому. Но поверьте, все мы в какой-то момент столкнемся с этим. Потому что рынок диктует свои правила: нужно быть гибкими, быстрыми и конкурентоспособными. Компаниям нужно увеличивать скорость разработки, а значит, и от нас, тестировщиков, тоже ждут новой скорости. Давайте посмотрим, как это повлияет на нашу роль: что отнимет и что откроет нового. Переходите по ссылке, написала небольшую статью, чтение займет 4 минуты. https://telegra.ph/Kak-Agile-vliyaet-na-rol-testirovshchika-09-16-2

Только мы выдохнули после тайфуна. Радовалась, что не так сильно пострадали люди. Грустила, что очень много деревьев повырывало и природе придется долго восстанавливаться после такого стресса. Как сегодня пришло наводнение. Много регионов уже затопило до уровня 2-го этажа. Часть районов Ханоя уже затапливает. А дожди будут до конца недели 🤯 Напрямую, меня это не сильно коснется. Но проходить мимо такого бедствия для других не могу. Не теряйте меня, видимо на этой неделе я в блоге буду «набегами». На фото - Красная река сегодня утром. Это основная река в Ханое. На видео - это я вчера вечером пытаюсь с сыном доехать после садика домой.

Всю прошлую неделю я разбирала основные проблемные области, влияющие на нашу профессию СЕЙЧАС и в перспективе ближайших 3-5 лет. Все происходящее подводит нас к вопросу: что делать QA инженеру, чтобы не остаться за бортом через несколько лет? Мой ответ  - предвидеть, быстро учиться и адаптироваться. Ситуация на рынке зависит не только от компаний, но и от нас самих.  Задумайтесь, что вы делаете для своего развития?  Какие источники вы читаете, чтобы быть в теме? Просто пролистываете статьи на Хабре, где информация часто спорная и не всегда полезная? Какие книги по своей профессии вы действительно прочитали? Вы вникаете в документацию технологий, с которыми работает ваша команда, или ограничиваетесь только своей QA-зоной? А курсы посещаете? Повышаете свои компетенции, или думаете, что и так всё знаете? Как вы следите за трендами? Понимаете, что вообще происходит на рынке? - Умеете ли тестировать распределенные системы, асинхронность? Это не шутка, разработчики часто спрашивают об этом. - Понимаете, как работает serverless-архитектура и как её тестировать? А что, если ваша система будет интегрирована с несколькими облаками, типа AWS и Azure? На мировом рынке уже почти стандарт для QA инженера иметь AWS и Azure Practitioner сертификаты.  - Знаете, как использовать Copilot для автоматизации тестирования?  Или как ускорить написание тест-кейсов с помощью ChatGPT?  Недостаточно просто плыть по течению, делая только то, что предлагает работодатель. Нужно подходить к карьере стратегически. Раньше, например еще года 2 назад, переход в другую роль — будь то разработчик или менеджер — был проще. Вы могли потратить немного времени на обучение, потерять немного в зарплате, но быстро наверстать. Сейчас же конкуренция выросла. Легкого сценария не будет. Всю эту неделю я посвящу тому, как подходить к построению своей карьеры стратегически. Как создать себе план развития, как найти даже на своей неинтересной работе челленджи и зоны роста. И все для того, чтобы стать максимально привлекательным кандидатом на рынке труда.

Сегодня видимо без продолжения. На нас надвигается супер-тайфун Яги. Надо успеть подготовиться 🤯 За 2,5 года жизни в ЮВА для меня это первое стихийное событие.

​​Как же хорошо, что вчера в комментариях мне дали обратную связь! Я вовремя увидела, какие именно тезисы из моего текста выглядят неоднозначными. Поэтому прежде чем продолжать, давайте подытожим. Сначала определимся, что я имею в виду, когда называю базовые ожидания рынка от QA инженера «QA рутиной». Рутина — это что-то повторяющееся, не всегда интересное, не требующее челленджа и развития. Ключевое здесь в том, что после такой работы мы не чувствуем себя умнее или ценнее для бизнеса.  Когда нет челленджа, кажется, что топчешься на месте. Отсюда и мысли: «QA — это скучно и бесперспективно, пора бы уже менять профессию». Но проблема не только в «потолке развития». Многие из нас не имеют профильного IT-образования, максимум прошли курсы по тестированию и за всю свою карьеру прочитали Савина, Куликова и может быть “Agile-тестирование” Лизы Криспин. В итоге создаётся иллюзия, что мы уже всё знаем и умеем. А рутина на работе только подкрепляет это ощущение. Из-за недостатка знаний и опыта мы не видим, куда можно расти дальше.  Неудивительно, что многие начинают задумываться о смене ролей. Но есть ещё и внешние факторы, которые влияют на нашу профессию. Да, это может звучать тревожно, но не переживайте — в конце я расскажу, как использовать эти изменения в свою пользу. Итак, что влияет на нашу деятельность? Четыре ключевых фактора: сложность систем(complexity), Agile, DevOps и искусственный интеллект (AI). 1. Сложность систем 🌐 Современные продукты становятся всё сложнее и глобальнее. Мы уже не работаем над маленькими локальными системами. Продукты созданы для международных рынков, охватывают несколько регионов и стран, включают интеграции с другими системами и требуют работы с большими данными и машинным обучением. Event-driven и serverless архитектуры усложняют интеграционное и end-to-end тестирование. Всё это требует новых подходов и навыков. 2. Agile 🏃‍♂️ Agile пропагандирует командную ответственность за качество. В идеале это хорошо, но на практике часто получается, что разработчики, DevOps и аналитики берут на себя задачи тестирования, и QA остаются не у дел. Ключевые задачи по автоматизации переходят к разработчикам, потому что это быстрее и дешевле. Я уже не раз видела, как компании одурманенные аджайлом отказывались от роли QA. Правда потом, через пару лет снова нанимали их. 3. DevOps 🛠️ С приходом DevOps многие задачи, связанные с инфраструктурой, также отходят от тестировщиков. Если раньше мы настраивали CI/CD и тестовые среды, то теперь это делают DevOps-инженеры. Когда-то это была интересная часть работы для многих senior-ов, но сейчас такие вакансии редкость. 4. Искусственный интеллект (AI) 🤖 AI пока ещё не сильно влияет на нашу роль, но это ненадолго. Но я уверена, ситуация очень сильно изменится через 2-3 года. Прямо сейчас несколько компаний активно тренируют свои нейронные сети для автоматической генерации тестов. И здесь речь не только про автоматизацию, но и про анализ требований и проектирование тестов по этим требованиям.  Хотя пока модели не могут полностью заменить человека из-за недостатка контекста доменной области, они уже способны выполнять базовые сценарии.  В будущем это также приводит к тому, что часть наших обязанностей будет заменена.

Итак, проблема идентифицирована. К сожалению, под ранее опубликованными постами, включить комментарии я уже не смогу, так как там размещены кнопки-реакции. Выводы сделаны. Но, я уверена, что у кого-то из вас НАКОПИЛИСЬ ВОПРОСЫ по теме. Так что давайте этот пост будет для сессии вопросов-ответов. Сессия Q&A объявляется открытой, го в комментарии!❓

​​Карта компетенций STE Давайте разберёмся, что происходит с ролью Software Test Engineer (STE) на международном рынке. Здесь акцент делается не просто на знании различных видов тестирования, но и на способности принимать осознанные и стратегические решения. Требуется понимать, как тестировать в зависимости от архитектуры системы, инфраструктуры, тестовых сред и других факторов, чтобы не бездумно выполнять весь объем тестов. STE часто выступают в роли консультантов, которые адаптируя свой опыт, предлагают наилучшие стратегии тестирования. Это не просто "исполнители", выполняющие тесты по заранее прописанным требованиям. Они выбирают подходящую стратегию и тактику в зависимости от ситуации. Например, сначала проводят анализ рисков, а потом уже разрабатывают тесты.  Требования на международном рынке 🌍 Посмотрев на требования в вакансиях на международном рынке, становится понятно: акцент там не на выполнении конкретных задач, как на ru-рынке (типа регресс или автоматизация), а на принятии решений и ответственности. Требования могут включать:  как применять TDD, BDD или умение работать с пирамидой тестирования, анализировать архитектуру и выявлять узкие места, которые влияют на её тестируемость. Здесь ожидают, что тестировщик будет не просто "проверять функциональность", а предлагать улучшения в архитектуре, тесно работать с разработчиками. Это и сближает роль QA инженера с ролью разработчика. Поэтому, мы потом и наблюдаем переходы в разработку — у QA уже есть необходимые навыки, а зарплата там повыше. 💰 Почему же возникает несоответствие в ожиданиях к роли? 🤔 Почему же на рынке такие разные взгляды на роль QA инженера? Часто требования к этой роли диктуют менеджеры и CTO, которые вообще не в курсе современных практик тестирования. Их представления о тестировании устарели. Они думают, что тестирование — это просто "проверка функционала" после разработчиков, не понимая, что тестировщик может быть стратегическим консультантом, который реально улучшает продукт. Да, мы отвечаем за качество. Но не просто за "проверку качества", а за инженерный подход, за стратегии, за принятие решений. Большинство этого не понимает. В итоге, нет культуры того, что тестировщик — это инженер, который помогает создавать качественный продукт, а не просто делает рутинную работу. 🛠️ Что делать дальше? 💡 А что, если ничего не менять? Тогда в будущем нашу QA-рутину отдадут другим. Разработчики начнут автоматизировать тесты сами, процессы поддерживать будут engineering менеджеры. Уже сейчас видно, что внедрение пирамиды тестирования обычно ведёт к тому, что разработчики берут на себя большую часть автоматизации, оставляя тестировщиков без привычной автоматизации тестов. И что делать? Как доказать свою ценность бизнесу и руководству? Может, пора уходить в менеджеры или разработчики? Или пойти в сторону DevOps и SRE, где зарплаты выше и есть возможность работать с инфраструктурой? 🤷‍♂️ Это типичные шаги для многих, но не обязательно лучший путь для всех. Если вам реально нравится ваша профессия и вы видите в ней свою миссию, надо действовать, чтобы остаться в игре. Важно не просто реагировать на изменения рынка, а формировать его. Мы должны показать, что QA инженер  — это не просто исполнитель, а тот, кто отвечает за качество и реально влияет на продукт. ✨

А на сколько ваша работа похожа на QA-рутину? Приемка, регресс и тест-кейсы. И так 24/7. - 6 👍👍👍 11% Преимущественно QA рутина - 13 👍👍👍👍👍👍 23% 50% времени рутина. - 14 👍👍👍👍👍👍 25% У меня интересная инженерная работа. - 18 👍👍👍👍👍👍👍👍 32% Свой вариант (напишу в комментариях) - 5 👍👍👍 9% 👥 56 человек уже проголосовало.

Про QA рутину 🛠️ Основной триггер, который подталкивает тестировщиков задуматься о смене профессии, — это непонимание, как повысить свою ценность для компании и остаться востребованным на рынке, чтобы получать хорошую зарплату 💸. Грустная правда в том, что многие думают, будто вся их работа сводится к регрессу и написанию автоматизированных тестов. Если ты сам не понимаешь, чем твоя роль полезна компании, то и «продать» свою ценность кому-то другому будет сложно. Вот и начинается: “А может, ну его это тестирование?” 🤔 Проанализировав вакансии на QA Jobs, HeadHunter и Хабр.Карьера, я заметила, что большинство работодателей ищут людей для рутинных задач, или как я это называю, на «QA-рутину» . Это всё та же автоматизация, регресс, приемочное тестирование. Если в вашей работе есть что-то большее — вам повезло, но для многих это однообразие и есть вся суть работы. Отсюда и выгорание 🔥, скука 💤, ощущение, что ты стоишь на месте и деградируешь. Народ начинает искать пути побега — в менеджмент или другие роли, лишь бы сбежать от этого дня сурка 🐿️. А чтобы получать хорошую ЗП, нужно доказать, что роль QA не просто важна, она требует крутых навыков. И мало убедить в этом только своего начальника или команду. Также нужно показать, что обеспечение качества — это не просто регресс и тест-кейсы в TMS, даже если их автоматизировать. QA — это непрерывный поиск информации о качестве вашего продукта и помощь команде в принятии взвешенных решений ⚖️. И это не только про функциональное тестирование! Есть масса других подходов, про которые мы часто забываем (или даже не знаем). Но пока мы живем в этом круговороте рутины, наши коллеги по-прежнему считают, что QA — это просто проверка чек-листов ✅. QA-рутина в будущем В таких условиях трудно понять, как оставаться профессионально актуальным. Когда дело доходит до экономии 💰, наши руководители решают, что разработчики сами справятся с тестированием, а процессы может настроить любой process-менеджер. Всё потому, что эта наша «QA-рутина» создаёт иллюзию, что нас можно легко заменить, расширив обязанности других 🤷‍♂️. За последние 4 года я всё чаще вижу, как компании начинают отказываться от классической роли QA-инженера. Что же будет через 5 или 10 лет? 🤔 Свое видение я отразила на картинке к этому посту 📊. Получается, часть нашей QA-рутины перераспределится по другим ролям, и обосновать свою ценность бизнесу станет еще сложнее. Рынок меняется быстро, нам надо держать руку на пульсе, чтобы не оказаться без работы в условиях жесткой конкуренции. Нужно понять, что старый подход больше не работает — работа сама к вам не придет. Так вот, если посмотреть на международный рынок, можно заметить интересные отличия. У нас роль тестировщика часто называется просто "тестировщик" или “QA инженер”, а во всем мире — "software test engineer" (STE), что подчёркивает инженерный характер нашей работы. Более того, многие компании используют термин "software engineer" вообще без уточнения, но в описании обязанностей всё равно идёт речь о тестировании. Так что давайте двигаться в ногу со временем и не зарываться в свою рутину ⏩. ______ В следующих постах мы начнем разбирать, как подготовиться к будущему и как избавляться от “QA-рутины” на работе 📈.

Как человек, часто выступающий на конференциях, преподающий и организующий IT-мероприятия, я приобрела определенную насмотренность. Поэтому понимаю, куда движется рынок в перспективе 3-5 лет. Но, знаете, одного мнения обычно маловато, чтобы делать доклады или писать статьи. Так что я погрузилась в исследование и решила накопать максимум информации. На первой картинке вы можете увидеть основные источники информации, которые я использовала.  Я изучила публикуемую информацию за последние три года — и это не только статьи на Хабре и Medium, но и серьёзные научные исследования на ResearchGate и ACM. В моём списке были всё: от блогов и форумов до конференций и личных интервью. А чтобы понять, что происходит с ролями тестировщиков, я анализировала описание вакансий и резюме на LinkedIn и Levels — где только не рылась! Для поиска информации я использовала ключевые слова вроде "QA", "тестер", "software testing engineer" и тому подобное, на русском и английском. Хорошо, что c python я на ты и парсинг данных с этих сайтов существенно сэкономил мне время. И да, берите эти источники и пользуйтесь сами. Я до сих пор где-то раз в месяц просматриваю все указанные источники, чтобы понимать тренды.  Профессиональные переходы в карьере тестировщиков В процессе исследования выяснилось, что многие тестировщики со временем переходят в разработку. Логично, если ты неплохо умеешь писать код — задачи и навыки пересекаются. Второе место — у процесс-менеджеров: скрам-мастеры, руководители проектов, delivery-менеджеры. Потом идут роли, связанные с бизнесом, как бизнес-аналитики и продакт-менеджеры. Редко, но метко — кто-то умудряется уйти в software архитекторы. Интересное наблюдение, в среднем переход на соседние роли происходит где-то через 3-4 года в профессии.  Почему уходят из тестирования? Ну, тут всё просто. Первая причина — базовые потребности: безопасность и стабильность. Люди хотят быть уверены в своём будущем, обеспечить себя и свою семью, иметь работу, доход, крышу над головой. И если в роли тестировщика они не чувствуют этой уверенности, то начинают задумываться о смене профессии. То есть, если работая автоматизатором  ты не понимаешь как увеличить свой доход x2, то первое что приходит в голову - уйти в разработку. Или если видишь, что в случае рисков первыми в компании полетят "QA головы", то это добавляет тебе любви к своей профессии. Вторая причина — нехватка информации о перспективах. Как однажды сказала моя коллега: «Становится скучно», будто некуда расти. Многие просто не знают, какие возможности открываются в тестировании. Им кажется, что только разработчики и продакт-менеджеры могут делать что-то интересное и перспективное. А откуда бы знать? Мы же в универах не заканчивали курсы по QA, да и computer science тоже не всегда. Кто-то за всю свою карьеру осилил одну-две книги по профессии и прошёл пару курсов. И что слышишь, когда спрашиваешь, как люди развиваются? «Читаю Хабр». Ну, ещё блоги. Но, честно говоря, когда интернет всё больше напоминает мусорку, такая стратегия — не самая надёжная. Взгляните на разработчиков, PM-ов и продакт-менеджеров: у них и годичные курсы, и книжки умные. В таком инфо-пузыре и правда может показаться, что QA — это скучно и бесперспективно. Но это не так. Проблема не в профессии, а в нашей с вами неосведомлённости.

А на какую роль хотели бы перейти ВЫ? 😉 Developer - 7 👍👍👍 9% Analyst - 15 👍👍👍👍👍 20% Process manager (DM, PM, SM, etc) - 11 👍👍👍👍 15% Product Owner - 14 👍👍👍👍👍 19% Другой вариант - 28 👍👍👍👍👍👍👍👍 37% 👥 75 человек уже проголосовало.

​​В прошлом году, ко мне пришел клиент с запросом сделать доклад для их корпоративной конференции. Ну а я же заморочилась и сделала исследование на тему "Как развивается роль QA инженера" и как вообще тестировщикам карьерно расти в IT будущего. Почему я  решила в это погрузиться? На то есть две причины. 1. Первая: Как оставаться востребованным на рынке QA? Вокруг нас слишком много всего происходит, то санкции (с notion приходится съезжать 😀), то сокращения, то компании внезапно внедряют новые технологии. В этой суете важно понять: как стать тем самым спецом, которого не уволят при первых же сокращениях или трансформациях и который всегда будет ценен на рынке? Вы наверняка в курсе всех этих бесконечных лей-оффов, которые не прекращаются с 2021 года. 2. Вторая: Мифический “потолок развития” у QA. Поработав более чем с 13-ю различными компаниями как наемный сотрудник и консультант, я заметила, что именно тестировщики часто переходят на другие роли. Более того, я не раз слышала от своих же сотрудников или на менторинге, что тестирование — это не навсегда, и нужно двигаться дальше. Чтобы понять, так ли это, в процессе исследования я выяснила интересную тенденцию: оказывается, многие опытные QA действительно ищут новые пути для роста. Но вместо того чтобы углубляться в QA, например научиться применять risk-based testing, exploratory testing, model-based testing или вникать в особенности тестирования различных архитектур, чаще рассматриваются возможности перехода в роли бизнес-аналитика, product owner-а или разработчика. Почему так? Почему QA-шники меняют профессию? На мой взгляд, тут всё просто: тестировщик — это зачастую стартовая позиция в IT. Люди приходят, не всегда понимая, их ли это вообще. Со временем возникает потребность стратегически выстраивать свою карьеру. Но почему тестирование часто считают чем-то временным? Например, если ты хорош в процессах, тебя тянет в скрам-мастеры или PM-ы. Если умеешь кодить, рано или поздно уходишь в разработку. Например, самые частые карьерные свитчи, что я видела — это  в сторону процесс-менеджмента, бизнес-анализа или product management. Первой мыслью было, что это особенность российского рынка. Но нет, изучив международный рынок, я поняла, что ситуация схожая. Тестировщики по всему миру в какой-то момент начинают искать новые карьерные возможности. Почему? Из-за денег? Или работа становится скучной? Если скучной, то почему? Или просто ощущение, что больше некуда расти, ничего нового не происходит в профессии? Да, бывает, что люди меняют профессию из-за смены интересов, но это скорее исключение из правил. Чаще всего причинами перехода являются деньги  или ощущение, что ты достиг потолка в своем развитии. В следующих постах я расскажу вам об интересных наблюдениях, которые я обнаружила в процессе исследования и своем видении как выстраивать карьеру в QA так, чтобы оставаться ценным, с хорошей ЗП специалистом, и главное, расти профессионально без вынужденной смены карьерного трека.

Раз уж я упомянула про текстовую расшифровку доклада, вот и ссылка на него на YouTube. Чего скрывать — я действительно горжусь этим докладом. На его подготовку ушло больше месяца, и только один месяц я провела, погружаясь в ресерч и анализ фуллтайм, не считая времени на создание контента, презентацию и репетиции. О чем доклад? В современном IT-мире с приходом Agile, DevOps и теперь еще AI роль QA инженера меняется. В этом докладе я рассматриваю различные пути профессионального развития и карьеры QA инженера в 2023-2024 годах. Разбираю реалии как российского, так и международного рынка, и развенчиваю миф о "потолке развития" для QA инженеров. Вы узнаете , как развивать свою карьеру и оставаться востребованными на рынке. И, конечно же, я поделюсь, как стать тем самым "10x инженером", за которым охотятся компании. А вишенка на торте — алгоритм, который поможет понять, стоит ли стремиться к руководящим позициям или лучше сосредоточиться на дополнительных профессиональных навыках. Если возникнут вопросы после просмотра, задавайте их в комментариях, отвечу.

​​Привет! Последний год я провела в саббатикале — это было время для рефлексии, поиска себя и ответа на вопрос: «А куда дальше?» Долгие годы меня носило по разным ролям, от QA-инженера и тест-менеджера до agile-коуча и создателя IT-комьюнити и конференций. Каждый раз, когда меня просили рассказать о себе, я терялась: как вместить все эти разноплановые роли в одно предложение? Если честно, я всегда скептически относилась к «человекам-оркестрам». Ну разве можно быть экспертом во всём сразу? И вот, в течение года я искала то, что приносит мне истинное удовольствие. Оказалось, что кайфую я больше всего, когда учу других или сама погружаюсь в технические задачки. Теперь, когда я наконец-то разобралась, кем хочу стать, когда вырасту, решила вернуться к работе, отходя от роли фулл-тайм мамы. Итак, вот, что у меня нового: 1. Я фрилансер уже три года и пока не планирую менять этот статус. 2. Больше не преподаю в OTUS. Добби свободен! 3. Уже давно не руковожу ПК на TechLeadConf. 4. Всё ещё руковожу QA сообществами в Telegram, и теперь у меня есть время и желание их развивать. Приятно иметь под крылом 50к участников. 5. Люблю менторить и учить. Поэтому этот блог будет о том, что мне нравится — делиться опытом и знаниями. И да, я мама двух классных пацанов и замужем за этническим вьетнамцем. Вот уже два года мы живём в Ханое. Что будет в блоге? Никакой глобальной миссии, просто желание делиться тем, что я знаю и умею. В ближайшее время ждите серию постов, расширяющих доклад-исследование на тему "А куда и как расти QA в современном IT", которое я делала год назад. А потом вернусь к любимой теме — стратегиям тестирования. Фан-факт: после саббатикала мне стало проще писать. Больше не переживаю по поводу идеальности, главное — делиться тем, что знаю и люблю. И я больше не позицинирую QA Dojo как корпоративный блог. 😉