Yet another QA

Про преподавание, качество, ИИ и конференции

Не так давно я начала преподавать ещё и в ИТМО, чему очень рада ❤️
Сейчас довольно много говорю со студентами про тестирование, причём среди них есть и те, кто только начинает разбираться в профессии, и уже опытные специалисты, с которыми интересно обсуждать их собственную практику.

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

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

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

В этом смысле очень в тему программа Heisenbug 2026 Autumn, который пройдёт 16–17 октября в Санкт-Петербурге и онлайн: нашла там несколько выступлений, которые хорошо перекликаются с тем, что мы сейчас обсуждаем на занятиях.

Вот что я бы выделила в программе 👇

• «Как мы тестируем робота-доставщика» — Роман Еловских, Яндекс.
Здесь мне особенно интересно, как меняется стратегия тестирования на разных стадиях жизни продукта, потому что на таком конкретном примере хорошо видно, почему нельзя один раз придумать подход к качеству и дальше просто всегда ему следовать.

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

• «Кто отвечает за качество, когда код пишут агенты?»
Дискуссия о том, как меняется роль QA и что остаётся ответственностью человека, когда агенты уже участвуют и в разработке, и в проверках, то есть как раз про те вопросы, с которыми нам всё чаще приходится разбираться. Я б тут конечно подискутировала, жаль не зовут 🥲

• «AI-агенты для Auto QA: от хаотичных запросов к системной работе с навыками» — Никита Осипов, Т-Банк.
Про практическую сторону работы с агентами: как дать им нужный контекст, организовать работу и проверять результат, чтобы из этого получался полезный инструмент, которым можно пользоваться в своём проекте.

Мне такие темы нравятся ещё и тем, что после них можно вернуться к своей работе и посмотреть, что у тебя уже хорошо устроено, а что имеет смысл пересмотреть с учётом новых возможностей и задач. Если вы сейчас тоже об этом думаете, оставляю полную программу Heisenbug — можно посмотреть, что из неё ближе к вашим продуктам и вопросам. Кстати, думаю и сама наведаюсь в Питер - не все ж там только пить 🌚

Быстро или качественно, вот в чем вопрос

Часто сильного специалиста по качеству описывают как человека, который всегда отстаивает более глубокое тестирование, требует больше времени и готов остановить релиз из-за рисков.
И это, конечно, важно.

Но иногда я вижу посты лидов в духе: «Да, из-за меня релизы выходят медленнее. Зато качество не страдает». И всё чаще думаю: а точно ли это лучшее позиционирование хорошего лида?
Быть неудобным для бизнеса - нормально. Иногда релиз действительно нужно остановить. Но сильный лид - это не только человек, который умеет сказать: «Нам нужно больше времени».
Это ещё и человек, который знает, как это время сократить.
Не просто настаивает на полном регрессе, а понимает, как сделать его быстрее. Выстраивает процессы так, чтобы сокращались релизный цикл и time to market - без незаметного обмена качества на скорость.

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

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

UPD. Если что, это не призыв фигачить как попало с низким качеством, это про то, как можно сохранять его с другими процессами 😅

С прошлого года у меня на стене висит плакат Age of Empires II

Появился он довольно случайно: я помогала с мероприятием на Big Tech Night, на котором можно было поиграть в винтажные игры, а в конце мне его подарили. AoE2 - моя любимая игра, поэтому из всего конференционного мерча именно этот плакат неожиданно оказался настоящим сокровищем. Теперь я регулярно смотрю на него и радуюсь

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

Наверное, поэтому новость о следующей конференции я восприняла не как очередной анонс в календаре
В этом году Big Tech Night возвращается уже как Deep Tech Night. Вместо попытки охватить весь IT-мир - глубокое погружение в AI (куда уж без него нынче) и в то, как он меняет продукты, разработку и инфраструктуру.
В программе - путь Алисы от поиска к агентам, AI-управление Лавкой, роботы в реальном мире, генеративные рекомендательные системы и честный разговор о влиянии AI на продуктивность разработчиков. Об этом будут говорить Алексей Гусаков, Павел Капля, Стас Макеев, Сергей Мельник, Андрей Попов и другие коллеги из Яндекса

