Про груминг требований

На днях за чашкой кофе обсуждали с Катей — системным аналитиком в одном крупном банке — груминг требований.

Груминг требований — это командная практика, в рамках которой происходит уточнение и детализация требований к задаче до начала разработки.

В этом тексте Катя поделится, как в одной из ее команд появилась практика груминга требований: зачем они начали это делать, как выстраивали процесс и что получилось в итоге.

Расскажи об опыте груминга ТЗ

Груминг требований появился скорее как необходимость, чем модная фича. У нас была небольшая команда с огромным бэклогом неструктурированных задач. Требования чаще всего были неявными. Мы не знали многих подводных камней веб-приложения, поэтому были трудности с оценкой и соблюдением обещанных сроков.

Участники:

🔘системные аналитики
🔘тестировщики
🔘разработчики

Цели:

🟤Решить проблему излишней декомпозиции за счет более явного описания требований. Изначальный подход — максимально декомпозировать — приводил к потере общей связности требований. Разработчикам было трудно воспринимать большие ТЗ. Фокус решили сделать на четкую и понятную постановку задачи

🟤Сделать оценку времени на выполнение задачи более точной за счет учета мнения всей команды

🟤Повысить вовлеченность разработчиков и тестировщиков в работу с требованиями, снизить градус напряжения в команде и избавиться от взаимных обвинений

🟤Получать больше информации о технической стороне работы веб-приложения и доносить ее до бизнеса на этапе согласования требований

Как проходил процесс груминга?

У нас была распределенная команда, поэтому собирались онлайн. Тайминг — 1 час. В повестке не более 3 задач. Задачи должны быть по одной теме, например, один функционал / один раздел. Предварительно высылался черновик ТЗ.

Аналитик подробно рассказывал о доработке, а разработчики и тестировщики должны были задавать вопросы. Сначала это приводило к кейсу «все понятно, ок», что говорило о низкой вовлеченности. В итоге стали назначать ответственных разработчика и тестировщика, которым будет отдана задача в работу. Они высказывались по задаче обязательно. Также во время груминга оставляли комментарии по тексту: кто и что предложил. Затем аналитик правил ТЗ и досогласовывал с заказчиком.

Какие плюсы/минусы у этого подхода?

✔️ сокращение числа дефектов из-за неясностей, минимизация двойной работы и работы в стол

✖️ сложно соблюдать тайминг, иногда обсуждение затягивается, если участников много и взгляды сильно расходятся

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

Как ты оцениваешь эффективность этого подхода в вашей команде?

Мы не собирали статистику, но точно были хорошие эффекты для всех участников:

🤎 Для аналитиков — обратная связь от людей с незамыленным взглядом, бо́льшая погруженность в тех. ограничения системы, идеи по упрощению реализации от разработки на начальном этапе
🤎 Для разработчиков — избегание типовых ошибок за счет вовлеченности на раннем этапе, а также минимизация переписывания кода
🤎 Для тестировщиков — возможность на раннем этапе понять чего хочет бизнес. Это снижает неопределенность и дает больше уверенности в том, что баг, а что — нет
🤎 Для заказчика и руководителей — задачи стали точнее оцениваться, ушли кейсы, когда оценка могла быть превышена в 1,5-2 раза

Груминг дает площадку для дискуссии. У меня были кейсы, когда вопрос от тестировщика или разработчика наводил на классную мысль. У всех разный угол зрения — стоит сверяться. А еще груминг получился способом разделения ответственности и признания экспертности членов команды.

📖📖📖

Для меня груминг — это инвестиция в качество, при которой выигрывают все: аналитики получают более четкие вводные, разработчики — меньше переделок, а тестировщики — ясность. Хороший груминг — это вклад в зрелость команды.

#интервьюшная

Из прокуратуры в тестирование

Мне нравятся истории людей об удивительном карьерном треке. Я уже писала о некоторых из них. Но история Кристины — пожалуй, самая впечатляющая из всех, что доводилось мне слышать.

Кристина — тестировщица в GameDev. Мы познакомились на встрече менторов Women in Tech. Стандартный вопрос: расскажи, в какой сфере работала до IT? Кристина невозмутимо отвечает: в прошлом я — помощник прокурора. Наш стол замер! Следующий час мы донимали Кристину вопросами о ее карьерном пути :)

