Подготовка к собеседованию на QA Engineer
Менторы
Специалисты своей области, которые смогут помочь вам
Middle .Net Developer
Senior Product Manager
Middle Python Developer
Ведущий программист
Backend Software Engineer (PHP)
Senior .NET/C# developer
Middle DevOps Engineer | Tbilisi, Georgia
Middle C# .NET
Senior PHP-разработчик
Middle python developer
Каналы
Полезные Telegram каналы и чаты
Транскрипция видео:
а собственно Всем привет Вы на канале Саши и сегодня мы проведем публичный Собес на позицию кейлит Я хотела бы начать вообще с того что такое публичный Собес так как это первое видео чтобы немножечко объяснить но по сути публичный Собес этот обычный Собес который просто мы записываем на камеру для того чтобы у вас было больше информации как вообще проходит реально собеседование какие вопросы задают Какая коммуникация и так далее Вот и собственно Мне кажется безумно мало в Ютубе в целом контента связанного с
00:00:00 - 00:01:05
высоким уровнем с деньгами поэтому мне кажется это прям будет круто узнать как это примерно проходит Вот и сегодня буду собеседовать Дарину я сразу хочу сказать что это типа очень круто что ты согласилась потому что я прекрасно понимаю что это страшно и это большая ответственность Поэтому если кто-то не знаю там будет хейтить Или еще что-то я предлагаю этого человека прийти следующая собеседование Вот и как раз почувствовать каково это побыть в твоей шкуре вот Собственно как бы так как О настоящем собеседовании
00:00:34 - 00:01:55
Дарина будет слушать все вопросы первый раз также мы сейчас обсудим ее опыт Вот и в общем-то давайте начнем дадим Давай начнем с того что ты расскажешь о себе Я думаю параллельно мы покажем твою резюме Вот давай хорошо Я тестированием чисто тестированием занимаюсь больше трех лет начала работать тестирование в компании где я был аккаунт менеджером по интернет-рекламе просто заодно были задачки потестированию поняла что мне это нравится больше и решила развиваться в эту область чисто там мы делали Просто интернет
00:01:14 - 00:02:33
магазины сейчас у меня опыт в блокчейне был в стартапе очень классный работа там не долго потому что стартап закрывался и увольнял людей но это было очень классный опыт давший мне очень много знаний и перешла в Яндекс сначала в Яндекс афишу в основном на фронтен на позицию младшего тестировщика довольно быстро выросла и последний полгода в Яндекс афише у меня была цель вырастить команду поддержки ну нас была большая нагрузка нужно было как-то разгружать штатных тестировщиков и у меня был проект на полгода взять ребят из нашего
00:01:52 - 00:03:12
саппорта Кто хочет расти в тестирование обучить выстроить систему обучения и подключать ребят ко всем задачам и начинали там с одного человека который сказал Самый большой энтузиазм я уходила в другую команду когда там было шесть человек и на мое место мы в итоге взяли человека который Мы начинали Этот проект Очень классно прокачался очень горел этим это был мой первый опыт в роли Лида И вообще какого-то управления людьми Я до этого момента честно говоря не думала что я хочу когда-либо расти в Лиды такая
00:02:33 - 00:03:35
Нет это не моё Подождите но это очень интересно оказалось Потом я пришла в плюс просто поменять проект хотелось в плюс все сначала я уходила на такую линейную вакансию Ну как линейную Достаточно серьезный потому что это было самостоятельное ведение кросс командных проектов когда тебя разработчики из нескольких команд вы разрабатываете там с ребятами с плюса на базе Яндекс Маркета это много новых нюансов это много коммуникаций со всеми я уступала как тестировщик всего проекта координатор не только тестирую руками но
00:03:04 - 00:04:14
и выясняю все орг моменты Договариваюсь с тестировщиками там других команд Уточняю организационный момент очень много взаимодействий было с другими командами с разработчиками с тестировщиками с админами и вот этим летом я начала видеть 15 человек с места в карьер у меня четыре человека в штате остальные А вот став это четыре команды разработки одел тестирование просто распределенный по четырем команды мы все работаем проектами продуктом Яндекс плюс просто отвечаем за разные части и я сейчас занимаюсь как People
00:03:39 - 00:05:03
managementom то есть провожу 11 с ребятами обсуждаю там планы развития на год на полгода ставлю цели обсуждаю что из этого Получилось что не получилось кому хочется развиваться Скоро будем ставить цели на следующие полгода к следующему review и также процесс менеджментом То есть я выстраиваю процесс и улучшаю их поддерживаю там изменения бизнеса проращиваю их в команды То есть например Мы хотим больше идти в продуктовые команды делать более универсальных тестировщиков не у нас есть команда frontend есть Команда бэкенд А есть там
00:04:21 - 00:05:26
команды конкретно по какому-то продукту и нужно чтобы разделив на это команду перестроив тестировщиков ничего не сломали по-прежнему стабильные релизились чтобы у нас все процессы продолжили хорошо работать вот такими вещами тоже занимаюсь да Круто Слушай у меня сразу сходует много вопросов появилось таких уточняющих то есть я правильно понимаю что ты примерно где-то четыре с половиной года всего в тестировании правильно Если я поняла Да и последние полгода ты занимаешься именно непосредственно руководством
00:04:54 - 00:06:01
команды из 14 человек правильно отделом тестирование которые работает на 4 команды разработки Окей помимо этого даже я хотел спросить еще ты как играющий тренер или ты занимаешься только менеджером То есть ты сама делаешь какие-то задачи потестированию сейчас нет просто потому что там Большая команда много но еще устав ребят планирую меня в планах есть немножко нагрузку чтобы аутстафф ребят вели например тестировщики в команде И я могла подключаться еще и к тестированию тоже а вот ты еще упомянула да вы достаточно
00:05:27 - 00:06:42
сложные технические задачи связанные с перестройкой организации с тем чтобы заново какие-то интеграции построить А вот ты когда принимаешь участие ты больше принимаешь участие как человек который решает орк вопрос Ну то есть там фиксирует договоренности напоминает что вот это не забыть или ты очень хорошо понимаешь технически как это должно быть все устроено и у тебя там больше еще преобладает тех экспертиза вот в этом участие Я бы сказала что нечто среднее потому что я очень много взаимодействую здесь с
00:06:07 - 00:07:13
разработчиками следами разработки с нашей командой инфраструктуры которые очень большое представление как у нас происходит релизы как мы делим пока их по компонентам что мы можем поменять дальше за там более глубоким уровнем экспертизы Я обращаюсь к лидам и мы вместе придумываем какую-то схему как это будет работать дальше как мы можем перестроить процесс или я часто даже какими-то идеями типа ребята нам нужно сделать что-то вот такое Подскажите как это можно реализовать Давайте найдем Общее решение
00:06:40 - 00:07:47
то есть да получается как бы ты у тебя есть в тех спуститься но она такая на каком-то среднем уровне и при этом ты еще занимаешься именно менеджерской часть окей Да я поняла хорошо тогда я предлагаю сделать следующим образом насколько я понимаю у нас здесь будет самое главное все-таки область знаний которые нас интересует эта стратегия тестирования потом уже Немного тех Экспертиза и как-то сказал уже пипа менеджмент занимаешься Ты релиз процессами ты тоже упоминала да Окей тогда тоже люди процесс Вот хорошо давай
00:07:13 - 00:08:22
тогда начнем со стратегии вообще тестирования у меня наверное такой сразу вопрос очень абстрактно интересно узнать на него ответишь вот вообще вот эта фраза типа построить процесс тестирования что это для тебя возможно часть была какие-то шаги которые были детально описывают это понятие Ну я не устраивала процессы с нуля здесь я приходила в команду или какие-то процессы уже были дальше нужно было их улучшать для меня наверное выстроить процесс тестирования это во-первых сделать понятный и удобные прозрачные
00:07:48 - 00:09:06
правила для всех чтобы и тестирование понимала По какому Flow у нас идет там что Такие артефакты тестирования мы используем Какие не знаю браузер и глобально Я имею в виду и в том числе для каких-то там конкретных вещей типа разбраузерность как мы Тестируем и где и чтобы этот процесс был не только для тестирования понятное разработчики такие мы отдали на вам задачу дальше с ней происходит что-то а потом она иногда там возвращается А чтобы этот процесс был понятен всем то есть например те же отчёты это тестирование в каждой задаче
00:08:27 - 00:09:31
мы пишем чтобы разработчики видели что мы проверяем могли при необходимости что-то скорректировать например когда типа ребята вот эти вот эта фича ещё затронет вот эта часть проверьте её тоже пожалуйста для меня процесс тестирования это не какая-то абстрактная живущая отдельно от остальных процессов разработки вещь для меня это все должно быть единым циклом тестирования должна принимать участие в планировании в оценке задач Вносить свои корректировки если мы на планирование видим что какие-то еще вещи
00:08:59 - 00:10:03
надо подсветить просто потому что у нас Мы представляем этот продукт в этом месте Чуть более полно для меня это прорастить участие тестирование во всех процессах планировании в планировании на спринт планирование на квартал оценки нагрузки людей и до конкретно процесса самого тестирования как мы берем задачи как они к нам попадают что мы проверяем при тестировании какая у нас База знаний для тестировщиков с вами по регионам по экспериментам нашим по разброс и так далее Да хорошо давай тогда немного добавим
00:09:32 - 00:10:50
как бы детали в контекст чтобы было проще отвечать да ты сказала что у тебя не было опыта построения с нуля Окей тогда давай представляем что ты приходишь вот в проект мой например и тут уже есть какой-то процесс тестирование как раз твоя задача видимо что-то улучшать или там зачастую какой-то есть тестирование но нет ли дай ты приходишь такие вот Твои шаги будут первые вообще для того чтобы понять как куда улучшать Ну первые шаги это про именно понять то есть посмотреть в каком разном Flow задач Какие документации пишем ли мы
00:10:10 - 00:11:21
отчеты это присутствие на регулярных встречах если у меня там это задачи есть и peopleman то на 11 уточнять Что что как работает какие вопросы у ребят есть и Например у нас зависит от проекта но я сейчас вела например ретро тестирование отдельно чтобы не там в каждой команде обсудили четыре раза пытались решить одну и ту же задачу а именно тестировщиков обсудить какие у нас есть проблемы что мы можем улучшить кого собрать боль и собрать если у кого-то есть желание что-то развивать куда-то двигаться такие деньги а вот тут
00:10:46 - 00:12:04
работает не очень то там оценить Вот это пообщаться следами разработки Какие процессы выглядят с их стороны какие есть проблемы То есть первая задача просто понять Вообще что происходит со стороны со стороны лидов разработки Возможно со стороны менеджеров а для начала не сломать то что уже работает приходите сразу говорить Так сейчас мы все меняем Неважно как оно работало Ну так себе идея Так что понять что хорошо понять где болит после этого начать перестраивать например не писали отчеты и тестирование договориться что мы пишем
00:11:24 - 00:12:32
отчеты тестирование и этом нет распределение задач по тестировщикам некоторые задачи повисают договориться что там в каком порядке тестирование берет задачи или кто-то распределяет задачи на тестировщиков здесь зависит команды если проблема что задача например очень долго висят тестировании возвращаются в доработки там через неделю разработчик уже не помню что это было мне нужно оценить нагрузку на тестировать Проблема в том что у нас не хватает людей и мы не можем физически быстрее тестировать
00:11:59 - 00:13:08
Значит надо посвятить что нам нужны Новые люди проблема Не знаю с их Проблемы в том что тебе приходит зайчик тестирования Сначала два часа стенд пытаешься самостоятельно развернуть здесь например одной из классных улучшений которые у меня и в афише с моим участием внедрялась в плюсе уже было что разработчик передавая задачу в тестировании должен проверить что они открываются стенд что хотя бы просто основной сценарий его функциональности работает чтобы не было что ты идешь тестировать например страницы концерта
00:12:34 - 00:13:28
открываешь страницу концертом 500 такая классно потестировала там говорит что это должны выполнять разработчики это просто сокращает процесс тестирования всем делает удобно да да Я кстати с тобой согласна Но это по сути а внедрение некоторого Definition of Dan Четкого да для разработки И я тоже практикую такую тему Что как бы это ответственность разработчика убедиться что то что закодировал вообще работает хоть как-то Да окей вот если говорить так более может быть коротко про конкретные такие детальные кейсы в твоей жизни которые ты
00:13:00 - 00:14:17
считаешь успешным улучшением это написание отчета фотосинирование Это проверка разработчиками поднимается что задачи есть это прогон на каждом стенде автотестов и если у нас есть красный тесты то задача остается у разработчикам сразу не может привести ее в тестирование с красными тестами значит что-то сломалось а что еще хорошего такого У меня есть отдельная доска для тестирования то есть мы видим задачи которые к нам идут в тестирование и удобнее отслеживать чем по нескольким командам и наверное самое такое классное
00:13:38 - 00:15:01
что мне кажется я сделала Я настроила что мы планируем задачи на новый спринт продуктовые фичи которые пойдут в этот Принт Мы берем сразу на написание основных сценариев тест кейсов то есть буквально основной положительный сценарий чтобы он был нас до разработки и в процессе разработки разработчик сразу написал автотест на новую фичу чтобы нас не копился тех долг мы разрезели 5 в чеки когда-нибудь сделаем на них автотесты а чтобы это было встроено в процесс разработки и сразу писалось Окей круто да А вот если говорить о том
00:14:29 - 00:15:43
как ты измерила что те изменения которые вы внесли Они вообще как бы эффективны в какой-то степени то есть искал внедрение отчетов как ты поняла что это вообще на что-то повлияло И второй вопрос А как ты контролируешь что те практики которые ты вводишь Они вообще реализуются в команде внедрение им отчетов это у меня начиналось когда мы взяли Ребята с саппорта и вначале Я в ручном режиме проверяла их отчеты тестирование нагрузка и смотрела что ребята правильно проверяют ничего не забывают и выдавала
00:15:09 - 00:16:17
свои корректировки также я поступаю со стажировкой у стажёра я проверяю отчет говорю что исправить последующим отчетам я вижу что человек исправил с более опытными ребятами кто давно занимается тестированием Я там не проверяю каждый отчет разработка знает что у нас должны Вот это тестирование если нужно у нас в какой-то задаче уехал Крит в прот мы можем просмотреть по отчету например что этот сценарий просто не был протестирован или что этот сценарий там был протестирован в этой задаче и в этой
00:15:43 - 00:16:52
задаче там на стенде работала может быть дело в окружении То есть это позволяет потом немножко ретроспективно проверить почетам в чем причина В случае с автотестами просто нас ждет покрытие автотестами не Копится тех долг что еще Сейчас подумаю сказать Ну наверное Вот это какие-то основные метрики про которые я сейчас могу сказать а вот если в целом говорить о метриках который может быть ты использовался в команде Может быть ты их не применяла Но вот Какие ты знаешь метрики с точки зрения там оценки
00:16:18 - 00:17:35
качества продукта который ты можешь использовать для того чтобы понимать вообще в каком-то статусе находится у нас есть во-первых заработок полисе это график который меряет количество багов по блокерам квитан среднему приорите эту низкому каждого приоритета есть свой вес и мы комитимся что мы будем снижать цифры этого графика договариваемся С командами что вот изначально с менеджером потом с командой что вот наша целевая цифра такая-то мы снижаем уровень забагованный сервис как мы чиним баги в каком процесс для этого есть
00:16:58 - 00:18:05
Метрика периодически отслеживается мной при необходимости там Обсуждаем что например недостаточно что только дежурные разработчик чинит баги У него много других задач много задач по релизам Он не успевает чинить средний баги давайте мы будем планировать спринт выделяем просто тех квоту там не знаю 30 процентов на баги и автотесты и смотрим что действительно у нас спринт плане запланированы баги Мы не только на планировании такие Да вот эти баги Мы берем спринт а в конце спринта они выполнены починены
00:17:32 - 00:18:39
время до передачи до взятия задачи тестирования и время тестирования то есть сколько времени проходит от того как задача из Статус можно тестировать приходит тестировать и Сколько в среднем у нас задачи живут в тестировании с возможностью посмотреть каким-то конкретным пиковым данным в чем там причин то есть средний допустим время надо взять тестирования один день почему-то какая-то задача висела 4 дня в нее Можно перейти Посмотреть например там задача висела потому что мы разбирались она зависело другой команды
00:18:04 - 00:19:06
не поднимался стенд или почему-то ее четыре дня никто не брал могут быть разные причины не все из них на нашей стороне Ну и в целом это не только протестирование в целом Time to Market Сколько времени у нас от взятия сдачи в работу до ее реализации в провод проходит но это уже не только тестирование это работа всей команды то есть вот эти все метрики я правильно понимаю что там ты прям замеряешь То есть у тебя тоже интересные инструменты какие-то используешь там видимо в трекере То есть ты сама Строишь все эти
00:18:36 - 00:19:49
графики У тебя есть какие-то дашборды где ты ну условно прям держишь руку на полисе У нас есть наши внутренние инструменты которые позволяют это строить не самостоятельно использовать готовые тузы но да это графики которые раз в неделю проверяю смотрю Все ли Окей а мне интересно ты их как проверяешь типа как вот утром приходишь на работу открываешься даже такой кофеёчку попивая смотришь как это как стоит регулярная Тоска в моем тудушнике на четверг потому что встречи по каким-то целямбек полисе встречи по тому
00:19:19 - 00:20:44
выкладыванию бывает по четвергам я не помню Честно говоря периодичность каждый раз 2 недели поэтому раз в неделю в четверг днём Я открываю график смотрю на него отписываюсь в комментариях к нему и если там я вижу что график просел иду разбираться там не знаю кто-то некорректно разметил бак так бывает мы там договариваемся с менеджерами что давайте не будем ставить криты просто багам которые хотелось бы взять работы побыстрее ребята Это не Крик давайте мы как бы выстроим процесс по-другому или там почему-то нас действительно была
00:20:01 - 00:21:04
проблема с релизом с чем-то еще вот я один раз в неделю оцениваю потому что каждый день Мне кажется ту матч раз в неделю уже какое-то есть тенденция ты ее видишь и можешь обсуждать если нужно с людьми из-за кого это на этот раз случилось или там с кем Вам нужно обсудить Просто давайте брать баги спринты ему не успеваем их чинить Я тебя очень даже понимаю Я обожаю графики и я даже То есть я делаю даже больно мне так больше автоматизации моя экспертиза я делаю даже больно но все она типа А в каких квестах нет
00:20:33 - 00:21:51
достаточного количества тестов и так далее Это действительно очень прикольно но в плане Мне кажется это достаточно эффективно А если какие-то метки которые ты считаешь ну такие типа не очень эффективным способом вообще что на них не Нужно опираться а у нас сейчас таких нет возможно Ну сейчас я подумаю потому что навскидку те метрики которые мы используем действительно там полезно Я вижу их практическое применение но пока ты думаешь я могу привести пример например автоматизации Мне кажется это количество автотестов Ну то
00:21:12 - 00:22:28
есть это методика которая по которой можно о чем-то судить но опираться на нее как она абсолютно истину и типа что вот корреляция есть между этой метрикой и растущим качеством продукта Ну это корреляции нет теста У нас есть просто графики по скорой новым таском и закрытым таском чтобы просто видеть что мы автоматизируем но с автотестами Мне кажется важнее понимать что у нас в первую очередь автоматизируются критичные печи или там автотесты на критичные пропущенные баги это важнее чем просто общее количество тестов не знаю если у
00:21:54 - 00:23:08
нас 100 тестов все на баги среднего приоритета ни одного автотеста на не на баги на доске и ни одного на криты как бы смысл у тебя я так понимаю в твоей команде также ты заведуешь и автоматизации правильно немножко Да но и мы туда не будем выходить это мы тут на 3 часа Все застрянем у меня будет не остановить Да вот и да плавно переходя как раз ты рассказала о своих кейсах Я предлагаю тебе решить мойки вот он можно даже сказать практически из реальной жизни но я думаю достаточно типичная ситуация Но вот
00:22:32 - 00:23:50
представим что ты собственно собеседуешься куда-то и Придя на проект там следующая ситуация то есть продукт какой-то достаточно Вегасе выпускается раз в месяц допустим и оказывается Так что 50 процентов времени то есть две недели тратится на полную регрессию Ну то есть для того чтобы понять что продукт можно выпускать нам нужно закончить разработку за две недели релиза не получается что у нас есть каждый месяц как бы две недели разработки потом две недели весеннего тестирования Но конечно это идеальный
00:23:14 - 00:24:22
мир по факту там добивают Фиксы бла В итоге регрессию там до конца не успевают прогонять бедные эти тестировщики уже выгоревшие ненавидят эту регрессию вот как бы ты действовала да да нужно оценить кейсы из репрессионного набора Например приоритизировать во-первых если нас нет разделения по приоритетным потому что проходить в каждом регрессии какие-то минорные тест-кейсы не нужно На мой взгляд чтобы приватизировать и определить какой-то там scope которым прям Действительно хотим проходить прогрессе
00:23:46 - 00:25:07
определить вещи которые это какие-то корни редкие корни кейсы которые просто написали тест и сказали ой Давайте впихнем Прогресс Но на самом деле На мой взгляд они там в каждом регрессии не нужны они нужны если мы делаем фичу по какому-то функционалу и нам бы прогнать и знаем что может сломаться просто целиком весили любой его компонент в этом случае мы берем Поэтому функционалу в рамках тестирования прогоняем их все ну Прогресс Я бы это не брала дальше дальше говорят договариваться про автоматизацию если у нас нет ресурса
00:24:32 - 00:25:38
тестирования то договариваться что разработчики будут выделять на это время Ирина мы ищем отдельного коавтоматизатора просто чтобы то что можно не регрессировать руками не упарываться что люди две недели половину своего времени тратит на регресс так это правда очень тяжелая нагрузка переложить на регресс на авто теста то что можно переложить дальше если тут зависит от объема релиза если мы две недели пишем фичи а то и больше вряд ли Это возможно но например если у нас вообще не трогалась часть функционала какой-то там не знаю
00:25:05 - 00:26:20
компонент какая-то отдельная страница например личный кабинет пользователь там нет вообще ни одна Задача В релизе которая это затрагивает и там в соседних задачах в личный кабинет никто не лазил Наверное мы можем не включать э-э личный кабинет Прогресс при этом релизе После первых двух Да я к сожалению бывает очень вроде не трогали а потом оказалось что это компонент который используется и в личном кабинете вы такие смотри если как бы подводить итог того что ты сказала по сути я так понимаю мы этот раз перебираю кластеризируем по
00:25:42 - 00:26:56
какой-то функциональности отнесенный да да потом Разбираем разбиваем по функциональность какую-то функциональность можем не брать регресс то не берем и Копаем активно в сторону тестов Окей А как проверить что Ну вот как бы к успеху идем что правильном направлении движемся Ну во-первых оценивать время на регресс а во-вторых действительно хорошо считать количество пропущенных багов прот если мы там выкинули Корнер кейсы и у нас резко возросло количество багов проводе или которые мы находим роде или которые
00:26:22 - 00:27:38
мы находим в релизе то наверное мы что-то не так приоритизировали здесь можно даже не вести прям за рыбок в полисе можно просто вести Даже борт с багами из провода и если у нас вроде есть криты и блогеры то устраивать их разборы Ну я вводила это в афише И сейчас собираюсь здесь вести что мы у нас есть разбор инцидентов но мне некоторые баги хотелось бы еще такие что мы следами разработки или там человеком смотрим Почему этот бак пропустили не знаю у меня есть примеры жизни мы переходили на реакции часть страниц была
00:27:00 - 00:28:08
уже на реакте в проте через эксперимент раскатанный там но на сто процентов А в тесте тенге у нас не был этот эксперимент и у нас не было зафиксировано там не знаю при переводе значит можно тестировать не писался текст тестировщик Проверь реакции У нас два раза уезжали баги которые нам просто ломали страницы на реакте мы обнаружили Ты только в прозе Ну просто почти подряд они уехали срочно выключали эксперимент пилили хатфикс там обсудили что просто давайте мы в тестинге эксперименты Будем держать в
00:27:34 - 00:28:36
том же состоянии что и в проде и там тестировщиком повесим напоминалка просто природе тестирование будет прилетать комментарии Не забудь проверить страницу и на бэме и на реакция это помогло Да я думаю что мы немножечко поговорили про стратегию Я предлагаю двинуться как раз к теме раз ты играющая тренинг немножечко ближе к тестированию вот да Хотела узнать Вот какие вообще видят тестирование ты считаешь важными на каких-то фокусируешься При построении сейчас я вспомню просто в чистом виде как бы теорию с делением так в работе не
00:28:06 - 00:29:25
использовать Надо подумать но интеграционная сейчас традиционное регрессионное нагрузка нагрузка Я не занимаюсь но знаю что она есть интеграция просто часто встречаются Ну наверное вот функциональный функционально Я думаю ты активно используешь Судя потому что рассказывала да я пыталась вспомнить как это должно Да да я понимаю вот ну из поэтов функциональная из исследовательская иногда использую тестированию чисто uix мне в моем опыте это чаще задача не тестировщика это задача делать исследования на пользователях
00:28:50 - 00:30:20
с точки зрения X Потому что ты как человек внутри проекта ты смотришь на него не так же как юзер твое поведение отличается поэтому насколько У меня есть представление и исследование лучше я могу прийти сказать блин Мне кажется в этой фиче мы что-то сделали Очень неудобного Я прям иду по ней это мне кажется очень плохо Давайте обсудим Но именно полноценная как-то тестирование исследование надо делать на группе приближенные к нашим пользователям а не на людях изнутри потому что действительно искаженный взгляд
00:29:59 - 00:31:17
Окей хорошо И вот ты назвала какие-то Да вот Какие из них там ты считаешь важными какие-то мощные важными как-то они все важные Просто смотря для чего их применять то есть также как с графиками главное не забивать гвозди микроскопом не делать там не знаю графики ради графиков гонять из тестированием также гонять на каждую фичу и следует наверное тумачно какие-то большие новые фичи где мы хотим прям посмотреть как лучше сделать Да исследовательское тестирование бывает полезно хорошо бы не забывать что там надо
00:30:39 - 00:31:58
протестировании например задачи не только идем по тест кейсом по этой задаче А еще смотрим более широко но мне кажется исследовательская тестирование Классная штука ты никогда не забываешь что ты не только тупо чек-листу идешь как то тест условно говоря А твоя задача посмотреть немножко шире возможно какие-то вещи там чуть вбок не уверены что там насколько Понятно корректно сформулировала но мне кажется что здесь задача тестировщика всегда смотреть шире Да хорошо а вот да мы упоминали про твою команду как-то чекаешь что вообще твои
00:31:19 - 00:32:40
феи условно следует каким-то там техникам тест дизайна вообще пишут как-то корректно с точки зрения теории тестирования вообще считаешь что это важно может быть это такое типа больше тема для собеседований и не более того У нас есть ревью тест кейсов тест кейс на новую фичу обязательно должен превью другой тестировщик разработчик этой фичи чтобы ты с кейс был понятен не только тому кто ее там тестировал и написал кейс А я другим людям потому что правда бывает взгляд замыливается такой это же абсолютно очевидно
00:31:59 - 00:33:09
что тут очевидно я утрирую но правда на ревью бывает что является моменты лучших встреч там указать например подробнее У нас есть правило написания тест кейсов и там ревьюер может указать на то что в тест кейсе что-то Ну не указали компонент что-то сделали не так там предусловие неправильно писали плюс Ну я это делала в рамках работы в сторону автоматизации но я проводила ревью по ключам в тест кейсах и мы с одним из моих ребят договаривались что он просто выделит время на review всех наших кейсов из
00:32:35 - 00:33:55
регрессов чтобы проверить на дубли на не очень актуальные и вот такие вещи а вот если говорить вообще про техники дизайна какие-то считаешь важными Какие не очень какие-то самые часто использовал своей жизни Ну как-то мне кажется что чисто в моей практике там не знаю как в чистом виде ограниченные значения Например у меня редко бывает что такое нужно проверить просто какое-то поле на там словно вводимые символы Мне кажется самое все нужны в зависимости от задачи но для меня самый просто классная техника тест
00:33:16 - 00:34:30
дизайна без которой моя жизнь была бы гораздо сложнее две точнее таблицы принять решение Если я правильно помню тебе нужно проверить много сценариев и там если проводить Ну все сценарии это просто умереть можно а если ты можешь действительно разбить на вот блоки там типа очень такая это браузер такой-то как классический правильно помню описывается это очень сильный экономит время если ты пользуешься этим грамотно да Круто Спасибо И давай тогда такой немножко больше вопрос тоже про технику вот если мы представим какую-то базовую
00:33:53 - 00:35:19
веб-страничку там не знаю для доставки чего-нибудь давай что мы можем заставлять еды для доставки боула и там есть типа вот типа типа и кнопка заказать еще нужно ввести адрес доставки вот ну и соответственно ты нажимаешь заказать и у тебя заказывается всего просто одна такая страничка два года и вот как ты считаешь там с точки зрения своего опыта как эта система выглядит под капотом что на самом деле происходит когда я Нажимаю кнопочку ода сказать а у меня с фронта отправляется пост запрос с информацией о товарах в моем
00:34:36 - 00:36:01
заказе и моем адресе а на самом деле нет Сначала с адресом еще может быть что мы используем какую-то базу данных адресов когда человек не просто написал адрес это никак не проверяется не знаю когда ты будешь начинаешь водить улицы начинают вставляться из базы что-то Мы точно доставляем то есть нас должна быть проверка если не знаю допустим вставляем по всей Москве адрес должен быть в Москве если мы доставляем по всем регионам то нас должна быть не по всем районам должна быть проверка какой район доставка это
00:35:18 - 00:36:27
тоже как бы человек начинает водить адрес у нас уходит запрос частью адрес и мы смотрим Что мы можем подставить если это такого адреса у нас в базе Нет мы этот мы показываем это также Ну тут зависит от того это заставка готовой еды или там еды из ресторана тоже наличие товаров то есть Может быть 5 видов бол 1 какого-то нет в наличии надо про обязательно знать что наша система должна это учитывать не должна это учитывать как мы работаем с остатками тоже информации как бы как нам приходит возможно из какой-то другой
00:35:53 - 00:37:02
системы не напрямую нашей То есть это интеграция А дальше если у нас есть Да я хотела точнее еще просто дать А вот например когда ты отправляешь адрес доставки он некорректный вообще какой-то отправляешь запрос и какой тебе приходит ответ случай некорректного Ну тут зависит то как это оформлен второй момент это проверяется То есть если это у нас просто чекается адрес по воду не знаю там по символно то просто перестает предлагаться адрес и выводится на фронте ошибка а под капотом вот как происходит то есть нас же какой-то
00:36:27 - 00:37:46
сервис наверно валидирует ну то есть корректно адрес или нет И каким-то запросом делается как бы ты предположила какой ответ будет если это адрес некорректный если это адрес некорректный то нам просто в там массиве данных возможных начали водить улицу вывели Половину нам просто не приходит пустое множество Возможно подстановок мы не можем ничего поставить дальше показывает либо если мы валидируем адрес целиком то за отправляется запрос и нам приходит ответ вот я не помню сейчас точно какой-нибудь должен быть код ошибки
00:37:09 - 00:38:26
возможно зависит от Базы потому что например с Граф пелем это может прийти код будет 200 а вложенный уже будет текста номер ошибки или текст ошибки поэтому это зависит еще от того какой у нас бэк Ну смотри я тут скорее спрашиваю что точки зрения ты как Кейна чем бы настаивала что есть правильно с точки зрения такого какой ответ Ну вообще вообще тебе не найдено это у нас 404 Да это если бы у нас это ты бы искала с помощью поиска Да когда если с помощью поиска А так мне кажется зависит то как у нас реализовано потому что нас
00:37:48 - 00:39:16
например может если мы приходим с байка получаем пустое множество то нам просто говорит Вот поэтому адресу я ничего не нашел инфраньте мы должны это корректно А вот этот поезд Каким бы запросом ну поиск точно отправляется пост запросом потому что мы Передаем Мне кажется должен быть пост потому что мы Передаем в Боди там адрес если нескольких полях в нескольких но я думаю это по сути прочтение данных То есть ты читаешь данные да правильно Поэтому тут я думаю Get подходит больше но Окей То есть тут скорее Мне важно знать
00:38:36 - 00:40:00
твое мнение Как ты как-то бы просто наверное в том что я последнее время больше работала с grafq или почти все запросы пост был реализовано там у меня в моем опыте что чаще всего это пост даже если это там запрос на какие-нибудь не знаю Ну запрос на наличие чего-то в базе данных или что там по этому адресу У нас есть это был обычный пост так-то Да может быть Get вопрос скорее конкретный реализации конкретного бэкентом это rest или это Граф ql то Хорошо Окей но я тут скорее спрашиваю с точки зрения Да вот как бы
00:39:19 - 00:40:38
рекомендации теперь про такого скажем так хорошо еще такой вопрос Да вот когда ты создаешь сущность заказа ты тоже сказал что у тебя под запрос А какой будет ответ если все успешно а если все успешно то Ну 200 и должен прийти в ответ ну зависит от реализации но скорее всего нам должен не должен прийти в ответ айди заказа создано то нас надо проверить нас в базу про рост заказ что там он корректно весь пришел ничего не потеряли по дороге и в идеале клиенту в ответ должен приходить там номер заказа Возможно там что какой-то
00:40:01 - 00:41:21
экран подтверждения фронт скорее будет рисовать если у нас есть какие-то данные там про время доставки что-то такое то Мы тоже должны это показывать клиент Ну и получать соответственно от бэка а если например вот ну то есть мы когда создадим заказ мы создаем под авторизованным каким-то юзером А вот Каким образом Back and знаете что этот юзер авторизован мы ему в хедр по моему Передаем это А вот возможно ты знаешь какие-то виды авторизации какие мы можем передавать хайдеры конкретно Ну скорее всего мы Передаем стокен
00:40:44 - 00:42:04
и как это как это называется для соответствующего но это не то что обязательно знать Я скорее просто спрашиваю может ты знаешь я пытаюсь вспомнить потому что я точно это использую но я чаще всего что готовлю базу в постмоне или там в прописываю в хедер для Граф хюэля и у меня просто типа это сохранено уже настолько автоматика что я сохранено это поэтому наверное сейчас не скажу но это не так критично важно Поэтому да да ну в общем-то То есть если финализировать я а вот ещё такой вопрос про Ну то есть
00:41:24 - 00:42:42
когда ты отправляешь вот этот запрос на проверку адреса и Например тебе приходит там ответ такой что этот адрес не найден там либо если в зависимости от того проверка адреса что некорректный надпись некорректные данные то как в этом случае то есть Что должен делать фронтенд контент должен показывать валидный текст ошибки про то желательно не просто подсвечивать поле красным объяснять юзеру как-то вменяем ошибку что там адрес некорректный или в этот поэтому адресу мы не можем доставить если мы может быть если у нас есть такая
00:42:04 - 00:43:34
возможность если мы можем проверять опечатки У нас есть адрес отличающийся на одну букву мы можем предлагать его там то возможно в этом случае Нам тоже надо выводить ошибку что возможно печатка не Вот это ли это улицу условно говоря и Фронт в этом месте должен быть кнопку отправки заказа пока не будет введен корректный адрес точно так же как фронт должен быть кнопку если не выбран не один товар ни один бол да Хорошо окей Да я думаю что тогда можем постепенно Ну еще просто самый банальный я его всегда задаю на
00:42:48 - 00:44:08
собеседованиях потому что просто как это как кто-то мне сказал что это типа вопрос на дурака ли короче как-то это так объяснил но в общем это просто такой вопрос Чем отличается гет и пост Ну вообще как бы чаще всего говорят что Get Это только получить информацию о пост записать ее в базу данных Я знаю примеры Когда мы можем использовать пост для получения информации Мне кажется поэтому вот это конечно есть но это не ответ не на сто процентов с Get мы Передаем только через параметры информацию и не можем передавать если
00:43:28 - 00:44:40
правильно помню официально информация а с пост у нас есть боди у запросов которые мы можем передать больше параметров а сейчас больше параметров что еще Ну как раз например Да да я только единственное было наверное тут поправила Что именно не то что не можем так отправить скорее ну как протоколу мне рекомендую не рекомендуется дата физически наверное все таки можно но протокол Не рекомендую да да Хорошо окей Ну да еще там где-то есть пару свойств вот нота в целом Окей тогда да Давай двигаться дальше это
00:44:07 - 00:45:43
у нас было рубрика играющего тренера тренер в нашем случае да и дальше мы как раз перейдем к тоже одно из своих зон ответственности это пипал менеджмент Я думаю что наверное для меня это одна из важнейших частей в принципе еде потому что взаимодействие с людьми это конечно практически основная составляющая успеха одна из вот поэтому хотела для тебя узнать в первую очередь в чем в целом заключается People Management и какой ты какая-то элитка то есть есть разные типы Ты знаешь там больше которые поддерживают свою команду топит
00:44:59 - 00:46:25
за неё те кто больше топит за бизнес и пушат свою команду есть кто-то между то есть как-то себя оцениваешь ки для тебя основные ценности вообще пипл менеджмент Мне кажется что я как лит должна создавать для своей команды для своих там ребят ощущение что нас единая команда у нас нет не знаю я была на литкон в Питере и там было совершенно на каком-то докладе про как раз взаимодействие сотрудниками там был прекрасный вопрос зала про А вот если там рождаются сотрудников этой серии бизнеса это очень плохая для льда позиция потому
00:45:43 - 00:47:05
что тогда у вас Ты знаешь своих сотрудников фронтации с бизнесом от бизнеса приходят какие-то неадекватные идеи Вы почему-то должны их реализовывать у меня Я считаю что мне всегда везло С командами хороший то есть командами Мне тоже везло потому что нас всегда было представление что мы вместе работаем над продуктом у нас нет противостояния разработчики тестировщики разработчики менеджеры если где-то проблемы то мы вместе договариваемся потому что наша цель это как бы сделать продукт который будет нравиться
00:46:24 - 00:47:25
пользователям и зарабатывать деньги а не там не знаю есть такое часто мне кажется начинающих тестировщиков Да может быть опытных тоже нарежу встречала что вот там мы должны бороться за качество продукта любой ценой Ну вообще-то если мы будем делать стопроцентно идеальный продукт никогда не выйдем на рынок или вы позже всех конкурентов поэтому как как я это мои ребята должны понимать что мы оцениваем риски что мы с какими-то вещами готовы сказать что минорный баг который пользователь никогда не увидит
00:46:54 - 00:47:53
или там это баг не критичный для нашего функционала который нужно срочно запустить Мы готовы катиться с ним Мы принимаем эти риски мы доносим их до менеджмента обязательно потому что Наша задача какой-то книжки чтобы было про то что тестировщик это фары проекта мы не принимаем решение за всех но мы подсвечиваем все проблемы которые мы видим подсвечиваем риски мы даем бизнесу правильную оценку рисков Ну то есть не знаю сказать мы не Я запрещаю выпускать этот релиз это некорректно потому что во-первых это
00:47:24 - 00:48:31
может быть не знаю огроменный запуск на который Просто у нас завязаны реклама миллионы бюджета такой ну Нет я не буду выпускать этот блин У нас рекламы запускается через э-э полчаса какой они запускаем в рейс нам надо показывать риски для этого важно создавать в своей команде ощущения что А мы все вместе работаем над одним продуктом у нас нет противостояния а не нужно там не знаю даже если какие-то конфликты с разработкой для командой там моя позиция должна быть такая Да вот здесь у нас было не очень сейчас мы будем
00:47:58 - 00:48:59
договариваться как сделать лучше не они плохие что вот здесь там не знаю забыли про договорённости а там все люди бывают а-а сейчас мы выстраиваем процесс Чтобы такого больше не было мне кажется вот это вообще самое важное задача Лида Ну и дальше для меня очень важно поддерживать ребята Быть человеком которому которому придутся проблемами Потому что люди не роботы особенно В текущей ситуации для меня важно что ко мне приходят с проблемами для меня важно что там на один день приходит мои девчонки говорят
00:48:28 - 00:49:36
Слушай что-то я не очень я вот вижу что я косячила тут и тут я могу во-первых там человеку успокоить я не ждут человека сейчас там все эти последних ситуациях 146 процентов вложенности Не важно что происходит Я работаю Я понимаю что все переживают Я понимаю что сейчас у всех сказывается на работе моя задача следить чтобы совсем не просела Конечно все но при этом поддерживать людей потому что поддерживаешь работают и чувствую себя лучше чем люди которые работают не знаю на Ты должен опять же ко мне приходит там с вами Вот
00:49:02 - 00:50:13
здесь у меня я не очень Ты смотришь говоришь Ну вообще вот это не проблема вот это вот решается так-то а вот с этим Да нужно поработать это очень важно для меня как для руководителя не знаю быть руководителем с человеческим лицом у меня почти всегда были руководители человеческим лицом и это очень классно драйвит такая правда человек очень долго переучился скорее там в личной жизни не в работе работать не на критике а на позитивном подкреплении и это действительно вот совершенно разные вещи как популярные
00:49:38 - 00:50:46
психологи не знаю говорит что там на пинках самого себя далеко не уедешь или уедешь но как бы не очень эффективно надо работать жить с любовью к себе мне кажется что в отношениях с моими сотрудниками это тоже очень важно что я не там прихожу стучу кулаком говорю там не знаю А почему вот такой косяк не наезжа людей А если кто-то косячит там стараюсь это очень вежливо но и аккуратно подсветить там выяснить в чем проблема то может быть человек не забудь просто нужно отправить он год не был в отпуске это моя задача как
00:50:12 - 00:51:26
руководитель здесь сказать Блин давайте сходишь в отпуск а потом мы посмотрим Да если человек продолжает косячить то мы расстаёмся но не то что ты дурак Вот здесь плохо сделал Итак еще моя задача как руководителя принимать требования бизнеса и проращивать их в наши процессы например мы переходим на продуктовые команды Мне нужно понять как мы будем жить дальше как это прорастить в своей команды как исходя из того куда бежит бизнес я могу вставить цели своим сотрудникам То есть у меня есть всегда какая-то установка
00:50:49 - 00:51:55
сверху Куда мы движемся дальше я смотрю как на людей на их потребности я могу это перенести кто-то хочет сейчас развиваться больше в People менеджмент я могу человеку там дать команду где например много устав сказать он координирует их или это Мы готовы сейчас у меня было например период полгода когда мы договаривались что в первую очередь мы делаем упор на качество бизнес договорились с бизнесом что да разработка сейчас работает меньше процент над продуктовыми фичами большими занимаюсь там скоростью
00:51:21 - 00:52:30
стабильностью автотестами как я это могу прорастить в ИП цели своим сотрудникам Да очень на самом деле крутой ответ мне нравится в целом подход такой человечный Мне кажется он реально это единственный возможный подход при котором возможно чего-то добиться вообще и расти хоть как-то Да поэтому наверное месяц интересно можешь рассказать какой-то один кейс который ты считаешь самым тяжелым с точки зрения который у тебя был и как-то из него вырубила Сейчас подумаю Ну наверное здесь самый тяжелый кейс
00:51:55 - 00:53:09
который у меня был он был связан с недостаточностью предыдущих водных мне передали команду из числа моих ребят не передали команду с ребятами кстати вот у нас есть Старый Лид в этой команде тестирование и вот у нас новый человек который идет ему на замену будет новым лидом и вроде было все окей от старого предыдущего рядами не было никаких нареканий на человека а когда я пришла там сообщать командам что вот у вас будет новый допустим условный там Вася казалось что менеджмента есть вопросы к работе Вася Есть какие-то
00:52:34 - 00:54:04
конкретные там случае критики что было не очень здесь я считаю что просто была моя ошибка когда что я приняла водную как есть пообщалась с менеджером пообщалась Да нет прочекало всю ситуацию более детально и получилось что я сказала человеку что вот мы будем ставить себя ли дом после этого пришлось ставить встречу там один-два на со мной менеджмент менеджером чтобы рассказать про ошибки что мы хотим чтобы человек исправил Мне кажется из моих всяких ситуаций это была самая тяжелая потому что довольно
00:53:19 - 00:54:37
неприятно такая Да чувак Мы ставим тебя ли дом а потом такая Слышит вообще-то нет не очень для меня было прям не очень Мне было довольно неприятно в этой ситуации понятно что разрулили но как-то я чувствовал себя очень неловко да Ну я так понимаю что то есть ты считаешь цену этот кейс успешно завершенным правильно Ну он пока в процессе но он там на текущий момент мы договорились что там человека не ставим ли дом смотрим исправляет ли он свои ошибки если там ну не исправлять там вообще с ним расстаемся
00:53:59 - 00:55:13
Окей хорошо А если вот представить что такое кейс что Ну вот тоже ты приходишь на тот же проект который мы уже обсуждали и там ситуация с тем что людей куча регресса какого-то беспросветного Ну и нет никаких скажем так мотивирующих вдохновляющие задач Все супер выгорели все уже не хотят это делать задачу которую вдохновляли Нет вот как в этом случае Как спасти вообще команду людей Ну мне кажется здесь во-первых нужно разбираться с прогрессом немножко снимать людей нагрузку важно чтобы люди понимали что я готова менять учитывать
00:54:37 - 00:55:55
их пожелания и менять ситуацию к лучшему я сейчас просто со своими ребятами регулярно бегают просто с практически с помпонами такая если вас что-то болит скажите Давайте это переделаем смотрите Я занимаюсь процессами готовы это менять Мне важно во-первых чтобы был какой-то реальный результат что вот я работаю над регрессом становится легче процессы будут меняться показать что есть свет в конце тоннеля с действиями потому что словами здесь слова кто угодно может сказать Возможно там если позволяет нагрузка подправлять
00:55:17 - 00:56:25
ребят по очереди выпуска отдохнуть потому что правда отпуск помогает Если есть такая возможность а дальше оценивать если там ребята идут на контакт постараться выстроить этот контакт там где нужно не то что прикрывать а скорее Давайте ощущение что я стою за ними и поддерживаю Ну не знаю у нас Недавно была ситуация а нам нужно было выкатить срочных от фикс э дежурила э-э одна из моих сотрудниц которые не очень давно работает ну у нас пришло очень сложно и система Там есть много нюансов вот в середине таких от фикса приходит
00:55:51 - 00:57:06
менеджер в чат Такой типа А почему вот это не едет в релизе вроде обсудили это надо или кто не говорил что это должно ехать в релизе она пишет мне в личку такая Слушай а вот блин что не так мы действительно здесь я действительно здесь просящего или что я такая так спокойно Сейчас я приду в чат как бы если надо то возьму огонь на себя Потому что правда Ты не обязан знать Вот такие подкапотные вещи которые сильно подкапотные системы изнутри прихожу как бы говорю мы договорились вот об этом то у меня такой-то
00:56:29 - 00:57:34
представление что это сейчас функционал можно Опять без релиза если я не права то давайте это обсудим и зафиксируем выясняется что да раньше нельзя было поменять без релиза сейчас можно поменять без релиза все окей Просто случился такой Мисс индекс standing моя задача здесь прийти и защитить человека который точно совершенно вот здесь не виноват вот такое ощущение что как бы я на готова такие вещи разруливать я не буду говорить вот он виноват спускать всех собак прилюдно здесь дальше не знаю зависит правда от
00:57:01 - 00:58:24
команды может быть такое что действительно люди настолько выгорели что они больше не верят в этот проект У меня такое было в работе с которой я шла тестирование я уходила очень сильно выгоревший вообще не в том что приходило очень горя на эту работу Мне очень нравилось то что я делаю первое время я ходила абсолютно что не смогло бы поменять мое отношение к той работе возможно в этом случае нам нужно расставаться с людьми искать новых Хотелось бы конечно починить имеющиеся Но я допускаю что люди могут настолько
00:57:45 - 00:58:49
выгоревшие что просто не верит в этот проект они не верят что что-то будет меняться к лучшему и они не готовы уже ничего делать для этих изменений вот а скажи как ты проверяешь это состояние сотрудника ты сказала про выгорание Я так понимаю что ты сама пережила этот опыт и я думаю ты прекрасно понимаешь насколько там важна как бы ну вовремя За детектится состояние начать что-то делать Вот как Какие у тебя есть инструменты для того чтобы как-то чекать состояние сотрудников Ну у меня есть 11 сотрудниками на которых там я должна в
00:58:16 - 00:59:36
том числе оценивать состояние Хорошо если у меня доверительные отношения человек там состоянии сам это за собой заметить сказать у меня есть такие ребята которые говорят прям я как-то очень устал хорошо что меня отпуск через две недели я надеюсь что там сейчас спокойненько до отпуска без косяков доживем Я отдохну будет лучше или вещь которая могу прощать на 11 я чекаю на 11 вещи которые я могу фидбэк от менеджеров Потому что при хороших отношениях менеджерами как вот с примером протоколе Да надо просто раньше
00:58:56 - 01:00:07
спросить менеджеру конкретному сотруднику менеджера или разработку могут замечать что человек начал постоянно косячить не выполняя там свои обязательства и там это фидбэк который я могу получить от них это вещи которые я могу сама увидеть не знаю если мы Разбираем пропущенный в продлитые блогеры что у нас это постоянно задачах одного и того же человека либо здесь не хватает погруженности в проект Например у меня была история Что человеку брали сначала на одно а потом на него свалили тестирование гораздо больше функционала
00:59:32 - 01:00:42
и получилось что нет нормального погружения человек не то что плохой тестировщик а просто тебя не погрузив просто Кинули в режиме плыви сосиска в сложный проект в котором сложно разобраться вот так а если это у меня был кейс что правда человек там регулярно косячит пропускает криты впрод мне пишет документацию закрывает мои задачи на документацию не доделав я проверяю такая Блин где половина сделанного человек не справляется вещи по которым можно это следить там косяки В задачах невыполнение задач слив
01:00:08 - 01:01:21
договоренности и то что ты когда с человеком про это разговариваешь он говорит Да ничего не меняется Ну вот по этим всем можно прочекать но если ничего не меняется Да с человеком расстались в итоге а вот есть эти темы знаешь которые часто сами сотрудники немного табуированных прям поднимать это там типа вопрос окладов еще чего-то то есть как ты чекаешь скажем так вещи которые Да действительно сам их не назовет она то есть они так будут накапливаться накапливаться пока не вспыхнут в один день на этом не нет
01:00:44 - 01:02:03
ответа Я не настолько опытный руководитель очень интересующий меня вопрос на как раз Team litton Я сходила на очень интересный доклад Одноклассников бординг и в условиях работы в большой компании Я понятно следую правилам как процессом который у нас есть вообще по-другому работать в бордингом например были очень интересные идеи что у них Лектор рассказывала что культура Когда у вас например есть прозрачная система как мы расстаемся с человеком если человек уходит сам если нас не устраивает работает Просто зафиксированы на Вики
01:01:24 - 01:02:42
это помогает человеку самому понять не стесняться подойти сказать Слушай ну вот я собираюсь например увольняться навеки зафиксировано или я знаю что процессом если я прихожу говорю я увольняюсь не говорят не Ну и пошел А мне говорят типа да смотри Окей давай заключим пример от нее Давай заключим допник на расставание по соглашению сторон на два месяца За это время там ты сейчас ищешь работу передаешь свои дела И там через два месяца Мы точно Прощаемся Мне казалось что это очень интересный инструмент Я никогда с этим не
01:02:05 - 01:03:23
сталкивалась сама ну здесь мы правда нет хорошего ответа потому что я и наблюдала ситуации когда человек приходит Как ты Как коллега видишь что у тебя человек ну коллег твой коллега собирается увольняться но не хочет например об этом поговорить Или он не верит что там но он хочет просто уйти на большие деньги не верит что это здесь как-то можно решить как руководитель я не знаю как пока как такие вещи отслеживать на самом деле Да я понимаю просто интересно И у меня тоже это такое актуально для меня был вопрос А я не
01:02:44 - 01:03:47
помню где мне кажется тоже в какой-то книге либо это был курс оттоса прокинится вообще я нашла да матрицу чек которая в которой освящены все там Я не помню сколько по какой-то тоже по какой-то там теории менеджмента 12 где-то сфер важных в работе для любого человека Ну то есть это разные вещи насколько ты вовлечен в команду насколько ты удовлетворена накладом беннису ты офисом насколько тебя ценит насколько влияешь на ТО на решение руководства там в общем на самом деле большой список вопросов Я думаю возможно
01:03:18 - 01:04:30
кому-то будет интересно я прикреплю могу скинуть давку видео в общем Суть в том что там вот все разные сферы оцениваются Как тебе человек чувствует И Например я провожу Перед каждым антуаном человек заполняет эту форму и так ты оцениваешь это единицы до 10 насколько ты себя комфортно чувствуешь и это прикольно потому что человек мог не думать а устраивает ли его например его зарплата но у него есть такой вопрос обязательно в этой форме и он начинает задумываться и типа ты так или иначе видишь какую-то сводку знаешь такую
01:03:54 - 01:04:58
верхнюю уровневую А где мы сейчас где низко где хорошо сразу выявляешь вот я на основе этой формы выявляют темы для беседы на надувания то есть помимо того что так человека накопилось я сразу вижу что вот эти три темы часто например сейчас это продуктивность это Как вы оцениваете свой тайм-менеджмент вот это вот вещи которые сейчас например в текущее время он сразу думаешь как над этим работать вот но и оклад тоже знаешь можно как это из месяцев Месяц видеть прогрессию куда вы движемся и тогда Бывает такое что человек вообще он не
01:04:26 - 01:05:35
удовлетворялся меня был удовлетворяться докладом а потом резко раз и в общем почему-то стал удовлетворенной тоже интересную тему для какого-то анализа Вот Но это вообще были там был чек-лист [музыка] признаков по которым ваши сотрудник скорее всего собирается уволиться я себе фоткала как раз там с эффективностью работы с какими-то еще вещами То есть просто можно по какому-то комплексу причин предположить что возможно человек собирается увольняться и попробовать как-то аккуратно про это поговорить О
01:05:01 - 01:06:11
это я тоже предлагаю тебе скинуть Да отлично так но Смотри я думаю что у нас как раз таки не очень много времени я предлагаю двигаться к лиц менеджменту тут много наверное не буду спрашивать просто у тебя спрошу как ты видишь какой-то идеальный релиз процесс ты работаешь свет приложениями правильно но Давай назовем для для приложения допустим у нас может быть два Flow мы либо мерзнем задача сразу в какую-то релизную ветку либо у нас момент релиза собирается все что должно в мержиться первый вариант Мне кажется удобнее
01:05:37 - 01:06:58
потому что мы не решаем конфликты в момент релиза у нас идет сборка релизов тестинг прогонов тестов на тестинги проходится регресс можно могут например точно кстати про Как сделать еще жизнь легче если у вас огроменный регрессы У нас есть такое решение мы можем отдать им отдаем а должны быть какие-то договоренности как задачи попадают в релиз четкие То есть у меня были релизы где просто все Что успели находите в мерживается едет в релизе Мы тестировались в тестинге Ну часто так с бэкендом Мне кажется потому
01:06:22 - 01:07:58
что сложно поднимать очень дорого поднимать стенд на каждый брендовую задачу или у нас релизее это только протестированные задачи которые там вот в таком-то статусе с каким-то отчетом допустим собираем релиз на тестинге тестируются релиз если нужно то там прогоняется на отдельном стенде нагрузка в моем опыте скорее не при каждом релизе словно раз в неделю запускаем Так что может быть у кого-то может относиться к релизу может не относиться авто тесты регресс если нужно там проверка отчетов если у нас есть криты и блогеры в релизе
01:07:10 - 01:08:31
то мы их чиним ход фиксем или откатываем задачу из релиза зависит там важности задачи насколько Нам срочно нужен релиз если в релизе нет блокирующих багов то оптимально Мне кажется мы выкатами смотрим график ошибок но это чаще уже задача разработки и катимся в прод Отлично Да но на самом деле достаточно глубоко рассказала технические аспекты Я так понимаю что ты разбираешься скажем так как это выглядит примерно верхний уровень него сам сами условно там пай планы у нас разработка Да мы только мы
01:07:49 - 01:09:07
переезжали не так давно из гитхаба в этом году и у нас релизный цикл релизы переехали тоже на новую платформу и мы там вместе с разработкой внутренних наших инструментов и релизы у нас тоже сейчас Flow и все это в нашей внутренней одной системе как раз договаривались например там Какие вещи какой момент можно перевести можно тестировать в тестенг автотесты еще не прошли ручным тестированием Я здесь организационные какие-то вещи решала что вот как бы есть вещи которые мы не можем не как подвинуть есть вещи с которыми мы
01:08:31 - 01:10:00
можем просто не знаю поменять кубики запуска местами потому что это более логично или там параллельно запускать Я здесь Там выступала больше с менеджерской стороны Ну и потом с обновлением документации для тестирования Окей отлично Тогда слушай я думаю что красное время подходит концу Как можно то что мы перешли к фидбеку это завершению да да на самом деле в целом Я в восторге от нашего интервью потому что мне кажется это крайне полезной информации что мы здесь обсуждали вот касаемо моего фидбэка моей оценки Мне показалось
01:09:21 - 01:10:44
что ты твоя наверное самая сильная часть это реально пипл менеджмент стратегии тестирования тоже как мне кажется ты больше такой софт руководящий человек но я имею лисовский Чем хаски в плане Хаски это больше твоя зона роста асов скилл это то как раз твоя сильная сторона которая помогает тебе Ну я лично считаю это очень хорошо потому что неоднократно обсуждался этот вопрос выбирая между руководителем хардовым человеком и софтом человеком сто процентов Мне кажется Успех за софтовым Ну и особенно если он будет
01:10:03 - 01:11:17
качать в процессе Это замечательно вот ну и в целом тоже мне показалось что ты руководитель больше за команду за решение такой человек медиатор между своей командой и бизнесом вот из сильных сторон что мне очень понравилось это в первую очередь готовность ответов То есть когда я задавала вопрос У тебя готова будет сразу какой-то список кейсов список метрик готовых То есть тебе не приходилось знаешь в этот момент в голове сидеть и весь опыт свой авторизировать собирать все это структурировать то есть видно что у тебя
01:10:40 - 01:11:55
ты сразу знаешь какие у тебя сильные метрики Какие Как решаются кейсы и так далее про кейс который я тебе задала тестирования Мне кажется ты Отлично решила ты все сказала важные моменты которые Ну вот я тебе ждала единственная ты не упомянула про пирамиду тестирования то что иногда когда мы Разбираем там оказывается такое что-то с пересекают друг другу ну типа там 100 с кейсов которые на самом деле тестируют одно и то же да Ну вот по сути все остальное как раз было сказано вообще все что я ожидала Вот про people
01:11:17 - 01:12:34
менеджмент я тут прям записывала твои фразы потому что очень связано сильно вытирает эта тема про вот честность доверия то есть твоих кейсов ты рассказывала как люди приходят к тебе и честно говоря о том что они выиграли Мне кажется это офигенный уровень взаимоотношения со своим со своей командой вот еще мне понравилось фраза про то что тестирование это фара и некоторые подсвечивает риски то есть мы не можем как бы все переделать мы не можем реально остановить релиз это круто что ты не принципиально стоишь на своем
01:11:56 - 01:13:08
что вот у нас тут бак мы не идем А ты понимаешь что есть ситуации в которых мы не можем не идти то есть мы должны поэтому мы должны думать как вот жонглировать между ты кто там оказались Вот и соответственно это реально очень круто что прикольно что мы как фары подсвечиваем риски Вот про твой сильный кейс в People Management первое что ты сказала и я тоже прям сразу это схватила про то что твой твой кейс был в том что у тебя было недостаточно предыдущих водных данных Мне кажется это тот уровень зрелости
01:12:32 - 01:13:43
именно в таком менеджменте вообще человека когда Ну вот это прям очень важно что ты понимаешь что любая задача решается от контекста То есть ты можешь считать что человек сидел очень плохо и так далее но оказывается не хватало кого-то кубика в контексте и ты понимаешь что оказывается все иначе потому что ну коммуникации всегда много очень нюансов Вот и тут же в этом же кейсе ты упомянула что ты считаешь что ты ему недостаточно корректно разрешила это тоже мне кажется супер важно для руководителя уметь признавать свои
01:13:08 - 01:14:13
ошибки лично тем более лично и это значит что ты тоже на очень крутом уровне зрелости находишься Вот и про то как замотивировать людей тоже мне понравилось что то есть ты не решаешь этот вопрос обещанием каких-то гор золотых которые естественно сразу не прибудут А то что ты сказала что должна быть Вера людей в то что ситуация меняется с этим абсолютно согласна Я думаю самое главное что может замотивировать людей в такой ситуации вот а про релизные процессы мне понравился ты знаешь технически подробности То есть ты примерно
01:13:40 - 01:14:48
представляешь как устроены ветки кто что куда мерзнут и так далее То есть это ну абсолютно не обязательно часть для менеджера такого высокого звена но когда человек технически понимают высокого у него что происходит это замечательно Вот ну и целом еще упоминал что хочешь на концы видно что у тебя горят глаза профессии для меня это ну как для нанимающей стороны реально очень важный фактор вот если говорить про зоны роста которые Ну вот эти зоны роста так и в целом так и именно по прохождению собеседований А вот у меня
01:14:14 - 01:15:26
был вопрос про процесс тестирования про какие-то конкретные Шаги а ты там ответила но возможно в моем понимании ответ мог бы быть более структурированным с той точки зрения что когда ты собеседуешься на киеда это очень популярный вопрос и я всегда всем людям рекомендую заранее знаешь как Ну это тоже Просто сразу сложность ты не готовился выдать ответ на этот вопрос Поэтому иногда лучше тоже авторизовать этот опыт посидеть подумать Какие вещи для меня Важны и как-то их структурировать и тогда тоже всегда
01:14:50 - 01:15:48
будет готов ответ на этот вопрос В любой момент вот потом про описание тоже какие-то решений Ты часто говорила про какие-то такие мануальные проверки Это неплохо просто скорее я как человек который немножко склонны к автоматизации Мне было интересно Еще как ты какие-то процессы автоматизировала не с точки зрения даже кода с точки зрения там какой-то инструмент может быть какой-то пайплайн строил еще треки Ну то есть какие-то такие вещи тоже прикольно Это как кейсы можно собрать и рассказывать Чтобы
01:15:19 - 01:16:28
показать что ты еще тут с автоматизации тоже ничего Вот про виды тестирование Но это надо сказать очень популярная тема то есть практически все люди которых сейчас беседуют всегда с этим вопросом немножко теряются потому что ну я согласна первых это немного далековато или да Это скорее просто Тема которую У меня тоже самое было нужно просто один раз структурировать получить Потому что всегда в этом вопросе Мне кажется самым выигрышным ответом выглядит когда ты структурированно отвечаешь Что вот у нас
01:15:54 - 01:17:11
есть там видят тестирования по доступу коду Да там разные ящики У нас есть тестирование связанные с изменением в ходе это соответственно регрессии так далее есть там по тестированию функциональность не Тестируем функционале Короче когда вот это вот иерархия Новый человек в голове четко выстроена и он я быстро может воспроизвести я согласна что это не очень такой знаешь прям супер практичные знания Это скорее части знания для собеседований да про тоже про технике дизайна тоже тебя спрашивала и ты там ответила но у
01:16:32 - 01:17:45
меня скорее тут был комментарий про форму ответа тоже это чисто тема про подготовку к собеседованиям когда человек задает какой-то вопрос Например я у тебя спрашиваю типа там А какие техники тест дизайна ты у своих кей чекаешь или как ты это делаешь то тут как можно некоторые простроить структуру ответа Первое это хвататься ключевые слова Вот я упомянула слово техника дизайна значит для того чтобы ответ казался таким максимально просто не придраться первое что можно сказать но в этом теплотехники этот дизайн бывают
01:17:09 - 01:18:15
какие-то такие-то Я слежу за своими кеями так-то так-то делают а потом это потом Ну то есть в этом ответе иногда когда человек прямо не говорит теорию кажется что он от нее увиливает это просто составные интерьеры иногда такое бывает и поэтому Я рекомендую сначала директивно ответить типа бывают такие техники что у меня сразу я все Вопросов нет но как бы человек знает сейчас все объяснить вот ну ты потом ответила Я просто это к тому что в этом моменте Да у меня могло сложить впечатление что ты не знаешь и немного увеличиваешь вот да
01:17:42 - 01:18:49
и про там и про запросы разбирались тоже про эту тему то есть тоже это может быть зона роста в плане того что мы обсуждали там где дед где пост какие ответы возможные и там еще разницы нет пост тоже это тема чисто для собеседования рассказать про импотену Если всё такое Но это просто не практическое суперзнание просто сама на собеседование Я понимаю ну короче там тоже сказать про свойство безопасности Вот и про там у нас были коды ответов вот когда у нас некорректные данные 400 код ответ и про создание сущности у нас 201 отведка но
01:18:15 - 01:19:55
должен быть то есть то что Create от сущность создана Вот Но это такие как темы то есть меня бы это не смутило Потому что эти вопросы Скорее для того чтобы понять глубину твоих технических знаний но Понятное дело что технические знания не входит напрямую зону твоей ответственности то есть скорее в моем понимании от человека своей позиции требуется высокоуровневое понимание что происходит Вот как ты знаешь куда что мерцают на таком уровне а прям вот то что ты подзабываешь из-за того что активно не
01:19:06 - 01:20:12
занимаешься этим руками но это целом нормально вот да Так но еще я хотела сказать что здесь у нас собеседование пришло в таком варианте именно разговора и мне почему-то кажется что именно так должно приходить собеседование Ну я их так провожу обычно Тем более когда речь идет и руководители Вот я думаю что если ты хочешь тоже можешь дать какой-то фидбэк Ну у меня наверное есть Мне было очень интересно поучаствовать в собеседовании в роли льда с учетом там изменений которые у меня были в рабочих обязанностях за последний год
01:19:38 - 01:21:01
действительно очень интересно получить фидбэк про какие-то свои точки роста про там вопросы каких-то замечаний прямо у меня так нет наверное Просто ты очень интересный опыт я действительно думаю что есть что себе так записать как точки роста и не забыть об этом
01:20:21 - 01:21:03