Что еще круто - хэдлайнером станет Мо Гавдат, бывший Chief Business Officer Google X. Его тема - что ждёт нас после первого поколения AI-систем и как изменится сама роль разработчика.
Кажется, главный вопрос здесь уже не в том, умеет ли AI помогать человеку, бизнесу и ИТ, интереснее, что произойдёт, когда он сам станет частью инфраструктуры и начнёт управлять процессами вокруг нас. Или за нас?

Посмотрим 5 сентября, может и в этом году появится какой-нибудь артефакт, который останется со мной надолго

Про реверс, тестирование и неудобные вопросы

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

И тут невозможно не увидеть параллель с QA. Для реверс-инженера отсутствие документации не конец исследования, а его начало. Устройство само становится источником правды. Да и в QA примерно так же: требования описывают (если они вдруг есть), как система должна работать, а сам продукт показывает, как она работает на самом деле, и вот расхождение между этими двумя версиями обычно самое интересное.
По сути, мы постоянно занимаемся маленьким реверсом, когда спрашиваем:
• что здесь происходит на самом деле?
• какие предположения зашиты внутрь?
• что будет, если пользователь сделает «неправильно»?
• где заканчивается ожидаемое поведение и начинается случайность?
• сможем ли мы починить систему, если её автор завтра исчезнет?

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

Если на вопрос «почему мы делаем именно так?» отвечают «исторически сложилось», перед нами уже не процесс, а объект для реверс-инжиниринга. Остаётся изучать логи, зависимости, исключения и людей, которые знают тот самый секретный порядок действий, но нигде его не записали - у меня в операционке такое каждый день, реально!

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

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

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

Не могу не поделиться: будьте бдительны при поиске работы 💪🏻

Про ИТ и не ИТ одновременно

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

Так вот: в Genshin скоро выходит новый регион, «как бы славянский». И цепляет там не оружие и не сюжетка, а Царица Анастасия, а один вопрос, от которого мне сложно отделаться: а КАК это переведут и что там вообще в оригинале на китайском?

Славянский колорит это же не список слов «изба-балалайка-водка» и медведи в локациях. Это стилистика, история, фольклор, полутона, бессменные правители, в общем в малину улететь легко. Локализация игр вообще одна из самых недооценённых сложностей индустрии: ты переносишь не текст, ты переносишь целый МИР. И всегда что-то теряешь по дороге, к сожалению. А может и приобретешь, кстати!

И тут очень в тему попалась книга «Искусство утраты». Само название уже шикарная метафора перевода, по сути книга это нон-фикшн именно про локализацию игр. Автор на конкретных кейсах показывает, почему игру нельзя «просто перевести»: как по-разному адаптировали названия песен в Cyberpunk 2077, сколько «загубленных» русских переводов пережила GTA: San Andreas и как с китайского тащат на русский игры HoYoverse (ага, это делают Genshin, так что круг замкнулся сам собой).

Главная мысль оттуда: любая локализация это искусство осознанной потери. Сохранить всё нельзя, поэтому приходится решать, чем пожертвовать, чтобы главное всё-таки дошло до человека на другом языке. Не «как перевести идеально», а "потрачено" и что можно "добавить"

Ну вот и ровно то же самое происходит в работе каждый день. Берёшь смысл из одного процесса и переносишь в другой, и каждый раз выбираешь, что тут должно остаться, а чем можно пожертвовать. Смотришь на красивый снежный игровой регион, а по факту смотришь в зеркало, блин.

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

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

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

Мы поговорили с ней и узнали:

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

————————————

Как пришла в IT 🖥

Технологии я любила всегда, но про QA тогда не знала, поэтому к собеседованию готовилась всю ночь. Меня сразу взяли, и дальше пошло-поехало: профессия меня захватила. За это время были разные компании, должности и проекты в России и за рубежом.

