Публичное собеседование: QA Automation Lead

Транскрипция видео:

• Всем привет Это Алекс в шею и Сегодня у нас будет публичный Собес к automation Lida собственно напомню коротко правило вообще зачем нам нужен публичный Собес Это по типу обычного собеса просто мог интервью для того чтобы показать как вообще автомашин лица без может выглядеть потому что это достаточно тайная информация для публичного пространства и хочется как-то приоткрыть завесу и показать вообще какие здесь есть вопросы вот поэтому сегодня мы будем собеседовать Аню вопросы они будут как на настоящем

  00:00:00 - 00:01:24

• интервью слышать первый раз вот и собственно предлагаю начать Давай начнем с того что ты скажешь о себе своем опыте вот Окей Итак Меня зовут Анна шашурина я работаю в банке открытие работаю в автоматизации более 5 лет [музыка] мой опыт включает в себя как непосредственно работу специалиста в области автоматизации и я потихоньку потихоньку выросла до текущей моей позиции я руковожу несколькими проектами банковскими касающимися в тестирование а также тестирование мобильных продуктов банковских небольшой дисклеймер поскольку я под

  00:00:42 - 00:02:24

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

  00:01:34 - 00:03:04

• из таких людей Она состоит Это только автоматизаторы и также manow'key инженеры Я руковожу только командой автоматизаторов в нашей структуре у ручных тестировщиков отдельно есть и они занимаются исследовательским И собственно автоматизации Да вообще вот в твоем опыте Каких размеров примерно идет речь то есть 50 человек пять человек Если ты имеешь ввиду мою команду автоматизаторов то это 17 человек если имеется ввиду вся команда проектов то я даже затрудняюсь представить сколько их потому что это большое количество самых

  00:02:19 - 00:03:46

• разных людей начиная естественно руководителями проекта аналитиками тестировщиками это UX какие-то исследователи это дизайнеры в общем очень очень много людей Так что я думаю что там наверное человек около 200 если не больше хорошо то есть непосредственно людей за работу у которых ты отвечаешь около 20 человек примерно так где-то так все хорошо понятно я тогда предлагаю двигаться следующим образом как мне кажется для Key oftemation Лида важны темы это стратегия автотестирования построения всяких штук Так мы выяснили

  00:03:03 - 00:04:18

• что у тебя уже был опыт непосредственно самой автоматизации то вопросы связанные просто с автоматизацией все-таки Как Лиду нужно понимать наверное какие-то штуки как работают и по менеджмент классический или с менеджмент если ты если это тоже является твоей зоной ответственности и ты имеешь опыт работы Окей сразу маленький дисклеймер с релиз менеджментом Я имею только очень ограниченные контакты К сожалению практически не занимаюсь я скорее наблюдатель Ну а возвращаясь к стратегии тестирование у нас это очень специфично

  00:03:40 - 00:04:59

• как это происходит по сравнению с другими компаниями где-то в других компаниях обычно выбирают инструменты как-то изучают background команды которые у него есть в области автоматизации тестирования потом составляется тестовый план какие-то чек-листы или пишут тестовый сценарий и дальше уже либо люди экспериментируют либо составляют по этому плану какой-то родной внедряют автоматизацию У нас все несколько строже поскольку мы как банк Отвечая перед клиентами за сохранность их средств то у нас есть очень жесткие стандарты

  00:04:21 - 00:05:42

• безопасности и есть определенный пол инструментов Да конечно там Шаг в сторону это не расстрел но есть определенный пул инструментов которыми можно пользоваться на благо автоматизации мы травим эту экосферу мы ее развиваем естественно и работаем в ней например вот из таких ограничений о которых я могу рассказать это то что мы в одном проекте стараемся не совмещать несколько языков программирования То есть если к нам пришел какой-то новый классный автоматизатор и говорит А давайте Мы все дружно переедем с Java на

  00:05:03 - 00:06:07

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

  00:05:34 - 00:07:08

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

  00:06:25 - 00:07:43

• тестировщиков обычно уже есть некие тестовые сценарии если они есть отлично если их по какой-то причине нет то начинаешь выстраивать вместе с командой тестирования то что потом составит тестовый план параллельно с этим на начальном этапе когда привлекают [музыка] автоматизаторов к проекту Естественно уже есть некая функциональность и Значит уже можно что-то автоматизировать и можно выстраивать взаимоотношения с заказчиком рассказываю ему о том что автоматизация обычно это рассказ про то что мы можем то что мы с

  00:07:04 - 00:08:37

• радостью сделаем и чем будем полезны что мы в свою очередь ожидаем от команды что мы не можем сделать потому что это невозможно с технологическим стеком рассказываю про те вещи о которых заказчики или владельцы продукта зачастую могут не знать например Это какие-то тонкости могут быть работы с процессами или с продуктом или тонкости архитектуры которая для нас важны или метрик это очень много всего что нужно говорить на старте чтобы потом не было понимание Когда будем сравнивать ожидания их реализацию потом

  00:07:51 - 00:09:17

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

  00:08:34 - 00:09:44

• функционала с его приоритизацией с заказчиком также самом начале я проговаривала и буду проговаривать при начале нового проекта то сколько нужно автоматизаторов Сколько может потянуть бюджет проекта после этого обычно Договариваюсь О правильно договариваться о сроках написания основ то есть тестовый фреймворка минимального плюс в это время я еще закладываю обычно получение всех доступов так потихоньку потихоньку по нарастающей для всех сотрудников которые буду нанимать и которые будут приходить нам также нужно

  00:09:10 - 00:10:29

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

  00:09:51 - 00:11:15

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

  00:10:35 - 00:11:46

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

  00:11:10 - 00:12:23

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

  00:11:49 - 00:13:09

