«Хороший QA — не полицейский, а адвокат качества»: Анастасия Шарикова об IT и том, почему тестировщики не просто «придираются» к продукту

Настя пришла в IT почти случайно: перед собеседованием в QA она всю ночь читала форумы и книги, потому что почти ничего не знала о профессии. С тех пор прошло много лет — сейчас Настя работает операционным руководителем в Яндексе, преподает в университетах и консультирует специалистов, а также ведет тг-канал Yet another QA о тестировании и IT.
Мы поговорили с ней и узнали:

• почему тестировщик — не самый легкий вход в IT;
• как ИИ помогает в работе и как вредит;
• что такое айти-снобизм и кто им страдает;
• и почему не задавать вопросы очень плохо.


Как ты пришла в IT и почему выбрала именно QA? Чем занимаешься помимо работы?

В IT я пришла отчасти случайно и отчасти нет — технологии я любила всегда, но про профессию QA я на тот момент не знала, так что к собеседованию готовилась всю ночь — читала все форумы и книги, до которых смогла дотянуться. Меня сразу же взяли, и дальше уже пошло-поехало, новая профессия меня захватила. С тех пор прошло много времени, было много компаний, должностей и проектов — в РФ и за рубежом, и я рада, что начала именно с QA. Кроме работы в Яндексе я преподаю — в университетах, таких как Вышка и ТюмГУ, и в онлайн-образовании, а также консультирую в частном порядке.
Помимо работы, конечно же, есть и другие интересы — например, современная архитектура, вино и история повседневности. А, и недавно еще сдала на права капитана яхты, чем очень горжусь!

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

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

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

Есть ли у тебя профдеформация? Как проявляется?

Есть, и операционка наложила свой отпечаток сильнее всего.
Думаю, что я окончательно разучилась принимать «все нормально» на веру. Когда мне говорят, что все под контролем, внутри включается: «Под контролем — по каким метрикам, кто отвечает, что будет, если что-то пойдет не так?»
И еще одна, которую я про себя называю профдеформацией ответственности: если рядом что-то идет наперекосяк — встреча без повестки, задача без владельца, тусовка без списка покупок — мне физически некомфортно, и рука тянется навести порядок, даже когда меня об этом никто не просил.

Есть мнение, что тестировщик — самый легкий вход в IT. Правда ли это? Назови топ-3 мифа о работе тестировщика

Конечно, не правда — про это могу говорить часами, но лучше отвечу про мифы.

Миф 1: «Тестировщик просто кликает по кнопкам». На самом деле хороший QA-инженер работает с качеством на всех этапах разработки продукта: например, моделирует, как система может повести себя неожиданно, приоритезирует риски, придумывает сценарии, до которых не додумался ни аналитик, ни разработчик, занимается качеством до и после написания непосредственно кода. Это интеллектуальная работа, а не механическая, еще и разная на каждом проекте и продукте. Потому и ИИ не заменяемая

Миф 2: «QA — это трамплин, чтобы потом стать разработчиком». Тестирование — самостоятельная зрелая профессия со своей глубиной: тест-дизайн, автоматизация, нагрузка, безопасность, работа с требованиями. Из QA можно «переехать» куда угодно, но это не «зал ожидания» — это отдельный путь, на котором есть свои сеньоры и эксперты.

Миф 3: «Тестировщик — это тот, кто мешает и находит, к чему придраться». Наоборот: наша задача — не поймать разработчика на ошибке, а защитить пользователя и продукт. Хороший QA — это не полицейский, а адвокат качества, и работает он в одной команде с разработкой, а не против нее.

Как ты относишься к ИИ и вайбкодингу в работе тестировщика — помогает или мешает, как эффективно интегрировать ИИ в работу?

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

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

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

Ты часто пишешь про этику в IT и айти-снобизм. Что это такое, сталкивалась ли ты с ним сама и как с ним бороться?

Айти-снобизм — это когда знания и опыт превращают в инструмент возвышения над людьми, а не помощи им. Я сталкиваюсь с ним до сих пор, и даже в мою сторону. И честно скажу: чаще всего вижу, что такой снобизм часто идет не от самых сильных, а от неуверенных — тем, кто действительно много знает, обычно нечего доказывать. Он проявляется в мелочах: закатить глаза на «глупый» вопрос новичка, ответить так, чтобы человек почувствовал себя дураком, делить людей на «нормальных инженеров» и всех остальных, обесценивать нетехнические роли или тех, кто пришел в IT не «классическим» путем. Это культура, где страшно спросить, — а страшно спросить — значит, ошибки прячут, и в итоге проигрывают и продукт, и команда.

Как бороться: во-первых, культурой «глупых вопросов не бывает» — начинается она с руководителя и сеньоров, которые сами показывают, что не знать нормально. Во-вторых, разделять критику работы и критику человека: можно жестко, но вежливо, разбирать тот же самый код и при этом уважать того, кто его написал. И в-третьих, помнить, что каждый сеньор когда-то не знал, что такое git, — и вести себя с новичком так, как хотелось бы, чтобы вели себя с тобой тогда. Терпеть не могу подход «я страдал, и вы будете страдать»!

По мотивам твоей статьи на Хабре о найме джунов: какие ошибки чаще всего совершают новички в тестировании? Дай советы тем, кто только начинает путь в IT

Если говорить о частых ошибках, то новички, во-первых, молчат, когда не поняли. Боятся показаться некомпетентными и в итоге делают не то. Непонятая задача, сделанная идеально, — все равно потерянное время. Во-вторых, думают, что за ними «не следят», и работают откровенно плохо — авось и так сойдет. Часто они онятся за инструментами, а не за мышлением. Учат десять фреймворков, но не умеют задать вопрос: «А что мы вообще проверяем и зачем?»

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

Учись писать так, чтобы тебя было легко понять. Четкий баг-репорт, аккуратный комментарий, внятная формулировка — это половина профессии.

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

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



Подписывайтесь на наши соцсети:

— Телеграм

 ВК

 Возможно, вас также заинтересует: