[музыка] Всем привет У нас сегодня новое собеседование на Junior Kay с нами сегодня Александр он идет интересным путем пытается одновременно устроиться на ручного тестировщика и на автоматизатора оба Junior в любом случае для обеих специальностей потребуется знание теории тестирования которая и для ручных тестировщиков и для автоматизаторов в принципе идентичны поэтому смотрим видос Итак привет Александр расскажи пожалуйста чуть-чуть про себя чего бы ты хотел о себе узнать какой у тебя опыт тестирования
00:00:01 - 00:01:37
предыдущего если есть или обучение может где-то учился зовут Меня Александр Мне 26 лет в конце прошлого года завершил обучение по направлению автоматизация тестирования на языке программирования поэтому Вот соответственно хочу пройти собеседование на позицию мануального тестировщика Джуниора вот опыта коммерческого не имею только вот тестовый тестовый проектор Окей понятно Хорошо смотри в принципе если ты вдруг соберёшься где-то проходить собеседение на именно Junior автоматизатора от начинающего Да там обычно собеседование
00:00:53 - 00:02:31
состоит из трех частей Первое это часть которая касается общей теории тестирования это то о чем мы сегодня в принципе поговорим по сути мануально датировщика та же самая теория потом у тебя будет часть вторая третья беседование это будет именно вопросы по базам твоего языка программирования который ты выбрал твоем случае питон Да может быть или какой-то еще и третья часть обычно на таких собеседований это вопросы по непосредственно технологии авто тестирования То есть например если ты выбрал там селение мапиум
00:01:42 - 00:02:53
библиотеки для того чтобы тестировать через ЮА тебя будут спрашивать по ним там да какие там особенности Какие основные команды если будет какой-нибудь Другое Другая технология тебя по ней будут спрашивать просто чтобы ты знал что ждать на автоматизаторы и соответственно особенностями будет являться то что обычно собеседование будет где-то час идти и поэтому каждый из этих блоков будет довольно короткий И в частности вот этот блок который будет про теорию тестирования он будет прям совсем обычно сжатый То есть
00:02:18 - 00:03:21
автоматизаторов если ты видишь как автоматизатор Ну минут 20 по каким-то самым базовым вещам спрашивать в то же время если ты пойдешь каким-то причинам на ручное тестирование это будет по сути все собеседование вот эта часть вот как у нас будет и сегодня просто чтобы понимать Хорошо давай тогда поговорим про тестирование Расскажи пожалуйста что такое тестирование тестирование это процесс исследования программного продукта целью которого является соответствие проверка соответствия между ожидаемым поведением программ и
00:02:50 - 00:04:06
фактически где мы выявляем ожидаемое поведение Откуда мы выберем из требований а если нет требований Ну значит на основе пользовательского опыта возможно требования к другим проектам То есть если были другие проекты схожие можно взять требования с этих проектов [музыка] а если не было схожих проектов вот ты как Junior пришел Ты еще не тестировал никогда подобные проекты первый раз и требования нет что тогда будем делать Ну на основе пользовательского опыта хорошо то есть примерно понимаем как например
00:03:28 - 00:04:56
работает интернет-магазин Что там примерно должно быть и вот на основе этих знаний будем тестировать отлично супер Кто у нас является источниками если у нас есть документация допустим плохая у кого можем уточнить какие-то вопросы менеджер может быть а еще У нас есть еще иногда бывает не всегда но бывает отдельная должность которая отвечает за древний бизнес-аналитик не везде в крупной компании будет в маленькой не будет И опять же зачастую У нас есть иногда не всегда иногда есть выход на самого
00:04:12 - 00:05:38
заказчика то есть в некоторых небольших проектах заказчик же является и project-менеджером то есть грубо говоря либо у Project менеджера есть там письмо и он может сказать так некогда сейчас что-то выяснять вот почта заказчик сказал он ответит На любые вопросы если что и ты получается как бы пишешь заказчик говоришь что там на вас работаем типа у нас непонятка Да как мы это вопрос реализуем Какие цели тестирования Ты знаешь тестирование Ну проверка соответствия вот то что как бы сказал основная цель
00:05:03 - 00:06:19
а другие какими знаешь Ну я знаю принцип и тестирования это не то же самое ну пускай будет то же самое Расскажи про принципы Ну во-первых исчерпывающее тестирование невозможно то есть мы должны понимать что все протестировать принципе нереально все комбинации все Точнее то как может повести себя пользователь первый принцип второй принцип тестирования демонстрирует наличие дефектов они их отсутствие То есть если приложение протестировано это не значит что в нем нет дефектов как бы дефекты в любом случае могут быть
00:05:49 - 00:07:11
они скорее всего будут так ранее еще один принцип это ранее тестирование сохраняет время и деньги Чем раньше мы начнем тестировать тем соответственно сэкономим скорее всего время разработчиков которые потратят меньше на устранение дефекта ну и соответственно деньги еще один принцип это скопление дефектов и к примеру если в каком-то модуле найдено два дефекта а в другом модуле 5 то скорее всего там где 5 Будут еще найдены ошибки то есть вот такой принцип Ну и Парадокс пестицида Да это как Что означает что нужно
00:06:34 - 00:08:18
со временем менять свои тест кейсы вот читал в интернете такой пример как это как травят паразитов и они со временем адаптируются к отравили И вот так же примерно И тут со временем либо это должен писать эскиз другой человек чтобы посмотреть на ситуацию с другой стороны и был другой набор тестов ну в принципе верно не совсем только тот для того чтобы бороться с парадоксом пестицида нужно не тест ты там менять их вот а внутри теста как правило менять данные на вход то есть с пестицидами проблем не в том что Жуки привыкают ко
00:07:28 - 00:08:50
всем пестицидам привыкают к конкретному Поэтому иногда следует в шагах указывать например нечёткие шаги например вот мы Тестируем логин и пароль вот логин и пароли и мы можем в тесте написать вести админ поле пароль поле логина да А можем написать вести валидное поле логина и пароля таким образом каждый следующий раз когда тестировщик один или будет несколько человек будет проходить этот кейс он может писать что-то разное В поле логин и пароли Главное чтобы он был валидный то чтобы система принималась вот о чём э
00:08:10 - 00:09:16
Парадокс с пестициды в первую очередь о том чтобы текст тесты сделать иногда чуть менее подробными для того чтобы вот эта ситуация избежать хорошо Это были принципы не цели но тоже очень правильно сказано в принципе всё верно вот можешь себе пометить что есть еще цели тестирование есть несколько классификаций в них Обычно по три цели выделяется у разных авторов по-разному Выбери какой тебе понравится и на всякий случай Изучи могут на собеседование спросить и лучше их ответить простые там обычно например там
00:08:43 - 00:10:03
предоставление информации о качестве продукта выявление багов непосредственно и допустим проверка что выполняется все цели и сроки разработки да то есть ты как бы не только качество конечного продукта подтверждаешь но и контролируешь что ваш процесс разработки не буксует вот собственно Вот например ну бывает и другие классификации этих целей просто где-нибудь Какие проще такие выучить хорошо виды тестирования Какие тестирования это знаешь функциональные не функциональные их Также можно подразделять на
00:09:23 - 00:10:49
тестирование по степени автоматизации по позитивности сценария по доступу коду тестирование производительности нагрузочное тестирование тестирование локализации тестирования удобства пользования регрессионное тестирование Smoke тестирование ценники тестирование [музыка] Хорошо хорошо безопасности нагрузочное тестирование на самом деле нагрузочное тестирование это одно из видов тестирования производительности Ну да и там еще несколько есть вот поэтому тут Аккуратнее лучше просто мне производительность если будут подробно
00:10:08 - 00:11:38
спрашивать что там конкретно нагрузочная и стрессовая есть еще какой-нибудь Хорошо давай про там тестирование локализации что тестирование локализации входит смена перевод языка во-первых далее Возможно это перевод единиц валюты это ростовки если это может быть какой-то магазин размеры обуви там европейские корейские там какие там есть разные это формат даты формат времени [музыка] тестирование инсталляции она проводится на нативных приложениях проверяется установка удаление обновления отлично супер
00:10:55 - 00:12:51
разноцветные ящики знаешь про них что-нибудь Да есть черный ящик белый ящик серый ящик это наш доступ коду метод белого ящика это мы имеем доступ к коду и как сказать это тестирование Юнит тестирование да то есть это вот что тестирует приемник тестирование [музыка] [смех] Но это [музыка] как языка отдельный класс требованием Отлично так черный ящик у нас черный ящик подразумевает что мы не имеем доступа к коду или Тестируем как конечно пользователь тестами мы покрываем что функционал бизнес требования бизнес
00:12:04 - 00:14:07
требования так хорошо а серый ящик серый ящик это пограничное такое то есть мы понимаем Как устроена как работает система но в то же время доступа к коду не имеем Ну понятие размыто и на самом деле в разных источниках все это пишется по-разному но [музыка] как это применить на практике я сидел думал мне показалось что можно сюда отнести например тестирование баз данных то есть мы понимаем как это все устроено но как бы как-то так чаще лучше Привести примеры может быть а допустим тестирование может привязан быть базы данных может не
00:13:21 - 00:15:04
привязанность когда на запросы ответа запрос отправляем руками Пишем да и получаем ответ тогда получается что мы вроде как и не бизнес логика Тестируем мы все-таки внутри под капотом уже запрос руками пишем но при этом мы не знаем как работает наша база данных читать кот и не покрываем про стеклянный ящик слышал когда Нет это то же самое что и белый изначально литературе называлась стеклянный иногда на собеседование говорят стеклянный чтоб ты не потерялся стеклянный белый ящик это одно и то же хорошо
00:14:14 - 00:15:35
так про автоматизированное тестирование в принципе в общем можешь рассказать чем она от ручного отличается Ну мы пишем тесты на языке программирования которые запускаются там внутри запускаешь они проводят автоматически тестирование То есть это при написанных уже тестах сокращает время и наиболее нами применимо Это революционных тестах где мы уже все в принципе вручную проверили и чтобы по сто раз при добавлении нового функционала нам не проверяет и вручную вот создают автоматизацию здесь можно Можно также при тестировании API
00:14:59 - 00:16:32
Да это можно всякие части в постные запускать в виде авто тестов хорошо хорошо негативный тест сценарий подразумевает собой то что программа правильно отреагирует на попытку на попытку неправильного действия пользователя то есть не что программа подразумевает собой что пользователь может повести себя как-то некорректно и программа должна на это правильно отреагировать что у нас обычно ожидаемое поведение в негативных тестах какая Так сейчас я но мы пытаемся сломать систему она этого не дает А что она что она делает когда
00:15:47 - 00:17:25
ошибку Ошибку бывает еще допустим кроме ошибки какая реакция систем например сейчас принято в некоторых сервисах просто не давать тебе сделать физически что-то например ты вводишь поле ввода русские буквы система принимает только английский и ты просто нажимаешь на клавиатуру ничем не заполняется ошибки нет но и ничего не происходит есть у нас еще такая градация как статическая динамическое тестирование о чем это статическое тестирование это тестирование туда можно отнести тестирование требований можно
00:16:52 - 00:18:13
аналитическое это уже соответственно непосредственно функционала в чем разница с разные виды можно провести туда туда в чем граница находится наверное что мы не при статическом и наверное не пользуемся самим приложением мы запускаем код основная разница Хорошо Окей Ты говорил про Цените смогли грешен там применительно к автоматизации можешь принципе рассказать про эти три вида тестирования тестирование это набор минимальных тестов направленных на проверку основного функционала программного обеспечения
00:17:42 - 00:19:14
Цените тестирование это углубленное тестирование какого-то определенного функционала а регрессионное но это мы предъявляем то что новый функционал не сломал наши старые функции которые были так и есть можем мы без какого-то из этих видов тестирования в принципе существовать отказаться от него допустим в какой-то момент но Оцените явно мы не можем Но регрессивная наверное потому что оно когда-то было Цените скорее всего и оно уже было проверено но опять же здесь варианте Мне кажется будет прям хорошо
00:18:31 - 00:19:58
применимо автоматизация что мы функционал добавили отправили функционала регрессия это автоматизация ты попадаешь на проект на первый реальный вариант сейчас попадаешь на проект Ты один и тебя взяли руками тестирует ты говоришь я сейчас развернул фреймворк автоматизации все будет вообще чики пуки тебе говорят нет Александр времени нет на это руками у тебя мало времени и ты такой говоришь Ладно я могу протестировать руками но я все не успею тебе говорят Ну Выбери тогда что ты успеешь Какие вид тестирования Ну только скажи почему ты
00:19:16 - 00:20:45
их выбрал вот от какого бы ты из этих трех видов тестирования мог отказаться и почему регрессивная а почему потому что мы это уже проверяли и что значит что там минимальный минимальная вероятность что это будут найдены дефекты минимальная вероятность что будет найденный дефект мы это хотя бы раз уже видели все и наша функциональность Она обычно регрессивные кейсы не затрагивает если он затрагивает Мы обычно эти тесты туда же пихаем с Анти тестирование так как они связаны допустим А если вот например
00:20:04 - 00:21:23
вопросы нам говорят что мы Ну нет времени на регрессионное тестирование мы от него полностью отказываемся но потом находится там дефект ответственность будет тестировщики за этот дефект или как бы смотри когда ты отказываешься от регрессионного или если ты хочешь отказаться от регрессивно ты это не делаешь по своей воле просто сегодня я решил что не буду одна из важнейших функций тестировщика доносить информацию в it-компаниях ты доносишь информацию до своего менеджера Поэтому такие решения Какие виды тестов будут принес как что
00:20:48 - 00:21:57
ты согласуешь со своим project-менеджером или дом тестирование если есть либо имя обоями То есть ты говоришь есть такие-то риски мы вот так-то не успеваем давайте у нас есть два варианта либо мы отодвинем релиз если нас это возможно чтобы у меня было время пройти все виды тестирования либо я не буду проходить Ну или там сколько успею как обычно ты можешь все-таки успеть Ну типа не все неполноценно там прогрессию или вообще не пройду тогда есть риск что будет но риск маленький очень но есть и Project менеджер решает
00:21:24 - 00:22:37
он говорит Слушай нам нужно релизиса капец хрен с ним шансов мало значит будем рисковать Ну если выйдет менеджер взял на себя риски соответственно предоставлять информацию менеджером они уже потом решают что делать Окей есть еще там градация такая уровне тестирования называется или еще иногда называют виды тестирования по степени изолированности компонентов какие там бывают уровни помнишь модульные интеграционный системный и приёмочный Так чем они отличаются все модульный Это самый низкий уровень
00:22:00 - 00:23:33
Там тестируется вот белый ящик кот в отрыве от бизнес требований интеграционное тестирование это проверка связи между компонентами и взаимодействия с различными частями приложения система тестирование проверка функционала и требований в целом то есть как работает система в целом а приёмочная тестирование как бы это завершающая которая дает понять Готова ли приложение к выпуску один Документ и на нем завязано приёмочная чтобы мы решили что система готова к выпуску мы должны о чем-то договориться
00:22:51 - 00:24:30
и как-то оформить Ну так отчет о тестирование Ну не совсем отчет тестирование Когда мы уже провели А в приёмочную тестировании есть такое понятие ацетам сплан или по-русски план приёмочных работ формально называется мы заранее выбираем тест кейсы которым будем проходить и согласуем их с нашим заказчиком и мы договариваемся что если мы проходим эти тесты вот сейчас мы значит сдали систему если они не проходят Значит мы не проходим от тестирования Значит нам надо типа продолжить работу пока мы его
00:23:45 - 00:25:02
не пройдем вот Вся фишка Ну на самом деле во многих источниках более старых есть только три уровня модульная интеграционная системная приёмочного нет поэтому иногда иногда на собеседование можно сказать что есть три вида тестирования не говорить про приёмочные и ты пройдешь Дальше те вопросы никто не спросит иногда где приемы а иногда ты скажешь я тебе скажут Почему от системного отличается да такой ну есть план приёмочных работ А еще а еще как бы сложно сказать поэтому что серый ящик Что 3 или 4 уровня
00:24:23 - 00:25:47
тестирования Да это примерно одна и та же история Почему серым ящиком проблемы потому что вы тоже изначально не было во всей литературе базовой есть белый ящик черный никакого серого нет серый потом додумали также и уровнях есть модульная интеграционная системная додумали потом где-то кто-то приемы поэтому на реальных событиях тут надо ловить волну иногда план вот этих приемщик работ хорошо техники с дизайна Зачем нам нужен вообще какие-то техники что они нам дают но техники тест-дизайны это вообще
00:25:06 - 00:26:17
правила и подходы позволяющие при наименьшем усилии получить наибольший КПД скажем так вот и существует такие техники DTS дизайна как эквивалентное разделение анализ ограниченных значений таблица принятия решения парное тестирование диаграмма перехода состояний вот самый любимый на собеседование ковалентное разделение Ты можешь объяснить да Значит мы разделяем наше значение на классы подразумевая то что каждое значение внутри класса на каждое значение внутри класса программное обеспечение будет
00:25:50 - 00:27:30
реагировать одинаково так и это нам дает что это нам сокращает количество тестов то есть нам не нужно все значения одного класса проверять мы можем выбрать одно или там минимальное количество значений класса Да отлично супер хорошо Ну и вот если допустим нам нужно протестировать поле ввода логина Как мы можем применить эту технику Какие конкретно проверки мы можем сделать использовать технику разбиения на глаз но делим на класс это латиница кириллица цифры спецсимволы вот и нам не надо тестировать все буквы все цифры все СПИД
00:26:43 - 00:28:13
символы Нам необходимо минимальный набор какой-то вот взять из каждого класса этого будет достаточно все верно хорошо отлично и анализ граничных значений Как работает и на том же примере допустим на поле ввода анализ ограниченных значений связи с особенностями разработки вот наиболее вероятен дефект именно на стыке класса эквивалентности скажем так вот и при тестирование необходимо брать границы на этих классах То есть к примеру сложно рассказал перехитрил сам себя лучше что вот у нас есть интервал
00:27:28 - 00:29:04
интервалы которые чаще всего используются для того чтобы провалидировать там длину строки какой-то или еще чего-то в данном случае допустим с полем логина У нас есть обычный интервал минимальный максимальный длинный логина и проблема во-первых в том что вот эти интервалы они могут быть очень большими То есть это может быть от 10 до 20 может быть от 10 до 1000 допустим например в поле логин вряд ли бывает тысячи символов ограничений каким другие поля допустим бывает и для того же самого для того чтобы тебе весь
00:28:19 - 00:29:29
длиннющий интервал внутри не проверять каждое значение Мы допускаем также как и с классами ковалентности который носили мы допускаем что если мы возьмем парочку значений внутри интервала и парочку значений снаружи интервала мы можем проверить работу всего интервала мы сокращаем количество уходных сценарий и второй вопрос уже как конкретно мы Какие конкретно Мы берем значение чтобы проверить весь интервал Да И вот тут мы уже говорим о том что на стыке позитивных и негативных значений мы проверяем работу интервала и вот можно
00:28:55 - 00:30:15
привести пример вот допустим интервал от 10 до 20 У нас есть какие бы мы взяли проверки чтобы протестировать весь интервал минимальным количеством способов от 10 до 20 так 10 и 20 это у нас внутри Ну значит мы берем -1 это 9 берем 10 берем 19 и берем 20 а нет 20 21 20 у нас внутри интервала можно запутаться немножечко можно поэтому ладно не торопиться все правильно Да еще в некоторых источниках пишут что необходимо взять где-то в середине чтобы уж точно удостовериться и тоже рекомендую сделать То что на практике
00:29:35 - 00:31:14
тоже Всякое бывает лучше взять Как ты думаешь Вот такая проверка на возможно только на числовом интервале или на алфавите тоже можно проверить такое значение Например у нас есть требования чтобы там есть у нас список имен и системе которым мы Тестируем можно отфильтровать имена по интервалу вот можем мы по буквам как-то Ну конечно Ну мы же до Можем отсортировать по алфавиту то есть И вот проверку этого можем провести Да да конечно работает абсолютно также потому что компьютерная система не только знают
00:30:24 - 00:31:48
длину Ну какие числа за какое За каким идут автоматически они также знают все алфавиты поэтому тебе могут на собеседование реально попросить допустим и не числовой интервал допустим от 10 до 20 как сказали алфавитно сказать вот допустим значение Матвей до же русского алфавита или английского и подумать также получается можно и со временем то есть скидки только в четверг примеру с нуля 01 там календарными сложнее потому что там надо Ну в принципе система конечно известно система знает как время системно выстроены и она может
00:31:07 - 00:32:35
отталкиваться но там важно откуда система берет время бывает что время бывает берется с браузера бывает что время берется с бэкенда сервера то есть сервер у сервера свое время есть И кстати говоря это часто ошибка в реальных системах которые ты будешь тестировать если что-то будет завязано на времени то есть конечный пользователь будет пытаться скидка применить Как пример привел или что-то еще сделал потому что у него жена стал Новый день а сервер будет думать что еще не настал и не будет выпускать и
00:31:58 - 00:33:01
при этом ничего толком не сможет сказать и пользователь потеряется хорошо отлично супер Давай поговорим про тестовую документацию какую-то знаешь тесту документацию который тестировщик создается чек-лист кейс Back Report план сначала что это такое план Это документ который описывает весь объем работы берем указывается что нужно тестировать Когда нужно тестировать критерии начала тестирования критерий окончания возможно какие-то инструменты там что нам необходимо там телефоны стенды что-то еще что-то еще
00:32:33 - 00:34:01
там какие Компьютеры ты когда им писал сантосплан Нет но я знакомился с ним и видел там матрицу соответствия требований вот меня это прям так вот запомнилось что там требования и указано в каком тест кейсе это требование проверяется то есть по этой матрице определяется покрытие всех требований тест кейсами Круто А вот представляешь себе ты вот сейчас пойдешь на собеседование Да и техники берем ты будешь единственным нашим тестировщиком который нам расскажет как надо тестировать ты приходишь на проект
00:33:26 - 00:34:49
ты сможешь написать будешь его писать или он не нужен или как Но если как бы не является обязательным требованием то наверное не буду как я напишу наверное какую-то себяшку такую для себя на самом деле я советую писать всегда даже себяшку на коленке в Google доки на одну страницу Потому что часто в компаниях которые тебе будут нанимать единственным тестировщиком стартапах там никто не знает что должен делать тестировщик и написав тест-планты не просто выполняешь какую-то формальность ты буквально показываешь что тебе мешает
00:34:15 - 00:35:26
что тебе поможет в принципе будешь делать И это на бумагу на Google бумагу вносится и когда ты показываешь другим членам команды они лучше понимают что тебя вообще ожидать потому что иногда такое бывает что когда устраиваешься в небольшие компании ожидание с реальностью на тебя обижаются говорят Ну что Александр не умеешь тестировать безопасность тестировщики вообще не занимаются отдельно темы А я думал занимаются А что не сказал непонятно начинается Но если ты в тест-плане написал что будут применяться
00:34:50 - 00:36:05
такие твит тестирования такие твит тестирования не будут все вопросы этого не будет все посмотрели глазами сказали Я понял принял вы договорились на бумаге поэтому тест-план это не просто какая-то часть документация там формальность это огромный помощник для того чтобы тебе было проще в дальнейшем защищаться от каких-то там непонятных вопросов и так далее ну и плюс это помощь когда расширяется штат тестировщиков и тебе приходит новичок ты можешь дать почитать сначала потом рассказать что вы делаете
00:35:28 - 00:36:39
тоже свои плюсы поэтому Я рекомендую написать свою спал хотя бы раз и тренироваться в этом не обязательно должен быть там красивый на 20 Листовка простая на коленочная она решает те же самые задачи красивые тест-план нужен когда заказчику надо показать когда там какой-нибудь большой заказчик который любит вот эти вот документы которые оформлены в стиле дипломные работы чтобы кирпич был потолще чтобы оглавление было Вот это запарно Я согласен но если такого не требуется хотя бы на коленочки Вполне
00:36:03 - 00:37:17
себе Окей Что такое тест кейс Это документ описывающих последовательность действий для проверки функционала что он себя включает Первое это ID модификационный какой-то номер это название это исполнитель соответственно кто написал этот тест кейс это окружение это [музыка] шаги воспроизведения и ожидаемый результат также Сюда можно внести окружение и какое-то предусловие Что необходимо сделать перед тем как начинать этот пост условия Что нужно сделать что такое чек-лист чек-лист Это список проверка
00:36:40 - 00:38:41
так из чего он состоит так он состоит из также индификационного номера название [музыка] также наверное исполнителя окружения и список проверок которые в итоге мы вернулись к слову список проверок Ну обычно так говорят что чек-лист состоит из проверок который называется чеками чек-лист список проверок это из названия выходит и каждая вот эта проверка она представляет из себя ровно одно предложение где мы пытаемся описать всю суть проверки просто максимально вот сжато короткими словами иногда в принципе можно даже провести аналогию
00:37:53 - 00:39:16
между названием и чеком из чек-листа потому что в принципе они выполняют одну и ту же роль они говорят о сути проверки просто есть еще потом есть большое содержимое А в чеке больше ничего нет Вот и мы как бы примерно понимаем по чеку по названию что мы должны сделать Да это как бы название тест-кейса совмещенное с ожидаемым результатом этого ты совмещаешь и получается название чек-лист что-то вроде того Да зачем нам одновременно для вроде как одного тоже для того чтобы хранить тестовый сценарии
00:38:36 - 00:39:47
есть значит Широкая версия Да как тест есть вот какая-то сдержанная версия как чек-лист но чек-лист он предназначен для человека который знаком с проектом который не потеряется притом каком-то непонятном действии которое от него требуют в чек-листе все это подробно расписано куда нажать как нажать сколько раз что ввести то есть если в чек-листе мы просто пишем к примеру там зарегистрировать пользователя нового пользователя то чек-листе там нажать туда логин порой нам нужно четко выявить допустим
00:39:10 - 00:40:46
ситуацию ты приходишь проект написал Ты сплан на коленке как смог и такой Окей мне нужно писать тесту документацию на какие критерии вот ситуации что вокруг тебя происходит Ты будешь опираться и что-то выберешь в этом случае сложность проекта первая наверное потом так если проверки сложные тогда какое мы выбираем документацию так дальше количество тестировщиков на проекте единственный или несколько тестировщиков если несколько тут эскиз как бы я напишу в чек-листе одно тестировщик может другой это не понять как бы если мы не
00:40:00 - 00:41:26
знаком там с функционалом приложением так еще наверное Ну надо проанализировать нужен вот мы напишем если тест кейс нужен ли он будет кому-то в дальнейшем Ну то есть насколько приложение вообще потенциально она рассчитана То есть это какой-то долгоиграющий проект либо это вот что-то такое быстрее мимолетное нам не стоит затрачивать время бывает часто тебя приглашает на работу говорят у нас проект на три месяца стартапчик ты будешь один Через три месяца самое время для чек-листа во-первых нужно только мне читать никто не будет
00:40:47 - 00:42:04
во-вторых у нас очень мало времени на тестирование если мы будем слишком большие сложности писать мы само тестирование не проведем В итоге три месяца оформляйте Потом проект закончится и все окей Окей отлично так багри по Что такое Из чего состоит также как и предыдущие документы это индификационный номер Это название это приоритет это предусловие это шаги воспроизведения ожидаемый результат фактически результат это ну и дополнительная какая-то информация это может быть скриншоты скринкасты логи всевозможные То есть то
00:41:29 - 00:42:57
что может помочь разработчику понять из-за чего это все сломалось или как найти этот дефект еще нас бывает там автор указывается Кто создал чтобы было понятно просто создавать и бывает указаны еще сайту то есть наклон на данный момент задача висит чтобы разобраться кто в данную секунду на ней не сказал обязательно это наверное окружение указывается где этот был бак воспроизведен окружение Ну из версий наверное приложение еще то есть Какая версия если их там несколько вот ну это обычно оно может все вместе называться окружением
00:42:17 - 00:43:43
Вот это слово окружение Оно такое гуляющее оно может отвечать и за версию кода который ты тестируешь и за там железа на котором тестируешь Это обычно все в слове января указывается и так далее хорошо отлично жизнь цикл бак-репорта Давай обсудим вот репорт Ты завел вот Представьте ситуацию самым пока простую простой что дальше происходит находим бак получается у него статус новый То есть мы его нашли впервые соответственно мы его направляем получается на исправление то есть открываем и направляем на
00:43:02 - 00:44:28
исправление разработчику разработчик исправляет фиксит бак возвращает нам мы перепроверяем если все хорошо закрываем если бак воспроизводится Значит мы его переоткрываем и назад разработчику отлично супер вот представим ситуацию вот бак воспроизводится ты его опять переоткрыл разработчик его пару раз Починил Ты все равно решил воспроизводится в какой-то момент этой итерации разработчик говорит сочинить не буду у меня не воспроизводится Я устал Я занятой человек отстань от меня Александр со своими багами я пошел фичи новые делать
00:43:49 - 00:45:19
Мне некогда заниматься статусом что у меня работает Что ты будешь делать но наверное в первую очередь проверю сам себя то есть как бы в то ли то ли версия тестируется то есть одинаковые ли у нас версии с разработчиком может он уже там новую версию у разработчиков своя версия вот тестировщиков еще не дошла И мы там на разных языках общаемся вот этот вот это наверное проверю Что еще можно проверить но окружение Возможно если все вот полностью я уверен что бак есть и все у нас одинаково Ну наверное это вопрос должен решать кто-то
00:44:37 - 00:46:13
выше то есть надо снять себя ответственность доложить Как говорится Вот ну да ты то есть момент на самом деле очень часто ошибка у дженеров в реальных проектов Когда приходишь и ты бак завел Ты доволен нашел проблему я не бесполезные члены А теперь все говорят Да и хрен с ним Ну да вообще садится такой что как вот репорт чинить они говорят Да у нас есть дела поважнее и там чем-нибудь еще и ты теряешься и многие начинающие тестировщик они начинают бычить они начинают ты чё ты чё Вот и этим самым отвлекают
00:45:28 - 00:46:57
программиста там начинается нехороший иногда отношения вот чтобы этого не было да ты зарепортил ты пару раз искалировал с разработчиком не получается Он не хочет продолжать с ним работать так же как вот мы помнишь говорили там регрессию да кто выбирает или нет В итоге решает менеджер Так мы сообщаем менеджеру говорим менеджеру говорим я вижу бак Он не видит не хочет видеть что с ним делать и в зависимости от того какой у него статус что-то на проекте так далее менеджер может сказать Ну закрою либо может сказать
00:46:14 - 00:47:35
разработчику скажем так все отбрасывает не можешь можешь Давай до работы этот вопрос и если вдруг твой бак его все-таки решили что Да он есть допустим надо убрать твоя задача просто как можно больше оставить письменно доказательств в комментах написать что вот такой там proje Major Вася сказал мне убрать его я убираю но смотрите сами типа я не виноват чтобы потом в будущем к тебе опять же не было вопросов и идти дальше работать плевать Хорошо теперь представим ситуацию когда что-то не так пошло сразу
00:46:58 - 00:48:21
завел табак разработчик такой сразу говорит а не буду делать потому что по каким причинам может какие там статусы бывают когда сразу не хочет очень ну наверное это дубликат может быть дубликат это уже есть такой бак то есть они и что происходит Вот он поставил дублика что дальше происходит Ну дубликат он соответственно возвращается ко мне я я нахожу вы тот ту версию Бага соответственно нашел тот бак проверил исправлен ли тот бак или нет то есть если тот бак исправлен А этот неисправлен то есть до воспроизводится
00:47:42 - 00:49:18
бак то это получается не дубликат Ну да формально тем не менее над ним можно продолжить работу можно переоткрыть еще что-то А если тот бак изначально оригинальный в работе висит до сих пор тогда что Ну тогда мы наверное этот закрываем Зачем нам два одинаковых мы просто там помимо того что мы там закрываем еще что-то мы обычно стараемся еще там линковать есть возможность обычных программе Gran или других программах деле портится делать ссылки чтобы информация была соединена еще есть рекомендую все-таки когда разработчик
00:48:30 - 00:49:52
будет заводить такие баги пере необходимость найти оригинал до дубля на разработчика потому что очень часто разработчики любят говорить так это дубль я такой там где-то видел а ты потом целый день рабочий ищешь и ты не находишь ты говоришь А я такого не увидела разработчика Ну ладно мне показалось и ты потерял рабочий день чтобы этого не было все-таки Мы стараемся чтобы разработчик все-таки он дубликат чтобы мы убедились что все действительно так что очень часто кажется и так далее хорошо помимо
00:49:10 - 00:50:20
дубликата Что может быть еще там Ну отсрочен наверное Может быть на какой-то срок возможно отсрочен как правило его просто снижает им приоритеты кладут бы клок Там какой-то отдельный статус что еще бывает Ну наверное еще разработчик думает что это не баг или не думает может быть это так и есть не баг так вот тебе приходит задача со статусом не баг Чего ты делаешь но тут уж Надо как-то разбираться Бах это или не бак я думаю тут надо задействовать кого-то еще Наверное чтобы бывает что начиная с того что
00:49:45 - 00:51:06
перечитываешь все-таки документацию да да проверку требований еще раз чтобы понять же очередная житейская частая история ты написал Ты с кейсы по требованиям потом молча кто-то втихаря требования поменял по ним разработчик по новым требованиям написал новые изменения А ты как-то либо сам упустил либо это не от тебя зависело и ты проверял по своим старым ты с кейсам Оказывается ты с кейс надо поменять и Действительно это не Баг и тебе надо переписать тестовый сценарий вот а бывает что разработчики немножко
00:50:34 - 00:51:37
не понимает требования И вам надо вместе сесть и подумать вот что там не так Ну если ничего не помогает то вызов поддержки с воздуха вызов менеджеров А еще какие бывают ситуации когда самого начала дубликат обсудили ноты бак обсудили что еще [музыка] статус часто типа не будут делать я признаю что это я сделать не буду Потому что что не хочет наверное потому что почему не хочет Бывает такое что находишь ты Бат в части системы которая будет скоро претерпевать сильное изменение или вообще удалена То
00:51:06 - 00:52:27
есть ты нашел на сайте в разделе бака раздел будет полностью вычищена там следующим спринтеле в текущем Он говорит Да я признаю что есть бак но нет смысла чинить Мы скоро все оттуда удалим нахрен тоже на всякий случай менеджеру Правда он может сказать допустим Да завтра удалим а может сказать не это разработчику показалось ничего удалять не будем а если будем то через полгода и тут тоже либо принимаешь эту ситуацию либо разработчику вырежешь Да конечно когда ты это удалиться Но это будет не завтра Так что давай чини вот много
00:51:58 - 00:53:00
ситуаций бывает тут желательно в них ориентироваться так хорошо хорошо виды приложений какие ты в принципе знаешь виды приложения которые у нас сейчас на рынке существуют веб-приложения нативные и гибридные Отлично начнем свое приложение какая особенность их работы и тестирования в приложении это соответственно особенности это что для работы этого приложения нам необходим интернет первую очередь нам необходим браузер Вот соответственно приложение подразумевает собой общение клиента с сервером То есть
00:52:29 - 00:54:07
она общается посредством запросов ответов к серверу [музыка] что там еще такого Ну принципе разрешение на обновление требуется конечно пользователь так нет обновление разрешение все Обновили на сервере Обнови лась сразу пользователя хорошо вот процесс когда клиенты обменивается чем регулируется Так ну запросы ответы [музыка] Кто где был прописано то с чем регулируется то что должен быть такой-то запрос он из таких частей состоит такой-то ответ Ну какими-то правилами наверное Ну да правильно правилами они объединены в
00:53:25 - 00:55:01
протокол Мы даже протокола раньше писали в поисковой строке а сейчас она автоматически добавляет Ну да протокол http протокола вот да у них есть разные методы так вот давай Вопрос Из чего состоит запрос запрос из метода соответственно из URL это заголовок и тело тело запросы есть да хорошо методы какие-то статус кода [музыка] хорошо страница приходит 200 если у нас неправильные запрос поставленный сервер не знает как его обработать или 400 400 а если сервер сломался и криво там работает не поддерживается то
00:54:24 - 00:56:23
тогда Какая ошибка 500 хорошо супер класс в чем же особенность тестирования в приложении Да какие виды тестирования ты бы применил в первую очередь приложением кроссбраузерное тестирование тестирование Так что тут у нас есть такое что нельзя применить к другим Ну нельзя ли в полной мере Она ближе допустим браузер влияет да может быть мы можем проверить на этих самых верстку на разных экранах да то есть в данном случае нужно потому что устройств много и если нас адаптивная верстка то она должна правильно сжиматься
00:55:45 - 00:57:14
[музыка] соответственно проверяем как у нас на Recovery на отказ восстановления работает при отключении интернета то есть нам надо проверить что происходит если в определенной логике врубаем полностью интернет или не полностью а допустим мы можем сжимать его скорость регулировать как она будет реагировать наша система хорошо Так теперь нативные приложения обсудим Давай их особенности В чем заключается как они работают и как бы их тестировал нативные приложения соответственно они требуют установки Вот перед тем как его
00:56:38 - 00:58:08
запустить обновление Да если выходит какая-то новая версия Ну и удаление Так значит здесь у нас влияет сейчас скажу системные требования в отличие от веб-приложений то есть какой у нас железо стоит здесь у нас возможно не требуется подключение к интернету здесь у нас что еще может быть такого Требуется ли нам размещение в каких специальных сервисах чтобы установить это систему нет Как нет вот у нас есть AppStore допустим а в нем мы хотим нативное приложение для iPhone разместить А это целая история Да надо проходить
00:57:26 - 00:59:15
модерацию в этом AppStore А есть Google Play для Android приложение Вот то есть это надо учитывать при тестировании Потому что от этого может зависеть скорость релиза сейчас уже допустим в AppStore чуть побыстрее Все делается какое-то время назад я опять же это может время вернуться если не изменение правила опять изменит допустим бесполезно было релизм в Рождество католическое потому что никто не работал а потом Новый год и общем если ты до конца ноября не зарелизился значит лучше отложить до следующего года иначе все
00:58:27 - 00:59:34
просто застрянет вот еще иногда надо соблюдать вот эти правила этих площадок этого всего нету в приложении потому что там не происходит никакой модерации более того приложение в принципе не требуется никакая установка И помимо тестирования допустим установки сто раз откуда еще может нативное приложение с диска с флешки там не знаю Все правильно Да с внешнего диска с флешки с диска обычного большое количество софта до сих пор на диск продается вот еще допустим некоторые производители софта размещают свои программы на своих сайтах
00:59:01 - 01:00:28
минус Тора на сайте вот Окей хорошо так соответственно тестирование инсталляции в нативных нужно по поводу подключения к интернету ты сказал что Не совсем точно тут как лучше говорить для технической работы нативного приложения Интернет не нужен потому что вся логика приложение находится на устройстве но сейчас многие приложения имеют такой бизнес модель когда им нужно снаружи подгружать какие-то данные с которыми работает фоточки чаты файлы что-то еще то есть само приложение без Интернета работает
00:59:44 - 01:01:04
но бизнес смысла бизнес смысла работы нет потому что ему нужен интернет чтобы оно выполняла свою задачу поэтому мы можем как бы тестировать и без интернета и наличие интернета не является для нас базовой вещью но тем не менее какая-то часть тестирования может быть завязана на проверку взаимодействия с интернетом чтобы бизнес-задачу выполняла система вот в том числе вот также на отказ восстановления можем проверять только помимо отключения интернета Мы тут уже можем вводить изменения вносить какие-то изменения
01:00:25 - 01:01:42
помехи работать само устройство например уведомления от других приложений звонок на телефон аккумулятор разрядился там очень большой Спектр который именно для нативных приложений подойдет Больше допустим из телефона разрядился приложение Там могут быть баги в приложении возникнуть от этого ничего не будет просто контакт с сервером пропадет А с приложением в памяти Всякое может быть вот хорошо и также про нагрузочное тестирование можно отметить да то есть у нас допустим веби мы можем сервер грузить и так далее там
01:01:05 - 01:02:16
наплым пользователей то здесь уже с нативными это не тоже можно грузить сервер но это не такой имеет большую важность потому что большая часть нагрузки на приложение находится внутри самого устройства так гибридные приложения в чем у них фишка но они сочетаются какие-то функции нативных приложений какие-то веб-приложений Вот например могу привести в пример приложения интернет-магазин цифровой техники DNS у них приложение выполненная То есть это условно говоря браузер только в который вбита одна
01:01:49 - 01:03:14
только один адрес то есть сайт приложения То есть он не требует обновления но он требует установки как бы удаления это вообще [музыка] внутри сферы это называется тонкий клиент Если что то есть вот это вот нативная часть это называется тонкий клиент и такой подход это выбью модель То есть когда у нас есть точка входа которая устанавливается как нативное приложение ярлык свой есть и внешне она тоже часто выглядит нативным образом то есть она не Выглядит как будто вот приложение с установкой но при
01:02:32 - 01:03:56
этом внутри реализован так называемый встроенный браузер это не браузер Chrome и так далее браузер который пишется внутри как бы встроенная часть и в нем открывается веб-страницы но выглядит они как нативные ты видишь кнопку приложении а на самом деле это ссылка в этой странице просто для тебя выглядит так вот ты говоришь оно там совмещает это все ну такая тогда давай особенности тестирования Но тут уже наверное зависит от приложения как бы самого то есть конкретно какое какое приложение вот мы
01:03:14 - 01:04:29
представим что это вот вебвью с тонким клиентом значит установка требуется да Значит нужно подключение к интернету Нужно обязательно обязательно логика на сервере так вот дальше нагрузочное тестирование нужно проводить нагрузочно тут нагрузку на сервер получается как бы да да соответственно там можно еще выделить часть поэтому что тебе рекомендую во-первых это важно вопрос не только в теории Потому что ты будешь попадать на реальное собеседование и тебе иногда будут говорить вот у нас такое-то приложение как бы вы протестировали и
01:03:53 - 01:05:26
иногда вместо того чтобы там слушать подробно что за конкретно них предложения ты можешь опираться на тип так так и тебе уже ничего не надо знать что у них конкретно реализовано ты знаешь зависимости от виды приложений чтобы ты сделал и ты можешь быстро ответить как бы ты тестировал конкретно их сайт или их нативное приложение это очень хорошо на собеседование выглядит когда ты не просто потому что теоретически вопросы никому не интересно всем хочется понять какую-то пользу может принести ты можешь сказать ваш
01:04:41 - 01:05:44
сайт Я бы вот тестировал это это это вот или там ваше приложение Вот это бы я считаю в первую очередь требует проверки и они уже сразу лучше думают о тебе вот и еще я многим рекомендую чтобы прям вот четко на собеседование не забывать разницы между приложения сделать себе какой-нибудь там табличку матрицу и там столбик зависит от интернета Требуется ли обновление Требуется ли там установка требуется и три строчки нативная гибридная и там плюс поставить и ты потом на собеседовании не забудешь ничего и
01:05:15 - 01:06:26
будешь четче и быстрее называть между ними разницу глядя вот это вот шпаргалку или выучить рядышком положить потому что это важно Хорошо хорошо так и поговорим про процессы разработки немножко про методологии какие ты знаешь виды разработки методологии подходы так но есть у нас Agile это набор идеалов и принципов как бы служащих ориентиром наверное да В разработке в него он включает в себя скрам и Канбан вот есть также водопадная либо каскадная модель разработки по вот принципе такие вот там на самом деле очень много можно Да если
01:05:51 - 01:07:39
правильно лучше говорить Так что есть много моделей Но самое распространенные это значит Тоже имеет много под собой методология скрам камбан самый распространенный Вот про них типа Давайте поговорим тему экстремальное программирование что же типа вроде как отжаловать не для нас это два программиста сами собой что-то решают для тестировщика вот эти самые подходящие хорошо waterfall В чем в нем фишка как он работает waterfall он работает это основная особенность его в том что он последовательно переходит каждому
01:06:45 - 01:08:12
этапу разработки то есть и нельзя вернуться либо перескочить один из этапов Вот это нам не дает никакой гибкости обратной связи между этапами разработки вот из плюсов можно выделить здесь Наверное более более будет надежным наверное приложении на выходе То есть это как бы сказать применяется в тех областях где высокие риски да то есть там где важно не скорость разработки а качество потому что цена ошибки слишком высокая для того чтобы спешить ракеты медицина самолет так это гибкая методология Точнее ну как
01:07:34 - 01:09:11
методология набор идеалов и принципов вот но я знаю точно что там вот эти принципы есть что люди взаимодействия важнее инструментов там готовность к изменениям лучше точнее как готовность к изменениям важнее чем следовать плану потом сотрудничество с заказчиком важнее условия договора такого там по моему принципов вроде бы если там принципов много там есть четыре основные идеи Вот и три назвал там еще одна есть но не важно документ называется у него у него есть у этого же манифеста есть свой древний смешной сайт на чистом
01:08:28 - 01:10:02
http Вот и если хочется можно его почитать то есть там просто страница на ней есть эти четыре идеи есть ссылка на принципы которых дофига и никому не интересно четыре идеи можно называть а в принципе Окей так все Слыш Нет все уже все хорошо в принципе на собеседование чтобы прям наизусть Расскажите 4 идеи редко такое бывает могут Просто спросить типа про что в общем и целом манифест про то чтобы было меньше формальных движений и больше разработки но проблема заключается в том что чистого аджайла
01:09:33 - 01:10:51
нигде не существует потому что Если отказаться от договоров значит не вести документацию Ну во что это превратиться если у тебя не будет тест плана ты забудешь что-то делал вчера не будешь контролировать ничего И все это сыпется но Agile придумали тогда когда формальности было очень много когда процесс разработки он был как работают на госструктурах сейчас все друг другу носили служебные документальные всякие вещи на ранних этапах вот того же mail.ru баг-репорта распечатали на принтере и носили начальнику на
01:10:15 - 01:11:29
подпись Вот это всё это было в начале нулевых и на этой на этой почве возник аджайл типа давайте мы от этого всего откажемся Вот ну как бы что-то среднее получилось то есть от чего-то отказались например от распечатки на принтере обогрепортов Но с другой стороны все-таки жиру придумали да то есть это все перетекло виртуальный вид и какая-то документация всё-таки есть вот и в соответствии с этими принципами придумали несколько методологий вот самая популярная Это насколько я вижу и в принципе это там
01:10:52 - 01:12:01
рассказать да это гибкое управление проектом значит особенности её это то что мы время распределяем на спринты их концу каждого спринта но длится там везде по-разному там в среднем от одной до двух недель если я не ошибаюсь и в конце каждого сплита должен получиться какой-то прототип То есть то что мы можем посмотреть пощупать проверить показать заказчику чего в начале спринта обычно происходит какой процесс начались это Но это наверное постановка задач то есть определение того чем планирования дать
01:11:28 - 01:12:53
тем чем будем заниматься А как определять что там делается на планирование сели и там задача выбирается еще что происходит Ну наверное каждый может быть предлагает какие-то решения как он видит чтобы это было проще что-то такое предлагается не решение предлагается срок работы над задачей то есть устанавливается estema это каждая задача Один говорит я сделаю задачу Я думаю что можно сделать задачу За день я думаю что за три дня и вот каждый рассказывается и менеджер выбирает какой-то показатель который с которым
01:12:13 - 01:13:33
все согласны сколько заметят задачи потом берут следующие потому что иначе они не знали сколько задач взять на спринт так они во-первых задачи выбирают которые более важные Но это же менеджер как бы лучше знаки более важный А вот сроки сколько Какая задача займет трудозатрат уже устанавливается сама команда именно в процессе выбора этих задач и в какой-то момент так все мы все наши две недели забили всё планирование закончено так в процессе спринта какой там происходит [музыка] событие часто но
01:12:53 - 01:14:06
ежедневный митинги созвоны где каждый докладывает там или рассказывает что он сделал вчера что планирует сделать сегодня [музыка] подведение итогов то есть смотрим на презентация прототипа скажем так прототип это отдельный процесс демон что там еще какие слова я понял я слышал но забыл Сейчас запомнили Запиши есть еще ретро или ретроспективы это где все анализируют косяки хорошие вещи плохие чтобы следующим принте косяков этих не было там проблемы с коммуникациями проблемами с доступными каким-то вещам и так далее
01:13:28 - 01:14:53
вот Окей супер Мы в принципе обсудили практически все вопросы которые я хотел по поводу ответов Смотри вот цели тестирования Да Нам надо какие-то посмотреть принципы назад тестирование цели надо каким любые простые найти так по видам тестирования все в принципе по техникам там помнишь до ограниченное значение [музыка] границы мы покрываем не торопимся когда рассказываем отлично когда мы обсуждали что включает чек-лист в принципе есть система где действительно много всяких дополнительных данных но в большинстве
01:14:42 - 01:16:11
случаев чек-лист он и выделяется тем что у него мало полей Ты просто начал про чек-листы говорит тоже начал еще что-то еще лучше горе Так что чек-лист проверка из чеков каждый человек единое предложение в котором мы пытаемся указать проверки все вот то еще стоит чек-лист вот так конечно в каких-то системах хранения тестов может быть чек-лист будет очень сложно выглядит на самом деле он минималистичный хорошо так баг-репорт принципе хорошо назвал там подзабыл назвать автора и на ком засанина поля
01:15:40 - 01:16:54
что в принципе не критично так про принципы работы предложения вот здесь пожалуйста тоже Повтори здесь важно да что какие виды тестирования Каким видом приложения больше подойдут не чтобы не плавать и побольше назвать одну-два но там больше на самом деле есть различий вот ну и вспоминает Да что в приложении протокол http Или иногда есть версия Secure https запрос ответ методы вот ты ответил это все но не сразу немножко начали Вот и соответственно в принципе все Единственное что еще хотел сказать по видам приложений
01:16:18 - 01:17:44
когда мы говорим про гибридные приложения на самом деле нету общего понятия о том что назвать гибридными приложениями и подхода гибридности он на самом деле сейчас очень разные то есть вот есть вот этот подход Когда у нас есть тонкий клиент веб View И это не только это является гибридностью У нас есть еще гибридный фреймворки например фреймворк Самарин есть такой который Microsoft делает это тоже называют часто гибридным приложением Так вы сами да да вот Самарин тоже является гибридным приложением
01:17:11 - 01:18:30
но при этом он работает никак тонкие клиенты веб- часть оно как бы больше в нативную сторону идет есть другие подходы единственное Почему мы это не изучаем потому что это все мало распространено В отличие нашего подхода поэтому когда на реальном собеседовании будешь рассказывать про гибридность лучше начинается с того что значит есть несколько подходов к понятию гибридности самый распространенный вот такой вот про него расскажу потому что иногда собеседующий может сказать А я вот не знал про такое знаю про гибридный можно
01:18:09 - 01:19:16
сказать отлично но их мало Если у вас приложение не на самарине или на чем-то таком Давайте лучше обсудим более подходящий вот собственно и все у тебя какие-то вопросы остались Да в принципе нет но только вот может быть Не в плане тестирования Мне было интересно сейчас вот поиск работы и я джуниоров там требует там И как Вот мне интересно выглядел должен был выглядеть Junior там 10 лет назад Junior тестировщик 10 лет назад что он знал чтобы его взяли на работу проблема Джуниора 10 лет назад была в том что
01:18:43 - 01:20:03
вакансии было тоже мало было мало дженеров было мало вакансий 10 лет назад рынок АйТи он был не такой большой и по поводу что нужно было знать нужно было знать то что захочет услышать интервью Случайный момент времени примерно то же самое что и сейчас то есть во-первых то что ты читаешь и видишь вакансии это не значит что это будут спрашивать на интервью в интервью в интервью Может просто перемкнуть и он вообще про другое начнут я узнал паренька который почему-то обожал очень спрашивать по ветвлению веток в гите ручных
01:19:24 - 01:20:35
тестировщиков когда у него спрашивают Зачем ты это делаешь ведь ручные тестировщики не заливают никуда код и не беру очень редко когда они делают очень редко Если понадобится Ну это это не незнание которое вот оно нужно постоянно он говорит я не знаю что спрашивать я никаких книжек ничего не читаю ничего я знаю что есть я его спрашиваю Мне нравится мучить людей Вот и все это на такого попадаешь и ты никогда не готов или подобная ерунда вот в принципе из того что мы с тобой сейчас не обсудили что еще могут спрашивать Сейчас могут
01:20:00 - 01:21:16
попросить иногда написать какой-нибудь базовое запрос на SQL то есть буквально тебя дадут ссылку в какую Google долг и скажут напиши SQL запросто простой допустим с поиском какого-то значения Ну и ты там Напишешь Select там что-то fromw что-то так и то его даже не будут валидировать запускать при тебе ничего ты там если ошибаешься синтаксисе Но обычно никто не пристанет вот тоже на самом деле Вот Всем плевать Но вот у них там есть чек-лист где написано что знание SQL хотя на самом деле не надо Ну типа надо и второе что
01:20:36 - 01:21:45
это вот новое Прикол это epi То есть те самые запросы ответы через степи вот метод URL Да тело запроса ответ и так далее иногда спрашивают прям накапливаются есть разные методы а тему спросить какой метод Там же много это вот мы 4 распростран енные какую-нибудь Рандомный случайно из там 20 других что он делает учитель при этом все методы наизусть и хорошо знать разницу но я бы не стал Я бы лучше просто на другой собеседование пошел где тут не спросит либо мне встречались такие мне рассказывали что на некоторых собеседованиях Junior
01:21:13 - 01:22:43
это когда ходят их начинают при том что есть много программ по тестированию API вот по вот спрашивают программу постман вплоть до того что кого-то спрашивают А какие там вкладки как они называются я не могу допустим тебе сказать выучить постман наизусть знаешь там сделай скриншот Положи рядом И это но на некоторых собеседованиях такое можно встретить то есть общую такую девиацию можно встретить везде то есть всегда есть шанс попасть на вопросы которые очень странные которые подходят и все но большинство вопросов мы вот сейчас
01:22:03 - 01:23:19
проговорили и соответственно можешь чуть-чуть посмотреть как пишется SQL если это совсем как бы это ты не в курсе и можешь чуть глубже почитать про API и вот программа постман может быть через пару месяцев какая-то другая будет Вот умереть без него можно это вот действительно так вот в принципе когда ты откликаешься на вакансию сейчас пол дело если тебя пригласили на Собес потому что тебе просто часто не приглашаю поэтому очень важно хорошее резюме чтобы оно прошло первичный отбор а первичный отбор резюме для первого
01:22:42 - 01:24:11
собеседования сейчас часто происходит через ключевые слова то есть в первую очередь на твою резюме смотрит не живой человек а автоматизированная система которая читает ключевые слова Поэтому если у тебя хорошие резюме на него до него хотя бы дойдет живой человек а если не очень медбраковывает автоматизированной системы все те никто вообще ничего не ответит вот когда ты начнешь попадать на реальный собеседник в принципе не проходить тихо попадать на них это уже пол Победы на самом деле это хорошо
01:23:29 - 01:24:35
Значит я хорошее резюме Ты в нем сделал Все грамотно по возможности и ты начал светиться среди других кандидатов А уже как ты проходишь эти собеседования это уже будет вторая Понятно половина дела Но на самом деле тут зачастую чисто проходит с практикой ходишь у тебя становится как мы говорили самом начале меньше волнения вопросы многие ты уже не думаешь над ними ты знаешь ответы выдаешь автоматически потому что многие вопросы повторяются и с каждым разом Тебе проще на них отвечать вот и ты пройдешь вот
01:24:02 - 01:25:10
сейчас большая сложность это именно попасть на Собес раньше вероятно было проще 10 лет назад попасть на Собес но только информация Была намного меньше не было там не курсов не YouTube где есть куча блогеров которые рассказывают Как тестировать Нет там сидели такие деды которые тестировали Там сначала 90-х по совершенно другие системы по другим метрикам и ты вообще понятия не имел что тебя спросят сегодня на собеседовании ты мог поговорить о том как ты Хорошо на рыбалку сплавал а мог углубиться в
01:24:36 - 01:25:43
какие-то недры Юникс системы и в конце просто сидеть и все Вот например у меня одно из первых собеседований я пришел на собеседование первый вопрос спросили Ты умеешь программировать на языке си Я говорю Нет я даже не знаю что такое очень плохо Вы не пройдете собеседование ручного тестировщика до свидания а потом я узнал Что меня собеседовал программист потому что у них нету тестировщики они сказали так Вася иди там про собеседование знали язык Ну вот соответственно такая вот история я пошел на собеседование недавно и ну на
01:25:09 - 01:26:27
ручного тестировщика все созвон уже после HR уже с техническим человеком и он мне говорит приземе у вас указано Python автоматизация Ну давайте начнем с пайтона Напишите функцию которая принимает там число а я все у меня и соответственно все но потом он начал потестированию спрашивать Ну а после такого Ну ты уже мне кажется ничего не сможешь ответить когда ты уже морально подавлен и не как эффект вот этот неожиданности что ты готов очень большой шанс что как раз я тебя собеседовал разработчик которому
01:26:01 - 01:27:26
просто более интересно говорить про программирование чем проходит тестирование и поэтому и начал спать первое второе не каждый разработчик пройдёт собеседование где есть лайф-кодинг так называемый Где тебе говорят вот открывай айдые или там вот открывай и пиши там блокноте и в-третьих почти всегда лайв ходит Где тебе говорят что-то делать всегда переносят наконец-то собеседование потому что это всегда стрессовывает и так далее если с него начинать не каждый Middle программирования выдержит и просто у
01:26:47 - 01:27:41
него голова вскипит и всё но А в принципе в этом случае тут конечно желательно просто иметь отдельное резюме подручного тестировать под автоматизатора Тогда больше шансов заходить Потому что так может и тебя не выбирать Ну ты как бы указал что тебе интересно как бы автоматизация а потому что они смотрят думают Зачем тебе брать ручного если все равно хочешь автоматизацию объяснишь если они с тобой выйдут на разговор Ну а может быть они и тебя и не будут выбирать изначально поэтому тут может быть лучше даже два режима
01:27:13 - 01:28:25
отдельно вот тогда тогда Ну как я говорил Если пойдешь на автоматизатора вот наша общая вот эта вот часть которую мы сегодня час обсуждали Да она как правило в хорошей компании где построен процесс собеседник здесь я тестирует человек который шарит именно в автотестировании то вот где-то 20 на 20 на 20 20 минут Вот база вот этой части 20 минут спросит про пейтон и потом программирование принципы Расскажите вот это все там что такое наследование Что такое еще что-то вот и 20 процентов 20 минут вернее про конкретный инструмент
01:27:49 - 01:29:12
автоматизации который заявлял и все И может быть то может быть лайфхакинг может не быть Ну смотри в принципе я считаю что если ты разбираешься в pyth они тебя автоматизация заходит ты умеешь что наверное есть смысл на автоматизатора именно закидываться зачем особо не придет все равно мне кажется автоматизатор он должен иметь опыт ручного тестирования чтобы как-то ему это все легче давалось и узнал же какие-то там тонкости нюансы что без опыта сразу автоматизатор но можно но мне кажется это как-то немножечко
01:28:33 - 01:29:44
тяжелее не Александр на самом деле такой часто бывает что автоматизаторов нет опыта ручного это нормально Ничего страшного и я тебе рекомендую чтобы сконцентрировано вот если тебе нужно работать к автоматизации бить именно в автоматизацию Потому что если ты устроишься как automation Junior допустим да то скорее всего ты попадешь в команду где есть другие автоматизаторы Где у вас будет какая-то культура разработки То есть у вас будут коды View у вас будет нормально настроенная вот этот гид система и ты
01:29:24 - 01:30:51
научишься практикам именно написание кода хорошему вот этим это важно потому что если ты устроишься ручным тестировщиком Да С одной стороны ты будешь Лучше понимать может быть тестирование даже фундаментально но ты не получишь никаких навыков хороших работы с кодом с программированием А это автотестировании важнее это в итоге важнее чем быть именно хорошим теоретиком тестирования поэтому я тебе рекомендую именно бить в автоматизацию тем более собеседование по автоматизации сложнее и конкуренция в автоматизаторов
01:30:09 - 01:31:24
не такая высокая как у ручных тестировщиков вот так что очень рекомендую так даже если вот у тебя будет Вариант где будет одно одна вакансия типа автоматизатора другая там иногда сейчас любят такое 50 на 50 там 30 на 70 вот это все вот если будет выбор Цельсия туда где именно тебе обещают стопроцентно автоматизацию не без всяких совмещений потом в будущем когда ты в качаешься автоматизацию там Чего угодно будешь делать захочешь там 50 на 50 захочешь Там чисто технарь автоматизаторы Не важно но на
01:30:47 - 01:31:59
перспективу это лучше чем идти через ручную потому что ну вручную тоже хорошо Я ручную тестировщик уже 9 лет летом будет в июне Вот и деньги зарабатываются и сфера востребованные все дела Но это просто несколько Иной путь поэтому допустим я не был готов на старте учить программирование и биться в эту сторону вот сейчас уже может быть готов тогда нет А ты уже сейчас готов поэтому сосредоточиться тогда на автоматизации Идешь к лучшим результатам за то же самое время Ну если уж так получится что на
01:31:22 - 01:32:39
автоматизатор не получится возьмут Я принципе тоже не против как бы тогда просто ты пойдешь по немножко другой [музыка] вот так еще какой-нибудь вопрос да Нет в принципе все тогда хорошо что ты пришел ко мне сегодня Спасибо тебе спасибо тебе что позвал что даешь этот опыт который так нужен именно вот в разговоре когда ты сам читаешь и сам собой грубо говоря разговариваешь это все равно как-то не так а тут Практика это Огромное спасибо отлично хорошо тогда Удачи тебе в поиске новой работы хочешь на паблос подписывайся Пусть и на
01:32:02 - 01:33:42
мой за соточку если накопишь такие деньги вот там у нас принципе мы эти самые друг у друга смотрим и какие-то мудрые советы даем то у меня есть джуниоры и автотестеры есть опытные Так что там можно и завтра тестирования спрашивает тоже вот ну и так надеюсь что у тебя ближайшее время получится найти вакансию которая тебе нужна Ну как он собеседование Александр показал очень достойные знания в области тестирования программного обеспечения может быть не идеальные но в любом случае на моем опыте не так много
01:32:58 - 01:34:16
джуниоров которые могут так хорошо раскрывать некоторые вопросы в конце собеседования я все-таки посоветовал Александру сосредоточиться на конкретном направлении то есть в его случае это автоматизация тестирования в ней Разумеется также необходимо знать теорию тестирования но она составляет лишь часть необходимых знаний в любом случае желаю ему Удачи в поиске работы вам Напоминаю что у нас есть ссылка внизу под видео где вы можете записаться на подобное интервью либо же можете записаться на приватное интервью по
[музыка] Всем привет У нас сегодня новое собеседование на Junior Kay с нами сегодня Александр он идет интересным путем пытается одновременно устроиться на ручного тестировщика и на автоматизатора оба Junior в любом случае для обеих специальностей потребуется знание теории тестирования которая и для ручных тестировщиков и для автоматизаторов в принципе идентичны поэтому смотрим видос Итак привет Александр расскажи пожалуйста чуть-чуть про себя чего бы ты хотел о себе узнать какой у тебя опыт тестирования
00:00:01 - 00:01:37
предыдущего если есть или обучение может где-то учился зовут Меня Александр Мне 26 лет в конце прошлого года завершил обучение по направлению автоматизация тестирования на языке программирования поэтому Вот соответственно хочу пройти собеседование на позицию мануального тестировщика Джуниора вот опыта коммерческого не имею только вот тестовый тестовый проектор Окей понятно Хорошо смотри в принципе если ты вдруг соберёшься где-то проходить собеседение на именно Junior автоматизатора от начинающего Да там обычно собеседование
00:00:53 - 00:02:31
состоит из трех частей Первое это часть которая касается общей теории тестирования это то о чем мы сегодня в принципе поговорим по сути мануально датировщика та же самая теория потом у тебя будет часть вторая третья беседование это будет именно вопросы по базам твоего языка программирования который ты выбрал твоем случае питон Да может быть или какой-то еще и третья часть обычно на таких собеседований это вопросы по непосредственно технологии авто тестирования То есть например если ты выбрал там селение мапиум
00:01:42 - 00:02:53
библиотеки для того чтобы тестировать через ЮА тебя будут спрашивать по ним там да какие там особенности Какие основные команды если будет какой-нибудь Другое Другая технология тебя по ней будут спрашивать просто чтобы ты знал что ждать на автоматизаторы и соответственно особенностями будет являться то что обычно собеседование будет где-то час идти и поэтому каждый из этих блоков будет довольно короткий И в частности вот этот блок который будет про теорию тестирования он будет прям совсем обычно сжатый То есть
00:02:18 - 00:03:21
автоматизаторов если ты видишь как автоматизатор Ну минут 20 по каким-то самым базовым вещам спрашивать в то же время если ты пойдешь каким-то причинам на ручное тестирование это будет по сути все собеседование вот эта часть вот как у нас будет и сегодня просто чтобы понимать Хорошо давай тогда поговорим про тестирование Расскажи пожалуйста что такое тестирование тестирование это процесс исследования программного продукта целью которого является соответствие проверка соответствия между ожидаемым поведением программ и
00:02:50 - 00:04:06
фактически где мы выявляем ожидаемое поведение Откуда мы выберем из требований а если нет требований Ну значит на основе пользовательского опыта возможно требования к другим проектам То есть если были другие проекты схожие можно взять требования с этих проектов [музыка] а если не было схожих проектов вот ты как Junior пришел Ты еще не тестировал никогда подобные проекты первый раз и требования нет что тогда будем делать Ну на основе пользовательского опыта хорошо то есть примерно понимаем как например
00:03:28 - 00:04:56
работает интернет-магазин Что там примерно должно быть и вот на основе этих знаний будем тестировать отлично супер Кто у нас является источниками если у нас есть документация допустим плохая у кого можем уточнить какие-то вопросы менеджер может быть а еще У нас есть еще иногда бывает не всегда но бывает отдельная должность которая отвечает за древний бизнес-аналитик не везде в крупной компании будет в маленькой не будет И опять же зачастую У нас есть иногда не всегда иногда есть выход на самого
00:04:12 - 00:05:38
заказчика то есть в некоторых небольших проектах заказчик же является и project-менеджером то есть грубо говоря либо у Project менеджера есть там письмо и он может сказать так некогда сейчас что-то выяснять вот почта заказчик сказал он ответит На любые вопросы если что и ты получается как бы пишешь заказчик говоришь что там на вас работаем типа у нас непонятка Да как мы это вопрос реализуем Какие цели тестирования Ты знаешь тестирование Ну проверка соответствия вот то что как бы сказал основная цель
00:05:03 - 00:06:19
а другие какими знаешь Ну я знаю принцип и тестирования это не то же самое ну пускай будет то же самое Расскажи про принципы Ну во-первых исчерпывающее тестирование невозможно то есть мы должны понимать что все протестировать принципе нереально все комбинации все Точнее то как может повести себя пользователь первый принцип второй принцип тестирования демонстрирует наличие дефектов они их отсутствие То есть если приложение протестировано это не значит что в нем нет дефектов как бы дефекты в любом случае могут быть
00:05:49 - 00:07:11
они скорее всего будут так ранее еще один принцип это ранее тестирование сохраняет время и деньги Чем раньше мы начнем тестировать тем соответственно сэкономим скорее всего время разработчиков которые потратят меньше на устранение дефекта ну и соответственно деньги еще один принцип это скопление дефектов и к примеру если в каком-то модуле найдено два дефекта а в другом модуле 5 то скорее всего там где 5 Будут еще найдены ошибки то есть вот такой принцип Ну и Парадокс пестицида Да это как Что означает что нужно
00:06:34 - 00:08:18
со временем менять свои тест кейсы вот читал в интернете такой пример как это как травят паразитов и они со временем адаптируются к отравили И вот так же примерно И тут со временем либо это должен писать эскиз другой человек чтобы посмотреть на ситуацию с другой стороны и был другой набор тестов ну в принципе верно не совсем только тот для того чтобы бороться с парадоксом пестицида нужно не тест ты там менять их вот а внутри теста как правило менять данные на вход то есть с пестицидами проблем не в том что Жуки привыкают ко
00:07:28 - 00:08:50
всем пестицидам привыкают к конкретному Поэтому иногда следует в шагах указывать например нечёткие шаги например вот мы Тестируем логин и пароль вот логин и пароли и мы можем в тесте написать вести админ поле пароль поле логина да А можем написать вести валидное поле логина и пароля таким образом каждый следующий раз когда тестировщик один или будет несколько человек будет проходить этот кейс он может писать что-то разное В поле логин и пароли Главное чтобы он был валидный то чтобы система принималась вот о чём э
00:08:10 - 00:09:16
Парадокс с пестициды в первую очередь о том чтобы текст тесты сделать иногда чуть менее подробными для того чтобы вот эта ситуация избежать хорошо Это были принципы не цели но тоже очень правильно сказано в принципе всё верно вот можешь себе пометить что есть еще цели тестирование есть несколько классификаций в них Обычно по три цели выделяется у разных авторов по-разному Выбери какой тебе понравится и на всякий случай Изучи могут на собеседование спросить и лучше их ответить простые там обычно например там
00:08:43 - 00:10:03
предоставление информации о качестве продукта выявление багов непосредственно и допустим проверка что выполняется все цели и сроки разработки да то есть ты как бы не только качество конечного продукта подтверждаешь но и контролируешь что ваш процесс разработки не буксует вот собственно Вот например ну бывает и другие классификации этих целей просто где-нибудь Какие проще такие выучить хорошо виды тестирования Какие тестирования это знаешь функциональные не функциональные их Также можно подразделять на
00:09:23 - 00:10:49
тестирование по степени автоматизации по позитивности сценария по доступу коду тестирование производительности нагрузочное тестирование тестирование локализации тестирования удобства пользования регрессионное тестирование Smoke тестирование ценники тестирование [музыка] Хорошо хорошо безопасности нагрузочное тестирование на самом деле нагрузочное тестирование это одно из видов тестирования производительности Ну да и там еще несколько есть вот поэтому тут Аккуратнее лучше просто мне производительность если будут подробно
00:10:08 - 00:11:38
спрашивать что там конкретно нагрузочная и стрессовая есть еще какой-нибудь Хорошо давай про там тестирование локализации что тестирование локализации входит смена перевод языка во-первых далее Возможно это перевод единиц валюты это ростовки если это может быть какой-то магазин размеры обуви там европейские корейские там какие там есть разные это формат даты формат времени [музыка] тестирование инсталляции она проводится на нативных приложениях проверяется установка удаление обновления отлично супер
00:10:55 - 00:12:51
разноцветные ящики знаешь про них что-нибудь Да есть черный ящик белый ящик серый ящик это наш доступ коду метод белого ящика это мы имеем доступ к коду и как сказать это тестирование Юнит тестирование да то есть это вот что тестирует приемник тестирование [музыка] [смех] Но это [музыка] как языка отдельный класс требованием Отлично так черный ящик у нас черный ящик подразумевает что мы не имеем доступа к коду или Тестируем как конечно пользователь тестами мы покрываем что функционал бизнес требования бизнес
00:12:04 - 00:14:07
требования так хорошо а серый ящик серый ящик это пограничное такое то есть мы понимаем Как устроена как работает система но в то же время доступа к коду не имеем Ну понятие размыто и на самом деле в разных источниках все это пишется по-разному но [музыка] как это применить на практике я сидел думал мне показалось что можно сюда отнести например тестирование баз данных то есть мы понимаем как это все устроено но как бы как-то так чаще лучше Привести примеры может быть а допустим тестирование может привязан быть базы данных может не
00:13:21 - 00:15:04
привязанность когда на запросы ответа запрос отправляем руками Пишем да и получаем ответ тогда получается что мы вроде как и не бизнес логика Тестируем мы все-таки внутри под капотом уже запрос руками пишем но при этом мы не знаем как работает наша база данных читать кот и не покрываем про стеклянный ящик слышал когда Нет это то же самое что и белый изначально литературе называлась стеклянный иногда на собеседование говорят стеклянный чтоб ты не потерялся стеклянный белый ящик это одно и то же хорошо
00:14:14 - 00:15:35
так про автоматизированное тестирование в принципе в общем можешь рассказать чем она от ручного отличается Ну мы пишем тесты на языке программирования которые запускаются там внутри запускаешь они проводят автоматически тестирование То есть это при написанных уже тестах сокращает время и наиболее нами применимо Это революционных тестах где мы уже все в принципе вручную проверили и чтобы по сто раз при добавлении нового функционала нам не проверяет и вручную вот создают автоматизацию здесь можно Можно также при тестировании API
00:14:59 - 00:16:32
Да это можно всякие части в постные запускать в виде авто тестов хорошо хорошо негативный тест сценарий подразумевает собой то что программа правильно отреагирует на попытку на попытку неправильного действия пользователя то есть не что программа подразумевает собой что пользователь может повести себя как-то некорректно и программа должна на это правильно отреагировать что у нас обычно ожидаемое поведение в негативных тестах какая Так сейчас я но мы пытаемся сломать систему она этого не дает А что она что она делает когда
00:15:47 - 00:17:25
ошибку Ошибку бывает еще допустим кроме ошибки какая реакция систем например сейчас принято в некоторых сервисах просто не давать тебе сделать физически что-то например ты вводишь поле ввода русские буквы система принимает только английский и ты просто нажимаешь на клавиатуру ничем не заполняется ошибки нет но и ничего не происходит есть у нас еще такая градация как статическая динамическое тестирование о чем это статическое тестирование это тестирование туда можно отнести тестирование требований можно
00:16:52 - 00:18:13
аналитическое это уже соответственно непосредственно функционала в чем разница с разные виды можно провести туда туда в чем граница находится наверное что мы не при статическом и наверное не пользуемся самим приложением мы запускаем код основная разница Хорошо Окей Ты говорил про Цените смогли грешен там применительно к автоматизации можешь принципе рассказать про эти три вида тестирования тестирование это набор минимальных тестов направленных на проверку основного функционала программного обеспечения
00:17:42 - 00:19:14
Цените тестирование это углубленное тестирование какого-то определенного функционала а регрессионное но это мы предъявляем то что новый функционал не сломал наши старые функции которые были так и есть можем мы без какого-то из этих видов тестирования в принципе существовать отказаться от него допустим в какой-то момент но Оцените явно мы не можем Но регрессивная наверное потому что оно когда-то было Цените скорее всего и оно уже было проверено но опять же здесь варианте Мне кажется будет прям хорошо
00:18:31 - 00:19:58
применимо автоматизация что мы функционал добавили отправили функционала регрессия это автоматизация ты попадаешь на проект на первый реальный вариант сейчас попадаешь на проект Ты один и тебя взяли руками тестирует ты говоришь я сейчас развернул фреймворк автоматизации все будет вообще чики пуки тебе говорят нет Александр времени нет на это руками у тебя мало времени и ты такой говоришь Ладно я могу протестировать руками но я все не успею тебе говорят Ну Выбери тогда что ты успеешь Какие вид тестирования Ну только скажи почему ты
00:19:16 - 00:20:45
их выбрал вот от какого бы ты из этих трех видов тестирования мог отказаться и почему регрессивная а почему потому что мы это уже проверяли и что значит что там минимальный минимальная вероятность что это будут найдены дефекты минимальная вероятность что будет найденный дефект мы это хотя бы раз уже видели все и наша функциональность Она обычно регрессивные кейсы не затрагивает если он затрагивает Мы обычно эти тесты туда же пихаем с Анти тестирование так как они связаны допустим А если вот например
00:20:04 - 00:21:23
вопросы нам говорят что мы Ну нет времени на регрессионное тестирование мы от него полностью отказываемся но потом находится там дефект ответственность будет тестировщики за этот дефект или как бы смотри когда ты отказываешься от регрессионного или если ты хочешь отказаться от регрессивно ты это не делаешь по своей воле просто сегодня я решил что не буду одна из важнейших функций тестировщика доносить информацию в it-компаниях ты доносишь информацию до своего менеджера Поэтому такие решения Какие виды тестов будут принес как что
00:20:48 - 00:21:57
ты согласуешь со своим project-менеджером или дом тестирование если есть либо имя обоями То есть ты говоришь есть такие-то риски мы вот так-то не успеваем давайте у нас есть два варианта либо мы отодвинем релиз если нас это возможно чтобы у меня было время пройти все виды тестирования либо я не буду проходить Ну или там сколько успею как обычно ты можешь все-таки успеть Ну типа не все неполноценно там прогрессию или вообще не пройду тогда есть риск что будет но риск маленький очень но есть и Project менеджер решает
00:21:24 - 00:22:37
он говорит Слушай нам нужно релизиса капец хрен с ним шансов мало значит будем рисковать Ну если выйдет менеджер взял на себя риски соответственно предоставлять информацию менеджером они уже потом решают что делать Окей есть еще там градация такая уровне тестирования называется или еще иногда называют виды тестирования по степени изолированности компонентов какие там бывают уровни помнишь модульные интеграционный системный и приёмочный Так чем они отличаются все модульный Это самый низкий уровень
00:22:00 - 00:23:33
Там тестируется вот белый ящик кот в отрыве от бизнес требований интеграционное тестирование это проверка связи между компонентами и взаимодействия с различными частями приложения система тестирование проверка функционала и требований в целом то есть как работает система в целом а приёмочная тестирование как бы это завершающая которая дает понять Готова ли приложение к выпуску один Документ и на нем завязано приёмочная чтобы мы решили что система готова к выпуску мы должны о чем-то договориться
00:22:51 - 00:24:30
и как-то оформить Ну так отчет о тестирование Ну не совсем отчет тестирование Когда мы уже провели А в приёмочную тестировании есть такое понятие ацетам сплан или по-русски план приёмочных работ формально называется мы заранее выбираем тест кейсы которым будем проходить и согласуем их с нашим заказчиком и мы договариваемся что если мы проходим эти тесты вот сейчас мы значит сдали систему если они не проходят Значит мы не проходим от тестирования Значит нам надо типа продолжить работу пока мы его
00:23:45 - 00:25:02
не пройдем вот Вся фишка Ну на самом деле во многих источниках более старых есть только три уровня модульная интеграционная системная приёмочного нет поэтому иногда иногда на собеседование можно сказать что есть три вида тестирования не говорить про приёмочные и ты пройдешь Дальше те вопросы никто не спросит иногда где приемы а иногда ты скажешь я тебе скажут Почему от системного отличается да такой ну есть план приёмочных работ А еще а еще как бы сложно сказать поэтому что серый ящик Что 3 или 4 уровня
00:24:23 - 00:25:47
тестирования Да это примерно одна и та же история Почему серым ящиком проблемы потому что вы тоже изначально не было во всей литературе базовой есть белый ящик черный никакого серого нет серый потом додумали также и уровнях есть модульная интеграционная системная додумали потом где-то кто-то приемы поэтому на реальных событиях тут надо ловить волну иногда план вот этих приемщик работ хорошо техники с дизайна Зачем нам нужен вообще какие-то техники что они нам дают но техники тест-дизайны это вообще
00:25:06 - 00:26:17
правила и подходы позволяющие при наименьшем усилии получить наибольший КПД скажем так вот и существует такие техники DTS дизайна как эквивалентное разделение анализ ограниченных значений таблица принятия решения парное тестирование диаграмма перехода состояний вот самый любимый на собеседование ковалентное разделение Ты можешь объяснить да Значит мы разделяем наше значение на классы подразумевая то что каждое значение внутри класса на каждое значение внутри класса программное обеспечение будет
00:25:50 - 00:27:30
реагировать одинаково так и это нам дает что это нам сокращает количество тестов то есть нам не нужно все значения одного класса проверять мы можем выбрать одно или там минимальное количество значений класса Да отлично супер хорошо Ну и вот если допустим нам нужно протестировать поле ввода логина Как мы можем применить эту технику Какие конкретно проверки мы можем сделать использовать технику разбиения на глаз но делим на класс это латиница кириллица цифры спецсимволы вот и нам не надо тестировать все буквы все цифры все СПИД
00:26:43 - 00:28:13
символы Нам необходимо минимальный набор какой-то вот взять из каждого класса этого будет достаточно все верно хорошо отлично и анализ граничных значений Как работает и на том же примере допустим на поле ввода анализ ограниченных значений связи с особенностями разработки вот наиболее вероятен дефект именно на стыке класса эквивалентности скажем так вот и при тестирование необходимо брать границы на этих классах То есть к примеру сложно рассказал перехитрил сам себя лучше что вот у нас есть интервал
00:27:28 - 00:29:04
интервалы которые чаще всего используются для того чтобы провалидировать там длину строки какой-то или еще чего-то в данном случае допустим с полем логина У нас есть обычный интервал минимальный максимальный длинный логина и проблема во-первых в том что вот эти интервалы они могут быть очень большими То есть это может быть от 10 до 20 может быть от 10 до 1000 допустим например в поле логин вряд ли бывает тысячи символов ограничений каким другие поля допустим бывает и для того же самого для того чтобы тебе весь
00:28:19 - 00:29:29
длиннющий интервал внутри не проверять каждое значение Мы допускаем также как и с классами ковалентности который носили мы допускаем что если мы возьмем парочку значений внутри интервала и парочку значений снаружи интервала мы можем проверить работу всего интервала мы сокращаем количество уходных сценарий и второй вопрос уже как конкретно мы Какие конкретно Мы берем значение чтобы проверить весь интервал Да И вот тут мы уже говорим о том что на стыке позитивных и негативных значений мы проверяем работу интервала и вот можно
00:28:55 - 00:30:15
привести пример вот допустим интервал от 10 до 20 У нас есть какие бы мы взяли проверки чтобы протестировать весь интервал минимальным количеством способов от 10 до 20 так 10 и 20 это у нас внутри Ну значит мы берем -1 это 9 берем 10 берем 19 и берем 20 а нет 20 21 20 у нас внутри интервала можно запутаться немножечко можно поэтому ладно не торопиться все правильно Да еще в некоторых источниках пишут что необходимо взять где-то в середине чтобы уж точно удостовериться и тоже рекомендую сделать То что на практике
00:29:35 - 00:31:14
тоже Всякое бывает лучше взять Как ты думаешь Вот такая проверка на возможно только на числовом интервале или на алфавите тоже можно проверить такое значение Например у нас есть требования чтобы там есть у нас список имен и системе которым мы Тестируем можно отфильтровать имена по интервалу вот можем мы по буквам как-то Ну конечно Ну мы же до Можем отсортировать по алфавиту то есть И вот проверку этого можем провести Да да конечно работает абсолютно также потому что компьютерная система не только знают
00:30:24 - 00:31:48
длину Ну какие числа за какое За каким идут автоматически они также знают все алфавиты поэтому тебе могут на собеседование реально попросить допустим и не числовой интервал допустим от 10 до 20 как сказали алфавитно сказать вот допустим значение Матвей до же русского алфавита или английского и подумать также получается можно и со временем то есть скидки только в четверг примеру с нуля 01 там календарными сложнее потому что там надо Ну в принципе система конечно известно система знает как время системно выстроены и она может
00:31:07 - 00:32:35
отталкиваться но там важно откуда система берет время бывает что время бывает берется с браузера бывает что время берется с бэкенда сервера то есть сервер у сервера свое время есть И кстати говоря это часто ошибка в реальных системах которые ты будешь тестировать если что-то будет завязано на времени то есть конечный пользователь будет пытаться скидка применить Как пример привел или что-то еще сделал потому что у него жена стал Новый день а сервер будет думать что еще не настал и не будет выпускать и
00:31:58 - 00:33:01
при этом ничего толком не сможет сказать и пользователь потеряется хорошо отлично супер Давай поговорим про тестовую документацию какую-то знаешь тесту документацию который тестировщик создается чек-лист кейс Back Report план сначала что это такое план Это документ который описывает весь объем работы берем указывается что нужно тестировать Когда нужно тестировать критерии начала тестирования критерий окончания возможно какие-то инструменты там что нам необходимо там телефоны стенды что-то еще что-то еще
00:32:33 - 00:34:01
там какие Компьютеры ты когда им писал сантосплан Нет но я знакомился с ним и видел там матрицу соответствия требований вот меня это прям так вот запомнилось что там требования и указано в каком тест кейсе это требование проверяется то есть по этой матрице определяется покрытие всех требований тест кейсами Круто А вот представляешь себе ты вот сейчас пойдешь на собеседование Да и техники берем ты будешь единственным нашим тестировщиком который нам расскажет как надо тестировать ты приходишь на проект
00:33:26 - 00:34:49
ты сможешь написать будешь его писать или он не нужен или как Но если как бы не является обязательным требованием то наверное не буду как я напишу наверное какую-то себяшку такую для себя на самом деле я советую писать всегда даже себяшку на коленке в Google доки на одну страницу Потому что часто в компаниях которые тебе будут нанимать единственным тестировщиком стартапах там никто не знает что должен делать тестировщик и написав тест-планты не просто выполняешь какую-то формальность ты буквально показываешь что тебе мешает
00:34:15 - 00:35:26
что тебе поможет в принципе будешь делать И это на бумагу на Google бумагу вносится и когда ты показываешь другим членам команды они лучше понимают что тебя вообще ожидать потому что иногда такое бывает что когда устраиваешься в небольшие компании ожидание с реальностью на тебя обижаются говорят Ну что Александр не умеешь тестировать безопасность тестировщики вообще не занимаются отдельно темы А я думал занимаются А что не сказал непонятно начинается Но если ты в тест-плане написал что будут применяться
00:34:50 - 00:36:05
такие твит тестирования такие твит тестирования не будут все вопросы этого не будет все посмотрели глазами сказали Я понял принял вы договорились на бумаге поэтому тест-план это не просто какая-то часть документация там формальность это огромный помощник для того чтобы тебе было проще в дальнейшем защищаться от каких-то там непонятных вопросов и так далее ну и плюс это помощь когда расширяется штат тестировщиков и тебе приходит новичок ты можешь дать почитать сначала потом рассказать что вы делаете
00:35:28 - 00:36:39
тоже свои плюсы поэтому Я рекомендую написать свою спал хотя бы раз и тренироваться в этом не обязательно должен быть там красивый на 20 Листовка простая на коленочная она решает те же самые задачи красивые тест-план нужен когда заказчику надо показать когда там какой-нибудь большой заказчик который любит вот эти вот документы которые оформлены в стиле дипломные работы чтобы кирпич был потолще чтобы оглавление было Вот это запарно Я согласен но если такого не требуется хотя бы на коленочки Вполне
00:36:03 - 00:37:17
себе Окей Что такое тест кейс Это документ описывающих последовательность действий для проверки функционала что он себя включает Первое это ID модификационный какой-то номер это название это исполнитель соответственно кто написал этот тест кейс это окружение это [музыка] шаги воспроизведения и ожидаемый результат также Сюда можно внести окружение и какое-то предусловие Что необходимо сделать перед тем как начинать этот пост условия Что нужно сделать что такое чек-лист чек-лист Это список проверка
00:36:40 - 00:38:41
так из чего он состоит так он состоит из также индификационного номера название [музыка] также наверное исполнителя окружения и список проверок которые в итоге мы вернулись к слову список проверок Ну обычно так говорят что чек-лист состоит из проверок который называется чеками чек-лист список проверок это из названия выходит и каждая вот эта проверка она представляет из себя ровно одно предложение где мы пытаемся описать всю суть проверки просто максимально вот сжато короткими словами иногда в принципе можно даже провести аналогию
00:37:53 - 00:39:16
между названием и чеком из чек-листа потому что в принципе они выполняют одну и ту же роль они говорят о сути проверки просто есть еще потом есть большое содержимое А в чеке больше ничего нет Вот и мы как бы примерно понимаем по чеку по названию что мы должны сделать Да это как бы название тест-кейса совмещенное с ожидаемым результатом этого ты совмещаешь и получается название чек-лист что-то вроде того Да зачем нам одновременно для вроде как одного тоже для того чтобы хранить тестовый сценарии
00:38:36 - 00:39:47
есть значит Широкая версия Да как тест есть вот какая-то сдержанная версия как чек-лист но чек-лист он предназначен для человека который знаком с проектом который не потеряется притом каком-то непонятном действии которое от него требуют в чек-листе все это подробно расписано куда нажать как нажать сколько раз что ввести то есть если в чек-листе мы просто пишем к примеру там зарегистрировать пользователя нового пользователя то чек-листе там нажать туда логин порой нам нужно четко выявить допустим
00:39:10 - 00:40:46
ситуацию ты приходишь проект написал Ты сплан на коленке как смог и такой Окей мне нужно писать тесту документацию на какие критерии вот ситуации что вокруг тебя происходит Ты будешь опираться и что-то выберешь в этом случае сложность проекта первая наверное потом так если проверки сложные тогда какое мы выбираем документацию так дальше количество тестировщиков на проекте единственный или несколько тестировщиков если несколько тут эскиз как бы я напишу в чек-листе одно тестировщик может другой это не понять как бы если мы не
00:40:00 - 00:41:26
знаком там с функционалом приложением так еще наверное Ну надо проанализировать нужен вот мы напишем если тест кейс нужен ли он будет кому-то в дальнейшем Ну то есть насколько приложение вообще потенциально она рассчитана То есть это какой-то долгоиграющий проект либо это вот что-то такое быстрее мимолетное нам не стоит затрачивать время бывает часто тебя приглашает на работу говорят у нас проект на три месяца стартапчик ты будешь один Через три месяца самое время для чек-листа во-первых нужно только мне читать никто не будет
00:40:47 - 00:42:04
во-вторых у нас очень мало времени на тестирование если мы будем слишком большие сложности писать мы само тестирование не проведем В итоге три месяца оформляйте Потом проект закончится и все окей Окей отлично так багри по Что такое Из чего состоит также как и предыдущие документы это индификационный номер Это название это приоритет это предусловие это шаги воспроизведения ожидаемый результат фактически результат это ну и дополнительная какая-то информация это может быть скриншоты скринкасты логи всевозможные То есть то
00:41:29 - 00:42:57
что может помочь разработчику понять из-за чего это все сломалось или как найти этот дефект еще нас бывает там автор указывается Кто создал чтобы было понятно просто создавать и бывает указаны еще сайту то есть наклон на данный момент задача висит чтобы разобраться кто в данную секунду на ней не сказал обязательно это наверное окружение указывается где этот был бак воспроизведен окружение Ну из версий наверное приложение еще то есть Какая версия если их там несколько вот ну это обычно оно может все вместе называться окружением
00:42:17 - 00:43:43
Вот это слово окружение Оно такое гуляющее оно может отвечать и за версию кода который ты тестируешь и за там железа на котором тестируешь Это обычно все в слове января указывается и так далее хорошо отлично жизнь цикл бак-репорта Давай обсудим вот репорт Ты завел вот Представьте ситуацию самым пока простую простой что дальше происходит находим бак получается у него статус новый То есть мы его нашли впервые соответственно мы его направляем получается на исправление то есть открываем и направляем на
00:43:02 - 00:44:28
исправление разработчику разработчик исправляет фиксит бак возвращает нам мы перепроверяем если все хорошо закрываем если бак воспроизводится Значит мы его переоткрываем и назад разработчику отлично супер вот представим ситуацию вот бак воспроизводится ты его опять переоткрыл разработчик его пару раз Починил Ты все равно решил воспроизводится в какой-то момент этой итерации разработчик говорит сочинить не буду у меня не воспроизводится Я устал Я занятой человек отстань от меня Александр со своими багами я пошел фичи новые делать
00:43:49 - 00:45:19
Мне некогда заниматься статусом что у меня работает Что ты будешь делать но наверное в первую очередь проверю сам себя то есть как бы в то ли то ли версия тестируется то есть одинаковые ли у нас версии с разработчиком может он уже там новую версию у разработчиков своя версия вот тестировщиков еще не дошла И мы там на разных языках общаемся вот этот вот это наверное проверю Что еще можно проверить но окружение Возможно если все вот полностью я уверен что бак есть и все у нас одинаково Ну наверное это вопрос должен решать кто-то
00:44:37 - 00:46:13
выше то есть надо снять себя ответственность доложить Как говорится Вот ну да ты то есть момент на самом деле очень часто ошибка у дженеров в реальных проектов Когда приходишь и ты бак завел Ты доволен нашел проблему я не бесполезные члены А теперь все говорят Да и хрен с ним Ну да вообще садится такой что как вот репорт чинить они говорят Да у нас есть дела поважнее и там чем-нибудь еще и ты теряешься и многие начинающие тестировщик они начинают бычить они начинают ты чё ты чё Вот и этим самым отвлекают
00:45:28 - 00:46:57
программиста там начинается нехороший иногда отношения вот чтобы этого не было да ты зарепортил ты пару раз искалировал с разработчиком не получается Он не хочет продолжать с ним работать так же как вот мы помнишь говорили там регрессию да кто выбирает или нет В итоге решает менеджер Так мы сообщаем менеджеру говорим менеджеру говорим я вижу бак Он не видит не хочет видеть что с ним делать и в зависимости от того какой у него статус что-то на проекте так далее менеджер может сказать Ну закрою либо может сказать
00:46:14 - 00:47:35
разработчику скажем так все отбрасывает не можешь можешь Давай до работы этот вопрос и если вдруг твой бак его все-таки решили что Да он есть допустим надо убрать твоя задача просто как можно больше оставить письменно доказательств в комментах написать что вот такой там proje Major Вася сказал мне убрать его я убираю но смотрите сами типа я не виноват чтобы потом в будущем к тебе опять же не было вопросов и идти дальше работать плевать Хорошо теперь представим ситуацию когда что-то не так пошло сразу
00:46:58 - 00:48:21
завел табак разработчик такой сразу говорит а не буду делать потому что по каким причинам может какие там статусы бывают когда сразу не хочет очень ну наверное это дубликат может быть дубликат это уже есть такой бак то есть они и что происходит Вот он поставил дублика что дальше происходит Ну дубликат он соответственно возвращается ко мне я я нахожу вы тот ту версию Бага соответственно нашел тот бак проверил исправлен ли тот бак или нет то есть если тот бак исправлен А этот неисправлен то есть до воспроизводится
00:47:42 - 00:49:18
бак то это получается не дубликат Ну да формально тем не менее над ним можно продолжить работу можно переоткрыть еще что-то А если тот бак изначально оригинальный в работе висит до сих пор тогда что Ну тогда мы наверное этот закрываем Зачем нам два одинаковых мы просто там помимо того что мы там закрываем еще что-то мы обычно стараемся еще там линковать есть возможность обычных программе Gran или других программах деле портится делать ссылки чтобы информация была соединена еще есть рекомендую все-таки когда разработчик
00:48:30 - 00:49:52
будет заводить такие баги пере необходимость найти оригинал до дубля на разработчика потому что очень часто разработчики любят говорить так это дубль я такой там где-то видел а ты потом целый день рабочий ищешь и ты не находишь ты говоришь А я такого не увидела разработчика Ну ладно мне показалось и ты потерял рабочий день чтобы этого не было все-таки Мы стараемся чтобы разработчик все-таки он дубликат чтобы мы убедились что все действительно так что очень часто кажется и так далее хорошо помимо
00:49:10 - 00:50:20
дубликата Что может быть еще там Ну отсрочен наверное Может быть на какой-то срок возможно отсрочен как правило его просто снижает им приоритеты кладут бы клок Там какой-то отдельный статус что еще бывает Ну наверное еще разработчик думает что это не баг или не думает может быть это так и есть не баг так вот тебе приходит задача со статусом не баг Чего ты делаешь но тут уж Надо как-то разбираться Бах это или не бак я думаю тут надо задействовать кого-то еще Наверное чтобы бывает что начиная с того что
00:49:45 - 00:51:06
перечитываешь все-таки документацию да да проверку требований еще раз чтобы понять же очередная житейская частая история ты написал Ты с кейсы по требованиям потом молча кто-то втихаря требования поменял по ним разработчик по новым требованиям написал новые изменения А ты как-то либо сам упустил либо это не от тебя зависело и ты проверял по своим старым ты с кейсам Оказывается ты с кейс надо поменять и Действительно это не Баг и тебе надо переписать тестовый сценарий вот а бывает что разработчики немножко
00:50:34 - 00:51:37
не понимает требования И вам надо вместе сесть и подумать вот что там не так Ну если ничего не помогает то вызов поддержки с воздуха вызов менеджеров А еще какие бывают ситуации когда самого начала дубликат обсудили ноты бак обсудили что еще [музыка] статус часто типа не будут делать я признаю что это я сделать не буду Потому что что не хочет наверное потому что почему не хочет Бывает такое что находишь ты Бат в части системы которая будет скоро претерпевать сильное изменение или вообще удалена То
00:51:06 - 00:52:27
есть ты нашел на сайте в разделе бака раздел будет полностью вычищена там следующим спринтеле в текущем Он говорит Да я признаю что есть бак но нет смысла чинить Мы скоро все оттуда удалим нахрен тоже на всякий случай менеджеру Правда он может сказать допустим Да завтра удалим а может сказать не это разработчику показалось ничего удалять не будем а если будем то через полгода и тут тоже либо принимаешь эту ситуацию либо разработчику вырежешь Да конечно когда ты это удалиться Но это будет не завтра Так что давай чини вот много
00:51:58 - 00:53:00
ситуаций бывает тут желательно в них ориентироваться так хорошо хорошо виды приложений какие ты в принципе знаешь виды приложения которые у нас сейчас на рынке существуют веб-приложения нативные и гибридные Отлично начнем свое приложение какая особенность их работы и тестирования в приложении это соответственно особенности это что для работы этого приложения нам необходим интернет первую очередь нам необходим браузер Вот соответственно приложение подразумевает собой общение клиента с сервером То есть
00:52:29 - 00:54:07
она общается посредством запросов ответов к серверу [музыка] что там еще такого Ну принципе разрешение на обновление требуется конечно пользователь так нет обновление разрешение все Обновили на сервере Обнови лась сразу пользователя хорошо вот процесс когда клиенты обменивается чем регулируется Так ну запросы ответы [музыка] Кто где был прописано то с чем регулируется то что должен быть такой-то запрос он из таких частей состоит такой-то ответ Ну какими-то правилами наверное Ну да правильно правилами они объединены в
00:53:25 - 00:55:01
протокол Мы даже протокола раньше писали в поисковой строке а сейчас она автоматически добавляет Ну да протокол http протокола вот да у них есть разные методы так вот давай Вопрос Из чего состоит запрос запрос из метода соответственно из URL это заголовок и тело тело запросы есть да хорошо методы какие-то статус кода [музыка] хорошо страница приходит 200 если у нас неправильные запрос поставленный сервер не знает как его обработать или 400 400 а если сервер сломался и криво там работает не поддерживается то
00:54:24 - 00:56:23
тогда Какая ошибка 500 хорошо супер класс в чем же особенность тестирования в приложении Да какие виды тестирования ты бы применил в первую очередь приложением кроссбраузерное тестирование тестирование Так что тут у нас есть такое что нельзя применить к другим Ну нельзя ли в полной мере Она ближе допустим браузер влияет да может быть мы можем проверить на этих самых верстку на разных экранах да то есть в данном случае нужно потому что устройств много и если нас адаптивная верстка то она должна правильно сжиматься
00:55:45 - 00:57:14
[музыка] соответственно проверяем как у нас на Recovery на отказ восстановления работает при отключении интернета то есть нам надо проверить что происходит если в определенной логике врубаем полностью интернет или не полностью а допустим мы можем сжимать его скорость регулировать как она будет реагировать наша система хорошо Так теперь нативные приложения обсудим Давай их особенности В чем заключается как они работают и как бы их тестировал нативные приложения соответственно они требуют установки Вот перед тем как его
00:56:38 - 00:58:08
запустить обновление Да если выходит какая-то новая версия Ну и удаление Так значит здесь у нас влияет сейчас скажу системные требования в отличие от веб-приложений то есть какой у нас железо стоит здесь у нас возможно не требуется подключение к интернету здесь у нас что еще может быть такого Требуется ли нам размещение в каких специальных сервисах чтобы установить это систему нет Как нет вот у нас есть AppStore допустим а в нем мы хотим нативное приложение для iPhone разместить А это целая история Да надо проходить
00:57:26 - 00:59:15
модерацию в этом AppStore А есть Google Play для Android приложение Вот то есть это надо учитывать при тестировании Потому что от этого может зависеть скорость релиза сейчас уже допустим в AppStore чуть побыстрее Все делается какое-то время назад я опять же это может время вернуться если не изменение правила опять изменит допустим бесполезно было релизм в Рождество католическое потому что никто не работал а потом Новый год и общем если ты до конца ноября не зарелизился значит лучше отложить до следующего года иначе все
00:58:27 - 00:59:34
просто застрянет вот еще иногда надо соблюдать вот эти правила этих площадок этого всего нету в приложении потому что там не происходит никакой модерации более того приложение в принципе не требуется никакая установка И помимо тестирования допустим установки сто раз откуда еще может нативное приложение с диска с флешки там не знаю Все правильно Да с внешнего диска с флешки с диска обычного большое количество софта до сих пор на диск продается вот еще допустим некоторые производители софта размещают свои программы на своих сайтах
00:59:01 - 01:00:28
минус Тора на сайте вот Окей хорошо так соответственно тестирование инсталляции в нативных нужно по поводу подключения к интернету ты сказал что Не совсем точно тут как лучше говорить для технической работы нативного приложения Интернет не нужен потому что вся логика приложение находится на устройстве но сейчас многие приложения имеют такой бизнес модель когда им нужно снаружи подгружать какие-то данные с которыми работает фоточки чаты файлы что-то еще то есть само приложение без Интернета работает
00:59:44 - 01:01:04
но бизнес смысла бизнес смысла работы нет потому что ему нужен интернет чтобы оно выполняла свою задачу поэтому мы можем как бы тестировать и без интернета и наличие интернета не является для нас базовой вещью но тем не менее какая-то часть тестирования может быть завязана на проверку взаимодействия с интернетом чтобы бизнес-задачу выполняла система вот в том числе вот также на отказ восстановления можем проверять только помимо отключения интернета Мы тут уже можем вводить изменения вносить какие-то изменения
01:00:25 - 01:01:42
помехи работать само устройство например уведомления от других приложений звонок на телефон аккумулятор разрядился там очень большой Спектр который именно для нативных приложений подойдет Больше допустим из телефона разрядился приложение Там могут быть баги в приложении возникнуть от этого ничего не будет просто контакт с сервером пропадет А с приложением в памяти Всякое может быть вот хорошо и также про нагрузочное тестирование можно отметить да то есть у нас допустим веби мы можем сервер грузить и так далее там
01:01:05 - 01:02:16
наплым пользователей то здесь уже с нативными это не тоже можно грузить сервер но это не такой имеет большую важность потому что большая часть нагрузки на приложение находится внутри самого устройства так гибридные приложения в чем у них фишка но они сочетаются какие-то функции нативных приложений какие-то веб-приложений Вот например могу привести в пример приложения интернет-магазин цифровой техники DNS у них приложение выполненная То есть это условно говоря браузер только в который вбита одна
01:01:49 - 01:03:14
только один адрес то есть сайт приложения То есть он не требует обновления но он требует установки как бы удаления это вообще [музыка] внутри сферы это называется тонкий клиент Если что то есть вот это вот нативная часть это называется тонкий клиент и такой подход это выбью модель То есть когда у нас есть точка входа которая устанавливается как нативное приложение ярлык свой есть и внешне она тоже часто выглядит нативным образом то есть она не Выглядит как будто вот приложение с установкой но при
01:02:32 - 01:03:56
этом внутри реализован так называемый встроенный браузер это не браузер Chrome и так далее браузер который пишется внутри как бы встроенная часть и в нем открывается веб-страницы но выглядит они как нативные ты видишь кнопку приложении а на самом деле это ссылка в этой странице просто для тебя выглядит так вот ты говоришь оно там совмещает это все ну такая тогда давай особенности тестирования Но тут уже наверное зависит от приложения как бы самого то есть конкретно какое какое приложение вот мы
01:03:14 - 01:04:29
представим что это вот вебвью с тонким клиентом значит установка требуется да Значит нужно подключение к интернету Нужно обязательно обязательно логика на сервере так вот дальше нагрузочное тестирование нужно проводить нагрузочно тут нагрузку на сервер получается как бы да да соответственно там можно еще выделить часть поэтому что тебе рекомендую во-первых это важно вопрос не только в теории Потому что ты будешь попадать на реальное собеседование и тебе иногда будут говорить вот у нас такое-то приложение как бы вы протестировали и
01:03:53 - 01:05:26
иногда вместо того чтобы там слушать подробно что за конкретно них предложения ты можешь опираться на тип так так и тебе уже ничего не надо знать что у них конкретно реализовано ты знаешь зависимости от виды приложений чтобы ты сделал и ты можешь быстро ответить как бы ты тестировал конкретно их сайт или их нативное приложение это очень хорошо на собеседование выглядит когда ты не просто потому что теоретически вопросы никому не интересно всем хочется понять какую-то пользу может принести ты можешь сказать ваш
01:04:41 - 01:05:44
сайт Я бы вот тестировал это это это вот или там ваше приложение Вот это бы я считаю в первую очередь требует проверки и они уже сразу лучше думают о тебе вот и еще я многим рекомендую чтобы прям вот четко на собеседование не забывать разницы между приложения сделать себе какой-нибудь там табличку матрицу и там столбик зависит от интернета Требуется ли обновление Требуется ли там установка требуется и три строчки нативная гибридная и там плюс поставить и ты потом на собеседовании не забудешь ничего и
01:05:15 - 01:06:26
будешь четче и быстрее называть между ними разницу глядя вот это вот шпаргалку или выучить рядышком положить потому что это важно Хорошо хорошо так и поговорим про процессы разработки немножко про методологии какие ты знаешь виды разработки методологии подходы так но есть у нас Agile это набор идеалов и принципов как бы служащих ориентиром наверное да В разработке в него он включает в себя скрам и Канбан вот есть также водопадная либо каскадная модель разработки по вот принципе такие вот там на самом деле очень много можно Да если
01:05:51 - 01:07:39
правильно лучше говорить Так что есть много моделей Но самое распространенные это значит Тоже имеет много под собой методология скрам камбан самый распространенный Вот про них типа Давайте поговорим тему экстремальное программирование что же типа вроде как отжаловать не для нас это два программиста сами собой что-то решают для тестировщика вот эти самые подходящие хорошо waterfall В чем в нем фишка как он работает waterfall он работает это основная особенность его в том что он последовательно переходит каждому
01:06:45 - 01:08:12
этапу разработки то есть и нельзя вернуться либо перескочить один из этапов Вот это нам не дает никакой гибкости обратной связи между этапами разработки вот из плюсов можно выделить здесь Наверное более более будет надежным наверное приложении на выходе То есть это как бы сказать применяется в тех областях где высокие риски да то есть там где важно не скорость разработки а качество потому что цена ошибки слишком высокая для того чтобы спешить ракеты медицина самолет так это гибкая методология Точнее ну как
01:07:34 - 01:09:11
методология набор идеалов и принципов вот но я знаю точно что там вот эти принципы есть что люди взаимодействия важнее инструментов там готовность к изменениям лучше точнее как готовность к изменениям важнее чем следовать плану потом сотрудничество с заказчиком важнее условия договора такого там по моему принципов вроде бы если там принципов много там есть четыре основные идеи Вот и три назвал там еще одна есть но не важно документ называется у него у него есть у этого же манифеста есть свой древний смешной сайт на чистом
01:08:28 - 01:10:02
http Вот и если хочется можно его почитать то есть там просто страница на ней есть эти четыре идеи есть ссылка на принципы которых дофига и никому не интересно четыре идеи можно называть а в принципе Окей так все Слыш Нет все уже все хорошо в принципе на собеседование чтобы прям наизусть Расскажите 4 идеи редко такое бывает могут Просто спросить типа про что в общем и целом манифест про то чтобы было меньше формальных движений и больше разработки но проблема заключается в том что чистого аджайла
01:09:33 - 01:10:51
нигде не существует потому что Если отказаться от договоров значит не вести документацию Ну во что это превратиться если у тебя не будет тест плана ты забудешь что-то делал вчера не будешь контролировать ничего И все это сыпется но Agile придумали тогда когда формальности было очень много когда процесс разработки он был как работают на госструктурах сейчас все друг другу носили служебные документальные всякие вещи на ранних этапах вот того же mail.ru баг-репорта распечатали на принтере и носили начальнику на
01:10:15 - 01:11:29
подпись Вот это всё это было в начале нулевых и на этой на этой почве возник аджайл типа давайте мы от этого всего откажемся Вот ну как бы что-то среднее получилось то есть от чего-то отказались например от распечатки на принтере обогрепортов Но с другой стороны все-таки жиру придумали да то есть это все перетекло виртуальный вид и какая-то документация всё-таки есть вот и в соответствии с этими принципами придумали несколько методологий вот самая популярная Это насколько я вижу и в принципе это там
01:10:52 - 01:12:01
рассказать да это гибкое управление проектом значит особенности её это то что мы время распределяем на спринты их концу каждого спринта но длится там везде по-разному там в среднем от одной до двух недель если я не ошибаюсь и в конце каждого сплита должен получиться какой-то прототип То есть то что мы можем посмотреть пощупать проверить показать заказчику чего в начале спринта обычно происходит какой процесс начались это Но это наверное постановка задач то есть определение того чем планирования дать
01:11:28 - 01:12:53
тем чем будем заниматься А как определять что там делается на планирование сели и там задача выбирается еще что происходит Ну наверное каждый может быть предлагает какие-то решения как он видит чтобы это было проще что-то такое предлагается не решение предлагается срок работы над задачей то есть устанавливается estema это каждая задача Один говорит я сделаю задачу Я думаю что можно сделать задачу За день я думаю что за три дня и вот каждый рассказывается и менеджер выбирает какой-то показатель который с которым
01:12:13 - 01:13:33
все согласны сколько заметят задачи потом берут следующие потому что иначе они не знали сколько задач взять на спринт так они во-первых задачи выбирают которые более важные Но это же менеджер как бы лучше знаки более важный А вот сроки сколько Какая задача займет трудозатрат уже устанавливается сама команда именно в процессе выбора этих задач и в какой-то момент так все мы все наши две недели забили всё планирование закончено так в процессе спринта какой там происходит [музыка] событие часто но
01:12:53 - 01:14:06
ежедневный митинги созвоны где каждый докладывает там или рассказывает что он сделал вчера что планирует сделать сегодня [музыка] подведение итогов то есть смотрим на презентация прототипа скажем так прототип это отдельный процесс демон что там еще какие слова я понял я слышал но забыл Сейчас запомнили Запиши есть еще ретро или ретроспективы это где все анализируют косяки хорошие вещи плохие чтобы следующим принте косяков этих не было там проблемы с коммуникациями проблемами с доступными каким-то вещам и так далее
01:13:28 - 01:14:53
вот Окей супер Мы в принципе обсудили практически все вопросы которые я хотел по поводу ответов Смотри вот цели тестирования Да Нам надо какие-то посмотреть принципы назад тестирование цели надо каким любые простые найти так по видам тестирования все в принципе по техникам там помнишь до ограниченное значение [музыка] границы мы покрываем не торопимся когда рассказываем отлично когда мы обсуждали что включает чек-лист в принципе есть система где действительно много всяких дополнительных данных но в большинстве
01:14:42 - 01:16:11
случаев чек-лист он и выделяется тем что у него мало полей Ты просто начал про чек-листы говорит тоже начал еще что-то еще лучше горе Так что чек-лист проверка из чеков каждый человек единое предложение в котором мы пытаемся указать проверки все вот то еще стоит чек-лист вот так конечно в каких-то системах хранения тестов может быть чек-лист будет очень сложно выглядит на самом деле он минималистичный хорошо так баг-репорт принципе хорошо назвал там подзабыл назвать автора и на ком засанина поля
01:15:40 - 01:16:54
что в принципе не критично так про принципы работы предложения вот здесь пожалуйста тоже Повтори здесь важно да что какие виды тестирования Каким видом приложения больше подойдут не чтобы не плавать и побольше назвать одну-два но там больше на самом деле есть различий вот ну и вспоминает Да что в приложении протокол http Или иногда есть версия Secure https запрос ответ методы вот ты ответил это все но не сразу немножко начали Вот и соответственно в принципе все Единственное что еще хотел сказать по видам приложений
01:16:18 - 01:17:44
когда мы говорим про гибридные приложения на самом деле нету общего понятия о том что назвать гибридными приложениями и подхода гибридности он на самом деле сейчас очень разные то есть вот есть вот этот подход Когда у нас есть тонкий клиент веб View И это не только это является гибридностью У нас есть еще гибридный фреймворки например фреймворк Самарин есть такой который Microsoft делает это тоже называют часто гибридным приложением Так вы сами да да вот Самарин тоже является гибридным приложением
01:17:11 - 01:18:30
но при этом он работает никак тонкие клиенты веб- часть оно как бы больше в нативную сторону идет есть другие подходы единственное Почему мы это не изучаем потому что это все мало распространено В отличие нашего подхода поэтому когда на реальном собеседовании будешь рассказывать про гибридность лучше начинается с того что значит есть несколько подходов к понятию гибридности самый распространенный вот такой вот про него расскажу потому что иногда собеседующий может сказать А я вот не знал про такое знаю про гибридный можно
01:18:09 - 01:19:16
сказать отлично но их мало Если у вас приложение не на самарине или на чем-то таком Давайте лучше обсудим более подходящий вот собственно и все у тебя какие-то вопросы остались Да в принципе нет но только вот может быть Не в плане тестирования Мне было интересно сейчас вот поиск работы и я джуниоров там требует там И как Вот мне интересно выглядел должен был выглядеть Junior там 10 лет назад Junior тестировщик 10 лет назад что он знал чтобы его взяли на работу проблема Джуниора 10 лет назад была в том что
01:18:43 - 01:20:03
вакансии было тоже мало было мало дженеров было мало вакансий 10 лет назад рынок АйТи он был не такой большой и по поводу что нужно было знать нужно было знать то что захочет услышать интервью Случайный момент времени примерно то же самое что и сейчас то есть во-первых то что ты читаешь и видишь вакансии это не значит что это будут спрашивать на интервью в интервью в интервью Может просто перемкнуть и он вообще про другое начнут я узнал паренька который почему-то обожал очень спрашивать по ветвлению веток в гите ручных
01:19:24 - 01:20:35
тестировщиков когда у него спрашивают Зачем ты это делаешь ведь ручные тестировщики не заливают никуда код и не беру очень редко когда они делают очень редко Если понадобится Ну это это не незнание которое вот оно нужно постоянно он говорит я не знаю что спрашивать я никаких книжек ничего не читаю ничего я знаю что есть я его спрашиваю Мне нравится мучить людей Вот и все это на такого попадаешь и ты никогда не готов или подобная ерунда вот в принципе из того что мы с тобой сейчас не обсудили что еще могут спрашивать Сейчас могут
01:20:00 - 01:21:16
попросить иногда написать какой-нибудь базовое запрос на SQL то есть буквально тебя дадут ссылку в какую Google долг и скажут напиши SQL запросто простой допустим с поиском какого-то значения Ну и ты там Напишешь Select там что-то fromw что-то так и то его даже не будут валидировать запускать при тебе ничего ты там если ошибаешься синтаксисе Но обычно никто не пристанет вот тоже на самом деле Вот Всем плевать Но вот у них там есть чек-лист где написано что знание SQL хотя на самом деле не надо Ну типа надо и второе что
01:20:36 - 01:21:45
это вот новое Прикол это epi То есть те самые запросы ответы через степи вот метод URL Да тело запроса ответ и так далее иногда спрашивают прям накапливаются есть разные методы а тему спросить какой метод Там же много это вот мы 4 распростран енные какую-нибудь Рандомный случайно из там 20 других что он делает учитель при этом все методы наизусть и хорошо знать разницу но я бы не стал Я бы лучше просто на другой собеседование пошел где тут не спросит либо мне встречались такие мне рассказывали что на некоторых собеседованиях Junior
01:21:13 - 01:22:43
это когда ходят их начинают при том что есть много программ по тестированию API вот по вот спрашивают программу постман вплоть до того что кого-то спрашивают А какие там вкладки как они называются я не могу допустим тебе сказать выучить постман наизусть знаешь там сделай скриншот Положи рядом И это но на некоторых собеседованиях такое можно встретить то есть общую такую девиацию можно встретить везде то есть всегда есть шанс попасть на вопросы которые очень странные которые подходят и все но большинство вопросов мы вот сейчас
01:22:03 - 01:23:19
проговорили и соответственно можешь чуть-чуть посмотреть как пишется SQL если это совсем как бы это ты не в курсе и можешь чуть глубже почитать про API и вот программа постман может быть через пару месяцев какая-то другая будет Вот умереть без него можно это вот действительно так вот в принципе когда ты откликаешься на вакансию сейчас пол дело если тебя пригласили на Собес потому что тебе просто часто не приглашаю поэтому очень важно хорошее резюме чтобы оно прошло первичный отбор а первичный отбор резюме для первого
01:22:42 - 01:24:11
собеседования сейчас часто происходит через ключевые слова то есть в первую очередь на твою резюме смотрит не живой человек а автоматизированная система которая читает ключевые слова Поэтому если у тебя хорошие резюме на него до него хотя бы дойдет живой человек а если не очень медбраковывает автоматизированной системы все те никто вообще ничего не ответит вот когда ты начнешь попадать на реальный собеседник в принципе не проходить тихо попадать на них это уже пол Победы на самом деле это хорошо
01:23:29 - 01:24:35
Значит я хорошее резюме Ты в нем сделал Все грамотно по возможности и ты начал светиться среди других кандидатов А уже как ты проходишь эти собеседования это уже будет вторая Понятно половина дела Но на самом деле тут зачастую чисто проходит с практикой ходишь у тебя становится как мы говорили самом начале меньше волнения вопросы многие ты уже не думаешь над ними ты знаешь ответы выдаешь автоматически потому что многие вопросы повторяются и с каждым разом Тебе проще на них отвечать вот и ты пройдешь вот
01:24:02 - 01:25:10
сейчас большая сложность это именно попасть на Собес раньше вероятно было проще 10 лет назад попасть на Собес но только информация Была намного меньше не было там не курсов не YouTube где есть куча блогеров которые рассказывают Как тестировать Нет там сидели такие деды которые тестировали Там сначала 90-х по совершенно другие системы по другим метрикам и ты вообще понятия не имел что тебя спросят сегодня на собеседовании ты мог поговорить о том как ты Хорошо на рыбалку сплавал а мог углубиться в
01:24:36 - 01:25:43
какие-то недры Юникс системы и в конце просто сидеть и все Вот например у меня одно из первых собеседований я пришел на собеседование первый вопрос спросили Ты умеешь программировать на языке си Я говорю Нет я даже не знаю что такое очень плохо Вы не пройдете собеседование ручного тестировщика до свидания а потом я узнал Что меня собеседовал программист потому что у них нету тестировщики они сказали так Вася иди там про собеседование знали язык Ну вот соответственно такая вот история я пошел на собеседование недавно и ну на
01:25:09 - 01:26:27
ручного тестировщика все созвон уже после HR уже с техническим человеком и он мне говорит приземе у вас указано Python автоматизация Ну давайте начнем с пайтона Напишите функцию которая принимает там число а я все у меня и соответственно все но потом он начал потестированию спрашивать Ну а после такого Ну ты уже мне кажется ничего не сможешь ответить когда ты уже морально подавлен и не как эффект вот этот неожиданности что ты готов очень большой шанс что как раз я тебя собеседовал разработчик которому
01:26:01 - 01:27:26
просто более интересно говорить про программирование чем проходит тестирование и поэтому и начал спать первое второе не каждый разработчик пройдёт собеседование где есть лайф-кодинг так называемый Где тебе говорят вот открывай айдые или там вот открывай и пиши там блокноте и в-третьих почти всегда лайв ходит Где тебе говорят что-то делать всегда переносят наконец-то собеседование потому что это всегда стрессовывает и так далее если с него начинать не каждый Middle программирования выдержит и просто у
01:26:47 - 01:27:41
него голова вскипит и всё но А в принципе в этом случае тут конечно желательно просто иметь отдельное резюме подручного тестировать под автоматизатора Тогда больше шансов заходить Потому что так может и тебя не выбирать Ну ты как бы указал что тебе интересно как бы автоматизация а потому что они смотрят думают Зачем тебе брать ручного если все равно хочешь автоматизацию объяснишь если они с тобой выйдут на разговор Ну а может быть они и тебя и не будут выбирать изначально поэтому тут может быть лучше даже два режима
01:27:13 - 01:28:25
отдельно вот тогда тогда Ну как я говорил Если пойдешь на автоматизатора вот наша общая вот эта вот часть которую мы сегодня час обсуждали Да она как правило в хорошей компании где построен процесс собеседник здесь я тестирует человек который шарит именно в автотестировании то вот где-то 20 на 20 на 20 20 минут Вот база вот этой части 20 минут спросит про пейтон и потом программирование принципы Расскажите вот это все там что такое наследование Что такое еще что-то вот и 20 процентов 20 минут вернее про конкретный инструмент
01:27:49 - 01:29:12
автоматизации который заявлял и все И может быть то может быть лайфхакинг может не быть Ну смотри в принципе я считаю что если ты разбираешься в pyth они тебя автоматизация заходит ты умеешь что наверное есть смысл на автоматизатора именно закидываться зачем особо не придет все равно мне кажется автоматизатор он должен иметь опыт ручного тестирования чтобы как-то ему это все легче давалось и узнал же какие-то там тонкости нюансы что без опыта сразу автоматизатор но можно но мне кажется это как-то немножечко
01:28:33 - 01:29:44
тяжелее не Александр на самом деле такой часто бывает что автоматизаторов нет опыта ручного это нормально Ничего страшного и я тебе рекомендую чтобы сконцентрировано вот если тебе нужно работать к автоматизации бить именно в автоматизацию Потому что если ты устроишься как automation Junior допустим да то скорее всего ты попадешь в команду где есть другие автоматизаторы Где у вас будет какая-то культура разработки То есть у вас будут коды View у вас будет нормально настроенная вот этот гид система и ты
01:29:24 - 01:30:51
научишься практикам именно написание кода хорошему вот этим это важно потому что если ты устроишься ручным тестировщиком Да С одной стороны ты будешь Лучше понимать может быть тестирование даже фундаментально но ты не получишь никаких навыков хороших работы с кодом с программированием А это автотестировании важнее это в итоге важнее чем быть именно хорошим теоретиком тестирования поэтому я тебе рекомендую именно бить в автоматизацию тем более собеседование по автоматизации сложнее и конкуренция в автоматизаторов
01:30:09 - 01:31:24
не такая высокая как у ручных тестировщиков вот так что очень рекомендую так даже если вот у тебя будет Вариант где будет одно одна вакансия типа автоматизатора другая там иногда сейчас любят такое 50 на 50 там 30 на 70 вот это все вот если будет выбор Цельсия туда где именно тебе обещают стопроцентно автоматизацию не без всяких совмещений потом в будущем когда ты в качаешься автоматизацию там Чего угодно будешь делать захочешь там 50 на 50 захочешь Там чисто технарь автоматизаторы Не важно но на
01:30:47 - 01:31:59
перспективу это лучше чем идти через ручную потому что ну вручную тоже хорошо Я ручную тестировщик уже 9 лет летом будет в июне Вот и деньги зарабатываются и сфера востребованные все дела Но это просто несколько Иной путь поэтому допустим я не был готов на старте учить программирование и биться в эту сторону вот сейчас уже может быть готов тогда нет А ты уже сейчас готов поэтому сосредоточиться тогда на автоматизации Идешь к лучшим результатам за то же самое время Ну если уж так получится что на
01:31:22 - 01:32:39
автоматизатор не получится возьмут Я принципе тоже не против как бы тогда просто ты пойдешь по немножко другой [музыка] вот так еще какой-нибудь вопрос да Нет в принципе все тогда хорошо что ты пришел ко мне сегодня Спасибо тебе спасибо тебе что позвал что даешь этот опыт который так нужен именно вот в разговоре когда ты сам читаешь и сам собой грубо говоря разговариваешь это все равно как-то не так а тут Практика это Огромное спасибо отлично хорошо тогда Удачи тебе в поиске новой работы хочешь на паблос подписывайся Пусть и на
01:32:02 - 01:33:42
мой за соточку если накопишь такие деньги вот там у нас принципе мы эти самые друг у друга смотрим и какие-то мудрые советы даем то у меня есть джуниоры и автотестеры есть опытные Так что там можно и завтра тестирования спрашивает тоже вот ну и так надеюсь что у тебя ближайшее время получится найти вакансию которая тебе нужна Ну как он собеседование Александр показал очень достойные знания в области тестирования программного обеспечения может быть не идеальные но в любом случае на моем опыте не так много
01:32:58 - 01:34:16
джуниоров которые могут так хорошо раскрывать некоторые вопросы в конце собеседования я все-таки посоветовал Александру сосредоточиться на конкретном направлении то есть в его случае это автоматизация тестирования в ней Разумеется также необходимо знать теорию тестирования но она составляет лишь часть необходимых знаний в любом случае желаю ему Удачи в поиске работы вам Напоминаю что у нас есть ссылка внизу под видео где вы можете записаться на подобное интервью либо же можете записаться на приватное интервью по
01:33:45 - 01:35:05
другой ссылке смотрите вниз и всего хорошего пока
01:34:30 - 01:34:44