• санитарами леса потому что именно автоматизация подсвечивают Даже те вопросы которых не могут с которыми могут не сталкиваться тестировщики или как-то их обходить мы видим Battle nake некий о них соответственно даем знать параллельно планомерно проводим кудривью внутри команды на каких-то нерелизных неделях это так я считаю корректно делать Что еще Ну собственно Наверное это самое главное вещи того как я себе представляю как выстраивают работу и так как надо это делать а вот скажи на на основе твоей практики

  00:12:29 - 00:13:53

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

  00:13:10 - 00:14:47

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

  00:14:03 - 00:15:05

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

  00:14:36 - 00:16:15

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

  00:15:25 - 00:16:46

• проверять И то что вызывает зачастую ошибки из-за своей монотонности тут Представьте там из регресса в регресс несколько раз нужно проверять одни и те же тестовые сценарии Это обычно рано или поздно приводит к человеческой какой-то ошибке которая может вылиться соответственно в банк про то его убытки поэтому задача автоматизатора я людям объясняла заключается именно в том что монотонную работу Он берет на себя то что делается из регрессор регресс и таким образом разгружает тестировщика и тестировщику

  00:16:08 - 00:17:13

• от этого хорошо потому что он экономит себе время и не выгорает на одних и тех же задачах и автоматизатор естественно тоже хорошо Да это точно Давай тогда перейдем к такому кейсу Давай представим что ты пришла в какой-то новый проект например меня работу и просто это на самом деле случай мой из жизни в этом проекте есть регрессия она нагрелись запускается каждую ночь идет допустим там 10 часов и регулярно где-то 30 процентов от всего регресса это какие-то флаги тесты соответственно еще неделю автоматизаторы разбирают не

  00:16:40 - 00:18:14

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

  00:17:28 - 00:18:52

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

  00:18:10 - 00:19:37

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

  00:18:53 - 00:20:09

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

  00:19:32 - 00:20:42

• по какой-то причине само это не приключилось то соответственно нужно принудительно переносить фокус и в общем буду разбираться в первую очередь с тем что является причиной их толкования А если нет столько ресурсов потому что надо сесть и команды и разбирать огромные банки проблема нужно продолжать работать продолжать выпускать Лиза тестировать то есть продолжать вести обычную деятельность как в этом случае быть это в идеальном мире у нас есть как бы возможность есть разбирать пока пока все не разберем на

  00:20:08 - 00:21:20

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

  00:20:47 - 00:21:58

• самого важного а потом потихоньку улучшать буду уровень написания этих авто тестов наращивать специалистов доращивая их скиллы их навыки именно в плане борьбы с толкованиями со стабилизацией тестов то есть там есть очень много разных приемов которые позволяют избежать зависимости системы тех или иных Exception of или падение где-то это может быть не только падение непосредственно самих тестов Но это может быть и какие-то ошибки возникающие вследствие нестабильности тестового окружения и естественно это я смогу узнать от

  00:21:22 - 00:22:43

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

  00:22:02 - 00:23:07

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

  00:22:35 - 00:23:47

• для меня основной критерий это первое количество отловленных нами багов во время регресса потому что бывают ситуации когда у ручной тестировщиков нет времени на то чтобы проверить несколько тестовых сценариев похожих то что можно реализовать с помощью легко в автоматизации с помощью того же паттерна дата провайдер для них это монотонный труд поэтому они могут проверить там одну две комбинации А если в 2000 то потом на какую-то 700 найти неприятный сюрприз Вот и если мы помогаем людям избежать таких ошибок то это как раз

  00:23:13 - 00:24:34

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

  00:23:53 - 00:25:14

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

  00:24:34 - 00:25:54

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

  00:25:14 - 00:26:27

• направлений у нас оказалось несколько поэтому мы смогли непосредственно конвертировать это в тестировщика часы Да это классный пример А если какие-то метрики которые вы на регулярной основе отслеживаете не знаю может быть какие-то строить даже борт и держите руку на пульсе что вот Как сейчас обстановка то есть какие метрики описывают вашу обстановку если не у вас есть Ну или если может быть у тебя их нет но ты считаешь что они должны быть у нас Мы в основном отслеживаем метриками объем тестового сценариев который покрыт

  00:25:51 - 00:27:04

• автоматизацией и объем от критичного плана регрессионного который мы покрываем это наша главная Метрика по которой мы работаем какие метрики еще можно было бы использовать и что могло бы быть полезным нам в работе помимо сэкономленного времени вот я так может быть да я так понимаю что сейчас covery ждал упомянула то есть вас есть какой-то покрытие Вот это интересно Кстати а ты говоришь сейчас про Какой вид тестирования про какой уровень про вид и уровень Я имею ввиду тестирование непосредственно

  00:26:27 - 00:27:49

• регрессионные критичного функционального продукта что конкретно тебя Ты имеешь в виду это я тест да да чаще всего это энтуэн ТСТ реже где-то это это как ни странно Хотя бизнес логика Должна много где использоваться это апе тесты которые тоже позволяют выявить какие-то ошибки гораздо быстрее чем это делает ручное тестирование в основном эти направления на самом деле для API можно очень много разных метрик создавать для продукта для автотестов это и объем покрытия и много на самом деле очень всего Но мне

  00:27:17 - 00:29:02