Я попросила Кристину поделиться, как прокурорский бэкграунд влияет (или нет) на работу в тестировании.

Расскажи о своем карьерном пути

С 2014 по 2025 год я прошла путь от помощника прокурора до тимлида команды тестирования в GameDev. В конце 2020-го я тяжело переболела ковидом и задумалась: нравится ли мне моя жизнь? Ответ был грустным: я не на своем месте. Варианты о том, куда пойти, казались компромиссом, точно не тем, что могло бы стать любимым делом. И тут мой друг рассказал о тестировании. Я подумала: это же то, чем я занимаюсь в прокуратуре! Проверки, поиск ошибок, изучение документации, коммуникация с людьми — все, что мне всегда нравилось в работе. А дальше понеслось: курсы, стажировка в IT-компании, сокращение, новый проект, повышение. И сейчас я однозначно на своем месте.

Есть ли что-то общее у правоохранительной сферы и IT? :)

Концептуально есть много общего. Например, в части применения софт-скиллов: доносить до людей неприятные новости, будь то сообщение о факте нарушения законодательства или сообщение о баге, важно корректно и без эмоций. Общий механизм и у процесса проверки. Ты знаешь, как должно быть, и проверяешь на соответствие: в прокуратуре — уголовное дело, а в тестировании — требования или продукт.

Какие профессиональные навыки из работы прокурором оказались полезными в тестировании?

Критическое мышление. Базовый скилл как для прокурора, так и для тестировщика. Приходится анализировать факты, проверять достоверность информации и делать выводы только на основе подтвержденных данных. Любой факт в обвинительном заключении должен быть подтвержден документально. В тестировании так же

Коммуникация. И в суде, и в обсуждении дефекта важно уметь структурно и понятно излагать свои мысли. Кроме того, мне пригодился опыт представления доказательств, он аналогичен «защите» найденного бага перед разработчиками или менеджментом, чтобы убедить команду в приоритетности и необходимости его фикса

В профессии прокурора много работы с доказательствами и логикой. Как ты применяешь этот опыт в тестировании?

Хотелось бы выделить баг-репорты — по сути, это меры прокурорского реагирования, но по отношению к ПО. Мы находим несоответствие законодательству (в случае тестирования — техническому заданию) и приносим требование об устранении нарушений (в тестировании — баг-репорт). В обоих случаях мы используем системный подход к сбору доказательств. А еще для развития тестировщику полезно знакомиться с бэклогом задач, чтобы лучше разбираться в проекте и понимать, на что обращать внимание. В прокуратуре тоже есть такой бэклог — подшивка мер прокурорского реагирования. При подготовке к проведению проверки их изучают и смотрят, какие ошибки допускаются поднадзорными органами или в приговорах. Такой юридический Error Guessing

Бывают моменты, когда ты смотришь на продукт или проблему не как тестировщик, а как юрист?

Да, такое бывает. Особенно если это касается сроков и процессов, к которым отношусь с большой ответственностью. Чувство ответственности я бы тоже выделила как ключевое для юриста и для тестировщика: cоблюдение сроков и процессуальных норм (следование тест-плану, выполнение проверок, документирование), отказ закрывать глаза на нарушения/дефекты.

Для меня кризис стал точкой роста, благодаря которой я нашла любимую работу, где успешно применяю ранее полученные навыки.

✨✨✨

На мой взгляд, история Кристины показывает: любые навыки можно трансформировать для применения в новой сфере. Разносторонний опыт обогащает специалиста. Главное — не забывать подсвечивать это на собеседованиях :)

#интервьюшная

Полезные ссылки на каждый день

Эту подборку материалов я готовила для своей менти в рамках прошлогодней программы Women in Tech. С удовольствием пользуюсь подборкой сама, особенно во время подготовки к собеседованиям. Здесь собрано разное: статьи с Хабра, который иногда почитываю, посты из тг-каналов про тестирование, за которыми слежу, тренажеры и практические задания. Подойдет для начинающих и продолжающих тестировщиков.

1. Основы теории тестирования