Кроме Яндекса я преподаю и консультирую. Вне работы люблю современную архитектуру, вино, историю повседневности и недавно получила права капитана яхты, чем очень горжусь.

Про работу в Яндексе 👮‍♂️

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

О профдеформациях тестировщика 🧩

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

Три мифа о тестировщиках 🧠

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

Об ИИ и вайбкодинге 🤖

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

Про айти-снобизм 📌

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

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

Главные ошибки джунов 🐣

Молчат, когда не поняли. Непонятая задача, сделанная идеально, — все равно потерянное время.

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

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

————————————

Полная версия интервью на сайте

Это рубрика #амби_ток, в которой мы говорим с людьми из разных сфер

Хотите рассказать свою историю? Пишите 👉 @ambivert_client_bot

«Мы за качество» — а качество чего?

QA, DoD, ретро, метрики — слово «качество» звучит на каждом созвоне. Но стоит спросить - качество чего, начинается: у кого-то это отсутствие багов, у кого-то — скорость релиза, у кого-то — что заказчик не жалуется, у кого-то — красивый код.

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

Прежде чем в сотый раз сказать «нам важно качество» — стоит договориться, качество чего вы измеряете и для кого.

Страх и ненависть во внедрении LLM

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

Давайте разбираться в рубрике #о_сложном_на_пальцах, что на самом деле происходит

Проблема на входе и выходе

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

Но что происходит, когда это часть большого производственного процесса?

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

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

Куда смещается нагрузка

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

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

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

Системная задача

LLM нельзя эффективно воткнуть в середину процесса, не меняя ничего вокруг. Это не ускорение , просто перенос проблем на другое место. И ещё вопрос: а там ли вообще узкое место? Какой смысл, если разработчик с LLM пишет в три раза больше кода, а этот код всё равно упирается в ревью и тестирование?

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

Куда можно углубиться?

🔴Лонгрид архитектора T-банка про переход от Software Engineering 1.0 к Software Engineering 2.0. Вызовы, ограничения, подходы.

🟡Хороший и емкий разбор теории ограничений в жизни и почему писать больше кода не решает всех проблем (внезапно!)

#объясняем_на_пальцах

Новое - хорошо забытое старое

В мессенджерах активизировались «бухгалтеры» - не ведитесь, это спам, и предупредите менее знакомых с технологиями близких, которые могут поверить хакерам 🙏🏻

Пятничное философское

Всякое я в ИТ повидала, но что никогда не пойму - так это логику людей, которые откликаются на вакансию в определенную компанию, получают отказ (по итогам собеса или по резюме), после этого пишут агрессивный разгромный обвинительный пост про эту компанию в профессиональной (!) соцсети о том, какие неприятные непрофессиональные гады работают в отказавшей компании, чтобы им пусто было, а потом упорно продолжают откликаться в нее же, к тем же непрофессиональным гадам.

Казалось бы, ну отказали, если хочешь работать - прокачайся, приходи снова, может и сложится! Или сделай вывод, что не твое, обругай, раз по делу - но зачем тогда стучаться к таким неприятным непрофессионалам?
Загадочно!

Ожидание и реальность: Heisenbug

Всегда очень интересно сравнивать свои ожидания о том, что будет интересно на конфренции, и что в итоге понравилось больше всего. У меня редко все совпадает, и даже не только в плане самой программы, но и в плане ожиданий от формата и нетворкинга!
Так что решила вам рассказать, что меня заинтересовало, и уверена, может быть вдохновляющим и для других:
• Инструменты тестировщика 2026 - супер-полезный доклад про прикладные инструменты для тестировщиков от Юлии Атлыгиной! О чем-то я знала давно, что-то увидела новое, но уверена, что под рукой такое иметь надо. А чего стоит только "Периодическая таблица инструментов"!
• С одного взгляда: как работает и тестируется биометрия - просто очень интересно, как же тестируется биометрия. Меня всегда волновало, например, как платят "улыбкой" близнецы. Кстати, фото под постом как раз с этого доклада)
• Игры по правилам: тест-дизайн в мире хаоса геймдева - классный разбор тест-дизайна, я бы посоветовала его посмотреть новичкам, которым интересно понять, как применять тест-дизайн к чему-то, кроме банальных формочек. Кстати, в комментариях к последнему посту в канале @gameqachannel Алексей поделился еще одной записью другого доклада. Рекомендую!