• кажется это скорее задача Back and разработки которая контролирует то что они разработали то что они сделали Мы в свою очередь можем с помощью инструментов типа свагера отслеживать нет ли какого-то функционала то есть первичная обработка Может проводиться ими там тем Лид который проводит код ребенка своей системы проверяет чтобы не появилась каких-то Или это может даже делать какой-то анализатор который проверяет что не появился каких-то фичней охваченных С валером А дальше мы уже можем посмотреть

  00:28:11 - 00:29:25

• что за методы у нас появились и не появилось ли там какой-нибудь загадочной закладки которая позволит перевести деньги со всех счетов клиента куда-то на Багамы очень неожиданная ситуация это А вот да ты просто сейчас упомянула про как раз то что ты больше фокусируешься на юайтестах имеет растут интересно То есть ты как Какие автомашин литт видишь бэкент тесты E5 не в своей области ответственности правильно а на самом деле нет Я считаю что это может быть ответственностью всей команды не только автоматизаторов И не только

  00:28:48 - 00:30:13

• разработчиков и у нас в проекте как я считаю технологически очень близко могут быть завязаны какие-то моменты реализации юнитов и поэтому тут немножко в плане Да собственно и это и антенн тесты тоже получается немножко завязаны на июне то что я имею в виду Например если фроунд проверяет какие-то как я сейчас вот все вместе собрала но стараюсь это разобрать если например фронт проверяет какие-то методы корректно написал то однозначно будет вставлять в элементы некий идентификатор Если вдруг этого

  00:29:41 - 00:31:10

• айтишника нет Это означает что либо этот метод не проверяется потому что он еще не охвачен Но это в скором времени нужно будет сделать либо что-то не так про него могли забыть но если этот тестовый сценарий передан на автоматизацию то скорее всего что и на фронте должны быть Юнит тесты которые пишутся с этими же айдишниками а значит мы можем подсказать что ребята проверяете ли вы ту или иную фичу потому что мы видим что здесь нет яичников и нам неудобно это автоматизирует наших тестовых сценариях наших реализации А у

  00:30:31 - 00:31:49

• вас возможно тоже в это есть какие-то проблемы То что касается API к чьей ответственности она относится Почему я сказала что это ответственность всей команды потому что например напишу я эти авто тесты для своей релизного контура который выглядит сейчас реально и все хорошо на следующий спринт выкатят какие-то новые фичи свагер как-то изменится И когда я увижу что возникают какие-то ошибки я приду об этом спрашивать команду Ребята почему у вас нестабильно себя ведет что-то показывает вместо 200

  00:31:10 - 00:32:27

• вместо 200 ответа 500 все ли с этим хорошо Или где-то там допустим 404 вдруг внезапно вышло И это не вопрос который должен решать только автоматизатор особенно если мы работаем в рамках концепции джайла когда люди важнее документации А значит с ней проблема потому что иначе все бы в ней заказывались значит я общаюсь с командой для того чтобы понять а актуален тот или иной написанный мной тест и так и спринта спринт поэтому я не могу сказать что автоматизаторы сидят где-то на необитаемом острове сами себе что-то там

  00:31:48 - 00:33:00

• делают а потом показывают как все стало хорошо Нет мы плотно интересно работаем с командой для того чтобы улучшать качество продукта все вместе И это совместный труд Да я поняла Я на самом деле спрашиваю Наверное потому что зачастую это популярная проблема с Пирамиды тестирования с этим всем что часто когда мы разрабатываем там новые авто тесты где-то на фронтенде на это я уровне оказывается что мы могли его декомпозировать там на 10 других тестов и там 5 из них унести на Юнит уровень три из них унести на API и один только

  00:32:25 - 00:33:50

• оставить на вот ее уровне и как раз Ну вот определенных процессах при определенной командах Я не уверена что это супер приемлемо для банков здесь как я работал в банке я могу понять что там много другие процессы более разделенные существуют но в целом часто вот если ты не видишь как написано и не видишь как написано и 5S ты много чего упускать тоже другая частая проблема что A500 дублируют чуть ли не полностью Юнит тесты там случае API когда это по сути можно не делать то есть по сути это одни и те же запросы просто на разных уровнях

  00:33:06 - 00:34:25

• Вот поэтому я наверное спрашиваю А на счет айдишников я так поняла ты имеешь ввиду что у вас есть ID у тест кейса и можно увидеть покрытие этой тест там на уровне API правильно на уровне конкретно о какой-то кнопке которую обязательно проверить и если у этой кнопки нет идентификатор и вообще она сделана как-то странно через какой-то дифф и не имеет ни одного внятного атрибута то возникает вопрос а как ее собственно фронт тестировал и тестировал что касается разделения она существует поэтому тут вот

  00:33:46 - 00:35:03

• я не все могу рассказать но к сожалению могу сказать что это вынуждено разделение когда я не могу залезть внутрь какого-то кода для нас является черным ящиком и соответственно я выстраиваю проверку того чего я могу сделать Да ну тут Важно дополнение что для вас код вашего продукта это черный ящик Да да я поняла Окей А вот в случае когда ты настроила все что рассказала и так далее как ты после этого считаешь какой-то контроль над прогрессом именно над автотестами непосредственно нет качеством она такими

  00:34:33 - 00:35:50

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

  00:35:11 - 00:36:31

• есть определенный уровень стратегического видения то чего не знает зачастую тестировщик ручной в проекте то естественно ничего не знает автоматизатор в проекте Но знает бизнес Вот раз в какое-то время Приходим нам нужны тестовые сценарий от вас Мы вы нам тестовый сценарий мы вам дальше они что делают выделяется некоторое время ручного тестировщика он говорит что вот у меня есть какой-то вот такой стабильный монотонный функционал Я бы с радостью отдал его на автоматизацию что больше не заниматься дальше на это

  00:35:52 - 00:37:01

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

  00:36:26 - 00:37:38

