Техническое собеседование ручного тестировщика с компанией АО «ГНИВЦ»

Подготовка к собеседованию на QA Engineer

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

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

    00:00:00 - 00:01:26

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

    00:00:47 - 00:02:08

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

    00:01:28 - 00:02:57

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

    00:02:12 - 00:03:40

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

    00:03:00 - 00:04:31

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

    00:03:46 - 00:05:15

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

    00:04:33 - 00:05:51

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

    00:05:13 - 00:06:42

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

    00:06:01 - 00:07:46

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

    00:06:53 - 00:08:20

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

    00:07:37 - 00:09:26

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

    00:08:46 - 00:10:07

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

    00:09:26 - 00:10:57

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

    00:10:12 - 00:11:52

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

    00:11:14 - 00:12:37

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

    00:11:57 - 00:13:45

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

    00:12:53 - 00:14:20

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

    00:13:41 - 00:15:04

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

    00:14:21 - 00:16:04

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

    00:15:27 - 00:16:44

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

    00:16:06 - 00:17:34

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

    00:16:59 - 00:18:30

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

    00:17:47 - 00:19:36

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

    00:18:56 - 00:20:19

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

    00:19:39 - 00:21:24

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

    00:20:33 - 00:21:54

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

    00:21:13 - 00:22:34

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

    00:21:53 - 00:23:22

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

    00:22:45 - 00:24:07

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

    00:23:32 - 00:25:03

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

    00:24:18 - 00:25:44

  • проверять какие-то перес вокруг этого Бага потому что вот условно говоря принцип в том что баги имеют свойство скапливаться в каком-то одном месте как принято рассуждать что 80-20 потом Отсюда тоже в не совсем отсюда Но следующий принцип это так называемые принцип пестицидов заключается в том что Парадокс Да пестицидов в том что это все из вот как называется правильно агрокультура В общем если обрабатывать растение одним пестицидом не меняя его то баги будут в конце концов заводиться те же старые

    00:25:00 - 00:26:23

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

    00:25:49 - 00:27:08

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

    00:26:29 - 00:27:47

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

    00:27:11 - 00:28:26

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

    00:27:49 - 00:29:13

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

    00:28:30 - 00:29:55

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

    00:29:16 - 00:30:48

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

    00:30:07 - 00:31:43

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

    00:30:59 - 00:32:35

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

    00:31:49 - 00:33:28

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

    00:32:41 - 00:34:10

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

    00:33:31 - 00:34:45

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

    00:34:09 - 00:35:29

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

    00:34:48 - 00:36:28

  • ипаме работал как же его зовут А как называется Сейчас тестирование программного обеспечения есть на русском На английском я сейчас забыл на вылетел из головой фамилия но он знаменитый человек написал очень хорошую книжку Вот она что она есть тестирование много типов по разным параметрам разделяют функциональные функциональные автоматическое ручное Альфа Бета Гамма Вот то есть их много собственно насколько я помню функциональная структурная и тестирование изменений [музыка] в которую я не стал влазить

    00:35:46 - 00:37:13

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

    00:36:40 - 00:38:19

  • или по каким-то параметрам считаем что нужно перепроверить например когда мы получили нашли бак написали бы дали девелоперу он его исправил мы должны проверить функцию или проверить Все ли действительно ли подчинилось или нет поговорили по поводу вопрос был Ну ладно потом про уровне кажется это самая пирамида Да это речь про [музыка] unit-тестирование докационное тестирование Systems System тестирования Ты кажется больше специалист по истек би напомню что astic B говорит по поводу если сейчас там accepton с тестим на

    00:37:31 - 00:39:08

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

    00:38:31 - 00:39:53

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

    00:39:14 - 00:40:33

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

    00:39:52 - 00:41:22

  • проверяем чаще всего Как с точки зрения конечного пользователя как наша система работает вся вместе вот что мы делаем на приёмочную на приемочном а у нас не обязательно есть одна система в продукте у нас может быть там несколько систем например в продукте Вот но приёмочная тестирование Я насколько помню там тоже был спор по поводу этого типа Стоит ли его в пирамиду excepton включать спор по поводу того что вообще вся процедура вот этого exceptance тесте насколько я понимаю могу неправильно понимать в том что мы

    00:40:44 - 00:42:10

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

    00:41:27 - 00:42:57

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

    00:42:12 - 00:43:35

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

    00:42:54 - 00:44:04

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

    00:43:29 - 00:44:51

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

    00:44:11 - 00:45:38

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

    00:44:55 - 00:46:29

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

    00:45:41 - 00:47:16

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

    00:46:40 - 00:48:01

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

    00:47:23 - 00:48:36

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

    00:48:02 - 00:49:50

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

    00:49:06 - 00:50:58

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

    00:50:04 - 00:51:26

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

    00:50:45 - 00:52:30

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

    00:51:43 - 00:52:59

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

    00:52:24 - 00:54:01

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

    00:53:29 - 00:54:51

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

    00:54:12 - 00:55:51

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

    00:55:04 - 00:56:32

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

    00:55:53 - 00:57:15

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

    00:56:35 - 00:57:47

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

    00:57:10 - 00:58:58

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

    00:58:09 - 00:59:32

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

    00:58:50 - 01:00:12

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

    00:59:31 - 01:00:53

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

    01:00:21 - 01:01:43

  • скорость [музыка] совершенно страшное какое-то какие-то Ну с устаревший дизайн не хотелось бы чтобы новенькое что-то было Вот мы такие вещи собираем с от заказчика сделаем такой вот интервью Анкетирование можно назвать заказчиком и записываем собственно что что болит какая боль основная я пока что слышал вот приложение выглядит не очень красиво не актуально например там она 2020 2001 года например Но работает но выглядит устаревше другая проблема Это что оно работает медленно по какой-то причине хотелось бы Понять насколько

    01:01:03 - 01:02:33

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

    01:01:48 - 01:03:27

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

    01:02:40 - 01:04:14

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

    01:03:31 - 01:05:09

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

    01:04:20 - 01:05:59

  • очень популярная и у нас в день 12 или 20 тысяч заказов происходит Какие логии приходишь большой логин если сейчас включу логина Все у меня Все рухнет а что ты хочешь узнать Да если мы не знаем точно При каких условиях происходит ошибка Ну по крайней мере в логах мы можем отфильтровать влоги включает его чаще уже с фильтрами напротив говоришь Да мне нравится на одном из прошлых проектов мы использовали в мобилке Open Source продукт Send centry и для Веба есть встраивается в продукт легко используется

    01:05:15 - 01:06:52

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

    01:06:12 - 01:07:30

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

    01:06:56 - 01:08:24

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

    01:07:40 - 01:09:16

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

    01:08:30 - 01:10:08

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

    01:09:18 - 01:10:59

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

    01:10:15 - 01:11:49

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

    01:11:04 - 01:12:24

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

    01:11:44 - 01:13:13

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

    01:12:29 - 01:13:58

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

    01:13:13 - 01:14:41

  • и аналитики и продуктованы их не перечислил конечно съесть продуктовый У нас есть продукт менеджер они собирают хотелки Они формируют backlock на каждый реликт на каждый релиз у нас product Manager очень активно работает над главная его задача прям сильно отличается от предыдущего опыта Ну прям круто работает на самом деле очень четко следит за движением тикетов то есть работает полностью как скрам мастер замечательно когда у нас доходит до тикеты до состояния то есть они проходят простой вопрос Можем ли мы это

    01:14:00 - 01:15:35

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

    01:14:49 - 01:16:25

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

    01:15:41 - 01:17:01

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

    01:16:23 - 01:17:38

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

    01:17:01 - 01:18:16

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

    01:17:40 - 01:19:11

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

    01:18:28 - 01:20:28

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

    01:19:40 - 01:20:59

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

    01:20:20 - 01:21:29

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

    01:20:54 - 01:21:56

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

    01:21:26 - 01:22:41

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

    01:22:08 - 01:23:17

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

    01:22:42 - 01:23:53

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

    01:23:18 - 01:24:34

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

    01:24:04 - 01:25:20

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

    01:24:42 - 01:26:01

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

    01:25:22 - 01:26:43

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

    01:26:01 - 01:27:24

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

    01:26:43 - 01:28:04

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

    01:27:34 - 01:28:48

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

    01:28:10 - 01:29:15

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

    01:28:47 - 01:30:11

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

    01:29:35 - 01:30:47

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

    01:30:13 - 01:31:35

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

    01:30:54 - 01:32:15

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

    01:31:34 - 01:32:47

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

    01:32:12 - 01:33:41

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

    01:32:58 - 01:34:10

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

    01:33:33 - 01:35:08

  • знать Чарльз прокси потому что позволяет моделировать различные ситуации обмена данными допустим между мобилкой бэкендом записывать функции слифера тоже есть для мобилки это нужно знать Ну приложение которое позволяет выполнять подключаться к командному интерфейсу Android и выполнять там команды Разумеется нужно знать о том что существует с Fly для iOS то есть там где публикуются приложения для тестирования чаще всего это используется и наверное все ну и соответственно нужно знать эмулятор который в стандартном пакете

    01:34:23 - 01:35:51

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

    01:35:07 - 01:36:50

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

    01:36:03 - 01:36:40

Менторы

Специалисты своей области, которые смогут помочь вам

  • Нигма Нурия
    Нигма Нурия

    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

© 2024 HireGuru. Сделано в Санкт-Петербурге с hireguru.ru