✔️ Testbase — это ресурс Ольги Назиной. Структурно и понятно. Кажется, здесь все, что должен знать тестировщик :)
✔️ Большой учебник по тестированию — концепт такой же как у Назиной, но есть тесты для самопроверки
✔️ Библия QA — еще одна классная база знаний, на мой взгляд, с более углубленной тематикой + есть раздел по мобилкам
✔️ Статья на Хабре — важное про принципы тестирования
✔️ Статья на Хабре — что должен знать тестировщик
✔️ Очень рекомендую табличку полезностей от Ольги Ермолаевой из «QA FAQ» — по-настоящему впечатляющая база знаний по теории, практике, инструментам для новичков и опытных
✔️ Бот AI Mentor for QA — каждый день в канале появляются вопросы по тестированию с развёрнутыми ответами, подойдет для самопроверки

2. Техники тест-дизайна

🔵 Хороший конспект книги Ли Копленда «Практическое руководство по тест-дизайну» от Ирины Шляпиной из «Ещё один канал про QA»
🔵 Шпаргалка по техникам тест-дизайна — доходчиво по основным техникам
🔵 Статья на Хабре — как выглядит тест-дизайн на практике

3. Тестирование web-приложений

🟢 Статья от kirdenoff — про базовые проверки элементов веб-страницы
🟢 Статья от Kompot Journal — хороший чек-лист как проверить верстку приложения
🟢 Табличка полезностей от Ольги Ермолаевой из «QA FAQ» — на вкладке «Инструменты» есть полезные расширения, помогающие в работе веб-тестировщику

4. Работа с траффиком

✨Битва Charles и Fiddler
✨Погружение в Charles Proxy
✨Первые шаги с Fiddler Classic

5. Знание SQL

📱 Использую мобильное приложение Mimo. Помогает поддерживать необходимый уровень. Также есть неплохой тренажер по изучению SQL, смотри в разделе «Тренажеры»

6. Тестирование API

🔘 Видео на Ютубе от Artsiom Rusau — очень подробно про SoapUI и Postman
🔘 Статья на Хабре — список полезных статей и видео для изучения API
🔘 Обзор на самые популярные типы API от Юлии Горшковой из «QA hacking / Ermita»
🔘 Статья в Техноблоге про идемпотентность http-методов
🔘 Статьи на Хабре про типы данных: JSON, XML

7. CI / CD

🔘 Шпаргалка по CI/CD от Людмилы Борщевской из «SmartQA»

8. Docker

✅ Docker для начинающих — 7 уроков от Гоши Дударя на Ютубе
✅ Шпаргалка по Docker от Надежды Дудник из «ProTestingInfo»

9. Kafka

🤎Всеобъемлющий пост по работе с Kafka также из канала Надежды Дудник «ProTestingInfo»


✨✨✨✨✨✨✨✨✨

🤎Тренажеры для тестировщиков — здесь можно найти тренажер на любой вкус и попрактиковаться
🤎Тренажер на треугольники для начинающих
🤎Тренажер по DevTools
🤎Тренажер по SQL — там и учебник, и тренажер


✨✨✨✨✨✨✨✨✨✨✨✨✨

✏️ Список вопросов, которые стоит задать собеседующему на интервью
✏️ Мой пост про то, как разглядеть токсичного руководителя на собеседовании
✏️ Список тестовых заданий для тестировщиков
✏️ Ресурс Т-Банка для подготовки к собеседованиям
✏️ Ресурс Ozon для подготовки к собеседованиям

#куашная

Золотые часы когнитивной активности

Удалось ли вам синхронизироваться с осенью? 😴

Когда летний задор сменяется осенней апатией, тема ресурсов звучит актуальнее: как сохранить (а лучше приумножить) свои силы?

В этом тексте хочется поговорить о золотых часах когнитивной активности. Текст написан по материалам биолога Ирины Якутенко из «Безвольные каменщики».

Что это такое?

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

Принято считать, что мы имеем два хронотипа: жаворонки и совы. В действительности их три: жаворонки, совы и голуби. Большая часть человечества относится к третьим.

Жаворонки способны выполнять сложные задачи ранним утром сразу после пробуждения. И чем дальше, тем хуже они справляются. У сов период умственной продуктивности приходится на поздний вечер и ночь. А вот у голубей два пика высокой вовлеченности: первый — умеренным утром, то есть скорее в 10:00, чем в 7:00. Второй — ранним вечером, то есть часов в 16:00. А вот в середине наблюдается значительный провал в ментальной активности.