• из них это tfs где мы видим какой у из тестовых сценариев покрыт дальше из спринта в спринт когда мы проводим регрессионные тестирование на всю целевую аудитория ссылается отчет со всеми важными метриками это сколько было проверено Какие проблемы какие дефекты мы отловили а также каков прирост автоматизации То есть это все максимально прозрачно на самом деле мне очень важно сделать нашу работу максимально прозрачной и понятной для людей потому что то что там под капотом для несведущих это вообще

  00:37:02 - 00:38:20

• адский ужас А вот то что относится именно к пониманию что автоматизация чем она полезна Это я могу показать и соответственно я стараюсь донести это до людей максимально понятно с помощью каких-то графиков диаграмм с объяснением что у нас было что у нас есть за какие-то соответственно таймлапс за какое-то время да на самом деле Да да это звучит Прикольно да я поняла теперь как это примерно работает а я тогда Предлагаю перейти постепенно к полу вопросов про автоматизацию тестирования в целом Ты уже на самом деле на один из моих

  00:37:41 - 00:38:54

• потенциальных вопросов ответила частично про то как например обнаружить проблему флаги теста Да ты назвала какие-то причины по которым могут плакать тесты вот у меня наверное такой вопрос Вот когда тоже ты строишь эту автоматизацию и решаешь Какой выбрать язык программирования фреймворд библиотеки тестирования и так далее на что-то опираешься какой у тебя алгоритм действий а на самом деле я стараюсь опираться на те инструменты которые уже используются внутри проекта это завязка на определенные библиотеки на Я имею в

  00:38:20 - 00:39:53

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

  00:39:06 - 00:40:39

• мы Практически везде в связи с большой сложностью наших продуктов вынуждены тестовый фреймворк стандартный типа тех же testang или Юнита очень существенно расширять очень серьезно и меня Если честно фраза типа которые изучали на гейзенбаге о том что не надо писать в руки они несколько удивляют потому что в моей парадигме в моей жизни это совсем не так И от этого никуда не денешься где это можно обойтись с помощью той же селением или кликать какие-то банальные вещи естественно там не нужно сложно тесто

  00:39:52 - 00:41:12

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

  00:40:31 - 00:41:35

• то так и дальше подрастающей Да вот ты сейчас как раз и перечислял разные способы Да как ты можешь это реализовывать То есть я понимаю так то что ты все-таки работала как раз основными типа тестом джиджи-ю нет И вот расскажи если у тебя была бы задача такая что тебе по какой-то причине нужно логировать duration каждого теста время сколько он идет как бы ты например могла ее решить насколько я помню для этого есть стандартные инструменты типа Low J которые позволяют при подключении их проект все эти вещи

  00:41:03 - 00:42:23

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

  00:41:44 - 00:43:04

• выполнения а вот как ты обычно описываешь структуру самих классов например для вот тестирования ближе структуру класса для тестирования Я имею ввиду может быть или каких-то Ну вот если классический набор который ты пишешь первые когда ты начинаешь писать ЮА и какие-то автотест набор классов Я имею Сейчас ты говоришь про хорошо про все классы допустим Окей значит обычно это архитектура из нескольких уровней когда отдельно идут классы хелперов отдельно идут классы тестовых сценариев в хелперах тоже есть свое определенное

  00:42:26 - 00:43:56

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

  00:43:16 - 00:44:48

• для того чтобы тест проходила на да это очистка баз данных какая-то иногда это то что за мусоривает тест и считается правилом хорошего тона убирать какую-то инициализацию никаких падежей вне теста чтобы она не мешала читать тесто написанный чтобы его можно было Быстро проглядеть и Если вдруг что-то пойдет не так то быстро понять на каком моменте Может может быть проблема если вдруг вы не можете точно понять из сообщения об ошибке о том что это произошло вообще не тут у меня техника заработала Извините пожалуйста которые очень нужно

  00:44:04 - 00:45:30

• выключить Извините Ну как-то так это классы Helper и класса стандартные стараюсь А вот что-то используешь обычно Ну то есть там используешь ли ты что-то для ТМС как-то для того чтобы хранить сами Test кейсы или ты используешь может быть репосты на какой-то а для того чтобы хранить тестовый сценарий У нас есть отдельный инструмент который собственно обслуживаются ручными тестировщиками они пишут тестовый сценарии роль автоматизатора в этом случае сводится к тому чтобы посвятить какие-то проблемы

  00:44:50 - 00:46:12

• если тестировщик который написал тестовый сценарий вдруг забыли но взглядом не увидел то как он написал этот тоске есть не очень прозрачно в этом случае автоматизатор может оставить какой-то комментарий для последующих поколений не важно кого тех кто откроет этот кейс и увидит что там есть какие-то вопросы комментарии уточнения либо его комментарий будет учтен и тестовый сценарий будет изменен и инструмент опять же та же tfs которая все это живет и часть жизненного цикла обслуживает работы Так что мы работаем в основном в нем и

  00:45:39 - 00:47:11

• все наши замечания и все тестовые сценарии все наши правки мы вносим него Да я имею ввиду что как происходит линкование автоматических тестов имена тестов Вот то есть роскошная аннотация на самом деле собачка Линк аллюрная если мне память не изменяет и Она позволяет сделать ссылку прямо в tfs А значит когда я Валерий просматриваю отчет по тому или иному тесту сценарий если у меня возникает вопросы по реализации Например если он упал я хочу перейти мне не обязательно уходить из окна прогона авто теста Где демонстрируется в

  00:46:27 - 00:47:45

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

  00:47:07 - 00:48:09

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

  00:47:38 - 00:48:56

