Yet another 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