Как определить свой хронотип?

Достаточно понаблюдать за собой: в какое время тяжелее всего выполнять работу, требующую сосредоточения или умственного напряжения.

Определив хронотип, человек получает знание о золотых часах своей максимальной когнитивной активности. Основываясь на этом, можно грамотно планировать день. Например, распределить задачи так, чтобы новые/важные/сложные делать в золотые часы, а менее важные дела и рутину можно выполнять в часы спада. Таким образом, высок шанс сделать гораздо больше за меньшее количество времени, а главное делать это с меньшим сопротивлением.

ставь реакцию, если этой осенью ты:

😎 — чист, свеж, светел
👾 — хандришь
🤓 — справляешься без сов, жаворонков и голубей

Про тест-анализ

А вы любите тест-анализ также, как люблю его я? Собрала в тексте самые важные поинты на эту тему.

Тест-анализ — это первый этап в процессе тестирования, на котором тестировщик определяет объекты тестирования.

Объекты тестирования — это части приложения, которые нужно проверить.

Четкое определение объектов гарантирует, что ничего не будет пропущено при тестировании

На этапе тест-анализа главная задача тестировщика: собрать как можно больше информации об объекте тестирования.

Источниками информации могут быть:

🔘 Техническое задание
🔘 Макеты пользовательского интерфейса
🔘 Внутренняя база знаний проекта
🔘 Схожие задачи в баг-трекинговой системе
🔘 Коллеги: аналитики, разработчики и т.д

После того, как тестировщик определился что он будет тестировать, можно переходить к декомпозиции требований.

1. Декомпозиция — это подход тест-анализа, при котором тестировщик разбивает крупные объекты тестирования на более мелкие. Так проще проектировать проверки.

🟢Требования декомпозируют до атомарного уровня так, чтобы поделить их ещё раз было уже нельзя

🟢Требования декомпозируют в рамках существующего описания

Пример декомпозиции:

В требованиях сказано, что поле "Имя" формы предзаказа принимает только русские и английские буквы от 2 до 20 символов. Декомпозиция требований будет выглядеть так:

🔘 буквы русского алфавита

🔘 буквы английские алфавита

🔘 количество символов 👇

〰️ меньше 2
〰️ от 2 до 20
〰️ больше 20

❗️Это и есть атомарный уровень: разбить требование ещё раз не получится.

2. Визуализация

Диаграмма связей или mindmap — это способ визуализации требований. Создать такую карту можно после декомпозиции или параллельно с ней.

Визуализация особенно хорошо работает с объемными требованиями, где всегда высок риск упустить что-то важное. Еще лучше работает, когда требований нет вовсе :)

Создать mindmap можно в разных инструментах. Например:

🔵 XMind
🔵 Miro
🔵 draw.io

3. Поиск серых зон

После того, как все требования декомпозированы и перенесены в визуальную плоскость, следует еще раз просмотреть mindmap на наличие «серых зон».

Серые зоны — это пропуски, неточности и противоречия в требованиях, которые могут привести к неправильному пониманию и упущениям при тестировании.

Признаки серых зон:

💭Неясные формулировки
💭Противоречащие требования
💭Пропущенные сценарии

Решение:

💭Обратиться к аналитику для уточнения требований
💭Задокументировать уточнения (в ТЗ, задаче, письме)

Тест-анализ считается завершенным, когда выполнены три ключевых условия: требования полностью декомпозированы, объекты тестирования визуализированы и все серые зоны устранены.

✔️ Декомпозиция
Все требования разбиты до атомарного уровня

✔️ Визуализация
Структура приложения наглядно отображена

✔️ Поиск серых зон
Противоречия разрешены и задокументированы

Что почитать:

🔹Книга «Интеллект-карты. Полное руководство по мощному инструменту мышления», Тони Бьюзен
🔹Статья «Agile in IT: 8 методов декомпозиции задач»
🔹Статья «Mind map в помощь тестировщику»
🔹Статья «Mind map в тестировании, или лёгкий способ тестировать сложные приложения»

#куашная

Про пользу профессиональных сообществ