• свойства Java это объектно ориентированный язык касательно его свойств Ты наверное имеешь ввиду принципы оп базовые или что-то иное тебя интересует Ну да парадигму ты сказала да типизация Java язык не строго типизации Прошу прощения Java из строго типизация в отличие от того же PHP Например я просто начинала свое время с PHP потом переключилась вот что еще касательно принципов Это стандартные капсуляция полиморсизм наследование абстракция вот базовые 4 принципа есть много чего другого интересного

  00:48:16 - 00:49:48

• такого как принципы которые позволяют писать код с помощью например того же солида явные драй кисну и много-много вкусных паттернов которые позволяют сделать год в первую очередь читабельным и удобным не только для того кто это написал в текущем моменте но и дальше Простите увлеклась тогда это не буду спрашивать Как реализовать квадратный треугольник хорошо Да ну какой-нибудь тоже такой вопрос Вот например у нас есть такие ключевые слова статьи к файл Я думаю их многие используют Когда пишут автотесты вот

  00:49:05 - 00:50:26

• зачем они что не значит эта модификаторы Статик позволяет нам для какого-либо метода использовать его например для метода использовать его [музыка] обращаться точнее наверное правильно Так сказать будет к нему не по имени объекта А по имени класса если это касается некого свойства то опять же оно общим является для всех объектов данного класса Это то что касается статика то что касается файл обычно этим сопровождается константы которые Джаве принято писать по правилам хорошего тона большими буквами и сопровождать

  00:49:47 - 00:51:16

• этим служебным словом просто для того чтобы они были стабильные неизменно по всему правду допустим тоже число пие и прочие константы физического мира и не только Хорошо Окей А чем ну в чем отличие идеологическое вот или в использовании абстрактного класса интерфейсов То есть когда что-то используешь автотестах Интерфейс это контракт это договоренность для того чтобы расширить функциональность некого класса в Джаве как Наверное знаешь там наследование класса возможно только от единственного родителя поэтому интерфейсы это такая

  00:50:33 - 00:52:28

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

  00:51:34 - 00:53:26

• чем суть абстракции абстракция позволяет четко задать те методы которые обязательно должны быть реализованы в дочернем классе можно забыть что-то реализовать в дочерних классах но абстрактный класс не даст этого сделать потому что он попросит обязательно выполнить какой-то тот или иной метод который должен быть реализован в реальном классе а вот что касается инстансов То есть можно ли создать объект абстрактного класса насколько я помню Нет потому что они абстрактные все-таки Ну да да Окей А тогда давай такой более как бы

  00:52:32 - 00:54:13

• прикладной это было такое просто здесь по учебнику более прикладное Если бы ты ну описывала какой-то какие-то классы для API запросов например тестирующие 5 тебе нужно собственно делать какие-то запросы У тебя есть классический крут то есть клей делит запросы вот как бы ты реализовала это в рамках Java то есть какие бы ты классно понятно что не прям там детально какие-то Ну какие-то общие черты чтобы там было а ну во-первых я бы конечно вы как-то выделила те классы которые отдельно относятся к авторизации потому что

  00:53:22 - 00:54:51

• каждый раз делать авторизацию с нуля Это несколько нарушает все правила написания кода поэтому явно нужны некие классы для прохождения стандартного типа авторизации в системе Дальше я бы выделила матчеры которые обычно соответствует неким общим паттерном это либо какие-то даты либо типичные ответы либо какие-то другие форматы данных которые могут соответствовать каким-то регулярным выражением например что еще есть классов Ну вот например у тебя запрос происходит там ну создание какой-то сущности вот ты

  00:54:06 - 00:55:34

• как бы передавала Body там допустим Джейсон то есть Каким образом передавала запрос этот json то есть как формировала бы этот как-то Джейсон таким образом если он не изменит то его можно хранить если это какой-то один и тот же формат файла его можно хранить в тех же в той же папочке Resource изнутри проекта выделить его как-то или в папку или если их немного то отдельно Если же этот файл изменяется то я бы создала также классы которые позволили бы его парсить превращать возможные некий объект в позже например потом

  00:54:55 - 00:56:09

• модифицировать в нем какие-то значения потом дальше обратно превращать Джейсон И уже потом передавать его запрос а вот какие-то возможно знаешь какие-то библиотеки которые ты для этого бы использовала для того чтобы все это провернуть То есть если у тебя есть опыт с этим Опыт есть я правда название работает библиотеки jsona наизусть сейчас не могу вспомнить Джейсон Джейсон Я имею ввиду там есть всякие как-то такие всякие есть там лампочки когда ты готовишь данные да да Бог я нежно люблю за гетеросетера а

  00:55:35 - 00:56:55

• также многие другие аннотации типа с Ники frose Естественно Я активно использую его в своей работе то есть много всего полезного да Можете перейти на котлин и использовать реклама интеграция знаешь их не так много конечно но этих минусов может быть весьма существенно Хотя безусловно Может быть кутлин как следующая эволюционная там Java будет однозначно позитивен с точки зрения допустим написания скорости Но вот как показывает мой опыт работы например с тем же фреймворком мобильного тестирования на

  00:56:15 - 00:57:44

