Forwarded from ZenTest (Olga Artemyeva)
Страх и ненависть во внедрении LLM
Возможно, прямо сейчас вам пытаются внедрить AI-инструменты, которые заменят рутинную работу тестировщика. Или требуют срочно это сделать, потому что все побежали и нам надо. На практике это выглядит обычно так: есть какие-то подходы, какие-то результаты, красивое выступление на конференции — а вопрос «почему не взлетело» так и висит в воздухе.
Давайте разбираться в рубрике #о_сложном_на_пальцах, что на самом деле происходит
Проблема на входе и выходе
Весь хайп про «синьор с агентами заменит пять мидлов» обычно про работу одного человека, который решает свою частную задачу — или совсем как с личным проектом, или она изолирована от других участников.
Но что происходит, когда это часть большого производственного процесса?
Когда мы встраиваем AI в конкретную задачу, нужно решить три вещи: качественные данные на вход, промпты для системы и оценка результата. С промптами обычно все более-менее понятно и это основной фокус приложения усилий. Но начало и конец тонут во тьме.
Возьмем пресловутую генерацию тест-кейсов. Редко где требования полные и хорошо структурированные. В реальности это задача в две строчки, переписка в чате, комментарии к коду, обсуждения на синках и куча неявного знания в голове у тестировщика. Весь этот контекст, который собирается во время тест-анализа и тест-дизайна, просто не доходит до LLM. Т-банк в своём инструменте пытается тянуть данные отовсюду — но судя по их собственным результатам, получается не очень.
Куда смещается нагрузка
Чтобы генерировать качественные тест-кейсы, нужно больше работы сдвинуть влево — в анализ и структурирование требований. RAG-системы помогают c дополнительным контекстом, но это отдельная задача, которую тоже надо решать.
Другой путь — генерировать много и отбирать нормальное. Тогда нагрузка смещается вправо, на ревью. И вот тут тоже ловушка: проревьюить чужие тест-кейсов не проще, чем написать свои. Нужно всё равно понять общую картину, выстроить тестовые идеи и оценить покрытие. Эта ментальная модель не появляется сама собой от чтения текста.
По сути, мы меняем творческую работу по дизайну тест-кейсов и простую работу по их оформлению на сложную и часто скучную работу по их ревью. Отсылаю к докладу Наташи про человеческое тестирование в мире искусственного интеллекта.
Системная задача
LLM нельзя эффективно воткнуть в середину процесса, не меняя ничего вокруг. Это не ускорение , просто перенос проблем на другое место. И ещё вопрос: а там ли вообще узкое место? Какой смысл, если разработчик с LLM пишет в три раза больше кода, а этот код всё равно упирается в ревью и тестирование?
Сейчас международные бигтехи ищут ответы на эти вопросы, но общего решения нет. Понятно одно: это долго, сложно и дорого. Гораздо сложнее, чем «давайте генерировать тест-кейсы LLMкой».
Куда можно углубиться?
🔴 Лонгрид архитектора T-банка про переход от Software Engineering 1.0 к Software Engineering 2.0. Вызовы, ограничения, подходы.
🟡 Хороший и емкий разбор теории ограничений в жизни и почему писать больше кода не решает всех проблем (внезапно!)
#объясняем_на_пальцах
Возможно, прямо сейчас вам пытаются внедрить AI-инструменты, которые заменят рутинную работу тестировщика. Или требуют срочно это сделать, потому что все побежали и нам надо. На практике это выглядит обычно так: есть какие-то подходы, какие-то результаты, красивое выступление на конференции — а вопрос «почему не взлетело» так и висит в воздухе.
Давайте разбираться в рубрике #о_сложном_на_пальцах, что на самом деле происходит
Проблема на входе и выходе
Весь хайп про «синьор с агентами заменит пять мидлов» обычно про работу одного человека, который решает свою частную задачу — или совсем как с личным проектом, или она изолирована от других участников.
Но что происходит, когда это часть большого производственного процесса?
Когда мы встраиваем AI в конкретную задачу, нужно решить три вещи: качественные данные на вход, промпты для системы и оценка результата. С промптами обычно все более-менее понятно и это основной фокус приложения усилий. Но начало и конец тонут во тьме.
Возьмем пресловутую генерацию тест-кейсов. Редко где требования полные и хорошо структурированные. В реальности это задача в две строчки, переписка в чате, комментарии к коду, обсуждения на синках и куча неявного знания в голове у тестировщика. Весь этот контекст, который собирается во время тест-анализа и тест-дизайна, просто не доходит до LLM. Т-банк в своём инструменте пытается тянуть данные отовсюду — но судя по их собственным результатам, получается не очень.
Куда смещается нагрузка
Чтобы генерировать качественные тест-кейсы, нужно больше работы сдвинуть влево — в анализ и структурирование требований. RAG-системы помогают c дополнительным контекстом, но это отдельная задача, которую тоже надо решать.
Другой путь — генерировать много и отбирать нормальное. Тогда нагрузка смещается вправо, на ревью. И вот тут тоже ловушка: проревьюить чужие тест-кейсов не проще, чем написать свои. Нужно всё равно понять общую картину, выстроить тестовые идеи и оценить покрытие. Эта ментальная модель не появляется сама собой от чтения текста.
По сути, мы меняем творческую работу по дизайну тест-кейсов и простую работу по их оформлению на сложную и часто скучную работу по их ревью. Отсылаю к докладу Наташи про человеческое тестирование в мире искусственного интеллекта.
Системная задача
LLM нельзя эффективно воткнуть в середину процесса, не меняя ничего вокруг. Это не ускорение , просто перенос проблем на другое место. И ещё вопрос: а там ли вообще узкое место? Какой смысл, если разработчик с LLM пишет в три раза больше кода, а этот код всё равно упирается в ревью и тестирование?
Сейчас международные бигтехи ищут ответы на эти вопросы, но общего решения нет. Понятно одно: это долго, сложно и дорого. Гораздо сложнее, чем «давайте генерировать тест-кейсы LLMкой».
Куда можно углубиться?
#объясняем_на_пальцах
Please open Telegram to view this post
VIEW IN TELEGRAM
❤27🔥8👍3😢1
«Мы за качество» — а качество чего?
QA, DoD, ретро, метрики — слово «качество» звучит на каждом созвоне. Но стоит спросить - качество чего, начинается: у кого-то это отсутствие багов, у кого-то — скорость релиза, у кого-то — что заказчик не жалуется, у кого-то — красивый код.
Мы обсуждаем «качество» как общую ценность, с которой никто не спорит, — и именно поэтому не спорим о сути. А суть в том, что качество не существует в вакууме: только качество конкретного продукта, для конкретного пользователя, под конкретную задачу. Без этого «повышаем качество» — это лозунг, а не цель, и уж тем более не измеримая и достижимая.
Прежде чем в сотый раз сказать «нам важно качество» — стоит договориться, качество чего вы измеряете и для кого.
QA, DoD, ретро, метрики — слово «качество» звучит на каждом созвоне. Но стоит спросить - качество чего, начинается: у кого-то это отсутствие багов, у кого-то — скорость релиза, у кого-то — что заказчик не жалуется, у кого-то — красивый код.
Мы обсуждаем «качество» как общую ценность, с которой никто не спорит, — и именно поэтому не спорим о сути. А суть в том, что качество не существует в вакууме: только качество конкретного продукта, для конкретного пользователя, под конкретную задачу. Без этого «повышаем качество» — это лозунг, а не цель, и уж тем более не измеримая и достижимая.
Прежде чем в сотый раз сказать «нам важно качество» — стоит договориться, качество чего вы измеряете и для кого.
👍35❤10🔥9
Forwarded from Амбиверт
«Хороший QA — не полицейский, а адвокат качества»: Анастасия Шарикова об IT и том, почему тестировщики не просто «придираются» к продукту 👩💻
Настя пришла в IT почти случайно: к собеседованию в QA она готовилась всю ночь, так как почти ничего не знала о профессии. Сейчас Настя работает операционным руководителем в Яндексе, преподает и ведет тг-канал Yet another QA о тестировании и IT.
Мы поговорили с ней и узнали:
• почему тестировщик — не самый легкий вход в IT;
• что такое айти-снобизм и кто им страдает;
• и почему не задавать вопросы очень плохо.
————————————
Как пришла в IT 🖥
Технологии я любила всегда, но про QA тогда не знала, поэтому к собеседованию готовилась всю ночь. Меня сразу взяли, и дальше пошло-поехало: профессия меня захватила. За это время были разные компании, должности и проекты в России и за рубежом.
Кроме Яндекса я преподаю и консультирую. Вне работы люблю современную архитектуру, вино, историю повседневности и недавно получила права капитана яхты, чем очень горжусь.
Про работу в Яндексе👮♂️
Если коротко, я отвечаю за то, чтобы бизнес-процессы и люди работали слаженно, стратегия превращалась в реальность, а бюджеты сходились. В операционку я пришла из управления командами в разработке и тестировании. Иногда думаю, что операционное управление — это то же тестирование, только объект уже не продукт, а работа бизнеса.
О профдеформациях тестировщика 🧩
Я разучилась принимать «все нормально» на веру. Когда мне говорят, что все под контролем, внутри включается: «По каким метрикам? Кто отвечает? Что будет, если что-то пойдет не так?» Если рядом что-то идет наперекосяк, мне физически некомфортно, и рука тянется навести порядок, даже когда меня об этом никто не просил.
Три мифа о тестировщиках 🧠
Первый: «тестировщик просто кликает по кнопкам». На самом деле хороший QA работает с качеством на всех этапах: моделирует неожиданные сценарии, приоритезирует риски и думает о том, как система может сломаться.
Второй: «QA — это трамплин в разработку». Нет, это отдельная зрелая профессия: тест-дизайн, автоматизация, нагрузка, безопасность, работа с требованиями.
Третий: «тестировщик мешает и придирается». Наша задача — защитить пользователя и продукт. Хороший QA — не полицейский, а адвокат качества, и работает он в одной команде с разработкой, а не против нее.
Об ИИ и вайбкодинге 🤖
ИИ усиливает мышление, но не заменяет его. Он помогает с рутиной: черновиками тест-кейсов, логами, автотестами. Но он не понимает контекст так, как человек, и не может ответить на вопрос: «А надо ли это вообще так делать?» Проблемы начинаются, когда ИИ считают оракулом: если не перепроверять, можно получить тесты, которые проверяют не то. С вайбкодингом так же: чем быстрее пишется код, тем важнее человек, который спросит: «А мы уверены?»
Про айти-снобизм 📌
Айти-снобизм — это когда знания используют, чтобы возвыситься, а не помочь. Закатить глаза на «глупый» вопрос, обесценить нетехническую роль, делить людей на «нормальных инженеров» и всех остальных. Я сама с ним сталкивалась, и сталкиваюсь до сих пор. Чаще всего вижу, что такое идет от неуверенных в себе людей. Тем, кто действительно много знает, обычно нечего доказывать.
Это культура, где страшно спросить, а если страшно спросить, значит, ошибки прячут. В итоге проигрывает и продукт и команда.
Главные ошибки джунов 🐣
Молчат, когда не поняли. Непонятая задача, сделанная идеально, — все равно потерянное время.
Думают, что за ними не следят, и работают откровенно плохо. Не бойтесь задавать вопросы: лучше спросить в начале, чем переделывать в конце.
Гонятся за инструментами, а не за мышлением. Учат десять фреймворков, но не умеют задать вопрос: «А что мы вообще проверяем и зачем». Учитесь думать о рисках, писать понятные баг-репорты и фиксировать ошибки. И не слушайте тех, кто говорит, что честным путем работу не найти — эти идеи распространяют те, кому это выгодно.
————————————
Полная версия интервью на сайте
Это рубрика #амби_ток, в которой мы говорим с людьми из разных сфер
Хотите рассказать свою историю? Пишите 👉 @ambivert_client_bot
Настя пришла в IT почти случайно: к собеседованию в QA она готовилась всю ночь, так как почти ничего не знала о профессии. Сейчас Настя работает операционным руководителем в Яндексе, преподает и ведет тг-канал Yet another QA о тестировании и IT.
Мы поговорили с ней и узнали:
• почему тестировщик — не самый легкий вход в IT;
• что такое айти-снобизм и кто им страдает;
• и почему не задавать вопросы очень плохо.
————————————
Как пришла в IT 🖥
Технологии я любила всегда, но про QA тогда не знала, поэтому к собеседованию готовилась всю ночь. Меня сразу взяли, и дальше пошло-поехало: профессия меня захватила. За это время были разные компании, должности и проекты в России и за рубежом.
Кроме Яндекса я преподаю и консультирую. Вне работы люблю современную архитектуру, вино, историю повседневности и недавно получила права капитана яхты, чем очень горжусь.
Про работу в Яндексе
Если коротко, я отвечаю за то, чтобы бизнес-процессы и люди работали слаженно, стратегия превращалась в реальность, а бюджеты сходились. В операционку я пришла из управления командами в разработке и тестировании. Иногда думаю, что операционное управление — это то же тестирование, только объект уже не продукт, а работа бизнеса.
О профдеформациях тестировщика 🧩
Я разучилась принимать «все нормально» на веру. Когда мне говорят, что все под контролем, внутри включается: «По каким метрикам? Кто отвечает? Что будет, если что-то пойдет не так?» Если рядом что-то идет наперекосяк, мне физически некомфортно, и рука тянется навести порядок, даже когда меня об этом никто не просил.
Три мифа о тестировщиках 🧠
Первый: «тестировщик просто кликает по кнопкам». На самом деле хороший QA работает с качеством на всех этапах: моделирует неожиданные сценарии, приоритезирует риски и думает о том, как система может сломаться.
Второй: «QA — это трамплин в разработку». Нет, это отдельная зрелая профессия: тест-дизайн, автоматизация, нагрузка, безопасность, работа с требованиями.
Третий: «тестировщик мешает и придирается». Наша задача — защитить пользователя и продукт. Хороший QA — не полицейский, а адвокат качества, и работает он в одной команде с разработкой, а не против нее.
Об ИИ и вайбкодинге 🤖
ИИ усиливает мышление, но не заменяет его. Он помогает с рутиной: черновиками тест-кейсов, логами, автотестами. Но он не понимает контекст так, как человек, и не может ответить на вопрос: «А надо ли это вообще так делать?» Проблемы начинаются, когда ИИ считают оракулом: если не перепроверять, можно получить тесты, которые проверяют не то. С вайбкодингом так же: чем быстрее пишется код, тем важнее человек, который спросит: «А мы уверены?»
Про айти-снобизм 📌
Айти-снобизм — это когда знания используют, чтобы возвыситься, а не помочь. Закатить глаза на «глупый» вопрос, обесценить нетехническую роль, делить людей на «нормальных инженеров» и всех остальных. Я сама с ним сталкивалась, и сталкиваюсь до сих пор. Чаще всего вижу, что такое идет от неуверенных в себе людей. Тем, кто действительно много знает, обычно нечего доказывать.
Это культура, где страшно спросить, а если страшно спросить, значит, ошибки прячут. В итоге проигрывает и продукт и команда.
Главные ошибки джунов 🐣
Молчат, когда не поняли. Непонятая задача, сделанная идеально, — все равно потерянное время.
Думают, что за ними не следят, и работают откровенно плохо. Не бойтесь задавать вопросы: лучше спросить в начале, чем переделывать в конце.
Гонятся за инструментами, а не за мышлением. Учат десять фреймворков, но не умеют задать вопрос: «А что мы вообще проверяем и зачем». Учитесь думать о рисках, писать понятные баг-репорты и фиксировать ошибки. И не слушайте тех, кто говорит, что честным путем работу не найти — эти идеи распространяют те, кому это выгодно.
————————————
Полная версия интервью на сайте
Это рубрика #амби_ток, в которой мы говорим с людьми из разных сфер
Хотите рассказать свою историю? Пишите 👉 @ambivert_client_bot
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🎉24🔥23❤20🤩2🤔1
Про ИТ и не ИТ одновременно
Иногда случается, что личное и рабочее вдруг поворачиваются друг к другу лицом. Отдыхаешь себе от планирования и встреч, а увлечение подкидывает их же под новым углом.
Так вот: в Genshin скоро выходит новый регион, «как бы славянский». И цепляет там не оружие и не сюжетка,а Царица Анастасия, а один вопрос, от которого мне сложно отделаться: а КАК это переведут и что там вообще в оригинале на китайском?
Славянский колорит это же не список слов «изба-балалайка-водка» и медведи в локациях. Это стилистика, история, фольклор, полутона,бессменные правители, в общем в малину улететь легко. Локализация игр вообще одна из самых недооценённых сложностей индустрии: ты переносишь не текст, ты переносишь целый МИР. И всегда что-то теряешь по дороге, к сожалению. А может и приобретешь, кстати!
И тут очень в тему попалась книга «Искусство утраты». Само название уже шикарная метафора перевода, по сути книга это нон-фикшн именно про локализацию игр. Автор на конкретных кейсах показывает, почему игру нельзя «просто перевести»: как по-разному адаптировали названия песен в Cyberpunk 2077, сколько «загубленных» русских переводов пережила GTA: San Andreas и как с китайского тащат на русский игры HoYoverse (ага, это делают Genshin, так что круг замкнулся сам собой).
Главная мысль оттуда: любая локализация это искусство осознанной потери. Сохранить всё нельзя, поэтому приходится решать, чем пожертвовать, чтобы главное всё-таки дошло до человека на другом языке. Не «как перевести идеально», а "потрачено" и что можно "добавить"
Ну вот и ровно то же самое происходит в работе каждый день. Берёшь смысл из одного процесса и переносишь в другой, и каждый раз выбираешь, что тут должно остаться, а чем можно пожертвовать. Смотришь на красивый снежный игровой регион, а по факту смотришь в зеркало, блин.
В общем такие вот дела - увлечение это не способ отключить голову от работы, а ещё один угол зрения, под которым вдруг видно то, что в упор не замечаешь в привычных задачах. На этой позитивной ноте пойду ловить рыб в игре.
Иногда случается, что личное и рабочее вдруг поворачиваются друг к другу лицом. Отдыхаешь себе от планирования и встреч, а увлечение подкидывает их же под новым углом.
Так вот: в Genshin скоро выходит новый регион, «как бы славянский». И цепляет там не оружие и не сюжетка,
Славянский колорит это же не список слов «изба-балалайка-водка» и медведи в локациях. Это стилистика, история, фольклор, полутона,
И тут очень в тему попалась книга «Искусство утраты». Само название уже шикарная метафора перевода, по сути книга это нон-фикшн именно про локализацию игр. Автор на конкретных кейсах показывает, почему игру нельзя «просто перевести»: как по-разному адаптировали названия песен в Cyberpunk 2077, сколько «загубленных» русских переводов пережила GTA: San Andreas и как с китайского тащат на русский игры HoYoverse (ага, это делают Genshin, так что круг замкнулся сам собой).
Главная мысль оттуда: любая локализация это искусство осознанной потери. Сохранить всё нельзя, поэтому приходится решать, чем пожертвовать, чтобы главное всё-таки дошло до человека на другом языке. Не «как перевести идеально», а "потрачено" и что можно "добавить"
Ну вот и ровно то же самое происходит в работе каждый день. Берёшь смысл из одного процесса и переносишь в другой, и каждый раз выбираешь, что тут должно остаться, а чем можно пожертвовать. Смотришь на красивый снежный игровой регион, а по факту смотришь в зеркало, блин.
В общем такие вот дела - увлечение это не способ отключить голову от работы, а ещё один угол зрения, под которым вдруг видно то, что в упор не замечаешь в привычных задачах. На этой позитивной ноте пойду ловить рыб в игре.
❤46🔥13🤩4
Про реверс, тестирование и неудобные вопросы
Посмотрела документальный фильм о реверс-инжиниринге. Классный, суть простая - чуть больше часа про людей, которые разбирают железо, читают чужой код и пытаются понять, что у системы внутри. Но по факту фильм вообще не только про реверс - он, как мне показалось, про нежелание останавливаться на ответе «оно просто так работает».
И тут невозможно не увидеть параллель с QA. Для реверс-инженера отсутствие документации не конец исследования, а его начало. Устройство само становится источником правды. Да и в QA примерно так же: требования описывают (если они вдруг есть), как система должна работать, а сам продукт показывает, как она работает на самом деле, и вот расхождение между этими двумя версиями обычно самое интересное.
По сути, мы постоянно занимаемся маленьким реверсом, когда спрашиваем:
• что здесь происходит на самом деле?
• какие предположения зашиты внутрь?
• что будет, если пользователь сделает «неправильно»?
• где заканчивается ожидаемое поведение и начинается случайность?
• сможем ли мы починить систему, если её автор завтра исчезнет?
Последний вопрос особенно хорош. В фильме есть мысль о том, что реверс помогает восстанавливать знания, когда документация потеряна, а люди, которые всё создавали, давно ушли. И вот тут я понимаю, что это похоже не только на разработку, но и вообще на любые рабочие процессы.
Если на вопрос «почему мы делаем именно так?» отвечают «исторически сложилось», перед нами уже не процесс, а объект для реверс-инжиниринга. Остаётся изучать логи, зависимости, исключения и людей, которые знают тот самый секретный порядок действий, но нигде его не записали - у меня в операционке такое каждый день, реально!
Отдельно подумала про ИИ и вайбкодинг. Мы и так живём среди огромного количества чёрных ящиков, а теперь научились очень быстро производить новые, и если один чёрный ящик написал код, а другой его проверил, это ещё не обязательно качество. Точнее это точно вообще не про качество, часто это просто два очень уверенных чёрных ящика, которые одинаково не поняли задачу.
Поэтому чем быстрее появляются решения, тем важнее человек, который захочет снять крышку и спросить: «А мы вообще понимаем, что здесь происходит?»
Кажется, хороший тестировщик, реверс-инженер и операционщикв этом очень похожи. Они разбирают системы не ради удовольствия что-нибудь сломать, а чтобы система перестала быть магией. Неудобные вопросы здесь не придирка и не недоверие, а способ позаботиться о пользователе и о тех, кому придётся разбираться со всем этим после нас. А таких вопросов у меня много!
Посмотрела документальный фильм о реверс-инжиниринге. Классный, суть простая - чуть больше часа про людей, которые разбирают железо, читают чужой код и пытаются понять, что у системы внутри. Но по факту фильм вообще не только про реверс - он, как мне показалось, про нежелание останавливаться на ответе «оно просто так работает».
И тут невозможно не увидеть параллель с QA. Для реверс-инженера отсутствие документации не конец исследования, а его начало. Устройство само становится источником правды. Да и в QA примерно так же: требования описывают (если они вдруг есть), как система должна работать, а сам продукт показывает, как она работает на самом деле, и вот расхождение между этими двумя версиями обычно самое интересное.
По сути, мы постоянно занимаемся маленьким реверсом, когда спрашиваем:
• что здесь происходит на самом деле?
• какие предположения зашиты внутрь?
• что будет, если пользователь сделает «неправильно»?
• где заканчивается ожидаемое поведение и начинается случайность?
• сможем ли мы починить систему, если её автор завтра исчезнет?
Последний вопрос особенно хорош. В фильме есть мысль о том, что реверс помогает восстанавливать знания, когда документация потеряна, а люди, которые всё создавали, давно ушли. И вот тут я понимаю, что это похоже не только на разработку, но и вообще на любые рабочие процессы.
Если на вопрос «почему мы делаем именно так?» отвечают «исторически сложилось», перед нами уже не процесс, а объект для реверс-инжиниринга. Остаётся изучать логи, зависимости, исключения и людей, которые знают тот самый секретный порядок действий, но нигде его не записали - у меня в операционке такое каждый день, реально!
Отдельно подумала про ИИ и вайбкодинг. Мы и так живём среди огромного количества чёрных ящиков, а теперь научились очень быстро производить новые, и если один чёрный ящик написал код, а другой его проверил, это ещё не обязательно качество. Точнее это точно вообще не про качество, часто это просто два очень уверенных чёрных ящика, которые одинаково не поняли задачу.
Поэтому чем быстрее появляются решения, тем важнее человек, который захочет снять крышку и спросить: «А мы вообще понимаем, что здесь происходит?»
Кажется, хороший тестировщик, реверс-инженер и операционщикв этом очень похожи. Они разбирают системы не ради удовольствия что-нибудь сломать, а чтобы система перестала быть магией. Неудобные вопросы здесь не придирка и не недоверие, а способ позаботиться о пользователе и о тех, кому придётся разбираться со всем этим после нас. А таких вопросов у меня много!
❤13👍11🔥2
С прошлого года у меня на стене висит плакат 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 сентября, может и в этом году появится какой-нибудь артефакт, который останется со мной надолго
Появился он довольно случайно: я помогала с мероприятием на Big Tech Night, на котором можно было поиграть в винтажные игры, а в конце мне его подарили. AoE2 - моя любимая игра, поэтому из всего конференционного мерча именно этот плакат неожиданно оказался настоящим сокровищем. Теперь я регулярно смотрю на него и радуюсь
Мне вообще нравится, когда от больших событий остаётся что-то маленькое и личное, ведь конференция длится один вечер: вокруг много людей, разговоров, докладов, стендов - а потом всё быстро заканчивается, и через год ты можешь не вспомнить половину программы, зато какая-то случайная вещь на стене возвращает тебя в тот день целиком.
Наверное, поэтому новость о следующей конференции я восприняла не как очередной анонс в календаре
В этом году Big Tech Night возвращается уже как Deep Tech Night. Вместо попытки охватить весь IT-мир - глубокое погружение в AI (куда уж без него нынче) и в то, как он меняет продукты, разработку и инфраструктуру.
В программе - путь Алисы от поиска к агентам, AI-управление Лавкой, роботы в реальном мире, генеративные рекомендательные системы и честный разговор о влиянии AI на продуктивность разработчиков. Об этом будут говорить Алексей Гусаков, Павел Капля, Стас Макеев, Сергей Мельник, Андрей Попов и другие коллеги из Яндекса
Что еще круто - хэдлайнером станет Мо Гавдат, бывший Chief Business Officer Google X. Его тема - что ждёт нас после первого поколения AI-систем и как изменится сама роль разработчика.
Кажется, главный вопрос здесь уже не в том, умеет ли AI помогать человеку, бизнесу и ИТ, интереснее, что произойдёт, когда он сам станет частью инфраструктуры и начнёт управлять процессами вокруг нас. Или за нас?
Посмотрим 5 сентября, может и в этом году появится какой-нибудь артефакт, который останется со мной надолго
deep tech night
Конференция Яндекса о вызовах, с которыми IT-индустрия сталкивается в эпоху AI
❤11🔥5👍2
Быстро или качественно, вот в чем вопрос
Часто сильного специалиста по качеству описывают как человека, который всегда отстаивает более глубокое тестирование, требует больше времени и готов остановить релиз из-за рисков.
И это, конечно, важно.
Но иногда я вижу посты лидов в духе: «Да, из-за меня релизы выходят медленнее. Зато качество не страдает». И всё чаще думаю: а точно ли это лучшее позиционирование хорошего лида?
Быть неудобным для бизнеса - нормально. Иногда релиз действительно нужно остановить. Но сильный лид - это не только человек, который умеет сказать: «Нам нужно больше времени».
Это ещё и человек, который знает, как это время сократить.
Не просто настаивает на полном регрессе, а понимает, как сделать его быстрее. Выстраивает процессы так, чтобы сокращались релизный цикл и time to market - без незаметного обмена качества на скорость.
Тестирование вообще во многом про баланс. Нужно понимать, когда релиз стоит остановить, а когда его можно безопасно ускорить. Где необходимо глубокое тестирование, а где достаточно проверить самое рискованное.
То есть быть не врагом бизнеса с вечным красным флажком, а партнёром: иногда неудобным, иногда спорящим, но умеющим предложить оптимальный путь.
Кстати, это касается не только тестирования. В моей работе тоже постоянно возникает выбор: сделать долго и правильно или быстро и… скажем так, оптимально. Тут передаю привет своей команде - мы спорим об этом регулярно.
Потому что задача лида, кажется, не в том, чтобы всегда выбирать максимальную правильность. А в том, чтобы понимать, какой уровень правильности нужен здесь и сейчас - и какую цену мы готовы за него заплатить.
UPD. Если что, это не призыв фигачить как попало с низким качеством, это про то, как можно сохранять его с другими процессами 😅
Часто сильного специалиста по качеству описывают как человека, который всегда отстаивает более глубокое тестирование, требует больше времени и готов остановить релиз из-за рисков.
И это, конечно, важно.
Но иногда я вижу посты лидов в духе: «Да, из-за меня релизы выходят медленнее. Зато качество не страдает». И всё чаще думаю: а точно ли это лучшее позиционирование хорошего лида?
Быть неудобным для бизнеса - нормально. Иногда релиз действительно нужно остановить. Но сильный лид - это не только человек, который умеет сказать: «Нам нужно больше времени».
Это ещё и человек, который знает, как это время сократить.
Не просто настаивает на полном регрессе, а понимает, как сделать его быстрее. Выстраивает процессы так, чтобы сокращались релизный цикл и time to market - без незаметного обмена качества на скорость.
Тестирование вообще во многом про баланс. Нужно понимать, когда релиз стоит остановить, а когда его можно безопасно ускорить. Где необходимо глубокое тестирование, а где достаточно проверить самое рискованное.
То есть быть не врагом бизнеса с вечным красным флажком, а партнёром: иногда неудобным, иногда спорящим, но умеющим предложить оптимальный путь.
Кстати, это касается не только тестирования. В моей работе тоже постоянно возникает выбор: сделать долго и правильно или быстро и… скажем так, оптимально. Тут передаю привет своей команде - мы спорим об этом регулярно.
Потому что задача лида, кажется, не в том, чтобы всегда выбирать максимальную правильность. А в том, чтобы понимать, какой уровень правильности нужен здесь и сейчас - и какую цену мы готовы за него заплатить.
UPD. Если что, это не призыв фигачить как попало с низким качеством, это про то, как можно сохранять его с другими процессами 😅
👍28❤10🤔6😁1
Про преподавание, качество, ИИ и конференции
Не так давно я начала преподавать ещё и в ИТМО, чему очень рада ❤️
Сейчас довольно много говорю со студентами про тестирование, причём среди них есть и те, кто только начинает разбираться в профессии, и уже опытные специалисты, с которыми интересно обсуждать их собственную практику.
И в этих разговорах регулярно выясняется, что тестирование штука далеко не такая простая, как может показаться на первый взгляд, потому что за конкретными проверками довольно быстро появляются вопросы о том, что вообще нужно проверять, как понять, что этого достаточно, и что мы считаем качественным продуктом для конкретного пользователя.
С появлением AI всё это тоже никуда не девается, хотя инструмент, конечно, классный: можно быстрее разобраться в коде, придумать проверки, написать тесты и снять с себя часть рутины. При этом работу с качеством в целом он скорее делает другой, потому что теперь нужно ещё понимать, какую задачу отдать агенту, как проверить его результат, чего он мог не учесть, а потом отдельно разбираться с качеством продуктов, внутри которых тоже работает AI.
Поэтому одна из частей моих лекций — про эволюцию подходов к качеству и про то, как из года в год менялась наша работа вместе с технологиями, продуктами и ожиданиями пользователей. Сейчас мы как раз находимся внутри очередного такого изменения, и мне кажется важным следить за тем, что происходит, пробовать новое и смотреть на опыт других команд, чтобы в какой-то момент не обнаружить, что привычные подходы уже не отвечают на половину рабочих вопросов.
В этом смысле очень в тему программа Heisenbug 2026 Autumn, который пройдёт 16–17 октября в Санкт-Петербурге и онлайн: нашла там несколько выступлений, которые хорошо перекликаются с тем, что мы сейчас обсуждаем на занятиях.
Вот что я бы выделила в программе 👇
• «Как мы тестируем робота-доставщика» — Роман Еловских, Яндекс.
Здесь мне особенно интересно, как меняется стратегия тестирования на разных стадиях жизни продукта, потому что на таком конкретном примере хорошо видно, почему нельзя один раз придумать подход к качеству и дальше просто всегда ему следовать.
• «Ограничения покрытия тестами» — Авенир Воронов.
Тоже очень близкая мне тема: как менялись подходы к покрытию и почему, помимо процентов, нужно учитывать требования, контекст и то, насколько сценарий вообще важен для бизнеса и пользователя.
• «Кто отвечает за качество, когда код пишут агенты?»
Дискуссия о том, как меняется роль QA и что остаётся ответственностью человека, когда агенты уже участвуют и в разработке, и в проверках, то есть как раз про те вопросы, с которыми нам всё чаще приходится разбираться. Я б тут конечно подискутировала, жаль не зовут 🥲
• «AI-агенты для Auto QA: от хаотичных запросов к системной работе с навыками» — Никита Осипов, Т-Банк.
Про практическую сторону работы с агентами: как дать им нужный контекст, организовать работу и проверять результат, чтобы из этого получался полезный инструмент, которым можно пользоваться в своём проекте.
Мне такие темы нравятся ещё и тем, что после них можно вернуться к своей работе и посмотреть, что у тебя уже хорошо устроено, а что имеет смысл пересмотреть с учётом новых возможностей и задач. Если вы сейчас тоже об этом думаете, оставляю полную программу Heisenbug — можно посмотреть, что из неё ближе к вашим продуктам и вопросам. Кстати, думаю и сама наведаюсь в Питер - не все ж там только пить 🌚
Не так давно я начала преподавать ещё и в ИТМО, чему очень рада ❤️
Сейчас довольно много говорю со студентами про тестирование, причём среди них есть и те, кто только начинает разбираться в профессии, и уже опытные специалисты, с которыми интересно обсуждать их собственную практику.
И в этих разговорах регулярно выясняется, что тестирование штука далеко не такая простая, как может показаться на первый взгляд, потому что за конкретными проверками довольно быстро появляются вопросы о том, что вообще нужно проверять, как понять, что этого достаточно, и что мы считаем качественным продуктом для конкретного пользователя.
С появлением AI всё это тоже никуда не девается, хотя инструмент, конечно, классный: можно быстрее разобраться в коде, придумать проверки, написать тесты и снять с себя часть рутины. При этом работу с качеством в целом он скорее делает другой, потому что теперь нужно ещё понимать, какую задачу отдать агенту, как проверить его результат, чего он мог не учесть, а потом отдельно разбираться с качеством продуктов, внутри которых тоже работает AI.
Поэтому одна из частей моих лекций — про эволюцию подходов к качеству и про то, как из года в год менялась наша работа вместе с технологиями, продуктами и ожиданиями пользователей. Сейчас мы как раз находимся внутри очередного такого изменения, и мне кажется важным следить за тем, что происходит, пробовать новое и смотреть на опыт других команд, чтобы в какой-то момент не обнаружить, что привычные подходы уже не отвечают на половину рабочих вопросов.
В этом смысле очень в тему программа Heisenbug 2026 Autumn, который пройдёт 16–17 октября в Санкт-Петербурге и онлайн: нашла там несколько выступлений, которые хорошо перекликаются с тем, что мы сейчас обсуждаем на занятиях.
Вот что я бы выделила в программе 👇
• «Как мы тестируем робота-доставщика» — Роман Еловских, Яндекс.
Здесь мне особенно интересно, как меняется стратегия тестирования на разных стадиях жизни продукта, потому что на таком конкретном примере хорошо видно, почему нельзя один раз придумать подход к качеству и дальше просто всегда ему следовать.
• «Ограничения покрытия тестами» — Авенир Воронов.
Тоже очень близкая мне тема: как менялись подходы к покрытию и почему, помимо процентов, нужно учитывать требования, контекст и то, насколько сценарий вообще важен для бизнеса и пользователя.
• «Кто отвечает за качество, когда код пишут агенты?»
Дискуссия о том, как меняется роль QA и что остаётся ответственностью человека, когда агенты уже участвуют и в разработке, и в проверках, то есть как раз про те вопросы, с которыми нам всё чаще приходится разбираться. Я б тут конечно подискутировала, жаль не зовут 🥲
• «AI-агенты для Auto QA: от хаотичных запросов к системной работе с навыками» — Никита Осипов, Т-Банк.
Про практическую сторону работы с агентами: как дать им нужный контекст, организовать работу и проверять результат, чтобы из этого получался полезный инструмент, которым можно пользоваться в своём проекте.
Мне такие темы нравятся ещё и тем, что после них можно вернуться к своей работе и посмотреть, что у тебя уже хорошо устроено, а что имеет смысл пересмотреть с учётом новых возможностей и задач. Если вы сейчас тоже об этом думаете, оставляю полную программу Heisenbug — можно посмотреть, что из неё ближе к вашим продуктам и вопросам. Кстати, думаю и сама наведаюсь в Питер - не все ж там только пить 🌚
🔥18❤6