[музыка] Всем привет перед вами очередной ролик собеседованием на Junior qa особенностью этого ролика является то что Он записался не в очень хорошем качестве я не виноват виновата программа Zoom которая в таком качестве записывает на свои облака при том что в своем описании она обещает Что делает так не будет но тем не менее я записал данные собеседование и еще одно в таком качестве тем не менее я считаю что от этого информация которая содержится в этом собеседовании не менее полезно более того Вы привыкаете к реальным
00:00:00 - 00:01:34
собеседованиям в компании и к реальным созвонам Если вы пройдете собеседование куда-то устроитесь так как зачастую члены вашей команды могут находиться в местах с очень плохим интернетом имея Плохой микрофон и так далее и тому подобное и созвоны будут происходить именно в таком или подобном качестве Так что тренируйте свои уши глаза и смотрите собеседование так и так Сергей начнем тогда общение по поводу тестирования и в принципе мы можем начать с вопроса Что такое тестирование Какое понятие Ты знаешь
00:00:53 - 00:02:26
проверки наш продукт и ожиданием заказчика или клиента а как конкретно мы эту проверку осуществляем что мы Для этого делаем но мы используем различные методологии тестирования не совсем понял вопрос Ну вот ты говоришь мы осуществляем проверку на соответствие до тому как должно быть и как на самом деле есть вот ну проверку Понятно Мы осуществляем Но обычно мы Для этого какие-то критерии бывают выбираем есть у нас понятие там критерии качества например а ну да зависимости от того какая документация например на проекте есть
00:01:45 - 00:03:25
зависимости от того насколько подробно требования там есть у нас User Story мы уже отталкиваясь от этого проверяем приемную критерии у нас требования конкретным функционалу хорошо Сейчас это с понятием вообще что такое качество программного обеспечения а ну качество это то насколько вообще у нас продукт как бы удовлетворяет как бы удовлетворяет совокупность требований ожиданий своего то насколько ну примерно так да примерно примерно правильно Примерно вот чтобы лучше формулировать я тебе рекомендую просто заучить определение
00:02:51 - 00:04:40
есть определений бывает много определений Что такое тестирование бывает много определений Что такое качество Выбери то который тебе проще самому заполнить и просто выучить чтобы на собеседование его не формулировать как формулирует тебя слова иногда путаются забываешь просто выучить и все И уже когда знаешь тебя собеседование например А вот как ты это себе представляешь тут уже можно раскрыть свою поток сознания там это подумать что-то Выдумать вот ну когда тебе прямо определение выдай выученная
00:04:05 - 00:05:24
не придется потеть хорошо цели тестирования Ты какие-нибудь знаешь может встал день какой-нибудь [музыка] Так сейчас я секунду подумаю вспомните ничего конкретного не могу как бы попробовать предположить не надо Сергей предполагать если не помнишь если вот прямо сейчас читал тогда Следующий вопрос Лучше А это мы просто оставим себе на то чтобы повторить вот какой-нибудь классификацию тестирования типам тестирования ты можешь привести Ну вообще Основная это функциональная не функциональная изменения
00:04:45 - 00:06:16
Ну вот каким примеры видов функционального тестирования Ну примеры это в общем одна из классификаций функционального тестирования это blackbox Lightbox и greybox некоторые еще выделяют Также можно методологиям разделить например там заграничных значений [музыка] Ну и в общем так много то все взял Давай по очереди по кусочку попробуем вместе снимать там очень много видов тестирования много классификации но надо с ними Аккуратнее чтобы они не путались друг с другом вот у нас есть функциональный не функциональные до
00:05:53 - 00:07:20
функциональные такие как правило это так оно и называется функциональное тестирование которое Для чего нужно чтобы проверить выполняет продукт хорошо какие ты еще можешь виды функционально тестирования так зависимости от функционала приложения это может быть что угодно Хорошо давай тогда не функциональные виды какие-нибудь то что не связано да с этим тестирование это то есть только приложение работает то есть этот может быть нагрузочное тестирование тестирование безопасности вот Какой еще [музыка]
00:06:48 - 00:08:37
Так ну Хорошо давай поговорим про нагрузочное что это по твоему о чем это проверяем приложение будет Ну какой-то определенный объем там пользователей или каких-то процессов до которые производятся То есть может ли она удерживать нужное нам количество в течение какого-то времени Зато а что конкретно проверяется Да ты правильно В общем сказал что мы проверяем как приложение работает на нагрузку а что конкретно Какая часть приложения нагружается Куда идет нагрузка в итоге если допустим приложение не выдерживает до нагрузки и
00:08:05 - 00:09:45
начинает там плохо реагировать неправильно Что значит какая часть приложения значит не справляется Да все правильно да то есть мы нагружаем сервер проверяем как работает у нас эффективно beknd если приложение не выдерживает заданные нагрузки которые предполагается что должно выдерживать чтобы кента нужно чинить переписывать или менять схему хорошо вот допустим еще у нас бывает тестирование локализации Как ты думаешь про что это Ну тестирование локализации мы проверяем условно говоря правильно ли мы
00:09:10 - 00:10:40
подготовили приложение для какого-то конкретного рынка локального местного то есть допустим Мне нравится такой пример как когда-то coca-cola сделала короче рекламную кампанию в арабских странах и они такой коллаж слева направо но из-за того что в общем рекламная компания проводит в обратную сторону работала нам нужно чтобы такого мы избежали Нет ну пример с Колой хороший но это промышленность нас пройти Да вот ты можешь пример привязали указать пример Что может быть не так на веб-сайте допустим из-за того что
00:09:59 - 00:11:42
локализация неправильно не полностью или неправильно сделано Ну возможно допустим из-за того что другой язык или неправильно отображается кнопки что-нибудь такое так правильно еще что-нибудь может быть [музыка] какой-нибудь например читать эти этнические возможно цвета Ну или что-нибудь культур в культуре например воспринимается не так как допустим Но это прям очень это глубоко оценка тестирования мало Где применяется конечно как лучше сделать дизайнеры А вот Кроме того что может поехать верстка у нас еще
00:10:54 - 00:12:37
бывает что форматы некоторые в некоторых местах разные в разных странах например формат даты в России у нас день месяц года какие-то странах может быть другой знаешь какой да вместе за один год А еще помимо да бывает что формат Чего температура да то есть Фаренгейт А еще вот то что часто встречаются проблема это допустим у тебя магазин обуви да Или интернет садится обувь А есть формат размера ноги и он вообще там сколько там этих вариантов 5 по моему классификация Как мерить а еще у нас чего бывает
00:11:56 - 00:13:31
длина то есть измерение длины веса и так далее И еще у нас бывает такое что в некоторых местах пересчитать цена товара на какую-то локальную валюту когда ты переключаешь локализацию соответствии с курсом Вот видишь как много то есть надо помнить что локализация не только текст этом культурный взаимодействие вот такие вот вещи Хорошо про юзабилити тестирование Я слышал когда-нибудь а ну да то есть насколько условно говоря удобно пользоваться приложением то насколько она интуитивно понятно То есть
00:12:46 - 00:14:19
юзер чтобы он был комфортным Ладно хорошо Давай поговорим про ящики ты уже упоминал что существует белый черный серп Да ящики можешь сказать в чем их отличие о чем это вообще у меня на секунду пропало различие белого ящиков Ну понятие о чем они почему они существуют Да расскажи ну их различие уровни доступа тестировщика говорят внутренности приложения коду в частности blackbox это когда мы Тестируем как со стороны пользователя не имеет к коду ко всему что нам может быть это тоже по-разному классифицирует
00:13:36 - 00:15:29
а помимо доступа к коду да то что есть доступ или нет Как ты думаешь чем-то еще ящики отличаются Ну тебе Ты ручным тестировать подальше проект тебе дают ссылку говорят вот доступ коду короче и после этого что то тестирование становится тестированием белого ящика тут же Дайте ссылку от репозиторий тут кот лежит бах у тебя появляется доступ коду Ну значит тебе белый ящик Ну условно говоря только у нас построен план [музыка] планируем ли мы проводить какие-то проверки на тестировать будем отправлять
00:14:51 - 00:16:05
вот или мы просто мы будем допустим Какое тестирование пока у нас может быть не быть доступа к коду мы можем и 5 тестировать через ну мы отправляем запрос которому пишем руками это не кот и получаем ответ от условно говоря не только доступ коду А наверно вообще как работает Ну на самом деле тут дело во-первых познание внутреннего строения системы насколько мы не просто имеем доступ коду да можем понимать во-вторых самое главное это тоже что покрываем тестами в черном ящике мы покрываем тестами бизнес-логику
00:15:46 - 00:17:18
приложение мы проверяем Может ли приложение выполнять Возможно на него бизнес функцию А в Белом ящике тестами покрывается код код вне зависимости от бизнес функции то есть белый ящик это на самом деле Юнит тесты которые пишут разработчики то есть тесты которые проверяют строчки кода они не проверяют допустим добавить товар в корзину и сможет ли пользователь купить себе носки через интернет-магазине он проверит что модуль кода работает и вот Поэтому в тестирование белый ящика тестами покрывается код а при
00:16:34 - 00:17:55
тестировании черным ящиком тестам покрываются требования которые написаны изначально вот в чем разница это неважно есть доступ входа или нет главное что ты тестируешь в итоге а серый ящик это очень страшное понятие которое во всех учебниках и статьях прописано по-разному Вот и некоторые могут указать на то то можно считать серым ящиком это вот ты проверяешь Ну не бизнес требования все-таки проверяешь чтобы кэнд правильно работает и запрос и ответ правильно присылает с другой стороны ты как бы не
00:17:15 - 00:18:33
совсем покрываешь тестами строчки кода потому что все таки Back and работает полноценно когда ты его тестируешь просто у тебя frontendo нет И вот такая вот дуализм на ситуации он как бы позволяет сделать вывод иногда о том что API Это что-то вроде серый ящик Но не все с этим могут согласиться это такая дискуссионная очень тема Хорошо давай поговорим про Цените смог регрессия Знаешь ли ты вот эти три понятия и как они друг другом соотносятся Да ну ягрессии организационно тестирование это связано с применениями то есть после
00:17:54 - 00:19:20
каких-то внесенных разработчиками мы должны убедиться в том что не произошло регрессии Да потому что функционал который напрямую что он продолжает работать что короче разработчики ничего не сломали из того что уже Работала а смог конкретно пишет что это одно и то же Вот но на это тоже У всех разные взгляды смог конкретно тестирование это тестирование основного функционала которая проводим в первую очередь для того чтобы понять есть ли нам смысл дальше тестировать приложение или у нас какое-то банальный
00:18:39 - 00:20:22
функционал не работает и на мне да да Оцените что нам нужно просто немного Да я картинка подтормаживает ну реально собеседование Когда ты пойдешь Я рекомендую с этим как-то Ну на самом деле мне кажется не сильно поможет нашем случае Но если хочешь можешь выключить Да соответственно лучше усилить как-то свой интернет и улучшить свой звук чтобы потом реально собеседованиях просто лучше впечатление от тебя создавалось по поводу [музыка] да да по поводу Цените что ты можешь сказать Ну если определения то из того что я читал это
00:19:34 - 00:21:21
а ты что же базовая проверка основного как бы основным функционала Но более специализирована в каком-то одном одной сфере приложения условно говоря то есть допустим приложение мы конкретно там проверяем какой-нибудь один модуль Правильно ли он работает вот это как я понял это правильно все понял я поддерживаю такую точку зрения то есть да все верно смог нужен для того чтобы быстро проверить что Приложение работает в принципе Цените чтобы проверить какой-то конкретный функциональность как правило это либо новая фича которую
00:20:56 - 00:22:17
только что написали требует внимания либо какая-то отдельная фича по каким-то признакам и определяем А regression мы проверяем Что сломалось все остальное все верно все правильно Прости кубе вообще опасный источник там много интересных вещей написано сожалению сертификация кубик сделал человек который никогда не работал тестировщиком при разработке программного обеспечения не сделал профессор университета и поэтому она обладает определенной такой вот долей странных иногда выводов и иногда сложных размышлений например там
00:21:37 - 00:22:53
выделяется отдельно р бак и дефект и Значит есть Три разных понятия не знаю как там это в общем когда ты начинаешь только путь тестирование оно может больше даже вредить чем помочь потому что какие-то такие философские выкладки иногда дает что ты просто не понимаешь что ты читаешь сложно Сложно Вот поэтому я даже новичкам не советовал по поводу того как ты ответил по этим трем понятиям все верно А как ты думаешь Вот когда мы работаем в проекте Какие вот из этих трех видов до смог сэнтеригрейшн За
00:22:15 - 00:23:27
каким следует как правило какая у них приоритет Ну так сейчас секунду подумаю подумаю Ну допустим после какого-то Я наверное сказал что сначала проверяем все приложения в целом работает хотя бы потом уже в зависимости от наших приоритетов Наверное мы делаем сами какую-то одну или несколько каких-то функций и потом мы проверяем регрессию какой-то уже [музыка] хорошо А почему мы не можем допустим начать с регрессии Я закончил с молоком ко нам разница а ну а какой смысл нам Если мы проверим весь готовый
00:22:51 - 00:24:40
функционал до что он правильно работает потратил на это время а в итоге окажется что новых функционал вообще не выпускает Совершенно верно молодец правильно все Все ты правильно сказал что мы выделяем приоритет потому что иначе может оказаться что не имеет смысла так супер Давай поговорим про статический динамическое тестирование Знаешь ли ты разницу да [музыка] статическое тестирование это тестирование условно говоря мы проверяем код не запуская его Это пример статического тестирования а динамическое тестирование соответственно
00:24:04 - 00:25:43
запуском кода запуском приложения а ну еще наверное статическому тестированию мы можем тестирование документации то есть проверку требования наверное да все верно все правильно Окей и Давай поговорим про соотношение ручного автоматизированного тестирования в принципе Что такое автоматизированное тестирование чем-то ручном отличается И как ты думаешь когда нам есть смысл использовать автоматизированное тестирование когда нет [музыка] соответственно нам автоматизированное тестирование проводит по пирамиде
00:24:57 - 00:26:12
наибольшее покрытие автоматизированного тестированием мы делаем Юнит тестах это их пишет разработчики сами на свой на свой код после этого идут какие-то есть смысл автоматизировать то что у нас чаще всего повторяется то что занимает очень много времени монотонная работа например учитывая чтобы время затраченное на автоматизацию не получилось больше чем мы тратим на собственноручное тестирование вот поэтому тестирует часто автоматизирует муфты Вот и и в последнюю очередь автоматизируется интерфейс тестирование интерфейса
00:25:48 - 00:27:34
Окей хорошо Так а что же такое автоматизация как она выражается технически условно говоря пишется какой-то инструмент автоматизации тестирования для того чтобы условно говоря программа производила какие-то действия какие-то шаги для проверки нужно Ну то есть это программа которую вы проверяет другую программу мы пишем программу которая либо виде кода либо может виде каких-то блоков готовых мы используем логических Вот и соответственно нашу программа автоматически при своей работе проверять другую программу
00:26:50 - 00:28:17
хорошо супер Давай поговорим про уровни тестирования [музыка] у нас там бывает либо три либо четыре уровня в зависимости от того Какую книжку прочитали знаешь какие-нибудь уровни про один из них Мы уже поговорили несколько раз это unit-тестирование или по-другому она еще называется модульным тестированием Какие еще там бывают уровни Если я правильно понял вопрос потом идет после проверяем взаимодействует между собой Как как целая система Ну и потом [музыка] не такого уровня нет У нас есть значит
00:27:47 - 00:29:23
модульное тестирование потом идет это как-то сильно конкретного модуля потом эти интеграционный это тестирование взаимосвязи модулей а потом у нас идет системная Да System testing это когда система работает в целом а еще бывает выделяют и не выделяют 4 вид сюда Еще сюда часто приёмочная тестирование пихают это спорный вопрос иногда его пихают иногда нет Мне кажется ему здесь делать нечего поэтому приемшем тестировании Но кому-то кажется что есть вот про приёмочная тестирование знаешь что-нибудь что это такое
00:28:50 - 00:30:07
Ну это со стороны заказчика условно говоря проверяется окончательно после завершения протест тестирования то есть после выполнения там плана даты стратегии тестирования проверяется ли соответствует ли итоговый результат поставленного требованиям задачам и ожиданиям хорошо хорошо Так давай поговорим про техники дизайна Знаешь ли ты какие-нибудь техники ну это про методологии Да правильно я понял то есть анализ граничит методологии Нет методологии есть иногда это называют методология тестирования Вот Но лучше называть
00:29:33 - 00:31:23
техники это дизайн потому что еще есть методология разработки которая про другое оно там и так далее Поэтому вот слово методология но тут немножко сбивает часто с толку Ну да вот какие-нибудь метод граничного значений мы используем для того чтобы ну вообще как все техники дизайна мы используем для того чтобы рационализировать Да тестовое покрытие и при этом не слишком много времени сил на это затратить конкретно метод [музыка] какой-то набор значений чтобы не проверять все значения Мы берем только те которые
00:30:37 - 00:32:01
находятся на границах и рядом потому что именно там наиболее ошибки Вот то есть условно говоря если там какая-то форма у нас требует чтобы пользователь был старше 18 лет то мы проверяем мы проверяем значение 18 лет который находится на границе и 17 значение там на один ниже на один выше вот Ну давай возьмем конкретный интервал и проверим Ну или проще еще так сделаем Как ты думаешь сколько у нас будет проверок при тестировании любого интервала допустим число Так ну чтобы интервал то есть мы берем
00:31:26 - 00:33:25
Так ну 18 до 40 до 8 просто чтобы например да то есть мы берем [музыка] на 1 17 18 Да хорошо Ну то есть в итоге получается 5 Да вот ну верно отлично супер А еще какой-нибудь технику знаешь Ну эквивалентное значение как это анализы не помню валентное разделение называется Вот его используют часто вместе с мяч какие-то условно говоря классы значение да то мы должны использовать по одному значению каждого класса То есть если мы будем там 10 значений внутри каждого класса использовать это покрытие не
00:32:29 - 00:34:20
увеличивается но заточивается опять же если мы накладываем на наш предыдущую значение [музыка] меньше 18 до 40 и больше 40 ну интересно подход к а если допустим еще проще мы попробуем эквивалентное разделение сюда привнести не мешаю вас с границами с какими-то Вот как ты думаешь на плод я тебя пример приведу У нас есть поле ввода вот поле ввода у нас есть требования что должны вписываться какие-то символы допустим символы английского алфавита буквы поле вода Ника для регистрации пользователя может
00:33:44 - 00:35:29
состоять только из букв Каким образом мы здесь можем применить эквивалентное разделение Ну должны позитивные поле должно принимать английские буквы не должно принимать символы Так а как здесь работает эквивалентное разделение помимо негативности один класс Это у нас английские буквы второй класс а ну допустимый класс это только английские буквы имя все остальные это недопустимо можно такая на это посмотреть А как ты думаешь нам нужно проверять все английские буквы нет но суть этих классов что если
00:34:42 - 00:36:18
вообще принимает английский все они будут принимать Ну вот да то есть в принципе ответ в том что нам не надо проверять весь алфавит достаточно проверить как минимальное значение количество этих букв и мы считаем что все буквы как вводное значение они друг другу эквивалентны то есть равны и соответственно мы подразумеваем что нам нет смысла проверять все буквы потому что они должны обрабатываться системой а одинаково Мы конечно можем проверить все на всякий случай Мы можем сэкономить время и все Не проверять Вот вот
00:35:47 - 00:37:01
Собственно как мы можем на как мы на самом деле чаще всего используем классы эквивалентности чтобы сэкономить наше время Ладно хорошо Давай поговорим про тестовую документацию Какие ты знаешь виды документации которые составляют тестировщик в процессе своей работы [музыка] первый уровень до теста документации это чек-листы и багре порты которые именно ручной тестировщик чаще всего выставляет [музыка] еще тест-план бывает да да но это уже более такой высокоуровневое [музыка] требованиями тоже работают
00:36:24 - 00:37:59
Вот еще оценка времени тестирование тоже Вот наверное стоит Можно же отнести документацию Ну давай говорим про тест-план допустим из чего он состоит что это такое план Это документ в котором мы описываем ресурсы которые у нас есть для тестирования инструменты которые мы планируем использовать и почему методы тестирования Что именно И как мы будем тестировать вот ну и возможно если большая команда мы там же можем распределить допустим работать да кто там будет каким конкретно заниматься Так что будем тестировать как будем
00:37:22 - 00:39:16
тестировать что нам еще важно какими там бывают критерии да да критерия то есть когда мы будем знать что мы можем закончить тестирование уровень метрики можно включить то есть [музыка] на основе чего мы будем делать вывод о качестве продукта допустим то есть какое-то отношение там выявлены и багов такое соотношение Всё верно А вот еще у нас допустим ты тестируешь приложение нативное что тебе нужно определить для того чтобы доступно и нативные приложения тестировать желательно окружение системы все правильно да то есть нужно выявить
00:38:42 - 00:40:24
требование лаборатории Хорошо давай поговорим про чек-лист и тест кейс Да что это за поменять о чем они зачем они Ну это артефакты так называемый вид документации соответствии с которым мы проводим наш тестирование функцию они выполняют примерно одну и ту же но различия в уровне детализации То есть если у нас просто перечисляет проверки определенные и отметку более подробно описывает шаги конкретной проверки ожидаемой итоговый результат какие-то Ну там окружение допустим и так далее В общем более подробно и в зависимости от
00:39:51 - 00:41:34
наших нужд на проекте в зависимости от ресурсов времени мы уже выбираем то что более оптимально будет более удобно а как ты выберешь в зависимости от нужд и от ситуации про это что он отклонение повлияет Да чтобы выбрать чек-лист или тест влияет допустим если я один тестирую какой-то небольшое приложение у меня будет проще я буду знать что у меня там каждая проверка если допустим это будет долгосрочный проект который планирует там походу нанимать возможно Потому что таким образом новые тестировщики
00:40:59 - 00:42:24
более подробно еще будут понимать что они делают [музыка] нужно покрытие тестированием допустим если горят сроки какие-то и у нас не хватает времени на полное покрытие то нам нужно как минимум покрыть приоритетной до функционал который обязательно должен работать поэтому лучше сэкономим время напишем чек-лист но при этом хорошо а если мы выбираем тест кейсы то В таких случаях они будут полезны если чек-лист такой крутой Зачем таскейс [музыка] так Ну если мы также можем использовать если у нас какой-то сложный функционал
00:41:51 - 00:43:32
неочевидный допустим да И нам нужны подробно расписать как мы будем тестировать опять же если это длительный проект до который будут добавляться новые функции в ходе проекта чтобы старый функционал был документированно говоря чтобы ему можно было потом Ну правильно в принципе все про То есть если мы проверяем какие-то сложные проверки которые просто велик листа Не укажешь потому что их потом не повторишь там где надо сложно там подготовить тестовое окружение и так далее потом соответственно После этого мы можем
00:43:00 - 00:44:23
применять чек-листы там где у нас планируется вообще большая команда большой штат где будут новички тестирование надо будет объяснять Как тестировать и чтобы не объяснять мы заранее напишем тыс кейсов подробно чтобы они просто начитали и проходили вместо того чтобы бегать и спрашивать всех им было понять вот когда у нас есть принципе перспективы того что проект будет развиваться даже если сейчас там ты один да Ну ты знаешь что у вас там проект на год вперед на два И что все хорошо вот это и время есть на это
00:43:58 - 00:45:05
понятно дело написание этих сценариев в принципе хорошо хорошо так поговорим тогда про репорт что это такое Что все включает Зачем нужен [музыка] Это отчет о найденной ошибке условно говоря мы фиксируем какое-то несоответствие [музыка] нашего софта требования и фиксируем его для того чтобы разработчики могли его исправить выделяют несколько обязательных полей чтобы там он учитывался в какой-то рейтинговой системе она используется краткое описание в котором должно быть Понятно вообще в чем проблема
00:44:31 - 00:46:07
Что когда где да то есть что произошло в такой ситуации и в какой части нашего приложения после этого мы указываем какой может быть дополнительное питание какое-то [музыка] шаги воспроизведения этого Бага возможно какое-то предусловие перед шагами то есть что мы сделали перед этим непосредственно вот [музыка] ожидаемый результат который мы должны были получить и реальный результат который мы получили вот также могут быть какие-то там возможность прикрепить допустим скриншот да Или какой-то Лог логика Вот
00:45:34 - 00:47:29
[музыка] Ну там кроме логов просто есть такой раздел от touchments то есть могут быть логи могут быть скорее могут быть видеозаписи чё чё угодно Может быть там не только логин Ну в принципе хорошо Да нормально по поводу жизненного цикла репорта Давай поговорим Вот ты завел багри по что с ним дальше происходит команда Ну как это сферическая команда в вакууме условно говоря PM видит что я завел баг он ставит приоритет ему и назначает кому-то из разработчиков после чего разработчик Ну либо говорит что это не бака фича и в
00:46:41 - 00:48:30
общем закрывается либо если это действительно то он исправляет его ставит отметку что он исправил после этого бак уходит на ретест я перепроверяю действительно ли бак больше не воспроизводится если не воспроизводится он закрывается производится то он опять отправляется хорошо в принципе Понятно теперь поговорим давай про частные случаи вот допустим [музыка] Ты завел разработчиков признал исправил ты его перепроверяешь и вот как ты сейчас только что сказал баг воспроизводится перепроверьте киты его Направляешь опять разработчику
00:47:47 - 00:49:25
разработчик говорит тебе меня он больше не воспроизводится я его починил и отправляет бак опять тебе что ты будешь делать Ну проверить на каком-то другом устройстве например [музыка] например проверил производится вообще на всех устройствах ну скинуть разработчику более подробную информацию там по логах как какие-то ошибки возможно скинуть разработчику информацию о об окружении Какое окружение ты используешь там браузер система если работает то можно [музыка] Ну попросить разработчиков подойти показать им на своем просто компьютере
00:48:42 - 00:50:31
хорошо то есть ты проверил версию окружения проверил проверил этом девайс если это нативное проверил разные браузеры на разных версиях если [музыка] помимо окружения что еще может быть не так окружение именно на котором ты тестируешь и возможно вы беда но это тоже к окружению относится вот бывает еще то сама версия кода правильная то есть допустим ты видишь ошибку А то что она осталась а потом оказывается что разработчик залил свои изменения в версию где ну который еще не вышла для тестировщика в релиз и ты
00:49:42 - 00:51:10
просто ну проверяешь там где нет то еще этого фикса Вот хорошо Вот вы правее или код правильный и окружение все одинаково Ну по максимуму одинаково может не идеально одно и тоже компьютер Вас могут быть разные все дела А он тебе все равно горит у меня не воспроизводится Что ты будешь делать так возможно другого разработчика попросить проверить именно этот Чине другого Нельзя просить другие заняты своими делами Ну попробовать на его то есть опять же пробовать моего компьютера самому тебя нет он тебя не даст свой компьютер Он
00:50:33 - 00:51:46
говорит тебя не трогай мой компьютер Ну тогда тогда нам следует менеджера обратиться У нас есть менеджер проекта который отвечает за проект целом и ты до него информацию Ну там негативных красках что там еще А как есть говоришь вот у нас как мне кажется есть бак у меня есть такое-то приоритет Мне кажется это очень важно и страшно разработчика его не видит давайте-ка мы разберемся и все И ты просто кидаешь ссылку на багре порта менеджеру менеджер разбирается если ему кажется менеджеру как правило чтобы
00:51:21 - 00:52:27
агрепорт не такой уж и приоритетный он тебя может написать суши Забей Забей закрой или там Отложи ты конечно же как профессиональные тестировщик напишешь об этом в комментариях к этому потом никто не вспоминал точнее тебе не пришлось вспоминать Почему ты его закрыл и так далее и отложили все он тебе скажу Ну вот Вася он программист очень важный для нас сейчас не может отвлекаться на вот такую мелочь вот а может оказаться Так что Баку действительно важный критичный и нехороший и менеджер попадет к
00:52:01 - 00:53:10
разработчику и скажет Вася давай чини что хочешь делай это надо починить и Вася может быть нехотя может быть еще что-то он начнет чинить и окажется что воспроизводится ли он найдет причину почему у него значит не воспроизводится и все починится вот тут уже конечное слово за менеджером проекта хорошо представим себе тогда такой ситуации что ты завел попадает к разработчику и бочку сразу идет лотка с до говорит допустим что это не баг ноты бак стоит статус что дальше с багрепортом происходит Ну по идее он
00:52:36 - 00:54:03
если по идее он закрывается но он не закрывается он не закрывается он также как и при других действиях всегда идет на перепроверку тестировщику который завел его просто статус будет не фикс А типа не баг Ну и как правило разработчик он может написать типа мне кажется Ну какой-нибудь коммент чтобы информация больше было может не написать что ты в этом случае делаешь должна работать так работает не так поэтому Если подробно документации можно остаться на здравый смысл грубо говоря да то как В подобных приложениях это уже
00:53:20 - 00:54:50
реализовано в каких-то популярных известных общепринятая норма вот если это не работает то опять хорошо хорошо верно А предстам еще какую-нибудь ситуацию вот завели Ты завел бак он падает разработчику разработчика 5 не хочешь чинить Но в этот раз он ставит статус не ноты бак допустим А дубликат Что это значит что будет дальше Ну это значит что такой бак уже был зафиксирован да По идее дубликат то возможно он поставит ссылку на уже существующий чтобы можно было удостовериться в этом так поставил ссылку баг Report вернулся
00:54:17 - 00:55:58
к тебе чего ты делаешь Ну я смотрю который дублирует [музыка] Ну вот представим сюда что тот бак оригинальный до который был первым как бы его смотришь а он закрыт Он давно закрыт Что ты будешь делать со своим Ну если тот закрыт Я сейчас выйду вот значит ну его закрыли не пофиксил либо он опять так и в этом случае вот со своим багом который дублик а что ты будешь делать тут я не уверен Как вариант переоткрыть старый баг рекорд либо Ну тут я не уверен правильно все правильно ты все правильно говоришь что
00:55:19 - 00:57:01
и действительно можно быть не уверенным потому что в разных проектах по-разному где ты можешь действительно переоткрыть старый баг Report а новый просто туда его при линковать Ну чтобы информация сохранялась вот в некоторых же проектах просто Физически невозможно переоткрывать старые закрытые таски Ну в силу организационных причин и тогда ты своего Бога ставишь нормальный статус вот а в описании в комментариях ты просто указываешь что типа это уже повторяющийся бак но это не просто какой-то дубликат А это вполне себе
00:56:39 - 00:57:49
активный новый баг потому что старый вроде уже был пофигшен Так что вот вам информация про старый А ну пожалуйста почините Вот а если старый бак еще открыт и действует и может даже фикса или нет то твой является полноценным дубликатом который закрывается как правило как дубликат Ну опять же тоже принятовывается к оригинальному бог-репорту для того чтобы была информация о том что его лишний раз наткнулись вот так так хорошо Хорошо В принципе Окей давай поговорим про документацию хорошо поговорили про
00:57:15 - 00:58:34
принципы работы да и особенность тестирования разных видов приложений вот у нас в принципе выделяется три большие группы приложений которые тебе скорее тестировать это вы приложение мобильные приложения которые чаще называются нативными вот доступные приложения вместе с нативными как бы в одной упряжке идут и гибридные а соответственно вот по очереди Давай поговорим про них в чем как они работают да И как особенности тестирования этих приложений вот начнем например с вэб приложений Может ли это рассказать как работает вот
00:57:53 - 00:59:38
веб-технология что там куда передается и так далее работает на архитектуре то есть нашего там происходит [музыка] вычисления и нам уже обратно хорошо а Запрос который идет на сервер он что из себя содержит Ты знаешь Ну метод запроса адрес URL в зависимости от методам тело запросы всякие авторизации Отлично Да хорошо а ответ что содержит Ну тело так тело чего еще Да статус код сказал да то есть там тело есть еще хейдер Бади и статус код Какие статус когда ты знаешь Ну кто ты но они как бы по группам Да по
00:58:45 - 01:00:49
первому числу 100 это информационно можешь просто парочку объяснить просто парочку Назови да и все 404 самый известный 400 группа это проблема на клиента конкретно [музыка] [музыка] 500 500 это ошибка на стороне сервера например 503 это но она Вторая авторизована авторизацию не причем просто 500 ошибка на стороне сервера и соответственно либо сервер не работает либо работает некорректно вот этого достаточно опасно на самом деле уходить потому что тебя может собеседовать какой бывший садмин и если ты там начнешь рассказывать Ой
01:00:38 - 01:02:25
нафиг за душу не надо вот и 200 когда все хорошо страница пришла полноценно все отлично и все вот это как правило всем достаточно вот OK Какие особенности тестирование мы можем выделить Да вот он у тебя допустим Ты тестируешь веб-приложение что ты будешь проверять и чаще всего особенно что связано с вебом Какие виды тестирования будем применять Ну опять тестирование ну вспомним Мы про виды тестирование говорили в начале собеседования что есть разные виды тестирования Вот какие виды мы можем Ну или допустим желательно Да
01:01:41 - 01:03:10
именно в приложениях проверить на разных браузерах условно кроссбраузерное тестирование на разных устройствах то есть на разных то как у нас будет разве это устройство зависит разве это устройство разве это устройство зависит как его приложение работает разве как минимум визуально А может быть это от браузера зависит от приложения от устройства какая разница Как выглядит сайт в браузере Chrome на мойке или на Windows допустим ты можешь разница назвать нет про мобилки наверное то есть то как у нас не мы говорим про веб Мы про
01:02:49 - 01:04:12
мобилки В чем разница будет Ну там как это адаптивное или пончик вот этого так она адаптивно верстка на будет на любом она либо есть либо нет и вне зависимости от телефона она Я же это браузера и от Ну короче вы приложение от устройства может зависеть только от его размера экрана это опять же это проверяется то чтобы то что сказали существует ли в принципе адаптивная верстка на приложение или нет Ну ты как тестировщик который работает команде разработки Ты знаешь так есть она или нет А так в принципе зависит от браузера
01:03:43 - 01:05:14
Можно даже для себя выделить прямо по пунктам особенности работы и что из этого следует для тестирования от интернета зависит Значит нужно тестирование связанное с работоспособностью интернета там тестирование на прерывание можно выполнять Это например на ухудшение интернета второе зависит от браузера зависит Значит нам нужно [музыка] кроссбраузерное тестирование сделать третье зависит от железа ну как правило не зависит Ну то есть если железо тянет браузер то уже оно и все остальные веб- вещи подтянутся значит
01:04:28 - 01:05:50
железо нам неважно установки требуется установка для приложения Нет не требует значит инсталляционное тестирование нам не подходит вот дальше соответственно тестирование безопасности мы можем провести потому что у нас там есть клиент серверное взаимодействие которое может там атакам подвергаться данные как-то теряться и так далее Вот и 5 мы уже назвали Ну вот допустим это все А вот теперь поговорим про нативные приложения или десктопный Да нативный это на телефон доступны на компьютерах установки требует
01:05:10 - 01:06:34
требует Значит нам нужно тестирование инсталляции от работы интернета работа нативного приложения зависит Ну это спорный вопрос функционал в нативных приложениях он как правило работает без интернета интернет Нам нужен в нативных только чтобы контент какой-то свежий погрузить новые фоточки новые посты какие-то новые сообщения но по умолчанию полноценная нативное приложение оно просто будет показывать тебе старую информацию но он будет работать целиком полностью оно работает на стороне устройства и логика
01:05:55 - 01:07:03
срабатывает на стороне устройства ему сервер не нужен сервер нужен только так иногда подтянуть свеженькое вот Или вообще не нужно например есть приложение Фонарик на телефоне которому не нужен веб-сервер Окей в нативных предложениях инсталляционное мы провели кроссплатформенная Мы провели на разных устройствах кроссбраузерная не стали проводить Интернет постольку-поскольку батарейка проверили и горизонтально гленнские [музыка] Ну окей гибридное приложение знаешь что такое как правило у нас когда часть
01:06:37 - 01:08:14
нагрузки у нас происходит а часть [музыка] да да и исходя из той классификации которую мы только что обговорили можешь рассказать да что мы тестировали гибридным приложении Ну соответственно тоже установка требуется [музыка] требуется значит инсталляционная проводим сервер нужен Web для работы приложения да да правильно значит подключение к интернету нам нужно все время проверяем вот с точки зрения как Web и Pi у нас какой-то там есть да да Значит и 5 получается на самом деле что по сути собираются все
01:07:34 - 01:09:31
особенности допустим гибрио нативного и Веба и виды тестирования подтягивается оттуда оттуда но это если мы говорим о гибридном приложении в контексте вот такого гибридного приложения потому что на данный момент существует разные гибридные приложения и если гибридная технология не в виде смеси Вы бы и нативная система а допустим это гибридный фреймвор типа к Самарин там уже может быть другая история Вот но Фишка в том что гибридный фреймворки режет пользуются на данный момент и про них мало кто знает так скажем поэтому
01:08:40 - 01:09:58
спрашивает скорее всего не будут Вот Но эти рекомендую почитать про разные гибридные подходы которые сейчас существуют потому что они сейчас очень популярны а популярно не потому что быстрее дешевле разрабатывать гибридные приложения чем нативное или вот да Окей Ладно давай поговорим про методологию разработки какие-то знаешь методологии [музыка] [музыка] модель вот хорошо расскажет про водопад Ну это самое первое методология разработки она гибкая идет последовательно все свои последовательность сначала нас там вот
01:09:20 - 01:11:05
требований планирование потом разработка тестирование [музыка] в том что мы заранее определяем конкретно все наши требования максимально точно никаких правок не должно быть и мы поэтапно максимально сделали на каждом этапе Идем дальше Ну и в тот же момент плюсы этого же является минусом то есть допустим если нам нужно что-то без готовое Да условно говоря разрабатывать если нам на определенном моменте мы поймем что нам нужно что-то там добавить а что-то немного изменить мы этого просто сможешь сделать но используется это там
01:10:30 - 01:12:04
военных военной отрасли Может в какой-то максимально точно Нужно все заранее планирует [музыка] в принципе ты правильно хорошо назвал тут просто ты делаешь упор горишь максимально точно сделать лучше спланировать это как бы это верно но не совсем самое главное особенность это в том что в процессе разработки то есть в середине потока ватерфола этого очередного тяжело вносить изменения ваш самое главное это особенность фола и вот этих не отжал методологии что ты не можешь изменить продукт Когда уже
01:11:21 - 01:12:46
допущен запущен очередной цикл разработки и это бывает хорошо стоит точки зрения не что И в середине процесса разработки бывает что новые баги программиста допускают Ну потому что они вроде как одно пилили потом их попросили чуть-чуть это переключиться Но с другой стороны если не просят вносить изменения в середине очередного процесса разработки то разработчику Может лучше внимательнее и качественнее сделать То что от него просят просто другое проблема что то что просит уже может быть не актуально именно поэтому
01:12:12 - 01:13:42
Новый багов будет меньше Именно поэтому в аэрокосмической отрасли В самолетах и так далее применяют waterfall Потому что если будут баги самолет может упасть или ракета может упасть а конкуренция на рынке между самолетами ракетами она не такая быстрая как на рынке Допустим веб-сайтов или каких-то еще технологии поэтому по компаниям которые по разрабатывают в этих сферах они не так торопятся у них нету коротких быстрых циклов разработки но при этом Они каждый свой цикл выполняют очень тщательно вот а отжал он хорош там где
01:12:59 - 01:14:25
соответственно у нас не требуется такое прям сильно щепетильности в работе Где баги не является реально проблема жизни смерти людей допустим и там важна скорость разработки И самое главное изменчивость изменчивость чтобы можно было где-то подкрутить подделать переделать переосмыслить прямо на ходу сходу решать эти вопросы Вот и соответственно вот в отжали Да как в подходе Есть конкретные методологии нож про какие-нибудь рассказать ну там Канбан самый популярный так Ну вот и расскажи про них идет
01:13:43 - 01:15:07
[музыка] команда Там могут быть четырех недельных винты и в ходе каждой операции мы как бы работаем над каким-то одним [музыка] модулем так скажем Да каждую операцию В идеале должен сделать какой-то работающий продукт не обязательно выпи короче прям просто делается кусочек продукта то есть одна несколько фичей Вот они добавляются к основному продукту в конце спринта и и дальше снова спринт Опять вот а в компании как отличие от крана Вот она мне не очень знакомы но там я знаю что там используется
01:14:29 - 01:16:19
борт доска до проекта и там вот эти вот передвигается таски из столбцов то что нужно [музыка] сделать что делается что сделано с краем тоже есть такая доска это не не сказать что это прям отличие методологии Ну почитай основная основная суть канвана заключается в том что нет спринтов то есть в компании идет оценка работы исходя из каждой конкретной задачи то есть каждая задача планируется когда она появляется примерно рассчитывается нагрузка на команду и так далее То есть в реальном мире конечно в
01:15:34 - 01:17:04
компании есть что-то вроде промежуточных таких вот релизов но они легко отодвигаются оттуда выкидываются задачи закидываются они не такие важные А в скраме же к старту финишу вот этих вот спринтов очень подвязано там очень много основывается вот сейчас чаще Это увидишь скрам через чем Канбан В разработке но бывает всякое хорошо в скраме ты можешь назвать Какие действия у нас в процессе спринта происходит Что происходит в начале спринта Что происходит в процессе Что происходит в конце Ну мы планирование какой-то
01:16:28 - 01:17:54
встречу что мы будем делать примерно обозначает цели распределяются Потом каждый день Ну если они есть то есть команда говорит над чем она сейчас работает Если кто-то другой В общем не блокирует на работу и потом в конце дома то есть мы показываем что у нас В итоге получилось и ретро может быть то есть мы обсуждаем какие-то наши ощущения что нам не понравилось Да да все правильно хорошо а знаешь ли ты что такое блок это как я понимаю в общем наш список задач для всех которые нужно сделать которые
01:17:21 - 01:19:08
приносим то что актуальную повестку то что нужно будет прямо сейчас Ну не совсем все это бэклог это место где у нас лежат задачи Откуда мы берем их на доску на нашу Да и берем в работу не знаю что прямо сейчас на сделать нас сделать может быть конкретным спринте Вот и поэтому у нас бы клубы существует два Да есть бы клок спринта есть блок всего проекта всего проекта падает задачи когда они в принципе придумываются там бизнес-аналитиками заказчиками и так далее а каждый раз когда начинается спринт у нас происходит планирование
01:18:40 - 01:19:45
спринта Мы из бэк-лога проекта перекладываем часть задач бэк Локс принта Ну когда мы определяем вообще список задач которые мы будем делать спринте И затем когда спринт у нас идет Project Manager он Потихоньку Ну ему даже участники команды сами это делать Может менеджер дело они вытягивают задачи на доску себе по очереди и выполняют их когда задача кончаются они еще себе берут и так далее пока спринт не кончится потом в конце спринта Если какие-то задачи в букологи остались и там переносят следующий спринт или
01:19:15 - 01:20:30
убирают вообще в долгий ящик назад Быков проекта потому что допустим в процессе спринта Выяснилось что они не нужны вот так окей Окей в принципе мы с тобой много чего обсудили все что я хотел Давай дам фидбэк определенный по поводу того что мы обсудили во-первых я тебя прошу выучить определение базовые выучить Что такое тестирование Что такое качество Какие бывают цели тестирования Есть огромное количество этих разных целей тестирования Выбери то что тебе больше всего понравится Вот и чтобы четко было четко
01:19:53 - 01:21:22
по методологиям методология по тех с дизайна название техник четко анализ граничных значений эквивалентное разделение или по-английски можешь выучить баундари value analysis или эквивалент патришин все прям а тот В названиях тоже там начал выдумывать сам Вот лучше чтобы четко отлетала по видам тестирования Почитай еще раз классификации про ящики мы поговорили там функционально не функциональные что все чаще всего включают могут быть в разных источниках по-разному но хотя бы какой-то подход Вот это хорошо Это хорошо статическая
01:20:37 - 01:22:17
динамическая хорошо так плотность плану ты в принципе хорошо отвечал но все равно пришлось и навести Немножко там критерии оценки начала тестирования критерий окончания тестирование две группы критериев Повтори вот дальше талант чек-лист Это хорошо Тоже хорошо вот принципе работы гибридных приложений Почитай Вот и вот для себя вот эту структуру Придумай Да вот По каким критериям их разделять там необходимость установки необходимость наличие интернета и так далее И от этого Тебе будет проще отталкиваться когда
01:21:27 - 01:23:05
тебя попросят назвать виды тестирования именно конкретному виду приложений на реальном собеседовании более того тебе могут так сказать Какие сказать У нас есть приложение наша нативная Скажи пожалуйста какие бы ты тесты придумал для нашего вида приложения Да и фишка работает их приложение что сейчас вот рассказать это практически вопрос важный вот Так ну все остальное в принципе нормас про про Канбан чуть Почитай но в принципе эти сказал чем основная суть но так чтобы пошире отвечать Все у меня вопросов больше нет У тебя
01:22:23 - 01:23:42
есть вопрос я вот недавно нашел сделал проект на фрилансе То есть я по знакомству просто меня знакомый искал чтобы протестировал сайт Я в общем сделал и я думаю как это можно записать опыт Если две недели там буквально небольшой как это можно писать Но если в общем отвечает Ну ты можешь написать Не обязательно Призма писать я знакомым по блату за бутерброд ты напишешь я работал в такой-то компании [музыка] ты можешь написать что ты работал такой компании можешь вместо двух недель написать несколько
01:23:07 - 01:24:40
месяцев два месяца Например какая разница Ты в принципе на самом деле что что ты сделал за две недели то ты будешь делать годами годами много месяцев сильно не поменяется Вот и указать что тестировал выполнял какие-то виды тестирования и так далее В принципе можешь кинуть мне резюме я гляну Вот Но лучше меня по моему были видео про то как делать резюме на YouTube Поищи вот если нету скоро появится и соответственно Если что можешь допустим наше влиться мы там постоянно мои ребята все друг другу кидают резюме и пытаются просто
01:24:02 - 01:25:31
посмотреть сможешь несколько вариантов мне получить помимо его допустим Если ты хочешь посмотрим как у тебя там хорошо прописано или нет вот так понял Слушай еще такой вопрос можно на рингтоне добавиться и если мог бы попробовать Да это помогает можно вот LinkedIn я бы не сказал что это прямо хороший способ получать большое количество работ но по крайней мере до недавнего времени Это был способ получать интересные работы то есть в ликвине есть у тебя хорошо написано резюме ты можешь получить очень
01:24:46 - 01:26:04
интересное предложение за рубежа Ну прям Действительно интересно то есть меня и на автомобильный завод предлагали мне допустим тестировать компьютеры и в Японию были варианты про себя собеседовался я в Токио Вот но редко но метко так скажем А так в принципе для поиска работы для такого потного Ну все сервисы хороши везде можно искать но какие-нибудь вещи типа HeadHunter или [музыка] habr карьеры или еще других вещей они в России [музыка] Ну что да Ну смотри как хочешь как знаешь удаленщиков из-за границы тоже
01:25:28 - 01:27:06
Так что еще не отлично не очень много но у Джина обязательно Установи себе Бота Джинни бот телеграммного он будет тебя постоянно снабжать пачками вакансий на которой ты вручную будешь плавиться Вот Обязательно Все спасибо большое очень полезный эксперимент Да Сергей в принципе мне нормально я как человек который давно войтишки двигается постоянно работаю с таким звуком Потому что ты когда пойдешь в реальный проект у тебя будут коллеги которые сидят в бункере у них тоже плохой интернет будет пропадать связь они будут еще при этом
01:26:19 - 01:27:41
говорить на английском с каким-нибудь значит хитрым акцентом потому что они будут не носителями языка и ты будешь как на подводной лодке знаешь эти были чуваки с сонаром вот так сидеть с наушниками и сосредоточено пытаться понять чего они вообще говорят потому что и не слышно и непонятные все дела Вот Но в принципе да когда ты на собеседование идешь тут желательно сделать все возможное чтобы тебе было хорошо слышно не прерывалось ничего ну и желательно чтобы тебе было видно Тут уже сам смотри Вот потому что на
01:27:18 - 01:28:26
собеседовании важно а в реальных проектах там кошмарные иногда качество бывает и ничего не поделаешь с этим вот Приходится работать как есть так что Да вот если что звони пиши Как говорится и если хочешь сообщества и там тоже много чего обсуждаем пассивы еще раз пока давай пока Ну как вам было интересно мне особенно понравилось расслабленная Атмосфера Сергея он подложил подушечку и спокойным голосом вещал и рассказывал о том что он знает такой подход на самом деле очень сильно помогает на реальном собеседовании Когда
01:27:52 - 01:29:18
вы можете держать под контролем ваш уровень тревожности И даже если вы рассказываете что-то не так что-то неправильно не переживать и не впадать панику Так что многим могу порекомендовать такой настрой на сегодня все пока
[музыка] Всем привет перед вами очередной ролик собеседованием на Junior qa особенностью этого ролика является то что Он записался не в очень хорошем качестве я не виноват виновата программа Zoom которая в таком качестве записывает на свои облака при том что в своем описании она обещает Что делает так не будет но тем не менее я записал данные собеседование и еще одно в таком качестве тем не менее я считаю что от этого информация которая содержится в этом собеседовании не менее полезно более того Вы привыкаете к реальным
00:00:00 - 00:01:34
собеседованиям в компании и к реальным созвонам Если вы пройдете собеседование куда-то устроитесь так как зачастую члены вашей команды могут находиться в местах с очень плохим интернетом имея Плохой микрофон и так далее и тому подобное и созвоны будут происходить именно в таком или подобном качестве Так что тренируйте свои уши глаза и смотрите собеседование так и так Сергей начнем тогда общение по поводу тестирования и в принципе мы можем начать с вопроса Что такое тестирование Какое понятие Ты знаешь
00:00:53 - 00:02:26
проверки наш продукт и ожиданием заказчика или клиента а как конкретно мы эту проверку осуществляем что мы Для этого делаем но мы используем различные методологии тестирования не совсем понял вопрос Ну вот ты говоришь мы осуществляем проверку на соответствие до тому как должно быть и как на самом деле есть вот ну проверку Понятно Мы осуществляем Но обычно мы Для этого какие-то критерии бывают выбираем есть у нас понятие там критерии качества например а ну да зависимости от того какая документация например на проекте есть
00:01:45 - 00:03:25
зависимости от того насколько подробно требования там есть у нас User Story мы уже отталкиваясь от этого проверяем приемную критерии у нас требования конкретным функционалу хорошо Сейчас это с понятием вообще что такое качество программного обеспечения а ну качество это то насколько вообще у нас продукт как бы удовлетворяет как бы удовлетворяет совокупность требований ожиданий своего то насколько ну примерно так да примерно примерно правильно Примерно вот чтобы лучше формулировать я тебе рекомендую просто заучить определение
00:02:51 - 00:04:40
есть определений бывает много определений Что такое тестирование бывает много определений Что такое качество Выбери то который тебе проще самому заполнить и просто выучить чтобы на собеседование его не формулировать как формулирует тебя слова иногда путаются забываешь просто выучить и все И уже когда знаешь тебя собеседование например А вот как ты это себе представляешь тут уже можно раскрыть свою поток сознания там это подумать что-то Выдумать вот ну когда тебе прямо определение выдай выученная
00:04:05 - 00:05:24
не придется потеть хорошо цели тестирования Ты какие-нибудь знаешь может встал день какой-нибудь [музыка] Так сейчас я секунду подумаю вспомните ничего конкретного не могу как бы попробовать предположить не надо Сергей предполагать если не помнишь если вот прямо сейчас читал тогда Следующий вопрос Лучше А это мы просто оставим себе на то чтобы повторить вот какой-нибудь классификацию тестирования типам тестирования ты можешь привести Ну вообще Основная это функциональная не функциональная изменения
00:04:45 - 00:06:16
Ну вот каким примеры видов функционального тестирования Ну примеры это в общем одна из классификаций функционального тестирования это blackbox Lightbox и greybox некоторые еще выделяют Также можно методологиям разделить например там заграничных значений [музыка] Ну и в общем так много то все взял Давай по очереди по кусочку попробуем вместе снимать там очень много видов тестирования много классификации но надо с ними Аккуратнее чтобы они не путались друг с другом вот у нас есть функциональный не функциональные до
00:05:53 - 00:07:20
функциональные такие как правило это так оно и называется функциональное тестирование которое Для чего нужно чтобы проверить выполняет продукт хорошо какие ты еще можешь виды функционально тестирования так зависимости от функционала приложения это может быть что угодно Хорошо давай тогда не функциональные виды какие-нибудь то что не связано да с этим тестирование это то есть только приложение работает то есть этот может быть нагрузочное тестирование тестирование безопасности вот Какой еще [музыка]
00:06:48 - 00:08:37
Так ну Хорошо давай поговорим про нагрузочное что это по твоему о чем это проверяем приложение будет Ну какой-то определенный объем там пользователей или каких-то процессов до которые производятся То есть может ли она удерживать нужное нам количество в течение какого-то времени Зато а что конкретно проверяется Да ты правильно В общем сказал что мы проверяем как приложение работает на нагрузку а что конкретно Какая часть приложения нагружается Куда идет нагрузка в итоге если допустим приложение не выдерживает до нагрузки и
00:08:05 - 00:09:45
начинает там плохо реагировать неправильно Что значит какая часть приложения значит не справляется Да все правильно да то есть мы нагружаем сервер проверяем как работает у нас эффективно beknd если приложение не выдерживает заданные нагрузки которые предполагается что должно выдерживать чтобы кента нужно чинить переписывать или менять схему хорошо вот допустим еще у нас бывает тестирование локализации Как ты думаешь про что это Ну тестирование локализации мы проверяем условно говоря правильно ли мы
00:09:10 - 00:10:40
подготовили приложение для какого-то конкретного рынка локального местного то есть допустим Мне нравится такой пример как когда-то coca-cola сделала короче рекламную кампанию в арабских странах и они такой коллаж слева направо но из-за того что в общем рекламная компания проводит в обратную сторону работала нам нужно чтобы такого мы избежали Нет ну пример с Колой хороший но это промышленность нас пройти Да вот ты можешь пример привязали указать пример Что может быть не так на веб-сайте допустим из-за того что
00:09:59 - 00:11:42
локализация неправильно не полностью или неправильно сделано Ну возможно допустим из-за того что другой язык или неправильно отображается кнопки что-нибудь такое так правильно еще что-нибудь может быть [музыка] какой-нибудь например читать эти этнические возможно цвета Ну или что-нибудь культур в культуре например воспринимается не так как допустим Но это прям очень это глубоко оценка тестирования мало Где применяется конечно как лучше сделать дизайнеры А вот Кроме того что может поехать верстка у нас еще
00:10:54 - 00:12:37
бывает что форматы некоторые в некоторых местах разные в разных странах например формат даты в России у нас день месяц года какие-то странах может быть другой знаешь какой да вместе за один год А еще помимо да бывает что формат Чего температура да то есть Фаренгейт А еще вот то что часто встречаются проблема это допустим у тебя магазин обуви да Или интернет садится обувь А есть формат размера ноги и он вообще там сколько там этих вариантов 5 по моему классификация Как мерить а еще у нас чего бывает
00:11:56 - 00:13:31
длина то есть измерение длины веса и так далее И еще у нас бывает такое что в некоторых местах пересчитать цена товара на какую-то локальную валюту когда ты переключаешь локализацию соответствии с курсом Вот видишь как много то есть надо помнить что локализация не только текст этом культурный взаимодействие вот такие вот вещи Хорошо про юзабилити тестирование Я слышал когда-нибудь а ну да то есть насколько условно говоря удобно пользоваться приложением то насколько она интуитивно понятно То есть
00:12:46 - 00:14:19
юзер чтобы он был комфортным Ладно хорошо Давай поговорим про ящики ты уже упоминал что существует белый черный серп Да ящики можешь сказать в чем их отличие о чем это вообще у меня на секунду пропало различие белого ящиков Ну понятие о чем они почему они существуют Да расскажи ну их различие уровни доступа тестировщика говорят внутренности приложения коду в частности blackbox это когда мы Тестируем как со стороны пользователя не имеет к коду ко всему что нам может быть это тоже по-разному классифицирует
00:13:36 - 00:15:29
а помимо доступа к коду да то что есть доступ или нет Как ты думаешь чем-то еще ящики отличаются Ну тебе Ты ручным тестировать подальше проект тебе дают ссылку говорят вот доступ коду короче и после этого что то тестирование становится тестированием белого ящика тут же Дайте ссылку от репозиторий тут кот лежит бах у тебя появляется доступ коду Ну значит тебе белый ящик Ну условно говоря только у нас построен план [музыка] планируем ли мы проводить какие-то проверки на тестировать будем отправлять
00:14:51 - 00:16:05
вот или мы просто мы будем допустим Какое тестирование пока у нас может быть не быть доступа к коду мы можем и 5 тестировать через ну мы отправляем запрос которому пишем руками это не кот и получаем ответ от условно говоря не только доступ коду А наверно вообще как работает Ну на самом деле тут дело во-первых познание внутреннего строения системы насколько мы не просто имеем доступ коду да можем понимать во-вторых самое главное это тоже что покрываем тестами в черном ящике мы покрываем тестами бизнес-логику
00:15:46 - 00:17:18
приложение мы проверяем Может ли приложение выполнять Возможно на него бизнес функцию А в Белом ящике тестами покрывается код код вне зависимости от бизнес функции то есть белый ящик это на самом деле Юнит тесты которые пишут разработчики то есть тесты которые проверяют строчки кода они не проверяют допустим добавить товар в корзину и сможет ли пользователь купить себе носки через интернет-магазине он проверит что модуль кода работает и вот Поэтому в тестирование белый ящика тестами покрывается код а при
00:16:34 - 00:17:55
тестировании черным ящиком тестам покрываются требования которые написаны изначально вот в чем разница это неважно есть доступ входа или нет главное что ты тестируешь в итоге а серый ящик это очень страшное понятие которое во всех учебниках и статьях прописано по-разному Вот и некоторые могут указать на то то можно считать серым ящиком это вот ты проверяешь Ну не бизнес требования все-таки проверяешь чтобы кэнд правильно работает и запрос и ответ правильно присылает с другой стороны ты как бы не
00:17:15 - 00:18:33
совсем покрываешь тестами строчки кода потому что все таки Back and работает полноценно когда ты его тестируешь просто у тебя frontendo нет И вот такая вот дуализм на ситуации он как бы позволяет сделать вывод иногда о том что API Это что-то вроде серый ящик Но не все с этим могут согласиться это такая дискуссионная очень тема Хорошо давай поговорим про Цените смог регрессия Знаешь ли ты вот эти три понятия и как они друг другом соотносятся Да ну ягрессии организационно тестирование это связано с применениями то есть после
00:17:54 - 00:19:20
каких-то внесенных разработчиками мы должны убедиться в том что не произошло регрессии Да потому что функционал который напрямую что он продолжает работать что короче разработчики ничего не сломали из того что уже Работала а смог конкретно пишет что это одно и то же Вот но на это тоже У всех разные взгляды смог конкретно тестирование это тестирование основного функционала которая проводим в первую очередь для того чтобы понять есть ли нам смысл дальше тестировать приложение или у нас какое-то банальный
00:18:39 - 00:20:22
функционал не работает и на мне да да Оцените что нам нужно просто немного Да я картинка подтормаживает ну реально собеседование Когда ты пойдешь Я рекомендую с этим как-то Ну на самом деле мне кажется не сильно поможет нашем случае Но если хочешь можешь выключить Да соответственно лучше усилить как-то свой интернет и улучшить свой звук чтобы потом реально собеседованиях просто лучше впечатление от тебя создавалось по поводу [музыка] да да по поводу Цените что ты можешь сказать Ну если определения то из того что я читал это
00:19:34 - 00:21:21
а ты что же базовая проверка основного как бы основным функционала Но более специализирована в каком-то одном одной сфере приложения условно говоря то есть допустим приложение мы конкретно там проверяем какой-нибудь один модуль Правильно ли он работает вот это как я понял это правильно все понял я поддерживаю такую точку зрения то есть да все верно смог нужен для того чтобы быстро проверить что Приложение работает в принципе Цените чтобы проверить какой-то конкретный функциональность как правило это либо новая фича которую
00:20:56 - 00:22:17
только что написали требует внимания либо какая-то отдельная фича по каким-то признакам и определяем А regression мы проверяем Что сломалось все остальное все верно все правильно Прости кубе вообще опасный источник там много интересных вещей написано сожалению сертификация кубик сделал человек который никогда не работал тестировщиком при разработке программного обеспечения не сделал профессор университета и поэтому она обладает определенной такой вот долей странных иногда выводов и иногда сложных размышлений например там
00:21:37 - 00:22:53
выделяется отдельно р бак и дефект и Значит есть Три разных понятия не знаю как там это в общем когда ты начинаешь только путь тестирование оно может больше даже вредить чем помочь потому что какие-то такие философские выкладки иногда дает что ты просто не понимаешь что ты читаешь сложно Сложно Вот поэтому я даже новичкам не советовал по поводу того как ты ответил по этим трем понятиям все верно А как ты думаешь Вот когда мы работаем в проекте Какие вот из этих трех видов до смог сэнтеригрейшн За
00:22:15 - 00:23:27
каким следует как правило какая у них приоритет Ну так сейчас секунду подумаю подумаю Ну допустим после какого-то Я наверное сказал что сначала проверяем все приложения в целом работает хотя бы потом уже в зависимости от наших приоритетов Наверное мы делаем сами какую-то одну или несколько каких-то функций и потом мы проверяем регрессию какой-то уже [музыка] хорошо А почему мы не можем допустим начать с регрессии Я закончил с молоком ко нам разница а ну а какой смысл нам Если мы проверим весь готовый
00:22:51 - 00:24:40
функционал до что он правильно работает потратил на это время а в итоге окажется что новых функционал вообще не выпускает Совершенно верно молодец правильно все Все ты правильно сказал что мы выделяем приоритет потому что иначе может оказаться что не имеет смысла так супер Давай поговорим про статический динамическое тестирование Знаешь ли ты разницу да [музыка] статическое тестирование это тестирование условно говоря мы проверяем код не запуская его Это пример статического тестирования а динамическое тестирование соответственно
00:24:04 - 00:25:43
запуском кода запуском приложения а ну еще наверное статическому тестированию мы можем тестирование документации то есть проверку требования наверное да все верно все правильно Окей и Давай поговорим про соотношение ручного автоматизированного тестирования в принципе Что такое автоматизированное тестирование чем-то ручном отличается И как ты думаешь когда нам есть смысл использовать автоматизированное тестирование когда нет [музыка] соответственно нам автоматизированное тестирование проводит по пирамиде
00:24:57 - 00:26:12
наибольшее покрытие автоматизированного тестированием мы делаем Юнит тестах это их пишет разработчики сами на свой на свой код после этого идут какие-то есть смысл автоматизировать то что у нас чаще всего повторяется то что занимает очень много времени монотонная работа например учитывая чтобы время затраченное на автоматизацию не получилось больше чем мы тратим на собственноручное тестирование вот поэтому тестирует часто автоматизирует муфты Вот и и в последнюю очередь автоматизируется интерфейс тестирование интерфейса
00:25:48 - 00:27:34
Окей хорошо Так а что же такое автоматизация как она выражается технически условно говоря пишется какой-то инструмент автоматизации тестирования для того чтобы условно говоря программа производила какие-то действия какие-то шаги для проверки нужно Ну то есть это программа которую вы проверяет другую программу мы пишем программу которая либо виде кода либо может виде каких-то блоков готовых мы используем логических Вот и соответственно нашу программа автоматически при своей работе проверять другую программу
00:26:50 - 00:28:17
хорошо супер Давай поговорим про уровни тестирования [музыка] у нас там бывает либо три либо четыре уровня в зависимости от того Какую книжку прочитали знаешь какие-нибудь уровни про один из них Мы уже поговорили несколько раз это unit-тестирование или по-другому она еще называется модульным тестированием Какие еще там бывают уровни Если я правильно понял вопрос потом идет после проверяем взаимодействует между собой Как как целая система Ну и потом [музыка] не такого уровня нет У нас есть значит
00:27:47 - 00:29:23
модульное тестирование потом идет это как-то сильно конкретного модуля потом эти интеграционный это тестирование взаимосвязи модулей а потом у нас идет системная Да System testing это когда система работает в целом а еще бывает выделяют и не выделяют 4 вид сюда Еще сюда часто приёмочная тестирование пихают это спорный вопрос иногда его пихают иногда нет Мне кажется ему здесь делать нечего поэтому приемшем тестировании Но кому-то кажется что есть вот про приёмочная тестирование знаешь что-нибудь что это такое
00:28:50 - 00:30:07
Ну это со стороны заказчика условно говоря проверяется окончательно после завершения протест тестирования то есть после выполнения там плана даты стратегии тестирования проверяется ли соответствует ли итоговый результат поставленного требованиям задачам и ожиданиям хорошо хорошо Так давай поговорим про техники дизайна Знаешь ли ты какие-нибудь техники ну это про методологии Да правильно я понял то есть анализ граничит методологии Нет методологии есть иногда это называют методология тестирования Вот Но лучше называть
00:29:33 - 00:31:23
техники это дизайн потому что еще есть методология разработки которая про другое оно там и так далее Поэтому вот слово методология но тут немножко сбивает часто с толку Ну да вот какие-нибудь метод граничного значений мы используем для того чтобы ну вообще как все техники дизайна мы используем для того чтобы рационализировать Да тестовое покрытие и при этом не слишком много времени сил на это затратить конкретно метод [музыка] какой-то набор значений чтобы не проверять все значения Мы берем только те которые
00:30:37 - 00:32:01
находятся на границах и рядом потому что именно там наиболее ошибки Вот то есть условно говоря если там какая-то форма у нас требует чтобы пользователь был старше 18 лет то мы проверяем мы проверяем значение 18 лет который находится на границе и 17 значение там на один ниже на один выше вот Ну давай возьмем конкретный интервал и проверим Ну или проще еще так сделаем Как ты думаешь сколько у нас будет проверок при тестировании любого интервала допустим число Так ну чтобы интервал то есть мы берем
00:31:26 - 00:33:25
Так ну 18 до 40 до 8 просто чтобы например да то есть мы берем [музыка] на 1 17 18 Да хорошо Ну то есть в итоге получается 5 Да вот ну верно отлично супер А еще какой-нибудь технику знаешь Ну эквивалентное значение как это анализы не помню валентное разделение называется Вот его используют часто вместе с мяч какие-то условно говоря классы значение да то мы должны использовать по одному значению каждого класса То есть если мы будем там 10 значений внутри каждого класса использовать это покрытие не
00:32:29 - 00:34:20
увеличивается но заточивается опять же если мы накладываем на наш предыдущую значение [музыка] меньше 18 до 40 и больше 40 ну интересно подход к а если допустим еще проще мы попробуем эквивалентное разделение сюда привнести не мешаю вас с границами с какими-то Вот как ты думаешь на плод я тебя пример приведу У нас есть поле ввода вот поле ввода у нас есть требования что должны вписываться какие-то символы допустим символы английского алфавита буквы поле вода Ника для регистрации пользователя может
00:33:44 - 00:35:29
состоять только из букв Каким образом мы здесь можем применить эквивалентное разделение Ну должны позитивные поле должно принимать английские буквы не должно принимать символы Так а как здесь работает эквивалентное разделение помимо негативности один класс Это у нас английские буквы второй класс а ну допустимый класс это только английские буквы имя все остальные это недопустимо можно такая на это посмотреть А как ты думаешь нам нужно проверять все английские буквы нет но суть этих классов что если
00:34:42 - 00:36:18
вообще принимает английский все они будут принимать Ну вот да то есть в принципе ответ в том что нам не надо проверять весь алфавит достаточно проверить как минимальное значение количество этих букв и мы считаем что все буквы как вводное значение они друг другу эквивалентны то есть равны и соответственно мы подразумеваем что нам нет смысла проверять все буквы потому что они должны обрабатываться системой а одинаково Мы конечно можем проверить все на всякий случай Мы можем сэкономить время и все Не проверять Вот вот
00:35:47 - 00:37:01
Собственно как мы можем на как мы на самом деле чаще всего используем классы эквивалентности чтобы сэкономить наше время Ладно хорошо Давай поговорим про тестовую документацию Какие ты знаешь виды документации которые составляют тестировщик в процессе своей работы [музыка] первый уровень до теста документации это чек-листы и багре порты которые именно ручной тестировщик чаще всего выставляет [музыка] еще тест-план бывает да да но это уже более такой высокоуровневое [музыка] требованиями тоже работают
00:36:24 - 00:37:59
Вот еще оценка времени тестирование тоже Вот наверное стоит Можно же отнести документацию Ну давай говорим про тест-план допустим из чего он состоит что это такое план Это документ в котором мы описываем ресурсы которые у нас есть для тестирования инструменты которые мы планируем использовать и почему методы тестирования Что именно И как мы будем тестировать вот ну и возможно если большая команда мы там же можем распределить допустим работать да кто там будет каким конкретно заниматься Так что будем тестировать как будем
00:37:22 - 00:39:16
тестировать что нам еще важно какими там бывают критерии да да критерия то есть когда мы будем знать что мы можем закончить тестирование уровень метрики можно включить то есть [музыка] на основе чего мы будем делать вывод о качестве продукта допустим то есть какое-то отношение там выявлены и багов такое соотношение Всё верно А вот еще у нас допустим ты тестируешь приложение нативное что тебе нужно определить для того чтобы доступно и нативные приложения тестировать желательно окружение системы все правильно да то есть нужно выявить
00:38:42 - 00:40:24
требование лаборатории Хорошо давай поговорим про чек-лист и тест кейс Да что это за поменять о чем они зачем они Ну это артефакты так называемый вид документации соответствии с которым мы проводим наш тестирование функцию они выполняют примерно одну и ту же но различия в уровне детализации То есть если у нас просто перечисляет проверки определенные и отметку более подробно описывает шаги конкретной проверки ожидаемой итоговый результат какие-то Ну там окружение допустим и так далее В общем более подробно и в зависимости от
00:39:51 - 00:41:34
наших нужд на проекте в зависимости от ресурсов времени мы уже выбираем то что более оптимально будет более удобно а как ты выберешь в зависимости от нужд и от ситуации про это что он отклонение повлияет Да чтобы выбрать чек-лист или тест влияет допустим если я один тестирую какой-то небольшое приложение у меня будет проще я буду знать что у меня там каждая проверка если допустим это будет долгосрочный проект который планирует там походу нанимать возможно Потому что таким образом новые тестировщики
00:40:59 - 00:42:24
более подробно еще будут понимать что они делают [музыка] нужно покрытие тестированием допустим если горят сроки какие-то и у нас не хватает времени на полное покрытие то нам нужно как минимум покрыть приоритетной до функционал который обязательно должен работать поэтому лучше сэкономим время напишем чек-лист но при этом хорошо а если мы выбираем тест кейсы то В таких случаях они будут полезны если чек-лист такой крутой Зачем таскейс [музыка] так Ну если мы также можем использовать если у нас какой-то сложный функционал
00:41:51 - 00:43:32
неочевидный допустим да И нам нужны подробно расписать как мы будем тестировать опять же если это длительный проект до который будут добавляться новые функции в ходе проекта чтобы старый функционал был документированно говоря чтобы ему можно было потом Ну правильно в принципе все про То есть если мы проверяем какие-то сложные проверки которые просто велик листа Не укажешь потому что их потом не повторишь там где надо сложно там подготовить тестовое окружение и так далее потом соответственно После этого мы можем
00:43:00 - 00:44:23
применять чек-листы там где у нас планируется вообще большая команда большой штат где будут новички тестирование надо будет объяснять Как тестировать и чтобы не объяснять мы заранее напишем тыс кейсов подробно чтобы они просто начитали и проходили вместо того чтобы бегать и спрашивать всех им было понять вот когда у нас есть принципе перспективы того что проект будет развиваться даже если сейчас там ты один да Ну ты знаешь что у вас там проект на год вперед на два И что все хорошо вот это и время есть на это
00:43:58 - 00:45:05
понятно дело написание этих сценариев в принципе хорошо хорошо так поговорим тогда про репорт что это такое Что все включает Зачем нужен [музыка] Это отчет о найденной ошибке условно говоря мы фиксируем какое-то несоответствие [музыка] нашего софта требования и фиксируем его для того чтобы разработчики могли его исправить выделяют несколько обязательных полей чтобы там он учитывался в какой-то рейтинговой системе она используется краткое описание в котором должно быть Понятно вообще в чем проблема
00:44:31 - 00:46:07
Что когда где да то есть что произошло в такой ситуации и в какой части нашего приложения после этого мы указываем какой может быть дополнительное питание какое-то [музыка] шаги воспроизведения этого Бага возможно какое-то предусловие перед шагами то есть что мы сделали перед этим непосредственно вот [музыка] ожидаемый результат который мы должны были получить и реальный результат который мы получили вот также могут быть какие-то там возможность прикрепить допустим скриншот да Или какой-то Лог логика Вот
00:45:34 - 00:47:29
[музыка] Ну там кроме логов просто есть такой раздел от touchments то есть могут быть логи могут быть скорее могут быть видеозаписи чё чё угодно Может быть там не только логин Ну в принципе хорошо Да нормально по поводу жизненного цикла репорта Давай поговорим Вот ты завел багри по что с ним дальше происходит команда Ну как это сферическая команда в вакууме условно говоря PM видит что я завел баг он ставит приоритет ему и назначает кому-то из разработчиков после чего разработчик Ну либо говорит что это не бака фича и в
00:46:41 - 00:48:30
общем закрывается либо если это действительно то он исправляет его ставит отметку что он исправил после этого бак уходит на ретест я перепроверяю действительно ли бак больше не воспроизводится если не воспроизводится он закрывается производится то он опять отправляется хорошо в принципе Понятно теперь поговорим давай про частные случаи вот допустим [музыка] Ты завел разработчиков признал исправил ты его перепроверяешь и вот как ты сейчас только что сказал баг воспроизводится перепроверьте киты его Направляешь опять разработчику
00:47:47 - 00:49:25
разработчик говорит тебе меня он больше не воспроизводится я его починил и отправляет бак опять тебе что ты будешь делать Ну проверить на каком-то другом устройстве например [музыка] например проверил производится вообще на всех устройствах ну скинуть разработчику более подробную информацию там по логах как какие-то ошибки возможно скинуть разработчику информацию о об окружении Какое окружение ты используешь там браузер система если работает то можно [музыка] Ну попросить разработчиков подойти показать им на своем просто компьютере
00:48:42 - 00:50:31
хорошо то есть ты проверил версию окружения проверил проверил этом девайс если это нативное проверил разные браузеры на разных версиях если [музыка] помимо окружения что еще может быть не так окружение именно на котором ты тестируешь и возможно вы беда но это тоже к окружению относится вот бывает еще то сама версия кода правильная то есть допустим ты видишь ошибку А то что она осталась а потом оказывается что разработчик залил свои изменения в версию где ну который еще не вышла для тестировщика в релиз и ты
00:49:42 - 00:51:10
просто ну проверяешь там где нет то еще этого фикса Вот хорошо Вот вы правее или код правильный и окружение все одинаково Ну по максимуму одинаково может не идеально одно и тоже компьютер Вас могут быть разные все дела А он тебе все равно горит у меня не воспроизводится Что ты будешь делать так возможно другого разработчика попросить проверить именно этот Чине другого Нельзя просить другие заняты своими делами Ну попробовать на его то есть опять же пробовать моего компьютера самому тебя нет он тебя не даст свой компьютер Он
00:50:33 - 00:51:46
говорит тебя не трогай мой компьютер Ну тогда тогда нам следует менеджера обратиться У нас есть менеджер проекта который отвечает за проект целом и ты до него информацию Ну там негативных красках что там еще А как есть говоришь вот у нас как мне кажется есть бак у меня есть такое-то приоритет Мне кажется это очень важно и страшно разработчика его не видит давайте-ка мы разберемся и все И ты просто кидаешь ссылку на багре порта менеджеру менеджер разбирается если ему кажется менеджеру как правило чтобы
00:51:21 - 00:52:27
агрепорт не такой уж и приоритетный он тебя может написать суши Забей Забей закрой или там Отложи ты конечно же как профессиональные тестировщик напишешь об этом в комментариях к этому потом никто не вспоминал точнее тебе не пришлось вспоминать Почему ты его закрыл и так далее и отложили все он тебе скажу Ну вот Вася он программист очень важный для нас сейчас не может отвлекаться на вот такую мелочь вот а может оказаться Так что Баку действительно важный критичный и нехороший и менеджер попадет к
00:52:01 - 00:53:10
разработчику и скажет Вася давай чини что хочешь делай это надо починить и Вася может быть нехотя может быть еще что-то он начнет чинить и окажется что воспроизводится ли он найдет причину почему у него значит не воспроизводится и все починится вот тут уже конечное слово за менеджером проекта хорошо представим себе тогда такой ситуации что ты завел попадает к разработчику и бочку сразу идет лотка с до говорит допустим что это не баг ноты бак стоит статус что дальше с багрепортом происходит Ну по идее он
00:52:36 - 00:54:03
если по идее он закрывается но он не закрывается он не закрывается он также как и при других действиях всегда идет на перепроверку тестировщику который завел его просто статус будет не фикс А типа не баг Ну и как правило разработчик он может написать типа мне кажется Ну какой-нибудь коммент чтобы информация больше было может не написать что ты в этом случае делаешь должна работать так работает не так поэтому Если подробно документации можно остаться на здравый смысл грубо говоря да то как В подобных приложениях это уже
00:53:20 - 00:54:50
реализовано в каких-то популярных известных общепринятая норма вот если это не работает то опять хорошо хорошо верно А предстам еще какую-нибудь ситуацию вот завели Ты завел бак он падает разработчику разработчика 5 не хочешь чинить Но в этот раз он ставит статус не ноты бак допустим А дубликат Что это значит что будет дальше Ну это значит что такой бак уже был зафиксирован да По идее дубликат то возможно он поставит ссылку на уже существующий чтобы можно было удостовериться в этом так поставил ссылку баг Report вернулся
00:54:17 - 00:55:58
к тебе чего ты делаешь Ну я смотрю который дублирует [музыка] Ну вот представим сюда что тот бак оригинальный до который был первым как бы его смотришь а он закрыт Он давно закрыт Что ты будешь делать со своим Ну если тот закрыт Я сейчас выйду вот значит ну его закрыли не пофиксил либо он опять так и в этом случае вот со своим багом который дублик а что ты будешь делать тут я не уверен Как вариант переоткрыть старый баг рекорд либо Ну тут я не уверен правильно все правильно ты все правильно говоришь что
00:55:19 - 00:57:01
и действительно можно быть не уверенным потому что в разных проектах по-разному где ты можешь действительно переоткрыть старый баг Report а новый просто туда его при линковать Ну чтобы информация сохранялась вот в некоторых же проектах просто Физически невозможно переоткрывать старые закрытые таски Ну в силу организационных причин и тогда ты своего Бога ставишь нормальный статус вот а в описании в комментариях ты просто указываешь что типа это уже повторяющийся бак но это не просто какой-то дубликат А это вполне себе
00:56:39 - 00:57:49
активный новый баг потому что старый вроде уже был пофигшен Так что вот вам информация про старый А ну пожалуйста почините Вот а если старый бак еще открыт и действует и может даже фикса или нет то твой является полноценным дубликатом который закрывается как правило как дубликат Ну опять же тоже принятовывается к оригинальному бог-репорту для того чтобы была информация о том что его лишний раз наткнулись вот так так хорошо Хорошо В принципе Окей давай поговорим про документацию хорошо поговорили про
00:57:15 - 00:58:34
принципы работы да и особенность тестирования разных видов приложений вот у нас в принципе выделяется три большие группы приложений которые тебе скорее тестировать это вы приложение мобильные приложения которые чаще называются нативными вот доступные приложения вместе с нативными как бы в одной упряжке идут и гибридные а соответственно вот по очереди Давай поговорим про них в чем как они работают да И как особенности тестирования этих приложений вот начнем например с вэб приложений Может ли это рассказать как работает вот
00:57:53 - 00:59:38
веб-технология что там куда передается и так далее работает на архитектуре то есть нашего там происходит [музыка] вычисления и нам уже обратно хорошо а Запрос который идет на сервер он что из себя содержит Ты знаешь Ну метод запроса адрес URL в зависимости от методам тело запросы всякие авторизации Отлично Да хорошо а ответ что содержит Ну тело так тело чего еще Да статус код сказал да то есть там тело есть еще хейдер Бади и статус код Какие статус когда ты знаешь Ну кто ты но они как бы по группам Да по
00:58:45 - 01:00:49
первому числу 100 это информационно можешь просто парочку объяснить просто парочку Назови да и все 404 самый известный 400 группа это проблема на клиента конкретно [музыка] [музыка] 500 500 это ошибка на стороне сервера например 503 это но она Вторая авторизована авторизацию не причем просто 500 ошибка на стороне сервера и соответственно либо сервер не работает либо работает некорректно вот этого достаточно опасно на самом деле уходить потому что тебя может собеседовать какой бывший садмин и если ты там начнешь рассказывать Ой
01:00:38 - 01:02:25
нафиг за душу не надо вот и 200 когда все хорошо страница пришла полноценно все отлично и все вот это как правило всем достаточно вот OK Какие особенности тестирование мы можем выделить Да вот он у тебя допустим Ты тестируешь веб-приложение что ты будешь проверять и чаще всего особенно что связано с вебом Какие виды тестирования будем применять Ну опять тестирование ну вспомним Мы про виды тестирование говорили в начале собеседования что есть разные виды тестирования Вот какие виды мы можем Ну или допустим желательно Да
01:01:41 - 01:03:10
именно в приложениях проверить на разных браузерах условно кроссбраузерное тестирование на разных устройствах то есть на разных то как у нас будет разве это устройство зависит разве это устройство разве это устройство зависит как его приложение работает разве как минимум визуально А может быть это от браузера зависит от приложения от устройства какая разница Как выглядит сайт в браузере Chrome на мойке или на Windows допустим ты можешь разница назвать нет про мобилки наверное то есть то как у нас не мы говорим про веб Мы про
01:02:49 - 01:04:12
мобилки В чем разница будет Ну там как это адаптивное или пончик вот этого так она адаптивно верстка на будет на любом она либо есть либо нет и вне зависимости от телефона она Я же это браузера и от Ну короче вы приложение от устройства может зависеть только от его размера экрана это опять же это проверяется то чтобы то что сказали существует ли в принципе адаптивная верстка на приложение или нет Ну ты как тестировщик который работает команде разработки Ты знаешь так есть она или нет А так в принципе зависит от браузера
01:03:43 - 01:05:14
Можно даже для себя выделить прямо по пунктам особенности работы и что из этого следует для тестирования от интернета зависит Значит нужно тестирование связанное с работоспособностью интернета там тестирование на прерывание можно выполнять Это например на ухудшение интернета второе зависит от браузера зависит Значит нам нужно [музыка] кроссбраузерное тестирование сделать третье зависит от железа ну как правило не зависит Ну то есть если железо тянет браузер то уже оно и все остальные веб- вещи подтянутся значит
01:04:28 - 01:05:50
железо нам неважно установки требуется установка для приложения Нет не требует значит инсталляционное тестирование нам не подходит вот дальше соответственно тестирование безопасности мы можем провести потому что у нас там есть клиент серверное взаимодействие которое может там атакам подвергаться данные как-то теряться и так далее Вот и 5 мы уже назвали Ну вот допустим это все А вот теперь поговорим про нативные приложения или десктопный Да нативный это на телефон доступны на компьютерах установки требует
01:05:10 - 01:06:34
требует Значит нам нужно тестирование инсталляции от работы интернета работа нативного приложения зависит Ну это спорный вопрос функционал в нативных приложениях он как правило работает без интернета интернет Нам нужен в нативных только чтобы контент какой-то свежий погрузить новые фоточки новые посты какие-то новые сообщения но по умолчанию полноценная нативное приложение оно просто будет показывать тебе старую информацию но он будет работать целиком полностью оно работает на стороне устройства и логика
01:05:55 - 01:07:03
срабатывает на стороне устройства ему сервер не нужен сервер нужен только так иногда подтянуть свеженькое вот Или вообще не нужно например есть приложение Фонарик на телефоне которому не нужен веб-сервер Окей в нативных предложениях инсталляционное мы провели кроссплатформенная Мы провели на разных устройствах кроссбраузерная не стали проводить Интернет постольку-поскольку батарейка проверили и горизонтально гленнские [музыка] Ну окей гибридное приложение знаешь что такое как правило у нас когда часть
01:06:37 - 01:08:14
нагрузки у нас происходит а часть [музыка] да да и исходя из той классификации которую мы только что обговорили можешь рассказать да что мы тестировали гибридным приложении Ну соответственно тоже установка требуется [музыка] требуется значит инсталляционная проводим сервер нужен Web для работы приложения да да правильно значит подключение к интернету нам нужно все время проверяем вот с точки зрения как Web и Pi у нас какой-то там есть да да Значит и 5 получается на самом деле что по сути собираются все
01:07:34 - 01:09:31
особенности допустим гибрио нативного и Веба и виды тестирования подтягивается оттуда оттуда но это если мы говорим о гибридном приложении в контексте вот такого гибридного приложения потому что на данный момент существует разные гибридные приложения и если гибридная технология не в виде смеси Вы бы и нативная система а допустим это гибридный фреймвор типа к Самарин там уже может быть другая история Вот но Фишка в том что гибридный фреймворки режет пользуются на данный момент и про них мало кто знает так скажем поэтому
01:08:40 - 01:09:58
спрашивает скорее всего не будут Вот Но эти рекомендую почитать про разные гибридные подходы которые сейчас существуют потому что они сейчас очень популярны а популярно не потому что быстрее дешевле разрабатывать гибридные приложения чем нативное или вот да Окей Ладно давай поговорим про методологию разработки какие-то знаешь методологии [музыка] [музыка] модель вот хорошо расскажет про водопад Ну это самое первое методология разработки она гибкая идет последовательно все свои последовательность сначала нас там вот
01:09:20 - 01:11:05
требований планирование потом разработка тестирование [музыка] в том что мы заранее определяем конкретно все наши требования максимально точно никаких правок не должно быть и мы поэтапно максимально сделали на каждом этапе Идем дальше Ну и в тот же момент плюсы этого же является минусом то есть допустим если нам нужно что-то без готовое Да условно говоря разрабатывать если нам на определенном моменте мы поймем что нам нужно что-то там добавить а что-то немного изменить мы этого просто сможешь сделать но используется это там
01:10:30 - 01:12:04
военных военной отрасли Может в какой-то максимально точно Нужно все заранее планирует [музыка] в принципе ты правильно хорошо назвал тут просто ты делаешь упор горишь максимально точно сделать лучше спланировать это как бы это верно но не совсем самое главное особенность это в том что в процессе разработки то есть в середине потока ватерфола этого очередного тяжело вносить изменения ваш самое главное это особенность фола и вот этих не отжал методологии что ты не можешь изменить продукт Когда уже
01:11:21 - 01:12:46
допущен запущен очередной цикл разработки и это бывает хорошо стоит точки зрения не что И в середине процесса разработки бывает что новые баги программиста допускают Ну потому что они вроде как одно пилили потом их попросили чуть-чуть это переключиться Но с другой стороны если не просят вносить изменения в середине очередного процесса разработки то разработчику Может лучше внимательнее и качественнее сделать То что от него просят просто другое проблема что то что просит уже может быть не актуально именно поэтому
01:12:12 - 01:13:42
Новый багов будет меньше Именно поэтому в аэрокосмической отрасли В самолетах и так далее применяют waterfall Потому что если будут баги самолет может упасть или ракета может упасть а конкуренция на рынке между самолетами ракетами она не такая быстрая как на рынке Допустим веб-сайтов или каких-то еще технологии поэтому по компаниям которые по разрабатывают в этих сферах они не так торопятся у них нету коротких быстрых циклов разработки но при этом Они каждый свой цикл выполняют очень тщательно вот а отжал он хорош там где
01:12:59 - 01:14:25
соответственно у нас не требуется такое прям сильно щепетильности в работе Где баги не является реально проблема жизни смерти людей допустим и там важна скорость разработки И самое главное изменчивость изменчивость чтобы можно было где-то подкрутить подделать переделать переосмыслить прямо на ходу сходу решать эти вопросы Вот и соответственно вот в отжали Да как в подходе Есть конкретные методологии нож про какие-нибудь рассказать ну там Канбан самый популярный так Ну вот и расскажи про них идет
01:13:43 - 01:15:07
[музыка] команда Там могут быть четырех недельных винты и в ходе каждой операции мы как бы работаем над каким-то одним [музыка] модулем так скажем Да каждую операцию В идеале должен сделать какой-то работающий продукт не обязательно выпи короче прям просто делается кусочек продукта то есть одна несколько фичей Вот они добавляются к основному продукту в конце спринта и и дальше снова спринт Опять вот а в компании как отличие от крана Вот она мне не очень знакомы но там я знаю что там используется
01:14:29 - 01:16:19
борт доска до проекта и там вот эти вот передвигается таски из столбцов то что нужно [музыка] сделать что делается что сделано с краем тоже есть такая доска это не не сказать что это прям отличие методологии Ну почитай основная основная суть канвана заключается в том что нет спринтов то есть в компании идет оценка работы исходя из каждой конкретной задачи то есть каждая задача планируется когда она появляется примерно рассчитывается нагрузка на команду и так далее То есть в реальном мире конечно в
01:15:34 - 01:17:04
компании есть что-то вроде промежуточных таких вот релизов но они легко отодвигаются оттуда выкидываются задачи закидываются они не такие важные А в скраме же к старту финишу вот этих вот спринтов очень подвязано там очень много основывается вот сейчас чаще Это увидишь скрам через чем Канбан В разработке но бывает всякое хорошо в скраме ты можешь назвать Какие действия у нас в процессе спринта происходит Что происходит в начале спринта Что происходит в процессе Что происходит в конце Ну мы планирование какой-то
01:16:28 - 01:17:54
встречу что мы будем делать примерно обозначает цели распределяются Потом каждый день Ну если они есть то есть команда говорит над чем она сейчас работает Если кто-то другой В общем не блокирует на работу и потом в конце дома то есть мы показываем что у нас В итоге получилось и ретро может быть то есть мы обсуждаем какие-то наши ощущения что нам не понравилось Да да все правильно хорошо а знаешь ли ты что такое блок это как я понимаю в общем наш список задач для всех которые нужно сделать которые
01:17:21 - 01:19:08
приносим то что актуальную повестку то что нужно будет прямо сейчас Ну не совсем все это бэклог это место где у нас лежат задачи Откуда мы берем их на доску на нашу Да и берем в работу не знаю что прямо сейчас на сделать нас сделать может быть конкретным спринте Вот и поэтому у нас бы клубы существует два Да есть бы клок спринта есть блок всего проекта всего проекта падает задачи когда они в принципе придумываются там бизнес-аналитиками заказчиками и так далее а каждый раз когда начинается спринт у нас происходит планирование
01:18:40 - 01:19:45
спринта Мы из бэк-лога проекта перекладываем часть задач бэк Локс принта Ну когда мы определяем вообще список задач которые мы будем делать спринте И затем когда спринт у нас идет Project Manager он Потихоньку Ну ему даже участники команды сами это делать Может менеджер дело они вытягивают задачи на доску себе по очереди и выполняют их когда задача кончаются они еще себе берут и так далее пока спринт не кончится потом в конце спринта Если какие-то задачи в букологи остались и там переносят следующий спринт или
01:19:15 - 01:20:30
убирают вообще в долгий ящик назад Быков проекта потому что допустим в процессе спринта Выяснилось что они не нужны вот так окей Окей в принципе мы с тобой много чего обсудили все что я хотел Давай дам фидбэк определенный по поводу того что мы обсудили во-первых я тебя прошу выучить определение базовые выучить Что такое тестирование Что такое качество Какие бывают цели тестирования Есть огромное количество этих разных целей тестирования Выбери то что тебе больше всего понравится Вот и чтобы четко было четко
01:19:53 - 01:21:22
по методологиям методология по тех с дизайна название техник четко анализ граничных значений эквивалентное разделение или по-английски можешь выучить баундари value analysis или эквивалент патришин все прям а тот В названиях тоже там начал выдумывать сам Вот лучше чтобы четко отлетала по видам тестирования Почитай еще раз классификации про ящики мы поговорили там функционально не функциональные что все чаще всего включают могут быть в разных источниках по-разному но хотя бы какой-то подход Вот это хорошо Это хорошо статическая
01:20:37 - 01:22:17
динамическая хорошо так плотность плану ты в принципе хорошо отвечал но все равно пришлось и навести Немножко там критерии оценки начала тестирования критерий окончания тестирование две группы критериев Повтори вот дальше талант чек-лист Это хорошо Тоже хорошо вот принципе работы гибридных приложений Почитай Вот и вот для себя вот эту структуру Придумай Да вот По каким критериям их разделять там необходимость установки необходимость наличие интернета и так далее И от этого Тебе будет проще отталкиваться когда
01:21:27 - 01:23:05
тебя попросят назвать виды тестирования именно конкретному виду приложений на реальном собеседовании более того тебе могут так сказать Какие сказать У нас есть приложение наша нативная Скажи пожалуйста какие бы ты тесты придумал для нашего вида приложения Да и фишка работает их приложение что сейчас вот рассказать это практически вопрос важный вот Так ну все остальное в принципе нормас про про Канбан чуть Почитай но в принципе эти сказал чем основная суть но так чтобы пошире отвечать Все у меня вопросов больше нет У тебя
01:22:23 - 01:23:42
есть вопрос я вот недавно нашел сделал проект на фрилансе То есть я по знакомству просто меня знакомый искал чтобы протестировал сайт Я в общем сделал и я думаю как это можно записать опыт Если две недели там буквально небольшой как это можно писать Но если в общем отвечает Ну ты можешь написать Не обязательно Призма писать я знакомым по блату за бутерброд ты напишешь я работал в такой-то компании [музыка] ты можешь написать что ты работал такой компании можешь вместо двух недель написать несколько
01:23:07 - 01:24:40
месяцев два месяца Например какая разница Ты в принципе на самом деле что что ты сделал за две недели то ты будешь делать годами годами много месяцев сильно не поменяется Вот и указать что тестировал выполнял какие-то виды тестирования и так далее В принципе можешь кинуть мне резюме я гляну Вот Но лучше меня по моему были видео про то как делать резюме на YouTube Поищи вот если нету скоро появится и соответственно Если что можешь допустим наше влиться мы там постоянно мои ребята все друг другу кидают резюме и пытаются просто
01:24:02 - 01:25:31
посмотреть сможешь несколько вариантов мне получить помимо его допустим Если ты хочешь посмотрим как у тебя там хорошо прописано или нет вот так понял Слушай еще такой вопрос можно на рингтоне добавиться и если мог бы попробовать Да это помогает можно вот LinkedIn я бы не сказал что это прямо хороший способ получать большое количество работ но по крайней мере до недавнего времени Это был способ получать интересные работы то есть в ликвине есть у тебя хорошо написано резюме ты можешь получить очень
01:24:46 - 01:26:04
интересное предложение за рубежа Ну прям Действительно интересно то есть меня и на автомобильный завод предлагали мне допустим тестировать компьютеры и в Японию были варианты про себя собеседовался я в Токио Вот но редко но метко так скажем А так в принципе для поиска работы для такого потного Ну все сервисы хороши везде можно искать но какие-нибудь вещи типа HeadHunter или [музыка] habr карьеры или еще других вещей они в России [музыка] Ну что да Ну смотри как хочешь как знаешь удаленщиков из-за границы тоже
01:25:28 - 01:27:06
Так что еще не отлично не очень много но у Джина обязательно Установи себе Бота Джинни бот телеграммного он будет тебя постоянно снабжать пачками вакансий на которой ты вручную будешь плавиться Вот Обязательно Все спасибо большое очень полезный эксперимент Да Сергей в принципе мне нормально я как человек который давно войтишки двигается постоянно работаю с таким звуком Потому что ты когда пойдешь в реальный проект у тебя будут коллеги которые сидят в бункере у них тоже плохой интернет будет пропадать связь они будут еще при этом
01:26:19 - 01:27:41
говорить на английском с каким-нибудь значит хитрым акцентом потому что они будут не носителями языка и ты будешь как на подводной лодке знаешь эти были чуваки с сонаром вот так сидеть с наушниками и сосредоточено пытаться понять чего они вообще говорят потому что и не слышно и непонятные все дела Вот Но в принципе да когда ты на собеседование идешь тут желательно сделать все возможное чтобы тебе было хорошо слышно не прерывалось ничего ну и желательно чтобы тебе было видно Тут уже сам смотри Вот потому что на
01:27:18 - 01:28:26
собеседовании важно а в реальных проектах там кошмарные иногда качество бывает и ничего не поделаешь с этим вот Приходится работать как есть так что Да вот если что звони пиши Как говорится и если хочешь сообщества и там тоже много чего обсуждаем пассивы еще раз пока давай пока Ну как вам было интересно мне особенно понравилось расслабленная Атмосфера Сергея он подложил подушечку и спокойным голосом вещал и рассказывал о том что он знает такой подход на самом деле очень сильно помогает на реальном собеседовании Когда
01:27:52 - 01:29:18
вы можете держать под контролем ваш уровень тревожности И даже если вы рассказываете что-то не так что-то неправильно не переживать и не впадать панику Так что многим могу порекомендовать такой настрой на сегодня все пока
01:28:39 - 01:29:23