• Джаве выходить оттуда допустим на котлин Я бы пока побоялась потому что как не смешно но даже банальное обновление библиотеки какой-то малозначительные на более новую версию может привести к тому что все Не все а работа становится нестабильной крыш это какая-то функциональность И вообще проект перестает работать и все развалилось и поддерживались почему оказывается что где-то там в каком-то в какой-то из библиотек Есть транзитивная зависимость у другой библиотеки которая теперь не дружит с этой поэтому я стараюсь очень осторожно

  00:57:09 - 00:58:28

• я поняла это боль это боль гредла видимо не котлина но да это не только город ла некоторые проекты работают и на mavening успешно но и там эта проблема весьма актуальна это реально не проблема сборщика Это скорее проблема транзитивных зависимостей от них библиотека других и когда одни библиотеки в своих изменениях не учитывают то что должна быть некая обратная совместимость у продуктов Ну а результат это очень нестабильная работа тестовый фреймворка как-то Так Майк Сенс Майк Сенс Да окей Тогда давай движемся к

  00:57:49 - 00:59:11

• последнему вопросу то ли уже таком более практическому Давай представим что у нас есть Input куда мы вводим например подписка на какую-то газет и мы вводим туда наш e-mail и далее собственно что-то происходит мы нажимаем кнопку подписаться и что-то должно произойти Вот что ты думаешь о тех происходит под капотом когда я нажимаю на кнопку подписаться в зависимости от того ввела ли ты туда какое-то значение или не ввела Ну довольно корректно Для начала я вела в свой настоящий mail до нажала подписаться

  00:58:30 - 00:59:47

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

  00:59:10 - 01:00:45

• приложение возвращает в браузер ответ на запрос С 200 [музыка] ответ о том что все хорошо что ты успешно подписалась на некую рассылку или еще что-то и ты получаешь если все хорошо и правильно сделано на стороне фронта ты получаешь об этом сообщения какую-то обычно JavaScript который либо показывает тебе всплывающем окне либо что более наверное Корректно это просто появляется какая-то на страничке информация в каком-то деле который по обратной связи от сервера изменил свое состояние и перестал быть каким-то там

  00:59:58 - 01:01:41

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

  01:00:50 - 01:02:18

• те критерии которые заданы в этом поле для email Потому что если логикой разработчиков Туда нельзя вводить какие-то цифры какие-то спец символы или что-то еще то все это нужно учесть на этапе тестирования дальше я постаралась бы проработать некие возможно значение [музыка] тут Наверное даже ограниченное значение если можно так сказать здесь если употребим этот принцип для того чтобы исследовать минимальную длину Можно ли вести один символ или два или три Можно ли использовать какие-то домены не

  01:01:40 - 01:03:20

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

  01:02:37 - 01:04:02

• это записать как две отдельные записи что еще вот какие-то такие вещи да А вот если теперь говорить именно про автоматизацию допустим ты сформировала набор кейсов который ты хочешь Проверить там пусть будет там 30 с какими-то некорректными символами тремя разными точки много точек еще что-то вот как бы ты какие-то автотесты бы написала то есть меня интересует наверное больше уровень тестирования то есть а на фронтат я подумала что тебя интересует атомарность стала определять меня тут разные То есть это я обычно

  01:03:21 - 01:04:44

• здесь это открытые вопросы чтобы не то что не подводить к ответу чтобы как раз если у тебя возникла какая-то мальность тоже хорошо [музыка] Окей в плане томарности Это несколько Я наверное сейчас уведу на сторону Если тебе это надоест то ты меня Верни Дело в том что я исповедую тот подход когда каждый тестовый сценарий если ты должен предпринять какой-то рядом действие чтобы например добраться до этого поля Вот тебе нужно проделать час каких-то действий там регистрировать клиента регистрировать его адрес проживания его

  01:04:06 - 01:05:18

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

  01:04:42 - 01:06:05

• шаг выносить естественно из дальше касательно а самих тестовых сценариев Если есть возможность как-то их объединить и сделать что-то с помощью тех же софта сертов то я считаю что это не очень плохая практика Хотя кто-то считает это зло на земле но мне кажется что в условиях экономии времени из того к чему стремимся мы все И в первую очередь Наш бизнес Когда нужно как можно скорее выдавать результат тратить по часу на то чтобы сначала воспроизвести какую-то предварительное действие потом сделать

  01:05:23 - 01:06:26

• только одну атамарную проверку это мне кажется не позволительная роскошь вот поэтому наверное я бы старалась какие-то проверки если их можно объединить на одной и той же странице это сделать Например я бы явно не тратила если есть такая возможность время на то чтобы закрывать браузеры открывать его каждый раз если можно обновлять как-то страницу сбрасывать у до какого-то состояния простым refresion то почему бы этого не сделать и потом пробовать тестировать какие-то вещи если можно очищать поле и

  01:06:02 - 01:07:18

• это никак не влияет на дальнейшие результаты тестирования при условии что все очищено целиком и полностью то Вот соответственно можно принимать какие-то такие действия Это то что касается наверное уровня именно в по поводу того чтобы я вынесла на юань естественно минимум действия на самом деле все очень сильно зависит от того Где бы я это проверяла если честно Потому что если это проверка идет не в приложении А на мобильном устройстве то та же пирамида товарища майка Кона там перевернуто если когда-нибудь с этим

  01:06:40 - 01:08:00

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

  01:07:20 - 01:08:51

• разработчиками то что относится к верстке к отображению элементов и к каретностях атрибутов и так далее так далее вот а на ЮА Я бы вынесла тот необходимый минимум который целесообразно проверять Чем меньше тем лучше потому что это самые дорогие автотесты и они самые длительные А значит чем мы больше уберем на вот эти нежные слои пирамиды при тестировании приложения лучше да Это хороший замечание было про Мобайл Да давай тогда я думаю что мы пересекли границу с автоматизацией тестирования уже очень много обсудили разных классных

  01:08:07 - 01:09:41