Уже несколько лет я являюсь активной участницей разных сообществ. Все начиналось с прекрасного комьюнити QA Sisters. Долго почитывала его, стесняясь вовлекаться, а потом обстоятельства бахнули по голове, и именно туда я пошла за поддержкой. Писала об абьюзе на работе здесь и здесь.

Помимо прикладных советов, например, как себя отстоять, я получила много добрых слов, при личных встречах на меня смотрели по-настоящему сочувствующие глаза, и, главное, понимание: я не одна.

Именно на внутренней конференции QA Sis я впервые рассказала свою историю, и она перестала довлеть надо мной. Опыт получился чрезвычайно терапевтичным и привел меня в другое бережное сообщество — Women in Tech.

А потом и вовсе мне захотелось «выйти в видимое поле»: выступать, вести канал, менторить. Но внутренняя самозванка душила. И снова сообщество поддержало меня, буквально декларировав: «Ссы, но делай! Мы поддержим». Писала об этом в посте про достаточность. Кстати, первые подписчики пришли именно из этих профильных чатиков. Спасибо вам!

Не у каждого сообщества безопасно просить поддержку. Речь в этом тексте идет про сообщества, которые имеют внутренние правила, культуру и строгую модерацию.

Вот в чем могут помогать сообщества:

⚡ Быстрая обратная связь
Сообществу можно задать вопрос — и, скорее всего, отыщется тот, кто уже проходил через подобное. Опыт коллег сильно экономит время и (!) нервы

📍 Актуальные знания
Новости, обновления, тренды — все это активно обсуждается в профессиональном комьюнити. В некотором смысле в сообществе чувствуется пульс индустрии

💬 Нетворк и возможности
В чатах рождаются коллаборации, приглашения на конференции и новые офферы. Иногда достаточно просто быть активным, чтобы тебя заметили

❤ Поддержка и признание
Именно профессиональное окружение напоминает, зачем ты вообще всем этим занимаешься, возвращает значимость и помогает авторизовать собственные результаты

↗️ Рост через чужой опыт
Рост других может стать мотивацией к собственным изменениям

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

Этот пост — благодарность всем, кто создает, развивает, модерирует и активно участвует в сообществах. Вы делаете доброе дело! ❤️

а вы состоите в профессиональных сообществах? что они дали лично вам — знания, поддержку, уверенность?

Тестирование и дзен

Один из принципов тестирования гласит:

исчерпывающее тестирование невозможно

Почему нельзя проверить все?

🔵Количество возможных комбинаций входных данных, состояний системы и пользовательских сценариев может быть бесконечным

🔵Ограниченные ресурсы: время, команда, инфраструктура

🔵ПО постоянно изменяется, что делает полный охват тестами невозможным

Как же принять тот факт, что некоторые баги никогда не будут обнаружены?

Я думаю, этот принцип напоминает тестировщику, что важно стремиться не «проверить все», а протестировать продукт эффективно: чтобы выявить максимальное количество проблем с минимальными затратами времени и ресурсов.

Как тестировать эффективно?

✅Определять приоритеты.
Тестировать критичные и наиболее используемые функции в первую очередь

✅Использовать техники тест-дизайна. Классы эквивалентности, граничные значения, попарное тестирование помогают сократить количество тестов без потери качества

✅Анализировать риски.
Уделять больше внимания тому, что может нанести наибольший ущерб пользователям или бизнесу

✅Комбинировать ручное и автоматизированное тестирование.
Этот подход позволяет экономить ресурс, например, при повторяющихся сценариях. Автотесты дают скорость и стабильность,
ручное тестирование — гибкость и глубину. А вместе они создают качественный и надёжный процесс тестирования.

Попытка добиться абсолютной чистоты кода — утопична. Но что действительно под силу тестировщику: сделать продукт максимально удобным и стабильным в рамках реальных условий. Поэтому, считаю: умение ловить дзен — такой же базовый минимум в нашей работе, как и крепкие знания теории тестирования.

а вы что думаете, друзья?

#куашная

Что общего у exploratory testing и турецкого базара?

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

Писала о похожем опыте в посте про Грузию. И, если Грузия для меня про вкусы и текстуры, то Турция — про шум, движение и энергию. Вообще, Стамбул — один сплошной базар :)