А еще я была очень рада увидеться со своими знакомыми - вы чудо! Так что спасибо организаторам)
Все презентации уже доступны на странице конференции, и да, это не реклама 💅🏻

Heisenbug 2026 Spring: конференция по тестированию не только для тестировщиков

Как применять LLM в тестировании? Почему автотесты могут стать уязвимостью? И как строить тестовую инфраструктуру, которая не разваливается под нагрузкой? Эти и другие вопросы будут разбирать на Heisenbug этой весной.

📅 27–28 апреля, Москва + онлайн

В программе: инструменты, архитектура тестовой инфраструктуры, безопасность, производительность и реальные кейсы из продакшена. Также расскажут про применение AI в QA и тесты ИИ-агентов.

А вот мой ТОП докладов:
1) LLM'изация тестирования в Яндексе: измеряем эффект от AI в команде из 1000+ QA-инженеров - тут, конечно, первая мысль была ПОЧЕМУ ОН А НЕ Я. Но ничего, наша команда тоже скоро расскажет про наш супер-проект 💪🏻, а пока послушаем и поддержим коллегу!
2) QAртирник: как понять, что меня собираются уволить - я была искренне удивлена, увидев такую тему на гейзенбаге: ведь обычно тут только технические темы, а тут мало того, что не техническая, да еще и такая актуально-провокационная!
3) Как тестируют квантовые компьютеры - потому что я понятия не имею, как, а вдруг пригодится!

Собственно, буду рада увидеться со знакомыми и завести новые контакты на конфе 🚀

Спасибо всем участникам конкурса - за такие живые и искренние доводы за победу!
Было очень сложно выбрать, но победитель в этот раз только один - прекрасная девушка с именем на букву О 🔥
Скоро я с тобой свяжусь!

Кстати, уже готовлю пост про всякие интересные забытые и не очень технологии - stay tuned

👉 Несу анонс конференции от дружественного сообщества тестировщиц - QA Sis Conf #4! 👉

Предыдущие три сезона конференция проводилась только для состоящих в сообществе QA Sisters, но теперь мы готовы расширить круг участниц и хотим дать возможность девушкам других IT-профессий тоже почерпнуть что-то полезное для себя 💜

🔥 В программе конференции:

👉 31 доклад! из них:
👉 12 экспресс докладов, максимум пользы за минимальнное время
👉 19 полноразмерных докладов с глубоким погружением в тему
👉 Круглый стол о CI/CD
👉 Воркшоп IAmRemarkable
👉 Тренинг против синдрома самозванки


🔥 Про что поговорим:

👉 Софт-скиллы:
Навыки психологической гибкости, возвращение к жизни после выгорания, как сохранять профессиональную устойчивость в мире неопределенности
👉Харды и тулы:
Девтулс, Playwright, CI/CD, вебвью, графана, вебсокеты, кафка, юнит-тесты
👉 Развитие карьеры:
От основ к лидству и обратно, как проводить собеседования - и как проходить собеседования, построение ИПР "снизу" и как создать профиль в линкедин, который работает на вас
👉Построение процессов:
Взаимодействие между куа, техподдержкой и другими стейкхолдерами, решение конфликтов в команде, как собрать метрики тестирования и превратить их в свои достижения
👉Новые технологии:
AI LLM тестинг и внедрение ИИ в тестирование

🔥 Когда и где?

👉 28 марта - 18 апреля
👉 Стоимость билета 3000 рублей, пакет мерча - 2300 рублей.
👉 Конференция проходит онлайн в зуме и телеграме
👉 Подробности, программа и расписание: https://qa-sisters.com/qa-sis-conf-4

🔜 Покупка билетов через бота: @QA_Sisters_Conf_Bot