• поинтов Вот и постепенно передвижник People mangemento вот здесь я наверное спрошу просто два кейса и как бы ты как бы ты их Решала скажем так я думаю себе знакомо Вот первый кейс про то что ну и я часто таким сталкивался Возможно ты тоже У нас есть такая некоторые проторенная дорожка для акула с тем что они любят много кодить все остальное не любит и им все нужно каждый раз все хардко не Хард корня если вот такая ситуация что у тебя твой инженер жалуется надоело писать эти тесты Все очень просто понятно все одно и то же

  01:08:54 - 01:10:14

• устал выгорел вот хочет хардкор чтобы ты ему могла предложить как вообще бы коммуницировал с таким человеком Для начала я бы выяснила что он подразумевает под хардкором потому что для кого-то это может быть Хочу залезть в другую профессию пойти куда-нибудь вязать а для кого-то это может быть я хочу знакомиться с Допустим нагрузочным тестированием или поучаствовать какие-то Баунти программах и так далее а для кого-то это может быть это все слишком Просто я хочу освоить какие-то другие фреймворки соседние соседних команд Я

  01:09:36 - 01:10:51

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

  01:10:13 - 01:11:28

• новые инструменты или особенности применения старых и я либо прокачиваю сама людей но я стараюсь не играть в дятло и не заставлять людей что-то учить типа тоже вот хотел прокачаться Давай сделай это а я стараюсь давать возможность развиваться кто-то возможно не очень созрел до понимания того какие бывают допустим там метрики на других проектах Какие бывают паттерны в нашей разработке именно для нашего кода значит это еще не пришло и он может снять свой какой-то слой на этих кудри Вью те же когда кто-то создает квесты мы

  01:10:51 - 01:12:19

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

  01:11:37 - 01:12:52

• вообще очень здорово Наша область не знаю не уверен что об этом где-то много говорится по крайней мере много интровертов а значит формировать какой-то комьюнити Я считаю что это очень правильный подход поэтому для человека который уже Open в использовании наших инструментов если он не особо видит для себя целесообразно данный момент как-то дальше увеличивать свои скиллы горизонтальном направлении то я бы прокачивала какие-то Соф скиллы менеджерские То есть можно попросить человека самого допустим привести

  01:12:14 - 01:13:28

• какие-то кудривью можно давать какие-то задачи потом спрашивать человека начиная с каких-то небольших а потом увеличивая нагрузку давать какие-то поручения и Смотреть насколько человек ответственность состояние он справится без того чтобы ты напоминал о чем-то например делает ли он задачу если у него возникает какие-то проблемы не откладывает ли он все на последний момент чтобы в последний момент когда уже наступает дедлайн сказать тебе слушаю извини Я облажался Вот это тоже лучше выяснить заранее прежде чем ты

  01:12:52 - 01:13:52

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

  01:13:22 - 01:14:28

• это круто второй кейс будет такой жестковатый но дядя из моей жизни Вот что ты будешь делать Если возникнет такая ситуация что там ну два твоих автоматизатора ливюре кот друг друга и один сторон Он присылает ссылку ты переходишь по ссылке открываешь а там изображение фекалий и этого так он прокомментировал код естественно на основе этого часа конфликт недовольство вот это все но это наверное такой это конкретный пример но я бы сказала что-то обобщающий пример про токсичность в код ревью и вот про

  01:13:55 - 01:15:14

• все вот это а Скажу честно я у себя в команде когда набирала своих сотрудников я чтобы предостеречь возникновение таких картинок на самом первом этапе собеседования предупредила людей сразу о том что у меня очень разная команда у меня в команде работает несколько девушек не только парни чему я очень рада потому что девочки войти Это замечательно Я считаю и я предостерегла что в команде нет разделения по гендеру по национальности божию по религии любая дискриминация будет но очень жестко пересекаться любая

  01:14:34 - 01:15:54

• попытка каких-то оскорблений любая попытка какого-то какой-то демонстрации своего ЧС за счет кого-либо другого она будет пресекаться зачастую я у себя в команде в некотором смысле Ну не то чтобы скоро мастер выполняют такую роль или психолог или какой-то фасилитатор но я стараюсь чтобы общение внутри моей команды но всегда оставалась именно корректным и если вдруг такая ситуация предположим что по какой-то причине случилось это привело к конфликту то Естественно Я выслушаю обиженную сторону и постараюсь

  01:15:17 - 01:16:32

• разобраться но обидевшую сторону я что сделаю во-первых еще маленький такой дисклеймер я использую принцип не критиковать публично а только хвалить и это значит что человеком который накосячил если это там вот индивидуально кому-то было переслан я буду разговаривать этот и буду объяснять ему что либо это токсичность из его общения с людьми уходит либо в случае если это будет еще раз где это зафиксировано то мы просто расстанемся с таким сотрудником Каким бы он офигительно ценным не был потому что

  01:15:55 - 01:17:18

• я считаю то что одно звено слабое в коллективе не заведет весь коллектив до его уровня если кто-то есть кто кому интересно разложить коллектив и сделать его не синергичным и неработающим как-то в одной парадигме но вот кто-то тянет одеяло на себя то это очень плохо влияет на всю команду поэтому для начала Я исповедую практику конструктивных разговоров если по какой-то причине Это не приведет к положительному результату то тогда уже буду принимать Да спасибо большое Я думаю что на этой прекрасной ноте будем двигаться к

  01:16:36 - 01:18:00

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

  01:17:20 - 01:18:30

