[музыка] Всем привет У нас сегодня новое собеседование на Junior Key с нами сегодня Арнольд который в кратчайшие сроки выучил определенный объем теории тестирования и хочет проверить свои знания Ну что же Давайте смотреть Итак всем привет С нами сегодня Арнольд Расскажи пожалуйста что хочешь о себе чего-то ожидаешь от нашего созвона а вообще хочу проверить уровень своих знаний и Вот потому что изучают тестирование довольно таки недавно буквально полторы недели вот то есть две недели назад и ничего не знал про
00:00:00 - 00:01:27
тестирование вообще ничего вот Начал вы изучать сам Точнее по курсам по курсам которые мне посоветовали друзья Вот и дошел до какой-то точки что принципе я всю теорию до которую можно которая была на курсах Я выучил вот также я работал в постмоне сдавал запросы Вот и принципе вот на этом все а какой-нибудь тест документацию составлял там чек-листы вставлял чек-листы составлял То есть это все было по программе курса Хорошо Ну тогда начнем с общих вопросов и немножко такое отступление сделаю так я
00:00:50 - 00:02:17
все наверное удивляться тестирование очень короткое время Вот поэтому я буду пытаться на твои вопросы отвечать а не прям скажем по учебникам да то есть у меня знания не заученные до терминов то есть пытаться отвечать как-то В принципе немножко даже своими словами Это нормально Арнольд У меня тоже знания не заучены у меня знания из моего рабочего опыта и когда я собеседую в компанию в которой работаю для меня не главное сравнить значит учебник и то что ты знаешь для меня лично главное понять Какое будущее работник будет на работе
00:01:37 - 00:02:51
да что он с чем он справится с чем Он не справится то есть для меня не так важно прям четкие определения важно понимание Так что я думаю все у нас получится хорошо начнем с общих вопросов Расскажи пожалуйста что такое тестирование Ну вообще есть много определений этому Да термину но как я понимаю тестирование Другими словами это проверка то есть мы что-то проверяем То есть у нас есть какой-то результат которого мы ожидаем и какой-то результат который мы получаем и вот сравнивать два эти результаты мы
00:02:14 - 00:03:22
имеем какое-то вот представление о том что мы Тестируем Да будь то это по будь то это вообще что будь то велосипед образно хорошо мы соотносим результат и ожидаемый вот мы хорошо представим что мы тестирование велосипед И как ты думаешь для тестирования по ожидаем результат Где мы можем взять ожидаем результат Да ну ты говоришь мы Тестируем фактическое поведение Да с чем что мы хотим увидеть то что мы хотим увидеть Откуда мы получаем информацию значит в нашей команде по идее так скажем лучше так скажем образе должен
00:02:49 - 00:04:12
быть Project Manager Так мы должны попросить его его взять эту спецификацию у заказчика и попросить предоставьте нам как тестировщиком как наша команде эту спецификацию чтобы мы уже исходя из неё начинали тестировать продукт вот отличный план А ты знаешь есть еще один член команды которые за спецификацию отвечает Project менеджер может так сделать как-то сказал это в принципе вариант но часто еще выделяют отдельное человека который прям отвечает именно за документацию знаешь я слышал только Проджект
00:03:43 - 00:05:02
менеджера Но если кто-то еще есть я Ну Пальцем в небо Может бизнес-аналитик есть такая отдельная профессия тоже в крупных компаниях крупных проектах бывает в маленьких не бывает Но тем не менее Если есть возможность обращаясь со в первую очередь к нему вот Project менеджер именно управлением проектом занимается обычно более Ну хорошо так спецификации допустим нет я не могу тебе помочь в принципе нет его Да в команде Ну значит включаем логику нашего мышления Мы что все-таки работаем войти сфере Да и должны как-то пользоваться в
00:04:22 - 00:05:48
том числе логикой нашей Да вот и что это я подразумеваю под логикой то есть мы осмотрим на продукты наших конкурентов да то есть продукт создаем там не знаю продукт примеру там приложение по прогнозу погоды Вот Мы открываем какие-то сторонние приложения Смотрим как у них и уже исходя из этого мы сами Составляем сертификацию и уже пользуемся вот данными конкурентов так если конкурентов нет Или допустим ты не знаком с конкурентов нет Ну слушай тогда получается уникальный продукт которому нет аналогов Да и тогда
00:05:12 - 00:06:35
мы уже подходим к доске там виртуальные или физической составляет сами чем хотим уникальный продукт Конечно мы можем что мы можем сами даже что-то придумать От чего мы можем оттолкнуться еще конкурентов нет Или допустим вот этого куска конкурентов Нет без аналитика нет менеджер не может помочь выхода на заказчика Нет спецификации нет что у нас остается но мне кажется есть два момента от которых можем утолкнуться во-первых наш бюджет сколько у нас денег во вторых во вторых это какой-то временной промежуток то есть не можем
00:05:54 - 00:07:13
создавать год-два Да мы уже исходим из нашего бюджета и заливного промежутка А и исходим из того из потребности наших как бы будущих пользователей наших клиентов Вот смотри ты тестируешь приложение Просто представь себе ты веб-сайт ковыряешь и страница на веб-сайде неожиданно схлопывается и вылетает допустим данные не сохраняются на странице это баг лопается Нажимаешь кнопку и у тебя там не знаю дизайн съезжает во все стороны и все все данные исчезают или ты допустим Ну да вот визуальной частью тебя там
00:06:34 - 00:08:10
элементы перемешиваются все И ты запутываешься или у тебя нативное приложение на телефоне ты переходишь на каком-нибудь экран она у тебя Ну сворачивается исчезает вылетает приложение например Это баг или нет Ну слушай мне поворачивается язык сказать нормальное поведение программа Ну значит бак конечно правильно аствуйте в документации Если даже она есть прямо не написано что приложение на этой странице не должно вылетать тогда это баг или нет если нет такого требования прописанного Ну смотри понимаешь я как бы вживую
00:07:28 - 00:08:53
будущем Когда уже буду работать но я так понимаю что сферации не все может быть описано в принципе да не каждый шаг действия Вот и в этом случае про который ты сказал Конечно то есть там это не описано но по логике конечно не должно вылетать правильно то есть по сути мы можем руководствоваться здравым смыслом пользователя есть такое понятие то есть свои что приложение не должно вылетать даже если это прямо в документации не написано или там документации нет Да если даже есть что допустим есть некоторые вещи как кривой дизайн Да вот
00:08:12 - 00:09:31
и смотришь Ну сайт работает приложение работает но выглядит Ужасно да это относится больше к их тестированию и ты можешь завести баг репорт не отталкиваясь от каких-то допустим строгих требований особенно когда их нет от своего понимания поговорить с командой Что может быть это надо починить так далее и в принципе в реальной жизни Если будешь работать до ближайшее время если ты будешь работать какой-то маленькой команде стартапе и так далее там всегда Беда с требованиями и наверное половина требований о
00:08:51 - 00:09:53
приложении ты как бы генерируешь сам Разумеется В некоторых случаях ты стаканевые штаны заказчиком без аналитиком уточ няешь но часто Даже эти возможности нету И поэтому ты просто идешь от здравого смысла это очень частая история хорошо Какие цели тестирования Ты знаешь Ну вообще может быть их много но самые основные до которые я могу выделить это во-первых сэкономить репутацию компании да то есть компания не упала в грязь лицом во-вторых сэкономить деньги компании и в-третьих это как бы удовлетворить 13
00:09:22 - 00:10:55
пользователей то есть такие цель интересно да классификация принципе меня устраивает хорошо расскажи пожалуйста про виды тестирования которые ты знаешь [музыка] Я может начну не по порядку Но вот все что буду вспоминать говорить во-первых это юньки тестирование это тестирование которое проводится как бы самими разработчиками в момент написания Кода да проверяет какую-то отдельную функциональность кода То есть это да это не работают вот дальше если мы идем по классификации уровней тестирования компоненты
00:10:12 - 00:12:00
компонент на это в принципе все что исходит из самого название дальше что можно еще сказать инновационная тестирование То есть это уже в принципе тестирование каких-то двух компонентов нашего по и соответственно их взаимодействие несколько компонентов и то как Они между собой взаимодействуют также Сюда можно отнести приёмочная тестирование тестирование тоже когда финальный этап Когда уже заказчик сам проверяет приемку вот это то что А да Кстати забыл еще если скин на тестирование это уже Мы Тестируем
00:11:19 - 00:12:40
но понимаю полностью приложение полностью как бы систему может я не прав но вот я просто вспомнил Какое тестирование Да сколько Значит у нас уровне получается тестирование существует Юнит компонентная интеграционная системная приёмочная 5 юниты компонентная это одно и то же 4 Да еще иногда не включает в уровне иногда приёмочные то есть по умолчанию У нас есть компоненты интеграционная системная и иногда приемы зависимости от источника Откуда ты читаешь эту информацию вот так принципе да Окей хорошо
00:12:13 - 00:13:42
Да дальше идем хорошо есть [музыка] позитивная скирование то есть мы проверяем в принципе позитивные сценарии до нашего приложения то есть то как она работают работает при каких-то нормальных условиях То есть то что мы от него ожидаем Вот и негативное тестирование то есть принципе мы уже пытаемся в этом тестировании сломать кавычках приложение и попробовать такое необычное допустим там вводим Поля такое какие-то инъекции делаем Я думаю Какое ожидаемое Поведение у нас в негативных тестах ожидаемое поведение в негативном
00:13:04 - 00:14:38
тестировании какое у нас что мы ожидаем в негативных тестах негативных тестах смотри хорошо если допустим какое-то злоумышленников ведет какую-то там HTML код и он пройдет дальше Да он поймет что допустим есть такая уязвимость допустим дальше может использовать какие-то более так скажем опасные воды до поля каких-то блоков кодов которые допустим повлияет на безопасность системы ожидаемые поведение вот мы пишем на негативный тестовый сценарий что мы ожидаем что система должна сделать в ожидании то что в принципе
00:13:56 - 00:15:19
ожидаем конечно что эти тесты не пройдут Но так уже по факту будет мы получим Вот смотри есть тебе поле логин и пароли ты вводишь неправильный пароль Что ты обычно получаешь вообще проверка на то что система пишет тебе ошибка то что пароль неправильно позитивный или негативный сценарий позитивный Нет это негативный Дело в том что когда ты проверяешь что система что-то пользователю не даст сделать это есть негативный сценарий допустим не дает пользователю войти с неправильным логином или с неправильным паролем
00:14:43 - 00:16:03
ожидаемого поведения такого сценария это показать ошибку или еще в некоторых сервисах ты в принципе пытаешься Когда в поле воду вести какие-то запрещенные символы они вводятся то есть Курсор не двигается и так далее Вот то есть в негативных сценариях мы не просто ломаем систему мы еще пытаемся увидеть что система как правило реагирует нормально на действия пользователей Может ему помочь что-то подсказать что он неправильно что-то вводишь ему надо как-то изменить подход к системе и так далее Вот и сюда не
00:15:28 - 00:16:31
обязательно относить какие-то сложные атаки хакеров и так далее Пожалуйста неправильный ввод данных это и есть негативные сценарий это то как правило что мы в реальной жизни будем использовать чаще всего подожди соответственно в реальной жизни твоими это проблема с интернетом Да Я слышу Ну ты так лагаешь иногда и падает это отключение Окей значит в реальной жизни твоим негативными тестами как правило будут являться типичные ошибки пользователя и в том числе может быть и твои собственные Потому что ты скорее тоже много раз и
00:16:00 - 00:17:20
логин неправильно вводил и пароль и что-нибудь делал на сайте что как бы предположительно сайт говорит что не надо делать Вот и все а какие-то сложные атаки хакеров там с каким-то инъекциями Это уже дело тестировщика безопасности Это другая история совсем хорошо помимо позитивных негативных тестов сценариев что-то еще помнишь конечно же есть автоматизированное тестирование это уже при использовании какого-то скриптов дальше есть такие виды тестирования как smoketest дымное тестирование А саники
00:16:56 - 00:18:18
тестинг ну и регрессионное тестирование так они О чем говорят каждый из этих видов про что смог тестирование мы проводим на начальных этапах скажем Да и проверяем что в принципе наше приложение работает в принципе работает да Саньки тест это мы уже делаем тестирование конкретное какую-то функциональности Вот а регрессивная тестирование такой важный считается что мы проверяем уже старый функциональности системы когда велись новые функциональности то есть между какой-то новой версии промежуточная версия Вот и этот Билд
00:17:43 - 00:19:26
новый выходит А мы должны проверить старый функциональности что можем отказаться от регрессивного тестирования тестирование вообще можем казаться тестирование принципе да Нет вот именно в тестировании Мы хотим чтобы качество у нас там не падало тестирование но при этом у нас существует обстоятельства вот мы же в принципе придумали что у нас есть Смоук ценники нам зачем-то нужна была эта вся структура мы могли без нее просто есть охапка тестов Давайте все проверять А мы вместо этого делим их на три группы которые ты сам только что
00:18:40 - 00:19:50
назвал мы не просто так их делим мы их делим на самом деле по степени важности приоритетности для тестирования мы можем отказаться допустим от регрессии но Смотри мне кажется если Время позволяет точнее точнее если много времени много то можем все проверять самое важное А что для нас самое важное из этих трех ну наверное регрессивно регрессивно самая не важно из этих трех прикол то в том что мы когда работаем Мы выпускаем новый кусочек новый Билл как ты сказал мы там же Лизун какой-то функционал и вот это есть для нас самое
00:19:21 - 00:20:41
важное новый функционал который то что написали Потому что потому что мы его еще ни разу не проверяли это вот свежая что-то а в плане регрессии мы проверяем что все остальное работает то есть мы проверяем тест кейсы которые были написаны когда-то давно в предыдущих операциях разработки И разумеется что шансов найти богов функциональность намного больше чем шанс найти баг в регрессии То есть можно сказать что регрессию часть все проверяет на всякий случай и вот ситуация как-то сказал правильно когда мало времени
00:20:27 - 00:21:35
часто опять же часто истории из реальной практики никакая статья из учебника Вот ты попадешь какой-нибудь стартап Где будут итерации по две недели и тебе надо будет задача за две недели успеть и документацию написать и провести тестирование этой документации и провести в новой фичи и провести регрессию ты скорее всего в конце у тереглись Может быть там ты от нее не полностью откажешься но ты будешь успевать просто по остаточному принципу там типа знаешь день-два осталось до конца Ну давайте что-нибудь успеем
00:21:00 - 00:21:59
проверить Ну разумеется это все обсуждается с руководителем проекты и так далее как правило тебе самому прямо скажут знаешь у нас агрессия Нет ну то есть регрессивный тесты есть но мы не успеваем будешь успевать красавчик не будешь успевать мы не будем тебя за это ругать какие-нибудь еще виды тестирования Да цитирование черного ящика Ну вот Ну и на курсах вообще нам говорили что лучше не упоминать о собеседование тестирование серого ящика Но на самом деле это правда да Потому что потому что во многих
00:21:30 - 00:22:47
источниках его нет также как с асептон с тестированием в уровнях то есть да Юнит интеграционная системная и приёмочная Анатолий есть или нет также с ящиками изначально их было два Потом где-то писали 3 Но не все интервьюеры знают или хотят знать Поэтому иногда достаточно безопасно рассказать два чтобы не рассказывать про серый ящик потому что серия ящик это серая зона про него сложно рассказывать потому что тебе могут спросить Как привести пример а потом скажут что ну это вот не совсем то и все это не знаешь что такое Никто не
00:22:12 - 00:23:27
знает Ну давай про популярный ящики да про какие-то белые черные уже нам известен код программы [музыка] Ну Это если вкратце и понятно Нет это очень вкратце можно вот вот смотри ты в проекте тебе программист показывает код рассказывает как он работает ты после этого становишься тут же тестировщиком белым ящиком или как Да нет мне кажется Слушай ну сказать и рассказать как работает код этого мало Ну пока что ну расскажет Да и что дальше можно с этим кодом работать Да вот и если тестировщик умеет с ним работать да
00:22:50 - 00:24:19
тестирование белого ящика Если он умеет и не знает что за код Ну вот смотри ты тебя взяли на тестировщика ты же говоришь ты питон там учил Да это говорил вот тебе показали код на питоне ты такой Я знаю как этот код работает и в эту секунду ты тут же становишься тестировщиком белого ящик или что-то происходит на самом деле ящики не только про то насколько ты можешь систему погрузиться в понимании ящики это про то что ты покрываешь тестами вот при тестирование белым ящиком ты покрываешь тестами кот
00:23:49 - 00:24:57
это те самые тесты а при тестировании черным ящиком ты покрываешь требованиями покрываешь тестами бизнес-требования То есть как ручной тестировщик ты спецификацию документацию до покрываешь по возможности Вот вот в чем основная разница белый ящик это как правило программисты которые пишут небольшие юниты на свой собственный код а черный ящик от ручной тестировщик который проверяют соответствие требованиям вот а серый ящик это вот очень сложно объяснить но лучше всего объясняется через тестирование 5 через тестирование
00:24:33 - 00:25:43
сервис сервер например то есть ты используешь вот то что ты говорил то что теплоне так далее ты с одной стороны код Back and не читаешь посмом не нужно знать код ты пользуешься протоколом http выбираешь методы адрес тело запросы и получаешь ответ но в то же время ты бизнес требования в этот момент не тестируешь то есть потому что бизнес требованиях указано действие пользователя но пользователь не будет открывать послан и руками кидать запросы таким образом это такой срединное состояние между белым и черным ящиком
00:25:09 - 00:26:19
где-то частично погружен в техническую часть но не совсем вроде как покрываешь тестами техническую сторону а не бизнес сторону но при этом не так что прям на уровне кода юнитов и так далее поэтому это подходит для примера серого ящика Да еще иногда бывает путаницы часто вот что такое стеклянный ящик Ты знаешь то же самое что и все то же самое что и белый потому что изначально не был бы ящика был стеклянный потом его кто-то покрасил в какой-то момент и он начал везде идти как белый но иногда по старинке его
00:25:44 - 00:26:59
называют стеклянным А так это одно и то же так окей какие-нибудь еще так скажем напоследок оставил да то что я функционально не функциональная локализации тестирование инсталляции тестирование что еще Ну и также есть ну давай протестирование то что наше приложение устанавливается еще тестирование инсталляции помимо самого установки еще включает удаление день инсталляция это тоже очень важно и обновление то есть она хоть называется инсталляция на самом деле инсталляция день инсталляция обновления
00:26:22 - 00:27:52
локализация тестирования Что такое локализация это мы уже ныряем то как наше приложение корректно допустим меняет язык меняет формат даты меняет допустим если это интернет-магазин вещей меня и допустим корректно правильный размер обуви Да там евро чтобы нашим пользователям было удобно допустим найти там нужны размер обуви посмотреть корректно язык иногда То есть ты как не будешь правильность перевода проверять но ты можешь работать с таким то есть в крупных продуктовых компаниях есть переводчики штатные и ты вместе с ними
00:27:30 - 00:29:14
работаешь они проверяют правильность языка ты проверяешь многие вещи остальные хорошо прекрасно тестирование что мы проверяем Как работает наше приложение на разных браузерах и на разных устройствах разные устройства это кроссплатформенный вот на разных браузерах помимо помимо помимо производителя браузера что нас еще интересует в браузере помимо того что вот они сами разрешение экрана Ну может быть а еще [музыка] Бразерс меняется еще бывает что кроме названия самого браузера сейчас просто уже реже ты с этим
00:28:25 - 00:29:56
сталкиваешься потому что это все происходит как бы на заднем фоне тебя не спрашивают допустим вы знали пять назад прям регулярно открываешь браузер тебе прям плашка выскакивает хочешь обновиться или нет еще иногда важно проверить на версии То есть у каждого браузера есть еще просто сейчас мы привыкли что браузеры молча обновляются до последней актуальной версии из нашего ведомства но иногда можно попасть на тестирование такого продукта который заточены под конкретной версии конкретного браузера Или под
00:29:16 - 00:30:25
несколько версий хорошо Ладно давай поговорим про техники Test Design знаешь какие-нибудь И зачем вообще Нам нужен тест дизайн [музыка] чего нужно вообще-то такая важная тема То есть это во-первых мы Составляем наш процесс тестирования то есть мы уже выбираем конкретный конкретный способ тестирования чтобы как-то с минимальными затратами времени ухватить большую площадь тестирования это Это интересный подход к этому понятию вообще-то дизайном нужен не для того чтобы площадь тестировать покрытие
00:29:50 - 00:31:24
дизайном нужен чтобы минимальным количеством тест-кейсов покрыть какую-то функциональность тест-дизайн это способ того как мы придумываем наши тестовые сценарии Вот для чего нужен тест дизайна и Ну не совсем площадь не меняется проверки площадью нас одна есть фича какая-то который надо проверить просто мы можем придумать все возможные тестовые сценарии которые на голову приходят А можем применить технику тест дизайна хитрую какой-нибудь из многих и сократить количество наших кейсов чтобы проверить Ту же самую
00:30:40 - 00:32:06
площадь покрытия площадь не меняется меняется количество сценария на одну и ту же площадь И для этого именно и придуманы эти техники потому что можно без техник тестировать Ты просто можешь из головы брать и фигачить но если мы берем техники это помогает тебе самому сократить твою работу если ты там продумаешь вот какой-нибудь из этих вот например их много есть до самые любимые на собеседованиях спрашивают ну и которых принципе будут встречаться тобой в реальной жизни очень много это вот допустим эквивалентное разбиение
00:31:23 - 00:32:32
вот в чем суть такой техники [музыка] разбиваем наши данные какие-то класс примеру если А что это за класса какие-то вот уже у нас есть этот класс мы проверяем допустим Один глаз вот мы разбили дату с какой-то сделали эквивалентное разделение А как Каким образом мы поняли что цифры и СПИД символы в одном классе находятся цифры в одном классе Да но это понимаю что мы сами вправе до выбирать как бы составлять эти классы вставляем разбиение но на чем-то основываемся то есть это они называются классы
00:31:57 - 00:33:26
эквивалентности то есть значение внутри класса должно быть равны Как ты думаешь системе Все равно вводишь ты цифру или спец символ [музыка] Может быть как это относится к тому что кириллицу да кириллица не во всех странах в одном классе ковалентности могут находиться да нет цифры сами по себе это есть класс эквивалентности все цифры друг друга равны спец символы это другой класс эквивалентности система компьютерной цифры СПИД символы одинаково Не отрабатывает это Разные классы но внутри они друг другу эквивалентны то есть
00:33:06 - 00:34:38
система знает что такое цифры но тебе не обязательно проверять все цифры с клавиатуры вот Для чего нужна техника дизайна с классом эквивалентности тебе достаточно вести одну или минимальное значение количество цифр чтобы допустить допустить что они все будут работать одинаково СПИД символы то другой класс эквивалентности ты можешь вести один или несколько СПИД символов и допускаешь что они все будут работать на системой одинаково но цифры спец символы это не одно и то же то же самое с алфавитом
00:34:04 - 00:35:09
есть кириллица допустим да есть латинице Ну там английский алфавитом разные на основании латинского это не один и тот же класс это Разные классы но буквы внутри каждого алфавита вот это вот они равнозначно не эквивалент вот этих классов может быть больше помимо вводных данных например ты тестируешь систему которая принимает какие-то файлы какого-то расширения на фоторедактор ты тестируешь который применяет только файл в таком-то расширении Вот это расширение это тоже будет отдельный класс эквивалентности разного
00:34:37 - 00:35:56
файла разного размера разного содержания но с одним расширением в теории должны системы отрабатываться одинаково Если она принимает решение Вот и этот подход нам позволяет как раз таки сузить количество данных которые мы подаем на вход внутри одного класса и сделать меньше чтобы сэкономить время на тестирование хорошо и техника анализа ограниченных значений можешь про нее рассказать да техника анализа гранично значениях также я могу забегать на перевод сказать что есть да техника попарного разделения
00:35:17 - 00:36:37
не Нам пока про нее не надо нам нужно про анализ граничных значений Слушай ну это уже мы проверяем Начну с того что баки чаще всего встречаются на границе на границе каких-то допустимых недопустимых значений так вот мы уже разделяем какой-то диапазон у нас поле ввода можно водить логин там от 4 до 10 символов да мы уже проверяем то есть минимальная максимальная количество это вводим там 410 и проверяем Три символа и 11 и 9 нам говорили проверять именно почему они говорили ты можешь сказать Почему нам этого не говорили но не знаю
00:35:57 - 00:37:31
как учили нам сказали что достаточно было проверять как раз таки 4 до 4 значения А ты сам подумай вот ты сам Подумай почему вот вот у тебя есть вот тебя взяли тестировать поле вода логина У нас есть требования что логин должен быть не короче 4 символов и не длиннее 10 ты такой вспоминаешь что вот как вас учили ты говоришь и Почему нам достаточно взять два значения внутри интервала Да минимальные максимальные позитивной два значения снаружи интервала Почему у нас допустим отдельно вот эти значения ограничены они
00:36:53 - 00:38:18
как-то отдельно не тестируются Почему мы не берем 5 9 но мне кажется в этом нет Потому что если мы проверяем минимально и максимальное Да количество символов в нашем случае это 310 до если все нормально уходит то какой смысл нам тестировать 49 до все правильно Да так и есть в этом смысла так и есть да то есть это Потому что вот эти значения которые как бы граничные они всегда либо сами входят в интервал либо нет у них не бывает какого-то третьего состояния они либо позитивные в нашем случае либо
00:37:35 - 00:38:46
негативные все это очень часто история на собеседованиях когда начинающие начинают говорить что есть ограниченное значение Значит надо их снаружи проверить и внутри проверить и так проверить очень много кейсов получается но если чуть-чуть размыть логикой то становится понятно хорошо Давай поговорим про тестовую документацию ты говорил что даже имел с ней дело можешь перечислить Какая бывает Ну во-первых введение можно можно без заведения какой-то объем работ во вторых в-третьих уже критерий качества То есть получается что
00:38:11 - 00:39:31
мы будем понимать под качественным продуктом Да дальше [музыка] Какие ресурсы Какой может Какое железо и так далее дальше может описываться также оценка рисков Ну и что еще может быть может быть какие-то еще может быть еще иногда бывает критерии какие-то начало тестирования начала тестирования там есть мы можем выставить какие-то условия после которых мы начинаем непосредственно тестирование мы должны начинать как можно раньше Да вот должны но иногда мы даже не можем начать вот прям ну слишком рано вот
00:39:24 - 00:41:00
что-то нам не хватает там Обычно бывают такие критерии как наличие необходимого железа Вот например ты попадаешь это тоже опять же это будет прям реальная история которая часто происходит Ты попадаешь на проект где есть нативное приложение то есть устанавливается на смартфоны тебе говорят арноль нам Надо протестировать на всех топовых айфонах которые сейчас популярны ты говоришь А мне нету ни одного топового Айфона я вообще на Андроиде сижу откуда у меня топовый iPhone они говорят Правда нам Надо закупить топовый
00:40:39 - 00:41:36
iPhone Вот и только что Обозначил что критерий начала тестирования будет наличие устройств на которых нужно будет протестировать Вот иногда если ты будешь тестировать какую-то сложную систему не просто интернет-магазин А вот что-то ядреное там какой-нибудь банковский сервис который подключается к другому сервису нужна документация там вот ну никак собственно опытом ты нет то же самое ты говоришь пишешь нам обязательно нужно документация по вот этому сервису Иначе мы просто не можем даже начать писать тестовые документацию чек-листы
00:41:15 - 00:42:22
мы не можем слишком сложно еще бывает критерии окончания тестирования тоже соответственно есть ряд критериев Нет это именно критерии окончания то есть при каких условиях мы можем считать что тестирование можно закруглять это не только там как ты говоришь сроки какие-то могут быть другие критерии например что в течение какого-то времени не находится новые баги или что На какой-то момент не будет открытых багов высокого приоритета то есть баги фикс есть они активные но нету открытых критиков менеджеров то есть тех
00:41:48 - 00:43:06
багов которые сильно очень ломают нашу систему и там есть другие следует посмотреть чек-лист Да что это такое Зачем нам нужно Ну чек-лист принципе самого названия исходчик Это проверка лист и это файтане список да то есть получается список проверка чек-лист в основном используют тогда когда мало времени не хватает времени составлять эскиз еще когда по-быстрому Нет ты правильно сказал когда мало времени нам лучше использовать чек-листы потому что с кейс слишком большой физически его долго описывать А как ты
00:42:30 - 00:43:55
думаешь когда еще можно применять Кроме того что вообще не нужны когда нам нужен чек-лист не нужен помимо того что мы ограничены во времени так а со сложностью проекта как это коррелирует сложно если проект то что какой Мы выбираем опять-таки мы приходим ко времени да то есть обязательно во времени нет сложность проекта это правильно но тут дело не во времени А в сложности проверок опять же ты попадаешь на тестирование в банковский проект и тебе надо сделать 25 шагов чтобы что-то узнать И это 25
00:43:20 - 00:44:35
сложных шагов не просто что-то на знает это куда-то зайти что-то настроить что-то перенастроить И ты в чек-листе это не укажешь никак тебе нужен подробный Хороший тест чтобы описать сложную проверку вот если сложных проверок мало или в принципе в текущий момент с ним не работаешь чек-листы подходят лучше если все проверки сложные даже если мало времени все равно придется использовать еще бывает такой критерий как сроки разработки в плане общей длительности проекта то есть тип проекта стартап ты
00:44:19 - 00:45:26
попадаешь стартап Все говорят Мы сегодня начнем И через три месяца закончим то же самое ты понимаешь что дело даже не только в том что там спринты короткие тени когда писать Дело в том что общий проект он скорее Через три месяца провалится Ну может быть нет но чаще Да и тебе нет смысла расписывать ты кейсы потому что ему потом никто не будет пользоваться если проект или еще важный критерий размер команды если вы вас много тестировщиков в одной команде то если каждый будет писать чек-листы они Ну они довольно субъективны и собственно
00:44:55 - 00:46:01
понимание и другие люди могут тяжело их понимать потому что типа пишешь Что проверить что логин работает А как А как что ты допустим для себя знаешь что ты имел в виду а другой тестировщик нет и особенно если тестировщиков много новичков которые ты уже как бы в курсе приложения ты можешь накидать там 15 человек листов чеков чек-листе и для себя принципе понять что-то сам хотел этим сказать но приходит новые новичок стажер Junior не понимает что этим хотел сказать и тем придется объяснять и если ты знаешь что у вас уже
00:45:27 - 00:46:38
будет много И вам придется делиться друг с другом своими тестами сценариями опять же мы стараемся использовать если этого нет Если ты один надолго то используешь чек-листы то есть определенное количество параметров поэтому и в реальной жизни ты будешь реально выбирать В чем хранить свою тестовую документацию хорошо про тест Давай поговорим вот мы обсудили что он большое что он подходит для сложных проверок что он себя включает себя ID номер Дальше он должен включать себя название и название должно быть
00:46:03 - 00:47:13
емким понятным для всех отвечающих на вопросы Что Где Когда дальше какие-то предварительные шаги да могут быть условия это Обычно такие предусловия то есть не указываем как правило Какие шаги должны делать Мы указываем допустим систему мы должны в какое-то состояние хитро перевести браузер может быть открыть режим инкогнито в котором мы проверяем или при загрузить какие-то там настройки на сервер Так что еще Ну если есть то есть что нужно сделать для проверки вот дальше могут быть в тест кейсе описаны данной допустим там ввести логин
00:46:44 - 00:48:11
такой Шаги для воспроизведения мы это называем обычно ожидаем результат ожидаем результатов должны ожидать от этого а потом могут быть прикрепленные там скрины могут быть это правда в некоторых проектах это можно встретить Проблема в том что они быстро устаревают эти дизайны и так далее и их надо будет подкреплять и потом если у тебя там 200 проверок и каждому в общем это отдельная история следует это делать обычно прикрепляем к другого рода документации Хорошо давай поговорим про баг-репорты что это такое Что они себя
00:47:36 - 00:49:01
включают ошибки когда мы нашли Дальше можно написать описание Как прийти к этому Богу дальше В каком проекте это используется точнее в каком порядке имеется воспроизводится бак версию что еще серьезно приоритет шаги Ну и Да еще у нас бывает про что-то говорил когда говорил про тоскейцы это всякие скриншоты скриншоты где там можно указать стрелочки Да что куда именно смотри Да если ссылка была видна Или допустим если скриншот скриншотом мало то какое-то видео А еще есть понятие с кем разговаривать сейчас что
00:48:26 - 00:50:09
он там застрял не застрял вот статус благо бывает еще новый он в работе закрыт и так далее в Это имеется цикл Да да конечно если в идеале то он открыт там в работе справлен и закрыт Это как в идеале Ну да еще бывают разные Вот мы сейчас кстати можем про это как раз поговорить вот представим себе идеальные условия когда ты создал баг-репорт что с ним происходит Дальше Ну я его создаю открываю потом он назначает какого-то разработчика меняется на работе если разработчик если не исправлен если он неисправен
00:50:07 - 00:51:58
[музыка] хорошо Как ты думаешь сколько можно вот так баг между татуировщиком разработчиком он его починил Опять ты перепроверяешь он опять неисправен открыл он опять его чинит и так далее лучше мне кажется не больше одного раза может не проблема как-то странно и нужно нужно лично подойти к разработчику Слушай ну в чем проблема Не трогай Может ты не умеешь отправлять баги вечно мне перенаправляет потом такой Дед сидит 15 лет [музыка] на самом деле пока нету спора То есть пока разработчик признает что
00:51:22 - 00:52:55
действительно бак есть а ты его каждый раз переоткрываешь он говорит Да Правда глянь что-то я там поторопился Да никакой проблемы нет никому не надо подходить все нормально все в рамках систем Все работает бывает сложные баги бывают неопытные разработчик то есть Junior пришел и разработчик пришел который тоже только вчера выучился ну тяжело ему не получается починить он старается может быть он торопится это не страшно проблема в какой момент получается когда в какой-то из итераций разработчики говорит так у меня
00:52:15 - 00:53:17
бак не воспроизводится Я думаю что я его починил что-то ты мне пишешь он воспроизводится я вот с тобой не согласен тут мы начинаем думать что происходит пока он согласен ничего не буду у меня все работает что ты в этой ситуации будешь делать если разработчик говорит что все работает да на тебя выкидает опять говорит все да типа у меня он больше не воспроизводится ты такой проверяешь блин воспроизводится Ну есть он говорит Нет все Ну слушай я обращусь к разработчику скажу Слушай пошли к моему компьютеру покажу на своем
00:52:47 - 00:54:06
компьютере как воспроизводится что меня свой компьютер есть мне вообще на твой компьютеры смотреть не хочу Хорошо тогда в таком случае [музыка] а перед тем как может быть стоит еще что-то проверить Ну если мы говорим реальный бак что это какая-то машинка ты видишь реально показалось что это говорят не бак вот что может быть стоит проверить Прежде чем кому-то идти особенно в распределенной разработке когда разработчик на Таиланде живет прожект менеджер в Канаде А ты там где-нибудь это некуда бывает
00:53:30 - 00:54:45
Нет ты посмотрел все смотри что бывает часто бывает что вы тестируете на разных версиях кода то есть разработчик починил придумал об этом да да а не залил вся пайплайн и этот код просто не прошел никуда То есть ты на старом коде проверяешь это может быть даже не твоя ошибка это его ошибка Но вам просто сравнить версию кода потом надо сравнить версию окружения системы то есть насколько у вас прямо сильно разные системы например ты работаешь на Маке Он работает на винде вот и ты тестируешь Веб на браузере Сафари а он в Хроме
00:54:21 - 00:55:42
кроме работает А в сафари Нет очень много в вебе багов которые относятся к Сафари то есть окружение Вот именно оказывается что браузер специфик так называемый вот эти вещи когда исключаешь и еще надо проверить актуальность требований Бывает такое что ты в свое время еще тест написал по одной версии требования а потом и требования поменяли без твоего ведома Ну ты был в отпуске болел Чего угодно тебе не сказали и разработчик просто написал часть приложения по новым требованиям А ты проверял по старым и
00:55:02 - 00:56:15
иногда стоит просто зайти в требования и посмотреть внимательно что также все осталось может быть у тебя твоя проверка устарела Вот и вот после вот этих трех проверок самопроверг Да ты уже куда-то там можешь идти как правило который спор есть пожалуйста решай На чьей стороне правда вот чё нам с ним делать Вот сразу мы не бежим Хорошо теперь представим ситуацию когда сразу что-то пошло не так то есть ты завел бак он попадает к разработчику но разработчик даже не думают и ученить он тебе ставит какой-то статус типа
00:55:39 - 00:57:02
который обозначает что я не буду с ним ничего делать и бак прилетает к тебе Без фикса какие там могут быть статус что-то может быть примеру что бак может быть отсрочено что он уже важный да на самом деле в реальности в реальности отсроченный такого нет просто ставит низкий приоритет бога Но его никто ни с кого не снимает то есть он остается висит на разработчики А вот прям к тебе возвращается не будет над ним работы Да я понял вопрос то что бакте что не так было написано наверное да еще какие разделе шаги воспроизведение там
00:56:20 - 00:57:41
какая-то была допущена ошибка Да и разработчик не мог у этим шагам которые ему описал Да воспроизвести Баг и он мне его обратно отправил есть такой Canon 3 produce называется статус чаще всего А еще какие бывают случаи дубликат когда-нибудь читал слышал дублика до когда такой бак уже существует как кажется разработчику Да тебе надо первую очередь убедиться что действительно это дубликат он существует потом что с ним делать Вот а бывает еще да бывает статус не буду делать вонду потому что какой часть функциональность Находишь в
00:57:15 - 00:58:44
ней бакте разработчик говорит мы эту часть выпиливаем нет смысла внутри что чинить мы 10 кусок отрежем Вот то же самое уточняешь правда ли это то что разработчику бывает показалось ошибается обидно я нашел бака он как бы да да Ну ничего страшного твоя задача как тестировщика предоставлять информацию а не топить за все баги очень частая ошибка многих джуниоров потому что человек очень сильно привязывается к багам который он завел души за них до последнего вплоть до прямо до какого-то сражения вот а иногда надо
00:58:11 - 00:59:31
просто Шаг в сторону сделать выдохнуть Ну и хрен ничего страшного ладно поговорим про разные виды приложений в Техническом плане вот у нас есть веб-приложение есть нативные приложения может быть есть еще какие-то можешь рассказать про них Как вот они работают в чем особенность их тестирования может быть Ну слушай В чем особенности ты тестирования конечно Может прям не скажу но что из нативные которые соответственно устанавливаются наш компьютер так есть в приложение которое работают из браузера вот ну есть третий
00:58:51 - 01:00:14
вид это гибридные то есть которые принципе сочетают нативные и вы приложение а бывает не сочетают вот с гибридным приложением есть некоторые проблемки Ну ладно мы это может быть обсудим давай с нативных то начнем вот в чем их особенность работы устанавливаются что еще с ними обновляется нужно разрешение пользователя на обновление какая у них подключение интернета нужен для их работы хорошо устанавливается Из каких источников [музыка] а кроме сайта приложения какие еще места бывают это важно для тестирования потому что
00:59:33 - 01:00:55
например если мы в каких-то не просто на сайте выкладываем кое-где еще выкладываем там бывает модерация где у нас будет набираться сторон то есть допустим у нас есть приложение на iPhone мы можем просто на сайте выложить скачать А можем выложить в Apple Store а выпал Store Просто нельзя выложить приложение надо пройти модерацию она не проходится Поэтому если мы будем релизе приложения надо помнить что социальные магазины да да а еще некоторые приложения уже это больше доступно тоже те же нативные
01:00:40 - 01:01:53
устанавливаются с диски с флешки и у тебя есть шанс попасть на тестирование приложений которые устанавливается с внешнего носителя и тут как раз таки инсталляционное тестирование очень важно как ты думаешь Какие виды тестирования важны для нативных учитывая их особенности Ну в принципе большинство видов тестирования важных для Ну какие у тебя ближе Вот мы только что обсудили особенность Вот ты придешь на собеседование Я тебе скажут рекрутер да Или на техническом тебе скажет специалист который говорит Вот ты знаешь
01:01:23 - 01:02:26
мы Тестируем нативное приложение вот у нас нативное приложение такое-то чтобы ты проверял нужно назвать Вот какие тестирования локализации она как правило меньше роль играет потому что все данные они хранятся вместе в телефоне то есть там они никуда не летают как правило особо вот какой-то Ну так это же безопасность операционной системы имеет роль они безопасность нашего конкретного приложения а вот допустим Когда вейп у нас там тестирование безопасности более важно потому что у нас данные наши летают в
01:02:00 - 01:03:09
сервер назад их можно перехватить их можно попробовать как-то воспроизвести и так далее другая история Да хорошо кроссплатформенная вот от железа от мощности зависит работоспособность Да Особенно это касается сложных приложений с 3D там игры какие-нибудь и так далее их надо устанавливать на устройство смотреть что них там не падает FPS еще что-то и вот все хорошо веб-приложение как они работают непосредственно из браузера мы ничего не устанавливаем на компьютер непосредственно с браузер нашего телефона компьютера так установка не
01:02:52 - 01:04:17
требуется обновление требуется разрешение на обновление это же данные обновляется на сервере Ты когда заходил на сайт который просит обновить сайт нет сайт обновляется в тот момент когда страницы подгружаешь мощность железа влияет на веб-приложение правильно Нет ну то есть понятно что современные браузеры много жрут там оперативной памяти еще это Но это особенность именно браузера это не особенности приложения поэтому как в нативных тут не влияет Какой еще кроссбраузерная наверное очень сильно подходит Да потому что браузеров
01:03:36 - 01:04:50
там много они по-разному отрисовывают и есть у нас гибридные Ну вот расскажи Давай про веб еще вот ты говоришь есть связь клиента сервером сейчас на собеседованиях очень любит ковырять эту тему просто вообще без нее жить Нет это вот этот самый взаимодействие вот это все вот можешь рассказать да там Из чего состоит взаимодействие теперь то есть на запрос на сервере есть ответ из чего состоит запрос еще стоит ответа так я могу рассказать про методы Get так методы есть правильно мысль в ту сторону
01:04:29 - 01:05:40
да да и про методы пост а еще какие методы есть самая основная патч хорошо кроме метода что еще в запросе идет на сервер Ты передаешь кроме метода еще какие-то данные сам метод это тип взаимодействия с сервером А что ты еще на сервер идет можно про что вот что голову приходит может быть просто запрос он состоит из определенных элементов метода выбираешь это один из элементов А что еще на сервер передается вместе с методом что у нас люди посмотрят это видео и скажут да что ты не знаешь вот же такие
01:05:20 - 01:06:48
методы Все учатся Все учатся Все нормально Мы тренируемся ну у нас есть адрес запроса да то есть у нас есть так называемый inpoint то есть сайт потом после доменов Конкретно inpoint что еще кроме адреса Юрий так называемая что еще кроме него мы можем отправлять тело есть еще запрос данные в теле указаны данные виде какого-то формата Да там же сон или еще какого-то да вот это тело запроса и ответ нам приходит от сервера после нашего запроса он тоже имеет определенную структуру там что есть статус кода так правильно какие там
01:06:25 - 01:07:51
бывают можешь парочку назвать все твои 200-300 400 500 это какие-то информативная 200 то что все окей Да 300 это перенаправление на другой сервер 400 это ошибка на стороне клиента А 500 на странице отлично супер кроме кодов вот этих что еще может приходить сервере 200 код у нас что все хорошо Да на отработку запрос что мы присылаем Кроме цифры 200 будет ответ Вот видите 200 еще там будет указаны от страницы может приходить наша страница которую браузер читает и рисует перед твоими глазами когда
01:07:25 - 01:09:10
допустим ошибка какая-то то бывает что тела нет запрос не отработан не знаю что прислать на экране браузера 404 написано или там 500 какая-нибудь А если все хорошо Сама страница приходит Окей Ладно про гибридные Да вот в том понимании в котором ты их понимаешь как они работают как бы они как бы совмещают себе нативные и в приложение то есть примеру это какой-то сайт который можем открыть браузера и допустим приложение которое мы можем установить на телефон один ресурс Но между собой соединяют и
01:08:27 - 01:10:01
установку на устройство и именно просмотр через соединяет Что является точкой входа в приложение гибридного в твоем понимании куда мы тыкаем чтобы это приложение открыть браузер или в иконку на странице предложения но входа одна и та же это как правило нативная часть есть такое понимание Как нативный клиент То есть это иконка приложений ты заходишь в него как в нативная но капотом когда ты в него зашел как нативное когда ты по приложению перемещаешься происходит запросы на веб-сервер То есть тебе кажется что ты в нативном
01:09:13 - 01:10:42
приложении но на заднем плане происходит Web взаимодействие на сервак летят запросы и приходит ответы вот магия а внешние Выглядит как будто ты в нативном приложении есть еще почему я говорил да есть проблема с гибридностью в том что не все люди одинаково воспринимают понятия гибридное приложение про помимо вот этого подхода который мы с тобой описали есть еще другие подходы допустим гибридный фреймворки так называемый подход например есть гибридный фреймворк Самарин он работает несколько по-другому
01:10:14 - 01:11:20
и пишется на языке си Sharp а на выходе получается нативные предложения одновременно для Android Хотя если мы писали нативное приложение для Android мы во-первых писали два разных и использовать совершенно другие языки Вот поэтому на собеседении на реальном надо говорить что сейчас наиболее популярность имеет гибридный подход такой что есть клиент нативный и сервер с которым клиент взаимодействует ну и соответственно Какие особенности тестирования такого приложения Как ты думаешь создался я понял
01:10:51 - 01:12:08
Да у меня так начались хорошо пошло Нет уже такой думаю блин оказывается не все знал хорошо ладно мы долго общаемся В принципе можем заканчивать что еще в реальном собеседовании тебя могут спросить вот на текущий момент да могут еще спросить про методологии разработки это все вот эти понятия и могут спросить про базы данных там типа Напишите коротенький запрос или принципе объяснить что такое база данных Как там взаимодействие происходит Да вот и в принципе это все что мне в голову приходит мог спросить что-то совершенно
01:11:42 - 01:13:07
странное Вот Но это уже Я в этом не спец какой-нибудь ересь которую спрашивают редко но метко вот по поводу того что мы сегодня с тобой обсуждали да [музыка] в принципе Что такое тестирование ответил Откуда мы берем тестовую документацию более-менее нормально Да там как мы без документации можем жить и так далее цель тестирования нормалец виды тестирования хорошо что надо повторить что при инсталляционном тестировании у нас значит есть не только установка но и обновление удаление еще про ящики запоминаем что важно не только то
01:12:28 - 01:13:50
насколько Мы погружаемся в систему и что мы Тестируем белый ящик Тестируем код черный ящик Тестируем функциональные бизнес требования смог regression тоже помним Да ты принципе правильно назвал что это важна их приоритетность что иногда мы можем отказаться от регрессии потому что в ней найти шанс бак меньше мы Тестируем новую сеть но если есть время Конечно мы все проверяем в уровнях запоминаем что компонент на июне тестирование это одно и то же интеграционная системная и приёмочная кто-то под вопрос это ставит кто-то не
01:13:12 - 01:14:29
ставит под вопрос но тем не менее техники то есть дизайна Тут надо четко отвечать В первую очередь Зачем они вообще нужны мы сокращаем количество входных вводных параметров при этом не теряем в покрытии тестами приложения вот зачем оно нужно масштабы куда двигаем нет масштабы остаются те же мы просто сокращаем количество эскизов путем какого-то такого определенного подхода к генерации в частности эквивалентно разбиение ограниченные значениях смотрим на клавиатуру и видим что у нас все вводные данные можно
01:13:53 - 01:15:13
примерно разделить по каким-то группам и рассказываем граничное значение правильно сказал хорошо Так дальше по этим самым по типам документации почетче запомню там есть список вопросов Это вообще есть такой сертификация качества есть сертификат 829 там указано список вопросов на которые должен отвечать любой тест-кейс проблема только в том что это было не конкретно про it Ой не тесте план проблема в том что было это в принципе проиндустриальный тест-планы но в принципе ты можешь загуглить где-нибудь
01:14:33 - 01:15:57
типа на какие вопросы должен отвечать хороший тест-план и Перечислить их для себя четко и в частности Привести примеры условий для старта тестирования для окончания критерии критерии начала тестирования критерии окончания Вот чек-лист эскиз более-менее хорошо чуть почетче поля в тесте самое главное начинаешь что шаги есть не условия не как-то еще тоже шаги для воспроизведения steps шаги шаги Вот это важно слово и ожидаемое поведение это самая-самая база А все остальное предусловие пост условия комментарии еще ID тут самый могут быть
01:15:20 - 01:16:46
могут не быть без них становится совсем плохим А вот без шагов ожидаемого поведения его быть не может баг-репорт принципе хорошо назвал забыл пару полей про автора про то на кого засанено так далее тоже надо повторить вот Ну а дальше все плохо дальше виды приложений есть правильно ты назвал веб нативные гибридные про гибридные это может чуть подробнее почитать нативный в принципе более-менее хорошо назвал просто очень полезно опять же это не какая-то теория непонятно Вот ты придешь на реальный собеса тебе
01:16:09 - 01:17:26
скажут как бы ты протестировал наше предложение но такое и если ты будешь хорошо разбираться в этих трех видах ты будешь понимать как их лучше тестировать и ты сможешь без вникания в детали Что конкретно у них за приложение Что конкретно ты просто они тебе говорят у нас сайт как бы ты наша и ты уже знаешь заранее что сайт это значит кроссбраузерная сайт это значит тестировать на интернет на плохом качестве интернета на отвал сайты для сайтов не нужно много железок то есть вот эти вот вещи вот для себя определить
01:16:52 - 01:17:57
Ну и мысль не поговорили но Повтори про всякие ватерфоллы от джайлы скромные комбайны вот собственно список замечаний Я думаю у тебя есть теперь почва для того чтобы улучшить свои знания и попробовать на реальных собеса походить класс Спасибо таким вопросы остались еще нет Окей хорошо Тогда готовься старайся все получится Спасибо пожалуйста Арнольд тогда все тогда давай пока Ну как вам Арнольд показал знания практически по всем вопросам которые ему задал но очень сильно не хватало глубины знания Надеюсь
01:17:23 - 01:18:59
теперь у него есть почва для подготовки он повторит все вопросы которые были не очень хорошо изучены и на реальном собеседовании он уже сможет показать глубину всех своих знаний Конечно стоит учитывать что он изучает тестирование меньше месяца Поэтому в принципе сегодняшний опыт был первым для него и я думаю что каждый следующий будет для него только лучше Спасибо за то что смотрели сегодняшний ролик Если вы хотите поучаствовать в подобном собеседовании переходите По ссылкам внизу в описании ролика можете
01:18:18 - 01:19:56
записаться на подобное собеседование либо на приватное собеседование которое не будет выложено в YouTube всего хорошего пока [музыка]
[музыка] Всем привет У нас сегодня новое собеседование на Junior Key с нами сегодня Арнольд который в кратчайшие сроки выучил определенный объем теории тестирования и хочет проверить свои знания Ну что же Давайте смотреть Итак всем привет С нами сегодня Арнольд Расскажи пожалуйста что хочешь о себе чего-то ожидаешь от нашего созвона а вообще хочу проверить уровень своих знаний и Вот потому что изучают тестирование довольно таки недавно буквально полторы недели вот то есть две недели назад и ничего не знал про
00:00:00 - 00:01:27
тестирование вообще ничего вот Начал вы изучать сам Точнее по курсам по курсам которые мне посоветовали друзья Вот и дошел до какой-то точки что принципе я всю теорию до которую можно которая была на курсах Я выучил вот также я работал в постмоне сдавал запросы Вот и принципе вот на этом все а какой-нибудь тест документацию составлял там чек-листы вставлял чек-листы составлял То есть это все было по программе курса Хорошо Ну тогда начнем с общих вопросов и немножко такое отступление сделаю так я
00:00:50 - 00:02:17
все наверное удивляться тестирование очень короткое время Вот поэтому я буду пытаться на твои вопросы отвечать а не прям скажем по учебникам да то есть у меня знания не заученные до терминов то есть пытаться отвечать как-то В принципе немножко даже своими словами Это нормально Арнольд У меня тоже знания не заучены у меня знания из моего рабочего опыта и когда я собеседую в компанию в которой работаю для меня не главное сравнить значит учебник и то что ты знаешь для меня лично главное понять Какое будущее работник будет на работе
00:01:37 - 00:02:51
да что он с чем он справится с чем Он не справится то есть для меня не так важно прям четкие определения важно понимание Так что я думаю все у нас получится хорошо начнем с общих вопросов Расскажи пожалуйста что такое тестирование Ну вообще есть много определений этому Да термину но как я понимаю тестирование Другими словами это проверка то есть мы что-то проверяем То есть у нас есть какой-то результат которого мы ожидаем и какой-то результат который мы получаем и вот сравнивать два эти результаты мы
00:02:14 - 00:03:22
имеем какое-то вот представление о том что мы Тестируем Да будь то это по будь то это вообще что будь то велосипед образно хорошо мы соотносим результат и ожидаемый вот мы хорошо представим что мы тестирование велосипед И как ты думаешь для тестирования по ожидаем результат Где мы можем взять ожидаем результат Да ну ты говоришь мы Тестируем фактическое поведение Да с чем что мы хотим увидеть то что мы хотим увидеть Откуда мы получаем информацию значит в нашей команде по идее так скажем лучше так скажем образе должен
00:02:49 - 00:04:12
быть Project Manager Так мы должны попросить его его взять эту спецификацию у заказчика и попросить предоставьте нам как тестировщиком как наша команде эту спецификацию чтобы мы уже исходя из неё начинали тестировать продукт вот отличный план А ты знаешь есть еще один член команды которые за спецификацию отвечает Project менеджер может так сделать как-то сказал это в принципе вариант но часто еще выделяют отдельное человека который прям отвечает именно за документацию знаешь я слышал только Проджект
00:03:43 - 00:05:02
менеджера Но если кто-то еще есть я Ну Пальцем в небо Может бизнес-аналитик есть такая отдельная профессия тоже в крупных компаниях крупных проектах бывает в маленьких не бывает Но тем не менее Если есть возможность обращаясь со в первую очередь к нему вот Project менеджер именно управлением проектом занимается обычно более Ну хорошо так спецификации допустим нет я не могу тебе помочь в принципе нет его Да в команде Ну значит включаем логику нашего мышления Мы что все-таки работаем войти сфере Да и должны как-то пользоваться в
00:04:22 - 00:05:48
том числе логикой нашей Да вот и что это я подразумеваю под логикой то есть мы осмотрим на продукты наших конкурентов да то есть продукт создаем там не знаю продукт примеру там приложение по прогнозу погоды Вот Мы открываем какие-то сторонние приложения Смотрим как у них и уже исходя из этого мы сами Составляем сертификацию и уже пользуемся вот данными конкурентов так если конкурентов нет Или допустим ты не знаком с конкурентов нет Ну слушай тогда получается уникальный продукт которому нет аналогов Да и тогда
00:05:12 - 00:06:35
мы уже подходим к доске там виртуальные или физической составляет сами чем хотим уникальный продукт Конечно мы можем что мы можем сами даже что-то придумать От чего мы можем оттолкнуться еще конкурентов нет Или допустим вот этого куска конкурентов Нет без аналитика нет менеджер не может помочь выхода на заказчика Нет спецификации нет что у нас остается но мне кажется есть два момента от которых можем утолкнуться во-первых наш бюджет сколько у нас денег во вторых во вторых это какой-то временной промежуток то есть не можем
00:05:54 - 00:07:13
создавать год-два Да мы уже исходим из нашего бюджета и заливного промежутка А и исходим из того из потребности наших как бы будущих пользователей наших клиентов Вот смотри ты тестируешь приложение Просто представь себе ты веб-сайт ковыряешь и страница на веб-сайде неожиданно схлопывается и вылетает допустим данные не сохраняются на странице это баг лопается Нажимаешь кнопку и у тебя там не знаю дизайн съезжает во все стороны и все все данные исчезают или ты допустим Ну да вот визуальной частью тебя там
00:06:34 - 00:08:10
элементы перемешиваются все И ты запутываешься или у тебя нативное приложение на телефоне ты переходишь на каком-нибудь экран она у тебя Ну сворачивается исчезает вылетает приложение например Это баг или нет Ну слушай мне поворачивается язык сказать нормальное поведение программа Ну значит бак конечно правильно аствуйте в документации Если даже она есть прямо не написано что приложение на этой странице не должно вылетать тогда это баг или нет если нет такого требования прописанного Ну смотри понимаешь я как бы вживую
00:07:28 - 00:08:53
будущем Когда уже буду работать но я так понимаю что сферации не все может быть описано в принципе да не каждый шаг действия Вот и в этом случае про который ты сказал Конечно то есть там это не описано но по логике конечно не должно вылетать правильно то есть по сути мы можем руководствоваться здравым смыслом пользователя есть такое понятие то есть свои что приложение не должно вылетать даже если это прямо в документации не написано или там документации нет Да если даже есть что допустим есть некоторые вещи как кривой дизайн Да вот
00:08:12 - 00:09:31
и смотришь Ну сайт работает приложение работает но выглядит Ужасно да это относится больше к их тестированию и ты можешь завести баг репорт не отталкиваясь от каких-то допустим строгих требований особенно когда их нет от своего понимания поговорить с командой Что может быть это надо починить так далее и в принципе в реальной жизни Если будешь работать до ближайшее время если ты будешь работать какой-то маленькой команде стартапе и так далее там всегда Беда с требованиями и наверное половина требований о
00:08:51 - 00:09:53
приложении ты как бы генерируешь сам Разумеется В некоторых случаях ты стаканевые штаны заказчиком без аналитиком уточ няешь но часто Даже эти возможности нету И поэтому ты просто идешь от здравого смысла это очень частая история хорошо Какие цели тестирования Ты знаешь Ну вообще может быть их много но самые основные до которые я могу выделить это во-первых сэкономить репутацию компании да то есть компания не упала в грязь лицом во-вторых сэкономить деньги компании и в-третьих это как бы удовлетворить 13
00:09:22 - 00:10:55
пользователей то есть такие цель интересно да классификация принципе меня устраивает хорошо расскажи пожалуйста про виды тестирования которые ты знаешь [музыка] Я может начну не по порядку Но вот все что буду вспоминать говорить во-первых это юньки тестирование это тестирование которое проводится как бы самими разработчиками в момент написания Кода да проверяет какую-то отдельную функциональность кода То есть это да это не работают вот дальше если мы идем по классификации уровней тестирования компоненты
00:10:12 - 00:12:00
компонент на это в принципе все что исходит из самого название дальше что можно еще сказать инновационная тестирование То есть это уже в принципе тестирование каких-то двух компонентов нашего по и соответственно их взаимодействие несколько компонентов и то как Они между собой взаимодействуют также Сюда можно отнести приёмочная тестирование тестирование тоже когда финальный этап Когда уже заказчик сам проверяет приемку вот это то что А да Кстати забыл еще если скин на тестирование это уже Мы Тестируем
00:11:19 - 00:12:40
но понимаю полностью приложение полностью как бы систему может я не прав но вот я просто вспомнил Какое тестирование Да сколько Значит у нас уровне получается тестирование существует Юнит компонентная интеграционная системная приёмочная 5 юниты компонентная это одно и то же 4 Да еще иногда не включает в уровне иногда приёмочные то есть по умолчанию У нас есть компоненты интеграционная системная и иногда приемы зависимости от источника Откуда ты читаешь эту информацию вот так принципе да Окей хорошо
00:12:13 - 00:13:42
Да дальше идем хорошо есть [музыка] позитивная скирование то есть мы проверяем в принципе позитивные сценарии до нашего приложения то есть то как она работают работает при каких-то нормальных условиях То есть то что мы от него ожидаем Вот и негативное тестирование то есть принципе мы уже пытаемся в этом тестировании сломать кавычках приложение и попробовать такое необычное допустим там вводим Поля такое какие-то инъекции делаем Я думаю Какое ожидаемое Поведение у нас в негативных тестах ожидаемое поведение в негативном
00:13:04 - 00:14:38
тестировании какое у нас что мы ожидаем в негативных тестах негативных тестах смотри хорошо если допустим какое-то злоумышленников ведет какую-то там HTML код и он пройдет дальше Да он поймет что допустим есть такая уязвимость допустим дальше может использовать какие-то более так скажем опасные воды до поля каких-то блоков кодов которые допустим повлияет на безопасность системы ожидаемые поведение вот мы пишем на негативный тестовый сценарий что мы ожидаем что система должна сделать в ожидании то что в принципе
00:13:56 - 00:15:19
ожидаем конечно что эти тесты не пройдут Но так уже по факту будет мы получим Вот смотри есть тебе поле логин и пароли ты вводишь неправильный пароль Что ты обычно получаешь вообще проверка на то что система пишет тебе ошибка то что пароль неправильно позитивный или негативный сценарий позитивный Нет это негативный Дело в том что когда ты проверяешь что система что-то пользователю не даст сделать это есть негативный сценарий допустим не дает пользователю войти с неправильным логином или с неправильным паролем
00:14:43 - 00:16:03
ожидаемого поведения такого сценария это показать ошибку или еще в некоторых сервисах ты в принципе пытаешься Когда в поле воду вести какие-то запрещенные символы они вводятся то есть Курсор не двигается и так далее Вот то есть в негативных сценариях мы не просто ломаем систему мы еще пытаемся увидеть что система как правило реагирует нормально на действия пользователей Может ему помочь что-то подсказать что он неправильно что-то вводишь ему надо как-то изменить подход к системе и так далее Вот и сюда не
00:15:28 - 00:16:31
обязательно относить какие-то сложные атаки хакеров и так далее Пожалуйста неправильный ввод данных это и есть негативные сценарий это то как правило что мы в реальной жизни будем использовать чаще всего подожди соответственно в реальной жизни твоими это проблема с интернетом Да Я слышу Ну ты так лагаешь иногда и падает это отключение Окей значит в реальной жизни твоим негативными тестами как правило будут являться типичные ошибки пользователя и в том числе может быть и твои собственные Потому что ты скорее тоже много раз и
00:16:00 - 00:17:20
логин неправильно вводил и пароль и что-нибудь делал на сайте что как бы предположительно сайт говорит что не надо делать Вот и все а какие-то сложные атаки хакеров там с каким-то инъекциями Это уже дело тестировщика безопасности Это другая история совсем хорошо помимо позитивных негативных тестов сценариев что-то еще помнишь конечно же есть автоматизированное тестирование это уже при использовании какого-то скриптов дальше есть такие виды тестирования как smoketest дымное тестирование А саники
00:16:56 - 00:18:18
тестинг ну и регрессионное тестирование так они О чем говорят каждый из этих видов про что смог тестирование мы проводим на начальных этапах скажем Да и проверяем что в принципе наше приложение работает в принципе работает да Саньки тест это мы уже делаем тестирование конкретное какую-то функциональности Вот а регрессивная тестирование такой важный считается что мы проверяем уже старый функциональности системы когда велись новые функциональности то есть между какой-то новой версии промежуточная версия Вот и этот Билд
00:17:43 - 00:19:26
новый выходит А мы должны проверить старый функциональности что можем отказаться от регрессивного тестирования тестирование вообще можем казаться тестирование принципе да Нет вот именно в тестировании Мы хотим чтобы качество у нас там не падало тестирование но при этом у нас существует обстоятельства вот мы же в принципе придумали что у нас есть Смоук ценники нам зачем-то нужна была эта вся структура мы могли без нее просто есть охапка тестов Давайте все проверять А мы вместо этого делим их на три группы которые ты сам только что
00:18:40 - 00:19:50
назвал мы не просто так их делим мы их делим на самом деле по степени важности приоритетности для тестирования мы можем отказаться допустим от регрессии но Смотри мне кажется если Время позволяет точнее точнее если много времени много то можем все проверять самое важное А что для нас самое важное из этих трех ну наверное регрессивно регрессивно самая не важно из этих трех прикол то в том что мы когда работаем Мы выпускаем новый кусочек новый Билл как ты сказал мы там же Лизун какой-то функционал и вот это есть для нас самое
00:19:21 - 00:20:41
важное новый функционал который то что написали Потому что потому что мы его еще ни разу не проверяли это вот свежая что-то а в плане регрессии мы проверяем что все остальное работает то есть мы проверяем тест кейсы которые были написаны когда-то давно в предыдущих операциях разработки И разумеется что шансов найти богов функциональность намного больше чем шанс найти баг в регрессии То есть можно сказать что регрессию часть все проверяет на всякий случай и вот ситуация как-то сказал правильно когда мало времени
00:20:27 - 00:21:35
часто опять же часто истории из реальной практики никакая статья из учебника Вот ты попадешь какой-нибудь стартап Где будут итерации по две недели и тебе надо будет задача за две недели успеть и документацию написать и провести тестирование этой документации и провести в новой фичи и провести регрессию ты скорее всего в конце у тереглись Может быть там ты от нее не полностью откажешься но ты будешь успевать просто по остаточному принципу там типа знаешь день-два осталось до конца Ну давайте что-нибудь успеем
00:21:00 - 00:21:59
проверить Ну разумеется это все обсуждается с руководителем проекты и так далее как правило тебе самому прямо скажут знаешь у нас агрессия Нет ну то есть регрессивный тесты есть но мы не успеваем будешь успевать красавчик не будешь успевать мы не будем тебя за это ругать какие-нибудь еще виды тестирования Да цитирование черного ящика Ну вот Ну и на курсах вообще нам говорили что лучше не упоминать о собеседование тестирование серого ящика Но на самом деле это правда да Потому что потому что во многих
00:21:30 - 00:22:47
источниках его нет также как с асептон с тестированием в уровнях то есть да Юнит интеграционная системная и приёмочная Анатолий есть или нет также с ящиками изначально их было два Потом где-то писали 3 Но не все интервьюеры знают или хотят знать Поэтому иногда достаточно безопасно рассказать два чтобы не рассказывать про серый ящик потому что серия ящик это серая зона про него сложно рассказывать потому что тебе могут спросить Как привести пример а потом скажут что ну это вот не совсем то и все это не знаешь что такое Никто не
00:22:12 - 00:23:27
знает Ну давай про популярный ящики да про какие-то белые черные уже нам известен код программы [музыка] Ну Это если вкратце и понятно Нет это очень вкратце можно вот вот смотри ты в проекте тебе программист показывает код рассказывает как он работает ты после этого становишься тут же тестировщиком белым ящиком или как Да нет мне кажется Слушай ну сказать и рассказать как работает код этого мало Ну пока что ну расскажет Да и что дальше можно с этим кодом работать Да вот и если тестировщик умеет с ним работать да
00:22:50 - 00:24:19
тестирование белого ящика Если он умеет и не знает что за код Ну вот смотри ты тебя взяли на тестировщика ты же говоришь ты питон там учил Да это говорил вот тебе показали код на питоне ты такой Я знаю как этот код работает и в эту секунду ты тут же становишься тестировщиком белого ящик или что-то происходит на самом деле ящики не только про то насколько ты можешь систему погрузиться в понимании ящики это про то что ты покрываешь тестами вот при тестирование белым ящиком ты покрываешь тестами кот
00:23:49 - 00:24:57
это те самые тесты а при тестировании черным ящиком ты покрываешь требованиями покрываешь тестами бизнес-требования То есть как ручной тестировщик ты спецификацию документацию до покрываешь по возможности Вот вот в чем основная разница белый ящик это как правило программисты которые пишут небольшие юниты на свой собственный код а черный ящик от ручной тестировщик который проверяют соответствие требованиям вот а серый ящик это вот очень сложно объяснить но лучше всего объясняется через тестирование 5 через тестирование
00:24:33 - 00:25:43
сервис сервер например то есть ты используешь вот то что ты говорил то что теплоне так далее ты с одной стороны код Back and не читаешь посмом не нужно знать код ты пользуешься протоколом http выбираешь методы адрес тело запросы и получаешь ответ но в то же время ты бизнес требования в этот момент не тестируешь то есть потому что бизнес требованиях указано действие пользователя но пользователь не будет открывать послан и руками кидать запросы таким образом это такой срединное состояние между белым и черным ящиком
00:25:09 - 00:26:19
где-то частично погружен в техническую часть но не совсем вроде как покрываешь тестами техническую сторону а не бизнес сторону но при этом не так что прям на уровне кода юнитов и так далее поэтому это подходит для примера серого ящика Да еще иногда бывает путаницы часто вот что такое стеклянный ящик Ты знаешь то же самое что и все то же самое что и белый потому что изначально не был бы ящика был стеклянный потом его кто-то покрасил в какой-то момент и он начал везде идти как белый но иногда по старинке его
00:25:44 - 00:26:59
называют стеклянным А так это одно и то же так окей какие-нибудь еще так скажем напоследок оставил да то что я функционально не функциональная локализации тестирование инсталляции тестирование что еще Ну и также есть ну давай протестирование то что наше приложение устанавливается еще тестирование инсталляции помимо самого установки еще включает удаление день инсталляция это тоже очень важно и обновление то есть она хоть называется инсталляция на самом деле инсталляция день инсталляция обновления
00:26:22 - 00:27:52
локализация тестирования Что такое локализация это мы уже ныряем то как наше приложение корректно допустим меняет язык меняет формат даты меняет допустим если это интернет-магазин вещей меня и допустим корректно правильный размер обуви Да там евро чтобы нашим пользователям было удобно допустим найти там нужны размер обуви посмотреть корректно язык иногда То есть ты как не будешь правильность перевода проверять но ты можешь работать с таким то есть в крупных продуктовых компаниях есть переводчики штатные и ты вместе с ними
00:27:30 - 00:29:14
работаешь они проверяют правильность языка ты проверяешь многие вещи остальные хорошо прекрасно тестирование что мы проверяем Как работает наше приложение на разных браузерах и на разных устройствах разные устройства это кроссплатформенный вот на разных браузерах помимо помимо помимо производителя браузера что нас еще интересует в браузере помимо того что вот они сами разрешение экрана Ну может быть а еще [музыка] Бразерс меняется еще бывает что кроме названия самого браузера сейчас просто уже реже ты с этим
00:28:25 - 00:29:56
сталкиваешься потому что это все происходит как бы на заднем фоне тебя не спрашивают допустим вы знали пять назад прям регулярно открываешь браузер тебе прям плашка выскакивает хочешь обновиться или нет еще иногда важно проверить на версии То есть у каждого браузера есть еще просто сейчас мы привыкли что браузеры молча обновляются до последней актуальной версии из нашего ведомства но иногда можно попасть на тестирование такого продукта который заточены под конкретной версии конкретного браузера Или под
00:29:16 - 00:30:25
несколько версий хорошо Ладно давай поговорим про техники Test Design знаешь какие-нибудь И зачем вообще Нам нужен тест дизайн [музыка] чего нужно вообще-то такая важная тема То есть это во-первых мы Составляем наш процесс тестирования то есть мы уже выбираем конкретный конкретный способ тестирования чтобы как-то с минимальными затратами времени ухватить большую площадь тестирования это Это интересный подход к этому понятию вообще-то дизайном нужен не для того чтобы площадь тестировать покрытие
00:29:50 - 00:31:24
дизайном нужен чтобы минимальным количеством тест-кейсов покрыть какую-то функциональность тест-дизайн это способ того как мы придумываем наши тестовые сценарии Вот для чего нужен тест дизайна и Ну не совсем площадь не меняется проверки площадью нас одна есть фича какая-то который надо проверить просто мы можем придумать все возможные тестовые сценарии которые на голову приходят А можем применить технику тест дизайна хитрую какой-нибудь из многих и сократить количество наших кейсов чтобы проверить Ту же самую
00:30:40 - 00:32:06
площадь покрытия площадь не меняется меняется количество сценария на одну и ту же площадь И для этого именно и придуманы эти техники потому что можно без техник тестировать Ты просто можешь из головы брать и фигачить но если мы берем техники это помогает тебе самому сократить твою работу если ты там продумаешь вот какой-нибудь из этих вот например их много есть до самые любимые на собеседованиях спрашивают ну и которых принципе будут встречаться тобой в реальной жизни очень много это вот допустим эквивалентное разбиение
00:31:23 - 00:32:32
вот в чем суть такой техники [музыка] разбиваем наши данные какие-то класс примеру если А что это за класса какие-то вот уже у нас есть этот класс мы проверяем допустим Один глаз вот мы разбили дату с какой-то сделали эквивалентное разделение А как Каким образом мы поняли что цифры и СПИД символы в одном классе находятся цифры в одном классе Да но это понимаю что мы сами вправе до выбирать как бы составлять эти классы вставляем разбиение но на чем-то основываемся то есть это они называются классы
00:31:57 - 00:33:26
эквивалентности то есть значение внутри класса должно быть равны Как ты думаешь системе Все равно вводишь ты цифру или спец символ [музыка] Может быть как это относится к тому что кириллицу да кириллица не во всех странах в одном классе ковалентности могут находиться да нет цифры сами по себе это есть класс эквивалентности все цифры друг друга равны спец символы это другой класс эквивалентности система компьютерной цифры СПИД символы одинаково Не отрабатывает это Разные классы но внутри они друг другу эквивалентны то есть
00:33:06 - 00:34:38
система знает что такое цифры но тебе не обязательно проверять все цифры с клавиатуры вот Для чего нужна техника дизайна с классом эквивалентности тебе достаточно вести одну или минимальное значение количество цифр чтобы допустить допустить что они все будут работать одинаково СПИД символы то другой класс эквивалентности ты можешь вести один или несколько СПИД символов и допускаешь что они все будут работать на системой одинаково но цифры спец символы это не одно и то же то же самое с алфавитом
00:34:04 - 00:35:09
есть кириллица допустим да есть латинице Ну там английский алфавитом разные на основании латинского это не один и тот же класс это Разные классы но буквы внутри каждого алфавита вот это вот они равнозначно не эквивалент вот этих классов может быть больше помимо вводных данных например ты тестируешь систему которая принимает какие-то файлы какого-то расширения на фоторедактор ты тестируешь который применяет только файл в таком-то расширении Вот это расширение это тоже будет отдельный класс эквивалентности разного
00:34:37 - 00:35:56
файла разного размера разного содержания но с одним расширением в теории должны системы отрабатываться одинаково Если она принимает решение Вот и этот подход нам позволяет как раз таки сузить количество данных которые мы подаем на вход внутри одного класса и сделать меньше чтобы сэкономить время на тестирование хорошо и техника анализа ограниченных значений можешь про нее рассказать да техника анализа гранично значениях также я могу забегать на перевод сказать что есть да техника попарного разделения
00:35:17 - 00:36:37
не Нам пока про нее не надо нам нужно про анализ граничных значений Слушай ну это уже мы проверяем Начну с того что баки чаще всего встречаются на границе на границе каких-то допустимых недопустимых значений так вот мы уже разделяем какой-то диапазон у нас поле ввода можно водить логин там от 4 до 10 символов да мы уже проверяем то есть минимальная максимальная количество это вводим там 410 и проверяем Три символа и 11 и 9 нам говорили проверять именно почему они говорили ты можешь сказать Почему нам этого не говорили но не знаю
00:35:57 - 00:37:31
как учили нам сказали что достаточно было проверять как раз таки 4 до 4 значения А ты сам подумай вот ты сам Подумай почему вот вот у тебя есть вот тебя взяли тестировать поле вода логина У нас есть требования что логин должен быть не короче 4 символов и не длиннее 10 ты такой вспоминаешь что вот как вас учили ты говоришь и Почему нам достаточно взять два значения внутри интервала Да минимальные максимальные позитивной два значения снаружи интервала Почему у нас допустим отдельно вот эти значения ограничены они
00:36:53 - 00:38:18
как-то отдельно не тестируются Почему мы не берем 5 9 но мне кажется в этом нет Потому что если мы проверяем минимально и максимальное Да количество символов в нашем случае это 310 до если все нормально уходит то какой смысл нам тестировать 49 до все правильно Да так и есть в этом смысла так и есть да то есть это Потому что вот эти значения которые как бы граничные они всегда либо сами входят в интервал либо нет у них не бывает какого-то третьего состояния они либо позитивные в нашем случае либо
00:37:35 - 00:38:46
негативные все это очень часто история на собеседованиях когда начинающие начинают говорить что есть ограниченное значение Значит надо их снаружи проверить и внутри проверить и так проверить очень много кейсов получается но если чуть-чуть размыть логикой то становится понятно хорошо Давай поговорим про тестовую документацию ты говорил что даже имел с ней дело можешь перечислить Какая бывает Ну во-первых введение можно можно без заведения какой-то объем работ во вторых в-третьих уже критерий качества То есть получается что
00:38:11 - 00:39:31
мы будем понимать под качественным продуктом Да дальше [музыка] Какие ресурсы Какой может Какое железо и так далее дальше может описываться также оценка рисков Ну и что еще может быть может быть какие-то еще может быть еще иногда бывает критерии какие-то начало тестирования начала тестирования там есть мы можем выставить какие-то условия после которых мы начинаем непосредственно тестирование мы должны начинать как можно раньше Да вот должны но иногда мы даже не можем начать вот прям ну слишком рано вот
00:39:24 - 00:41:00
что-то нам не хватает там Обычно бывают такие критерии как наличие необходимого железа Вот например ты попадаешь это тоже опять же это будет прям реальная история которая часто происходит Ты попадаешь на проект где есть нативное приложение то есть устанавливается на смартфоны тебе говорят арноль нам Надо протестировать на всех топовых айфонах которые сейчас популярны ты говоришь А мне нету ни одного топового Айфона я вообще на Андроиде сижу откуда у меня топовый iPhone они говорят Правда нам Надо закупить топовый
00:40:39 - 00:41:36
iPhone Вот и только что Обозначил что критерий начала тестирования будет наличие устройств на которых нужно будет протестировать Вот иногда если ты будешь тестировать какую-то сложную систему не просто интернет-магазин А вот что-то ядреное там какой-нибудь банковский сервис который подключается к другому сервису нужна документация там вот ну никак собственно опытом ты нет то же самое ты говоришь пишешь нам обязательно нужно документация по вот этому сервису Иначе мы просто не можем даже начать писать тестовые документацию чек-листы
00:41:15 - 00:42:22
мы не можем слишком сложно еще бывает критерии окончания тестирования тоже соответственно есть ряд критериев Нет это именно критерии окончания то есть при каких условиях мы можем считать что тестирование можно закруглять это не только там как ты говоришь сроки какие-то могут быть другие критерии например что в течение какого-то времени не находится новые баги или что На какой-то момент не будет открытых багов высокого приоритета то есть баги фикс есть они активные но нету открытых критиков менеджеров то есть тех
00:41:48 - 00:43:06
багов которые сильно очень ломают нашу систему и там есть другие следует посмотреть чек-лист Да что это такое Зачем нам нужно Ну чек-лист принципе самого названия исходчик Это проверка лист и это файтане список да то есть получается список проверка чек-лист в основном используют тогда когда мало времени не хватает времени составлять эскиз еще когда по-быстрому Нет ты правильно сказал когда мало времени нам лучше использовать чек-листы потому что с кейс слишком большой физически его долго описывать А как ты
00:42:30 - 00:43:55
думаешь когда еще можно применять Кроме того что вообще не нужны когда нам нужен чек-лист не нужен помимо того что мы ограничены во времени так а со сложностью проекта как это коррелирует сложно если проект то что какой Мы выбираем опять-таки мы приходим ко времени да то есть обязательно во времени нет сложность проекта это правильно но тут дело не во времени А в сложности проверок опять же ты попадаешь на тестирование в банковский проект и тебе надо сделать 25 шагов чтобы что-то узнать И это 25
00:43:20 - 00:44:35
сложных шагов не просто что-то на знает это куда-то зайти что-то настроить что-то перенастроить И ты в чек-листе это не укажешь никак тебе нужен подробный Хороший тест чтобы описать сложную проверку вот если сложных проверок мало или в принципе в текущий момент с ним не работаешь чек-листы подходят лучше если все проверки сложные даже если мало времени все равно придется использовать еще бывает такой критерий как сроки разработки в плане общей длительности проекта то есть тип проекта стартап ты
00:44:19 - 00:45:26
попадаешь стартап Все говорят Мы сегодня начнем И через три месяца закончим то же самое ты понимаешь что дело даже не только в том что там спринты короткие тени когда писать Дело в том что общий проект он скорее Через три месяца провалится Ну может быть нет но чаще Да и тебе нет смысла расписывать ты кейсы потому что ему потом никто не будет пользоваться если проект или еще важный критерий размер команды если вы вас много тестировщиков в одной команде то если каждый будет писать чек-листы они Ну они довольно субъективны и собственно
00:44:55 - 00:46:01
понимание и другие люди могут тяжело их понимать потому что типа пишешь Что проверить что логин работает А как А как что ты допустим для себя знаешь что ты имел в виду а другой тестировщик нет и особенно если тестировщиков много новичков которые ты уже как бы в курсе приложения ты можешь накидать там 15 человек листов чеков чек-листе и для себя принципе понять что-то сам хотел этим сказать но приходит новые новичок стажер Junior не понимает что этим хотел сказать и тем придется объяснять и если ты знаешь что у вас уже
00:45:27 - 00:46:38
будет много И вам придется делиться друг с другом своими тестами сценариями опять же мы стараемся использовать если этого нет Если ты один надолго то используешь чек-листы то есть определенное количество параметров поэтому и в реальной жизни ты будешь реально выбирать В чем хранить свою тестовую документацию хорошо про тест Давай поговорим вот мы обсудили что он большое что он подходит для сложных проверок что он себя включает себя ID номер Дальше он должен включать себя название и название должно быть
00:46:03 - 00:47:13
емким понятным для всех отвечающих на вопросы Что Где Когда дальше какие-то предварительные шаги да могут быть условия это Обычно такие предусловия то есть не указываем как правило Какие шаги должны делать Мы указываем допустим систему мы должны в какое-то состояние хитро перевести браузер может быть открыть режим инкогнито в котором мы проверяем или при загрузить какие-то там настройки на сервер Так что еще Ну если есть то есть что нужно сделать для проверки вот дальше могут быть в тест кейсе описаны данной допустим там ввести логин
00:46:44 - 00:48:11
такой Шаги для воспроизведения мы это называем обычно ожидаем результат ожидаем результатов должны ожидать от этого а потом могут быть прикрепленные там скрины могут быть это правда в некоторых проектах это можно встретить Проблема в том что они быстро устаревают эти дизайны и так далее и их надо будет подкреплять и потом если у тебя там 200 проверок и каждому в общем это отдельная история следует это делать обычно прикрепляем к другого рода документации Хорошо давай поговорим про баг-репорты что это такое Что они себя
00:47:36 - 00:49:01
включают ошибки когда мы нашли Дальше можно написать описание Как прийти к этому Богу дальше В каком проекте это используется точнее в каком порядке имеется воспроизводится бак версию что еще серьезно приоритет шаги Ну и Да еще у нас бывает про что-то говорил когда говорил про тоскейцы это всякие скриншоты скриншоты где там можно указать стрелочки Да что куда именно смотри Да если ссылка была видна Или допустим если скриншот скриншотом мало то какое-то видео А еще есть понятие с кем разговаривать сейчас что
00:48:26 - 00:50:09
он там застрял не застрял вот статус благо бывает еще новый он в работе закрыт и так далее в Это имеется цикл Да да конечно если в идеале то он открыт там в работе справлен и закрыт Это как в идеале Ну да еще бывают разные Вот мы сейчас кстати можем про это как раз поговорить вот представим себе идеальные условия когда ты создал баг-репорт что с ним происходит Дальше Ну я его создаю открываю потом он назначает какого-то разработчика меняется на работе если разработчик если не исправлен если он неисправен
00:50:07 - 00:51:58
[музыка] хорошо Как ты думаешь сколько можно вот так баг между татуировщиком разработчиком он его починил Опять ты перепроверяешь он опять неисправен открыл он опять его чинит и так далее лучше мне кажется не больше одного раза может не проблема как-то странно и нужно нужно лично подойти к разработчику Слушай ну в чем проблема Не трогай Может ты не умеешь отправлять баги вечно мне перенаправляет потом такой Дед сидит 15 лет [музыка] на самом деле пока нету спора То есть пока разработчик признает что
00:51:22 - 00:52:55
действительно бак есть а ты его каждый раз переоткрываешь он говорит Да Правда глянь что-то я там поторопился Да никакой проблемы нет никому не надо подходить все нормально все в рамках систем Все работает бывает сложные баги бывают неопытные разработчик то есть Junior пришел и разработчик пришел который тоже только вчера выучился ну тяжело ему не получается починить он старается может быть он торопится это не страшно проблема в какой момент получается когда в какой-то из итераций разработчики говорит так у меня
00:52:15 - 00:53:17
бак не воспроизводится Я думаю что я его починил что-то ты мне пишешь он воспроизводится я вот с тобой не согласен тут мы начинаем думать что происходит пока он согласен ничего не буду у меня все работает что ты в этой ситуации будешь делать если разработчик говорит что все работает да на тебя выкидает опять говорит все да типа у меня он больше не воспроизводится ты такой проверяешь блин воспроизводится Ну есть он говорит Нет все Ну слушай я обращусь к разработчику скажу Слушай пошли к моему компьютеру покажу на своем
00:52:47 - 00:54:06
компьютере как воспроизводится что меня свой компьютер есть мне вообще на твой компьютеры смотреть не хочу Хорошо тогда в таком случае [музыка] а перед тем как может быть стоит еще что-то проверить Ну если мы говорим реальный бак что это какая-то машинка ты видишь реально показалось что это говорят не бак вот что может быть стоит проверить Прежде чем кому-то идти особенно в распределенной разработке когда разработчик на Таиланде живет прожект менеджер в Канаде А ты там где-нибудь это некуда бывает
00:53:30 - 00:54:45
Нет ты посмотрел все смотри что бывает часто бывает что вы тестируете на разных версиях кода то есть разработчик починил придумал об этом да да а не залил вся пайплайн и этот код просто не прошел никуда То есть ты на старом коде проверяешь это может быть даже не твоя ошибка это его ошибка Но вам просто сравнить версию кода потом надо сравнить версию окружения системы то есть насколько у вас прямо сильно разные системы например ты работаешь на Маке Он работает на винде вот и ты тестируешь Веб на браузере Сафари а он в Хроме
00:54:21 - 00:55:42
кроме работает А в сафари Нет очень много в вебе багов которые относятся к Сафари то есть окружение Вот именно оказывается что браузер специфик так называемый вот эти вещи когда исключаешь и еще надо проверить актуальность требований Бывает такое что ты в свое время еще тест написал по одной версии требования а потом и требования поменяли без твоего ведома Ну ты был в отпуске болел Чего угодно тебе не сказали и разработчик просто написал часть приложения по новым требованиям А ты проверял по старым и
00:55:02 - 00:56:15
иногда стоит просто зайти в требования и посмотреть внимательно что также все осталось может быть у тебя твоя проверка устарела Вот и вот после вот этих трех проверок самопроверг Да ты уже куда-то там можешь идти как правило который спор есть пожалуйста решай На чьей стороне правда вот чё нам с ним делать Вот сразу мы не бежим Хорошо теперь представим ситуацию когда сразу что-то пошло не так то есть ты завел бак он попадает к разработчику но разработчик даже не думают и ученить он тебе ставит какой-то статус типа
00:55:39 - 00:57:02
который обозначает что я не буду с ним ничего делать и бак прилетает к тебе Без фикса какие там могут быть статус что-то может быть примеру что бак может быть отсрочено что он уже важный да на самом деле в реальности в реальности отсроченный такого нет просто ставит низкий приоритет бога Но его никто ни с кого не снимает то есть он остается висит на разработчики А вот прям к тебе возвращается не будет над ним работы Да я понял вопрос то что бакте что не так было написано наверное да еще какие разделе шаги воспроизведение там
00:56:20 - 00:57:41
какая-то была допущена ошибка Да и разработчик не мог у этим шагам которые ему описал Да воспроизвести Баг и он мне его обратно отправил есть такой Canon 3 produce называется статус чаще всего А еще какие бывают случаи дубликат когда-нибудь читал слышал дублика до когда такой бак уже существует как кажется разработчику Да тебе надо первую очередь убедиться что действительно это дубликат он существует потом что с ним делать Вот а бывает еще да бывает статус не буду делать вонду потому что какой часть функциональность Находишь в
00:57:15 - 00:58:44
ней бакте разработчик говорит мы эту часть выпиливаем нет смысла внутри что чинить мы 10 кусок отрежем Вот то же самое уточняешь правда ли это то что разработчику бывает показалось ошибается обидно я нашел бака он как бы да да Ну ничего страшного твоя задача как тестировщика предоставлять информацию а не топить за все баги очень частая ошибка многих джуниоров потому что человек очень сильно привязывается к багам который он завел души за них до последнего вплоть до прямо до какого-то сражения вот а иногда надо
00:58:11 - 00:59:31
просто Шаг в сторону сделать выдохнуть Ну и хрен ничего страшного ладно поговорим про разные виды приложений в Техническом плане вот у нас есть веб-приложение есть нативные приложения может быть есть еще какие-то можешь рассказать про них Как вот они работают в чем особенность их тестирования может быть Ну слушай В чем особенности ты тестирования конечно Может прям не скажу но что из нативные которые соответственно устанавливаются наш компьютер так есть в приложение которое работают из браузера вот ну есть третий
00:58:51 - 01:00:14
вид это гибридные то есть которые принципе сочетают нативные и вы приложение а бывает не сочетают вот с гибридным приложением есть некоторые проблемки Ну ладно мы это может быть обсудим давай с нативных то начнем вот в чем их особенность работы устанавливаются что еще с ними обновляется нужно разрешение пользователя на обновление какая у них подключение интернета нужен для их работы хорошо устанавливается Из каких источников [музыка] а кроме сайта приложения какие еще места бывают это важно для тестирования потому что
00:59:33 - 01:00:55
например если мы в каких-то не просто на сайте выкладываем кое-где еще выкладываем там бывает модерация где у нас будет набираться сторон то есть допустим у нас есть приложение на iPhone мы можем просто на сайте выложить скачать А можем выложить в Apple Store а выпал Store Просто нельзя выложить приложение надо пройти модерацию она не проходится Поэтому если мы будем релизе приложения надо помнить что социальные магазины да да а еще некоторые приложения уже это больше доступно тоже те же нативные
01:00:40 - 01:01:53
устанавливаются с диски с флешки и у тебя есть шанс попасть на тестирование приложений которые устанавливается с внешнего носителя и тут как раз таки инсталляционное тестирование очень важно как ты думаешь Какие виды тестирования важны для нативных учитывая их особенности Ну в принципе большинство видов тестирования важных для Ну какие у тебя ближе Вот мы только что обсудили особенность Вот ты придешь на собеседование Я тебе скажут рекрутер да Или на техническом тебе скажет специалист который говорит Вот ты знаешь
01:01:23 - 01:02:26
мы Тестируем нативное приложение вот у нас нативное приложение такое-то чтобы ты проверял нужно назвать Вот какие тестирования локализации она как правило меньше роль играет потому что все данные они хранятся вместе в телефоне то есть там они никуда не летают как правило особо вот какой-то Ну так это же безопасность операционной системы имеет роль они безопасность нашего конкретного приложения а вот допустим Когда вейп у нас там тестирование безопасности более важно потому что у нас данные наши летают в
01:02:00 - 01:03:09
сервер назад их можно перехватить их можно попробовать как-то воспроизвести и так далее другая история Да хорошо кроссплатформенная вот от железа от мощности зависит работоспособность Да Особенно это касается сложных приложений с 3D там игры какие-нибудь и так далее их надо устанавливать на устройство смотреть что них там не падает FPS еще что-то и вот все хорошо веб-приложение как они работают непосредственно из браузера мы ничего не устанавливаем на компьютер непосредственно с браузер нашего телефона компьютера так установка не
01:02:52 - 01:04:17
требуется обновление требуется разрешение на обновление это же данные обновляется на сервере Ты когда заходил на сайт который просит обновить сайт нет сайт обновляется в тот момент когда страницы подгружаешь мощность железа влияет на веб-приложение правильно Нет ну то есть понятно что современные браузеры много жрут там оперативной памяти еще это Но это особенность именно браузера это не особенности приложения поэтому как в нативных тут не влияет Какой еще кроссбраузерная наверное очень сильно подходит Да потому что браузеров
01:03:36 - 01:04:50
там много они по-разному отрисовывают и есть у нас гибридные Ну вот расскажи Давай про веб еще вот ты говоришь есть связь клиента сервером сейчас на собеседованиях очень любит ковырять эту тему просто вообще без нее жить Нет это вот этот самый взаимодействие вот это все вот можешь рассказать да там Из чего состоит взаимодействие теперь то есть на запрос на сервере есть ответ из чего состоит запрос еще стоит ответа так я могу рассказать про методы Get так методы есть правильно мысль в ту сторону
01:04:29 - 01:05:40
да да и про методы пост а еще какие методы есть самая основная патч хорошо кроме метода что еще в запросе идет на сервер Ты передаешь кроме метода еще какие-то данные сам метод это тип взаимодействия с сервером А что ты еще на сервер идет можно про что вот что голову приходит может быть просто запрос он состоит из определенных элементов метода выбираешь это один из элементов А что еще на сервер передается вместе с методом что у нас люди посмотрят это видео и скажут да что ты не знаешь вот же такие
01:05:20 - 01:06:48
методы Все учатся Все учатся Все нормально Мы тренируемся ну у нас есть адрес запроса да то есть у нас есть так называемый inpoint то есть сайт потом после доменов Конкретно inpoint что еще кроме адреса Юрий так называемая что еще кроме него мы можем отправлять тело есть еще запрос данные в теле указаны данные виде какого-то формата Да там же сон или еще какого-то да вот это тело запроса и ответ нам приходит от сервера после нашего запроса он тоже имеет определенную структуру там что есть статус кода так правильно какие там
01:06:25 - 01:07:51
бывают можешь парочку назвать все твои 200-300 400 500 это какие-то информативная 200 то что все окей Да 300 это перенаправление на другой сервер 400 это ошибка на стороне клиента А 500 на странице отлично супер кроме кодов вот этих что еще может приходить сервере 200 код у нас что все хорошо Да на отработку запрос что мы присылаем Кроме цифры 200 будет ответ Вот видите 200 еще там будет указаны от страницы может приходить наша страница которую браузер читает и рисует перед твоими глазами когда
01:07:25 - 01:09:10
допустим ошибка какая-то то бывает что тела нет запрос не отработан не знаю что прислать на экране браузера 404 написано или там 500 какая-нибудь А если все хорошо Сама страница приходит Окей Ладно про гибридные Да вот в том понимании в котором ты их понимаешь как они работают как бы они как бы совмещают себе нативные и в приложение то есть примеру это какой-то сайт который можем открыть браузера и допустим приложение которое мы можем установить на телефон один ресурс Но между собой соединяют и
01:08:27 - 01:10:01
установку на устройство и именно просмотр через соединяет Что является точкой входа в приложение гибридного в твоем понимании куда мы тыкаем чтобы это приложение открыть браузер или в иконку на странице предложения но входа одна и та же это как правило нативная часть есть такое понимание Как нативный клиент То есть это иконка приложений ты заходишь в него как в нативная но капотом когда ты в него зашел как нативное когда ты по приложению перемещаешься происходит запросы на веб-сервер То есть тебе кажется что ты в нативном
01:09:13 - 01:10:42
приложении но на заднем плане происходит Web взаимодействие на сервак летят запросы и приходит ответы вот магия а внешние Выглядит как будто ты в нативном приложении есть еще почему я говорил да есть проблема с гибридностью в том что не все люди одинаково воспринимают понятия гибридное приложение про помимо вот этого подхода который мы с тобой описали есть еще другие подходы допустим гибридный фреймворки так называемый подход например есть гибридный фреймворк Самарин он работает несколько по-другому
01:10:14 - 01:11:20
и пишется на языке си Sharp а на выходе получается нативные предложения одновременно для Android Хотя если мы писали нативное приложение для Android мы во-первых писали два разных и использовать совершенно другие языки Вот поэтому на собеседении на реальном надо говорить что сейчас наиболее популярность имеет гибридный подход такой что есть клиент нативный и сервер с которым клиент взаимодействует ну и соответственно Какие особенности тестирования такого приложения Как ты думаешь создался я понял
01:10:51 - 01:12:08
Да у меня так начались хорошо пошло Нет уже такой думаю блин оказывается не все знал хорошо ладно мы долго общаемся В принципе можем заканчивать что еще в реальном собеседовании тебя могут спросить вот на текущий момент да могут еще спросить про методологии разработки это все вот эти понятия и могут спросить про базы данных там типа Напишите коротенький запрос или принципе объяснить что такое база данных Как там взаимодействие происходит Да вот и в принципе это все что мне в голову приходит мог спросить что-то совершенно
01:11:42 - 01:13:07
странное Вот Но это уже Я в этом не спец какой-нибудь ересь которую спрашивают редко но метко вот по поводу того что мы сегодня с тобой обсуждали да [музыка] в принципе Что такое тестирование ответил Откуда мы берем тестовую документацию более-менее нормально Да там как мы без документации можем жить и так далее цель тестирования нормалец виды тестирования хорошо что надо повторить что при инсталляционном тестировании у нас значит есть не только установка но и обновление удаление еще про ящики запоминаем что важно не только то
01:12:28 - 01:13:50
насколько Мы погружаемся в систему и что мы Тестируем белый ящик Тестируем код черный ящик Тестируем функциональные бизнес требования смог regression тоже помним Да ты принципе правильно назвал что это важна их приоритетность что иногда мы можем отказаться от регрессии потому что в ней найти шанс бак меньше мы Тестируем новую сеть но если есть время Конечно мы все проверяем в уровнях запоминаем что компонент на июне тестирование это одно и то же интеграционная системная и приёмочная кто-то под вопрос это ставит кто-то не
01:13:12 - 01:14:29
ставит под вопрос но тем не менее техники то есть дизайна Тут надо четко отвечать В первую очередь Зачем они вообще нужны мы сокращаем количество входных вводных параметров при этом не теряем в покрытии тестами приложения вот зачем оно нужно масштабы куда двигаем нет масштабы остаются те же мы просто сокращаем количество эскизов путем какого-то такого определенного подхода к генерации в частности эквивалентно разбиение ограниченные значениях смотрим на клавиатуру и видим что у нас все вводные данные можно
01:13:53 - 01:15:13
примерно разделить по каким-то группам и рассказываем граничное значение правильно сказал хорошо Так дальше по этим самым по типам документации почетче запомню там есть список вопросов Это вообще есть такой сертификация качества есть сертификат 829 там указано список вопросов на которые должен отвечать любой тест-кейс проблема только в том что это было не конкретно про it Ой не тесте план проблема в том что было это в принципе проиндустриальный тест-планы но в принципе ты можешь загуглить где-нибудь
01:14:33 - 01:15:57
типа на какие вопросы должен отвечать хороший тест-план и Перечислить их для себя четко и в частности Привести примеры условий для старта тестирования для окончания критерии критерии начала тестирования критерии окончания Вот чек-лист эскиз более-менее хорошо чуть почетче поля в тесте самое главное начинаешь что шаги есть не условия не как-то еще тоже шаги для воспроизведения steps шаги шаги Вот это важно слово и ожидаемое поведение это самая-самая база А все остальное предусловие пост условия комментарии еще ID тут самый могут быть
01:15:20 - 01:16:46
могут не быть без них становится совсем плохим А вот без шагов ожидаемого поведения его быть не может баг-репорт принципе хорошо назвал забыл пару полей про автора про то на кого засанено так далее тоже надо повторить вот Ну а дальше все плохо дальше виды приложений есть правильно ты назвал веб нативные гибридные про гибридные это может чуть подробнее почитать нативный в принципе более-менее хорошо назвал просто очень полезно опять же это не какая-то теория непонятно Вот ты придешь на реальный собеса тебе
01:16:09 - 01:17:26
скажут как бы ты протестировал наше предложение но такое и если ты будешь хорошо разбираться в этих трех видах ты будешь понимать как их лучше тестировать и ты сможешь без вникания в детали Что конкретно у них за приложение Что конкретно ты просто они тебе говорят у нас сайт как бы ты наша и ты уже знаешь заранее что сайт это значит кроссбраузерная сайт это значит тестировать на интернет на плохом качестве интернета на отвал сайты для сайтов не нужно много железок то есть вот эти вот вещи вот для себя определить
01:16:52 - 01:17:57
Ну и мысль не поговорили но Повтори про всякие ватерфоллы от джайлы скромные комбайны вот собственно список замечаний Я думаю у тебя есть теперь почва для того чтобы улучшить свои знания и попробовать на реальных собеса походить класс Спасибо таким вопросы остались еще нет Окей хорошо Тогда готовься старайся все получится Спасибо пожалуйста Арнольд тогда все тогда давай пока Ну как вам Арнольд показал знания практически по всем вопросам которые ему задал но очень сильно не хватало глубины знания Надеюсь
01:17:23 - 01:18:59
теперь у него есть почва для подготовки он повторит все вопросы которые были не очень хорошо изучены и на реальном собеседовании он уже сможет показать глубину всех своих знаний Конечно стоит учитывать что он изучает тестирование меньше месяца Поэтому в принципе сегодняшний опыт был первым для него и я думаю что каждый следующий будет для него только лучше Спасибо за то что смотрели сегодняшний ролик Если вы хотите поучаствовать в подобном собеседовании переходите По ссылкам внизу в описании ролика можете
01:18:18 - 01:19:56
записаться на подобное собеседование либо на приватное собеседование которое не будет выложено в YouTube всего хорошего пока [музыка]
01:19:06 - 01:19:43