А еще я провожу розыгрыш билета! Для того, чтобы в нем поучаствовать, нужно ответить на вопрос "Почему билет должен достаться именно тебе?" в форме по ссылке до 20 марта, а 21 марта я подведу итоги и вручу приз победительнице 🚀
Лайки-шеры-репосты приветствуются ❤️

Пятничное про вайбкод

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

Тестировать вайбкод (код, сгенерированный нейросетями) с помощью нейросетей — плохая идея по следующим причинам:

1. Непредсказуемость на граничных условиях, плохая работа с тест-дизайном
Нейросети хорошо справляются с типовыми сценариями, на которых они обучались, но часто «проваливаются» в нестандартных ситуациях. Сгенерированный код может не учитывать:
* деление на ноль;
* обработку `null/undefined`;
* переполнение буфера;
* экзотические пользовательские сценарии
2. Иллюзия корректности кода
ИИ может сгенерировать код, который выглядит логичным, но:
* ссылается на несуществующие библиотеки, методы или API;
* содержит синтаксические или логические ошибки, которые проявляются только в определённых условиях
3. Проблемы безопасности
Нейросети не различают «работающий» и «безопасный» код. Они могут предложить решения, уязвимые к:
* SQL-инъекциям;
* XSS-атакам;
* небезопасной десериализации
4. Архитектурная хрупкость
ИИ не понимает контекста всего приложения:
* может сгенерировать функцию, которая нарушает принципы SOLID;
* создаёт избыточные зависимости;
* дублирует уже существующую логику — это усложняет поддержку и развитие продукта
5. Сложность отладки и сопровождения
Разработчики часто не разбираются в внутренней логике кода, сгенерированного ИИ. Это:
* удлиняет процесс поиска и исправления дефектов;
* усложняет рефакторинг и добавление нового функционала
6. Ошибки в зависимостях
Нейросети могут предлагать несуществующие или уязвимые библиотеки/пакеты. Если разработчик установит такой пакет, это может привести к внедрению вредоносного кода
7. «Галлюцинации» ИИ
Нейросети иногда генерируют код, который выглядит корректным, но не соответствует задаче или содержит логические ошибки. Такое тестирование может пропустить критические дефекты
8. Недостаток комплексного подхода
Автоматизированное тестирование с помощью ИИ часто фокусируется на функциональности, игнорируя:
* тестирование архитектуры;
* проверку форматов данных, протоколов, типов ответов API;
* негативные сценарии и обработку ошибок
9. Ограниченность обучающих данных
Модели ИИ обучаются на исторических данных и могут упускать новые типы ошибок или современные стандарты разработки
10. Риск ложных результатов
Автотесты, запущенные через ИИ, могут давать ложноположительные или ложноотрицательные результаты, создавая иллюзию «готового к релизу» продукта

Тестирование вайбкода должно сочетать автоматизацию (включая ИИ-инструменты) с ручным анализом и комплексными методами (статический анализ, пентесты, регрессионные тесты). Нейросети полезны для ускорения рутинных проверок, но не могут полностью заменить квалифицированного тестировщика.

Скажем спасибо многоуважаемой Алисе за такой детальный разбор и пожелаем нам всем видеть в работе баланс между качеством и скоростью!

Про баланс

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

Но в новом, 2026 году я все больше думаю о том, насколько важен навык поиск баланса вообще во всем - в том числе и в менеджменте, которым я сейчас занимаюсь:
• понимание того, что ты что-то не знаешь - не повод не делать, а то, что ты давно что-то делаешь не повод считать, что можно делать это только так, как оно выстроено сейчас
• глубокая экспертиза изнутри может прекрасно балансироваться перенятием чужого "внешнего" опыта
• важно как уметь работать с долгосрочной стратегией, так и уметь тушить пожары
• здорово стремиться к вежливости, корректности и здравому смыслу, но классно помнить, что конфликт помогает делать команду командой (привет Такману!)

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

В честь субботы - новая экспериментальная (!) рубрика #мемочная