• впечатление что ты такой некий естественно адвокат автоматизации но такой адвокат не с негативной точки зрения не пущу А вот такой объясняющий какой-то да то есть такой который спокойно рассудит аргументированно все расставить по полочкам очень классный впечатления Вот про конкретно какие-то вещи которые мне понравились В целом наверное Мне очень нравится тот факт что у тебя такой свой своеобразный опыт именно банкинга И это тоже очень важно о нем рассказывать потому что я часто сталкиваюсь с тем что например ребята из

  01:17:56 - 01:19:13

• продуктов что-то рассказывают Да и ребята которых очень много кто работает в Enterprise в банках просто ну говорят что это невозможно применить У нас у нас есть другой набор ограничений и все так просто как вы хотите не складывается и мне кажется очень круто что ты именно Рассказала про то как можно выстраивать процесс в рамках вот этих вот ограниченных условий потому что это зачастую более сложные задачи да И тут нужно действительно как ты говоришь выдумывать свои кастомизированные фреймворки Когда потом ребята

  01:18:35 - 01:19:36

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

  01:19:05 - 01:20:13

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

  01:19:38 - 01:20:57

• самом деле я проводила за последние Сколько времени в общем где-то последних 15 моих интервью людей и половины не ответили того что ты сходу ответила при том что ты ну не являешься играющим прям тренером То есть это не твоя каждодневная задача писать тесты когда ты это делала Ты все еще все помнишь И это тоже как бы знак такого качества для меня вот про people менеджмент тут тоже мне кажется классный подход то есть чувствуется что ты заботой некой то есть что ты являешься коучем наставником для своих ребят и тоже хочешь чему-то

  01:20:19 - 01:21:37

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

  01:20:58 - 01:22:03

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

  01:21:30 - 01:22:37

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

  01:22:04 - 01:23:27

• также Да ты там говорила про то что каждый новая фича должна быть а всегда покрыта ручными тестами исследовательской темы и все исследовательским тестированием То есть я идеологически с этим согласна абсолютно тут скорее просто что иногда как бы реальном мире не получается это пересечь Вот и наверное единственное то что я вижу что это не то что твой минус Это скорее у тебя просто опыт работы связан с другим это вот так как раз про вот эти все пирамиды тестирования когда ты активно вовлекаешься в другие уровни разработки

  01:22:45 - 01:23:59

• но в вашем случае это просто невозможно как мы выяснить за ограниченных условий поэтому здесь тоже я думаю что не совсем применим этот вот а так в целом мне кажется что я теперь перебила на самом деле это одна из областей Куда я могу дальше развиваться Да сто процентов и у тебя будет такой огромный бэкграунд который тебе сейчас вот из твоей текущей компании в общем это как бы да это поинты которые я тоже сформулировала но я не считаю какими-то важными так далее В целом я в полном восторге я думаю это будет супер полезно

  01:23:22 - 01:24:34

• Вот и даю Если ты хочешь себе тоже слово как-то впечатление вообще там что ты думаешь на самом деле мне тоже очень понравилось наше интервью признаться Честно я очень рожала потому что я стараюсь оставаться [музыка] тем человеком который несмотря на много менеджерской работы при этом сохраняет скиллы технические Обычно когда на собеседованиях начинают спрашивать какие-то такие вещи то про какой-то аннотацию сложно использовать библиотеке не всегда бывает легко это вспомнить и вернуться в конкретную точку потому что у нас у

  01:23:58 - 01:25:20

• автоматизаторов очень очень много всего вот и это то чего я очень сильно боялась если честно на нашем интервью вот касательно какого-то фидбэка наверное в отношении тебя я не могу ничего сказать кроме того что я тебе очень благодарна за то что ты делаешь это очень здорово а касательно все наши коллега Регине которые будут этим заниматься Наверное если это будет то что я бы чуть-чуть что-то рассказала Если ты не против отсыпала Советов Да конечно я только за да да Я бы очень хотела посоветовать людям во-первых

  01:24:40 - 01:26:17

• уважать и любить свое дело потому что без этого и вы завянете и то чем вы занимаетесь пойдет еще я очень исходя из своего опыта ратую за то чтобы люди читали литературу знакомились опытом других коллег неважно это где-то на конференциях типа или еще каких-то вот это может быть Хабар это может быть какие-то ролики на Ютубе многие другие источники вот как собственно на котором мы сейчас с тобой находимся но видеть Все и процессы инструмента с других точек зрения бывает очень полезно как менеджеров Я хочу призвать людей не

  01:25:29 - 01:26:51

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

  01:26:12 - 01:27:25

• Нет это обычно просто взаимодействие на равных двух специалистов это очень здорово Я хочу также посоветовать показывать пример развития своего потому что очень важно постоянно оставаться на плаву и не застывать в одном и том же тестом фреймворке Вот ты сегодня упомянула про котлен как следующая эволюционную стезил развития после жала я ни в коем случае не ретроград который вот как сказали пользоваться библиотекой селением 3-1459 больше все остальное от лукавого вот нет Я считаю что это нормально Поэтому нужно развиваться и

  01:26:49 - 01:28:08

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

  01:27:29 - 01:28:44

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

  01:28:07 - 01:29:28

• не бойтесь давать людям возможность спрашивать и создайте такую культуру при которой они будут приходить и спрашивать Тогда ваша команда объединяясь вокруг вас будет работать в Едином направлении это будет очень круто для всех Так что всем удачи девочка Большое спасибо Аня это было просто потрясающе Вот и всем пока да спасибо за просмотр

  01:28:48 - 01:29:53