Как и подобает всякому базару — хаоса здесь предостаточно. Шум заглушает все: где-то зазывают попробовать гранатовый сок, где-то — торгуются за специи. Много суеты. Запахи накладываются друг на друга. Полный расфокус. Первое впечатление — система сбоит 😳

Однако со временем культурный шок сменяется пониманием: передо мной живая, пульсирующая система, где есть структура и определенный порядок: здесь — лавки с тканями, там — специи, дальше — медь и керамика. Наконец, начинаешь распознавать закономерности и сигналы, улавливаешь правила и следуешь им.

Суть отделяется от шума

И вот что я подумала: турецкий базар — лучшая метафора для exploratory testing. Абсолютно серьезно! У исследовательского тестирования и поиска вещиц на рынке много общего.

Аналогия простая: приложение — это огромный рынок: шумный, пестрый, непредсказуемый. Каждый раздел системы — новая улочка, где продавцы так и норовят завернуть туриста в свою лавочку и заодно продать ковер, который точно не планировался к покупке. Но у опытного туриста только одна цель, например, отыскать редкий винтажный костяной фарфор. Никаких ковров, специй и блестящих вещей по пути — времени мало, задача четкая.

Это и есть классическая методика туров в исследовательском тестировании: четкая цель + сфокусированное движение по продукту.

Подробнее можно почитать здесь и здесь. Также мне нравится доходчивый разбор этой темы в книге Назиной «Тест-дизайн». И, конечно, можно почитать автора концепции исследовательских туров James A. Whittaker, книга «Exploratory Software testing».

На практике это выглядит так:

😉 Определение цели тура

На рынке: мне нужен фарфор, не отвлекаюсь на пахлаву

В тестировании: проверить все сообщения об ошибках, не останавливаясь на детальном тестировании, но замечая очевидные вещи

🥵 Продумывание плана действий

На рынке: если фарфор где-то и есть, то ближе к антикварщикам. Ищем сначала их

В приложении: начинаем с основной функциональности системы и методично проверяем все сообщения об ошибках, вводя невалидные данные

😳 Результат

На рынке: фарфор найден, турист доволен, кошелек почти цел

В тестировании: нужная функциональность изучена, гипотезы проверены, риски зафиксированы

Я думаю, тестировщик, как опытный турист на базаре, должен уметь улавливать важное в шуме и суете, а затем шаг за шагом превращать хаос в порядок. А ещё — знать, когда стоит торговаться, а когда пора откланиваться с улыбкой :)

#инсайтошная

Пост-знакомство 🎩

Привет! Время познакомиться поближе.

Я Алина, QA в домене FinTech. Вот уже 8 лет я тестирую разное ПО и очень люблю то, что делаю.

Второй год являюсь ментором в программе Women in Tech, помогаю организовывать разные it-мероприятия, курирую доклады на проф.конференциях в секции QA.

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

Я задумывала этот канал как пространство для обмена мыслями, идеями и опытом. Поэтому, охотно приглашаю вас в комментарии для дискуссий :) С единственным правилом: оставаться конструктивным и уважительным по отношению к другому.

В канале есть навигация:

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

💡💡💡 Дружеское напоминание в предновогодней суматохе:

ты сделал все, что мог в тех обстоятельствах, которые были

Тестирование в 2026: Manual VS Auto

Некоторое время назад мы с Олей Артемьевой из «Тестирование и жизнь» сделали статью о том, нужно ли тестировщику уметь автоматизировать в 2026. Короткий ответ: нет.

Этот пост — продолжение темы «Manual VS Auto», но с противоположной точкой зрения.

В рамках рубрики #интервьюшная поговорили с Олей Ермолаевой — QA Head в Lamoda, автором канала «QA FAQ».

Оля — нанимающий менеджер и в этом тексте подробно расскажет:

⚡ какие навыки станут must-have для QA в ближайшие несколько лет
⚡ кто такой идеальный QA
⚡ на что в резюме обращает внимание нанимающий менеджер
⚡ каких тестировщиков не стоит брать в команду

и самое главное: почему считает необходимым тестировщику развиваться в инженерной части.

Все это и многое другое в статье telegraph.

ставь 🔥 животворящий и пиши в комментариях свое мнение