[музыка] Всем привет У нас сегодня новое собеседование на Junior а с нами Роман Он проходил где-то какое-то обучение на тестировщика уже и подготовился смотрим собеседование Итак всем привет сегодня с нами Роман начинающий специалист по тестированию Роман в двух словах о себе что ты хочешь узнать какой у тебя есть опыт Если есть и так далее Ну тут Роман Мне 36 лет опыта как такового прям что-то в тестировании У меня нет помимо курсов которые приходил двухмесячные бирж труда так называемый у нас городе
00:00:01 - 00:01:40
вот ожидание вообще хотелось бы попасть войти грубо говоря выбор тестировщика Ну на профессию тестировщика пал потому что мне сама концепция нравится то есть обидно когда ты открываешь какое-то приложение на смартфоне или на компьютере что-то не работает то есть это такая Кошмар получается грубо говоря конечное звено такое который перед тем чтобы выпустить качественные приложения какое-то или контент грубо говоря то есть грубо говоря помогаешь людям чтобы придется нервничать вам вместо этих людей в процессе тестирования
00:00:56 - 00:02:22
Хорошо тогда начнем с базовых понятий и углубимся дальше Скажи пожалуйста что такое тестирование по-твоему тестирование это способ оценить качество продукта грубо говоря понять что он работает как написано как соответствует ожиданиям допустим клиент или заказчика что там все правильно сделано откуда еще мы можем брать ожидания помимо клиента или заказчика есть же спецификация то есть Обычно когда начинают разрабатывать продукт то есть вносится что и как должен работать так а вот бывает такое что спецификации
00:01:37 - 00:03:13
нет откуда еще требования Можно взять можно было бывают но создаются для этого специально приезжайте пути выявления требований грубо говоря существуют то есть каких-то то есть чтобы понять Вообще как должно что работать вот бывает вот я вам из реальной практики говорю То есть приходит заказчик в компанию говорит сделайте мне интернет-магазин у него спрашивают как он говорит сделайте мне хорошо сделайте хорошо вот чтобы было хорошо Я бизнесмен продаю мужские носки Я не знаю Как должен выглядеть интернет-магазин мне
00:02:26 - 00:03:46
надо чтобы было Вот как у всех не хуже а то и Лучше сделайте хорошо говорят Ну конечно за ваши деньги мы сделаем вам хорошо а потом начинают программисты как-то это делать Вот на что бы вы ориентировались таком случае я бы наверное посмотрел посмотрел бы как лучше сделать у конкурентов Например у конкурентов Да по-моему как раз один из источников выявления требований Да это как бы везде озвучивается почему-то Я смотрел в разных лекциях по-разному не везде указывается что можно так но вообще почему нет ну когда на практике
00:03:08 - 00:04:23
сталкивается с разными ситуациями тут тоже приходится придумывать что-то У конкурентов можно взять Ну у других интернет-магазинов которые продают мужские носки или типа того А еще Откуда мы можем взять можно провести какой-то Анкетирование например должно выглядеть собраться программистами как мы будем это реализовывать заказчик ничего не сказал что нужно чтобы было круто менеджер говорит сделайте фонтен что создает задачу в системе джира в ней ничего не написано Кроме слов сделайте хорошо а программисты Они читают такие А
00:03:48 - 00:05:09
ну я знаю как сделать хорошо Я даже спрашивать ни у кого не буду сделаю вот как я считаю правильным на самом деле еще одним источником может являться Как ни странно здравый смысл Потому что часто когда мы взаимодействуем с приложением и о некоторых вещах Ну не задумываемся по умолчанию Ну например мы понимаем что если мы находимся на сайте и перемещаемся по нему то наверное он ни на какой странице не должен падать этот сайт да то есть Логично но в документации это может не быть то есть там не может быть не
00:04:32 - 00:05:38
написано на каждой странице тут сайт не должен падать там тут сайт не должен падать вот ну мы знаем что так должно быть поэтому это знание оно переносится в тестовую документацию в требования в тесте в наши то есть не обязательно в требованиях писать к продукту но в проверках можем указать например мы знаем что пользователи если на нашем сервисе пользователи регистрируются пользователи иногда забывают а в требованиях заказчик не указал что надо чтобы была возможность пароль восстанавливать но используя здравый
00:05:04 - 00:06:18
смысл да мы знаем что любой пользователь может забыть пароль и чтобы этого не произошло мы должны функцию восстановление пароля все-таки примотать то есть требования Мы должны как-то дополнить наши Вот и соответственно ориентируясь на это мы можем как-то дополнять требования уже из своей собственной головы исходя из здравого смысла то есть И вот это понимание Это не просто какой-то теоретический Аспект который Надо выучить это вот Вас конкретно спасет на первом месте работы где придет заказчика скажет сделайте мне
00:05:42 - 00:06:59
хорошо чтобы не теряться можно это держать в голове хорошо Какие цели тестирования можно назвать [музыка] чтобы он был устойчивый надежный качественный продукт выпустить по большому счету Ну на самом деле есть несколько классификаций целей тестирования выделяется в разных источниках по-разному есть там понимание цели в широком смысле в узком смысле такие такие и Я рекомендую все-таки их где-то выучить обычно их там 3-4 там например есть такая классификация верификейшн или дар Red detection это мы проверяем что у нас сам процесс
00:06:21 - 00:07:53
разработки идет хорошо то есть выполняются все цели вовремя сдаются задачи то есть мы же как тестировщик не только находим возможные проблемы в самом продукте мы еще можем подсвечивать проблемы в самом процессе разработки например мы можем видеть что задачи которые должны реализовываться в первую очередь почему-то откладываются а задачи которые не так приоритетные разработчики с удовольствием берут и делают и мы понимаем что в итоге к релизу у нас будет сделано то что мы не особо торопимся Да и не будет сделано то что
00:07:23 - 00:08:38
нам очень нужно чтобы было сделано вот и В таких случаях Мы это можем подключить project-менеджер это велификейшн valetation это мы уже проверяем что программное обеспечение соответствует ожиданиям заказчика пользователя и так далее Вот и третий экшн это выявление непосредственно ошибок и репорт багов это одно из классификаций из трех шагов бывает многие другие лучше четко где-нибудь выучить и прочитайте либо то что я сейчас рассказал либо какой-то еще вариант их много нету единого но тем не менее
00:08:00 - 00:09:20
хорошо обсудим виды тестирования Какие известные виды функциональные тестирование Я знаю функциональная и и еще было какое-то Ой там очень много классификации очень много разных видов Да как бы то есть по большому счету Просто бывает там по доступу коду тестирования по уровням тестирования все правильно Да так Ну вот какие-нибудь конкретные виды можно обсудить например тестирование локализации Что в себя включает и о чем это Ну локализации как я понимаю это то есть мы должны к примеру тот же самый иностранный какой-то сайт
00:08:41 - 00:10:21
локализовать в нашей стране Что значит локализовать перевести на наш язык адаптировать адаптировать а что кроме языка меняется при переключении допустим страны на сайтах что может еще меня что еще если это сайт то есть какой-то где что-то можно купить то могут быть разные платежные системы Я думаю как-то это тоже локализации платежные системы вряд ли будет зависеть Вот время время тоже оно как само то время не поменяется потому что в каждой стране бывает так что несколько часовых поясов а поменяется формат
00:09:43 - 00:11:04
то есть допустим есть 12 часов формат там и пим до полудня после 24-часовой как у нас там в СНГ дата мы пишем день месяц год на западе часто пишут в Америке месяц день год вот потом вес например [музыка] да да вот это все учитывается в тестирование локализации при переключении что все должно меняться хорошо тестирование инсталляции что можно сказать тестируспилляции Тестируем инсталляции Если честно не слышал хорошо надо себе пометить и почитать там у нас что-то такого не было будет теперь это касается нативных
00:10:28 - 00:12:06
приложений и гибридных которые требуют установки бывают всякие особенности Когда вы устанавливаете обновляете и удаляете приложение 3 основные действия хорошо кросс-браузерное тестирование что-то браузерами когда в разных браузерах можно одно и тоже проверить будет [музыка] одна и та же функция допустим функции как правило будут работать проблема разных браузеров в том что отрисовки иногда бывает разная то есть Они по-разному читают код страницы в плане вида его и Бывает так что на одном браузере отображается
00:11:34 - 00:13:03
страница Ну понятно хорошо а на другом просто буквально то есть кроссплатформенная Что такое Но это на разных платформах получается тогда если только а по форме это что такое [музыка] повторить записать себе повторить хорошо тогда про ящики разноцветные что-нибудь известно белого серого и черного ящика на что вот за ящики получается тестирование белого ящика это по-моему с доступом кодом Если не ошибаюсь черного ящика без доступа А вот серия так понял что наполовину нигде не видел чтобы применяли где-то
00:12:31 - 00:14:22
конечно серым ящиком действительно есть определенные проблемы потому что разные авторы которые теорию развивают тестирование по-разному его описывают мы сейчас обсудим по поводу белого ящика есть доступ коду Да ну тут как правило дело не в доступе в кода в понимании то есть мы учитываем код когда мы Составляем какой-то тестовый сценарий А что мы покрываем тестами при белом ящике покрываем тестами тоже код то есть тесты которые написаны методом белого ящика это Юнит тесты это мы как ручные тестировщики их не пишем их пишут
00:13:44 - 00:15:10
разработчики и они Фишка в том что эти тесты они покрывают конкретные модули кода То есть когда пишутся Юнит тесты не учитывается общая бизнес логика приложение берется маленький участок кода и как бы маленький автопроверки которые пишут тестировщики они покрывают ими собственные кусочки приложения а при тестировании черным ящиком мы покрываем тестами бизнес-требования это уже дело мы ручные тестировщики читаем требования и в соответствии с ними пишем Как должно работать приложение и Тестируем по нашим этим
00:14:40 - 00:15:51
при тестировании серым ящиком мы пытаемся тестировать чем-то средним что можно сюда привнести пример Какой например тестирование бэкенда отдельно от frontendo нас веб-приложение есть фронт часть сайт как мы видим есть бэкент сервер и мы можем руками через какую-нибудь программу составлять запросы и отправлять их на сервер с одной стороны мы код сервера не знаем и код сервера Мы тестами не покрываем с другой стороны и бизнес логику Мы полностью не повторяем потому что у нас нету funt and получается
00:15:18 - 00:16:35
что-то такое среднее про серый ящик хорошо так есть у нас еще помимо ручного тестирования есть еще автоматизированное что можно про него рассказать не сталкивался на самом деле у нас был там ответвление что Вселенной [музыка] создавали какой-то грубо говоря на сайте Кликаешь чего-то и это заливали в пайчарн это было все поверхностно Так это отлично Я не спрашиваю не прошу сейчас код писать на питоне в пайчарме делать селением Я просто спрашиваю что это вообще Каким образом оно выделяется очень часто на каких-то проектах как я
00:15:56 - 00:17:33
понял бывает допустим к примеру 80 процентов тестирования фронта там и 20 бак или там 60 на 40 грубо говоря авто тестами Ну ты можешь чтобы не писать каждый раз вручную поменялись допустим это какие-то параметры транс новые параметры внес Нажал кнопку У тебя все заработало проще вот вас спрашивают правда тестирование на реальном собеседовании вы говорите автотестирование - это способ тестирования когда тесты пишутся в виде программы Да вот этих автотестов на каком-то языке программирования то есть
00:16:54 - 00:18:00
на собеседовании спрашивают от общего в частности То есть если вас будут глубже копать например А вот как это применяется как это тут можно рассказывать Значит у меня там есть опыт или там Я знаю что можно написать там на языке питон используется пайчам есть селением этой библиотека для тестирования веб- приложений через UI это всё можно Но обычно на собеседование просто хотят узнать что в принципе знаете что такое есть автоматизация тестирование Это значит что мы пишем автотесты на языке программирования и получается что мы
00:17:29 - 00:18:29
пишем программу которая тестирует другую программу и всё это бывает достаточно просто тут попроще Окей хорошо есть у нас позитивные и негативные сценарии тестирования вот какая между ними разница но позитивный это когда проверяются происходит проверка должна работать система грубо говоря логично Ты должен залогиниться если по большому счету а негативно мы Тестируем негативные варианты развития событий например Если ты не видел пароль тебя не должно запускать нужно проверить что реально тебя не залогинишься
00:18:01 - 00:19:35
а какой ожидаемое поведение обычно бывает что ты не должен залогиниться без пароль негативное тестирование правильно Это правильно А вот как вы думаете еще вот просто вы на сайте пытаетесь вести неверные данные да нажимаете кнопку там Пусти меня Да там залогин что обычно система она просто не пускает или что-то еще должна быть ошибку там зависимости от того что написано опять же Ну как она должна какое-то результат при разных вводе разных данных конечно конечно если там написано что должна быть
00:18:53 - 00:20:12
Неверный логин пароль там Попробуйте заново то должен какую кнопку не написано это вот оно не должно но тут о чем мы говорили 20 минут назад о том что иногда надо включать здравый смысл если в требованиях не написано что не должна быть показана ошибка это не значит что она не должна быть показана Это значит что кто-то просто может быть Не додумал потому что ошибки Это очень важно без ошибок мы с толку сбиваем конечного пользователя он просто не знает что он неправильно ввёл логин и пароль допустим и он сидит перед
00:19:36 - 00:20:38
ним ничего не происходит И что он будет делать Вот так что не все так просто хорошо есть у нас еще такая градация как статическая и динамическое тестирование с изменениями Если не ошибаюсь повторить записать тетрадочку повторений разницу четкую статическое тестирование это без запуска программы которую мы Тестируем динамическая с запуском Какие виды статического можно назвать что мы можем статистически тестировать так любую программу офлайн грубо говоря А как мы оффлайн будем тестировать вот у нас есть приложение сервер не работает
00:20:07 - 00:21:30
к примеру То есть я сталкивался с такой ситуацией мониторинг вакансии тестировщика у нас так это одно откликнулся то есть там было предприятие которое занимается какие-то микросхемы то ли чего изготавливает и когда мы прислали подходите тестовое задание Вот программу скинули программу грубо говоря она была не онлайн Она просто программа была открываешь там можно вести какие-то данные не в онлайне Дело не в том подключен или в интернет или нет Дело в том что запускается ли программа в принципе в
00:21:05 - 00:22:32
процессе тестирования или нет например вот телефон же у вас есть в нем есть фонарик А фонарик это тоже программа И когда вы нажимаете на кнопочку фонарик происходит работа кода которая идет к датчику лампочки он включается это уже динамическое тестирование А статическое тестирование в нашем случае это Например тестирование требований То есть у нас еще программы нет которую запустить можно но мы можем протестировать к ней документацию почитать ее внимательно найти какие-то в ней недочеты пробелы до что допустим у нас текст
00:21:52 - 00:23:04
ошибки не написано Хотя наша логика говорит что должно быть или еще что-то вот эта статическое тестирование как только вы программу запустили ее код отрабатывает Ваши действия это уже динамическое тестирование просто тического бывают кроме как тестирование документации например когда программист пишет код в программе вот пайчарм упоминали да что происходит до того как вы сбил телепроект пайчарм может сам подчеркивать проблемы с синтаксиса языка и логических взаимосвязи То есть он может сказать вам что о переменная
00:22:28 - 00:23:50
возвращайте не того Типа или пытаетесь вызвать функцию которая не существует Но код при этом даже еще не запущен это по аналогии с программой Word допустим Где вы пишете текст и так далее То есть текст тестируется статические и в данном случае код тестируется статический без запускать [музыка] новые знания в копилку OK [музыка] про уровни тестирования что-нибудь известно там Юнит тестирование сначала потом еще какой-то уровень потом еще какой-то уровень еще еще иногда называют тестирование по степени взаимодействия компонентов
00:23:12 - 00:24:41
[музыка] модульная вот тестирование это одно и то же модульное потом тестирование Так блин надо их разбить вспомните все функциональные функциональные не надо это не функциональный функционально это есть три или четыре уровня зависимости того где написано вот модульные компонент на это первый уровень это у нас Что такое Ну когда модуль это тестирование Когда проверяешь взаимодействие каких-то модулей между собой нет Роман один без взаимодействия когда взаимодействие между модулями какой-то уровень как он называется
00:24:09 - 00:25:38
[музыка] интеграционная интеграция А когда у нас все модули выстроены в одну как бы цепь и мы можем тестировать приложение целиком системы получается правильно системные подготовиться хорошо известно что-нибудь про техники тест дизайна Ну да есть класс эквивалентности разбиение пластиковые граничные значения потом попарно и тестирование так еще какие у нас там есть Ну ладно давайте поговорим про класс эквивалентности Как мы можем создавать проверки Да тестовые в соответствии с техникой допустим Не знаю есть у нас не знать 4
00:25:00 - 00:26:46
возрастных групп меру то есть начнем с общего Зачем нам нужно вот это эквивалентное разделение нужно протестировать какой-то окно ввода данных примеру в банковском приложении или где-нибудь и туда это и он должен принимать данные к примеру там от одного там до 65 лет кому-то кредиты выдавать какие-то возрастные ограничения к примеру есть если ты будешь грубо говоря 12345 на каждый год по одной проверки Но это замучаешься проверять на самом деле Вот и поэтому проще разбить на какие-то либо ну как бы
00:26:17 - 00:27:39
классики валентности грубо говоря на разбить на то что одни и те же данные сейчас сформулировать количество тестов короче правильно минимизировать количество тестов путем объединения входных данных входных параметров в определенные класс и тогда мы можем взять по одному параметру из каждого класса и таким образом сократить количество тестовых сценариев потому что мы подразумеваем что Если уж одна проверка прошла из одного класса то из этого класса все остальные проверки Окей про анализ граничных значений Вот
00:27:08 - 00:28:35
например у нас есть какой-то интервал позитивных данных например мы можем вести число от 10 до 100 сколько у нас будет проверок и какие соответствии вот с этой техникой тест дизайна Но получается от одного до 100 от 10 до 100 допустим насколько я помню часто ошибки на границах получается будет 9 10 11 и границы и 101 199 получается 6 проверок А зачем нам три проверки для того чтобы оценить каждую границу Почему не две например вот значение 10 и 100 в нашем они ходят внутрь границы или нет они позитивные или негативные
00:27:56 - 00:29:51
Зачем нам проверять 11 90 то и получается Я лишь не лишние Короче я накидал Почему Да ничего так многие делают потому что забывают что вот эти самые границы они не находятся в каком-то третьем состоянии они либо входят либо не входят это час Отлично так тогда поговорим дальше про тестовую документацию Какие виды теста документации известны [музыка] чек-лист Отлично Что такое тест-план и из чего он состоит тестированию описывает стратегии которые разрабатывается критериев грубо говоря до окончания есть
00:29:04 - 00:30:54
какой-то примеру тот же самый модуль который нужно протестировать Обычно он пишет какие проверки сделать как это программа а вот вам приходилось писать нет план писал они в конце там был он такой этот коротенький был так скажем видео созвон и скидывали но он был совсем коротенький я потом посмотрел как настоящий тест планы выглядят образцы Ну я бы не назвал Ну на самом деле ты планы бывают разные если грубо говоря работа на каком-то там предприятии где очень много формальных движений происходит там
00:30:22 - 00:31:42
тест-план будет выглядеть как дипломная работа в Университете но если если придется работать в каком-нибудь стартапе маленьком и в принципе никто не будет требовать от вас тест-план вы можете его создать для себя или для небольшой группы людей и он действительно может быть маленьким на одну на две страницы Это не проблема Это нормально Вот и следа может не быть Как ни странно когда Джуниор находит работу начинающий профессионал да то очень большой шанс попасть в стартап в маленький Где вы будете первым
00:31:08 - 00:32:17
тестировщиком и вот вы придете и спросит что будем делать дальше план Нам нужен У вас А вам надо будет его написать и все надо понимать будет как вы написать Зачем он нужен и так далее вот поэтому конечно лучше уметь его писать самому Даже если он маленький это не страшно если он корявенький страшненький это все не главное главное что в нем содержится то что должно быть тест-плане значит можно добавить можно если только получится написать Вот или где-то почитать перед этим как его лучше писать в принципе было перечислено
00:31:42 - 00:32:57
что в нем содержится но есть этот самый есть вопросы к нему я помню были типа что будем тестировать [музыка] все верно можете назвать критерии начала тестирования [музыка] готовность хорошо А еще какой-нибудь но подумать наличие должно быть тестовой документация должна быть в наличии как правило Хорошо хорошо замечательно всегда конечно бывает вообще должна быть какая-то документация в наличии по любому может быть может не быть может быть такой критерий начала может его не быть Как пример критерия Да отлично то
00:32:20 - 00:33:41
есть не всегда в каждом тестовом плане допустим будет такой критерий Ну достаточно просто знать что такое может быть а какие окончания тестирования какие-нибудь Я думаю что должно быть готова На мой взгляд написано же то что тестировать грубо говоря какой-то или модуль продукт должна быть написано Чтобы понимать тестирование раньше тем лучше но тем не менее все равно если уже чего-то есть критерии окончания тестирования помимо того что функционал должен работать как следует еще какие бывают критерии окончания
00:33:17 - 00:34:35
[музыка] надо выгонять продакшн просто все же сроки горят Не знаю бывает еще устанавливают допустим требования к количеству к наличию багов определенного приоритета Могут могут указать например что можно заканчивать тестирование если нет активных блокеров или критиков багов а допустим Если майнеры есть то есть а иногда могут указать что не должно быть никаких открытых вот любого приоритета хорошо В зависимости проекта с плана то есть мы обсуждаем то что может быть в критериях начала критериях окончания тестирование
00:34:13 - 00:35:46
что будет по факту это уже надо в реальном проекте смотреть невозможно конечно что это такое Что все включает [музыка] грубо говоря тестовая проверка одна То есть пишется с целью что одна проверка какого-то допустим то есть не знаю Ну проверка что что сценарий проверки какой-то проверки то есть грубо говоря чайник Там что кнопка нажимается хорошо а как Из чего состоит из Какие в нем бывают [музыка] потом описание должны быть Шаги по воспроизведению и фактически результат Ну что получилось [музыка]
00:35:02 - 00:36:52
хорошо есть у нас еще чек-лист он Для чего Нам нужен лист это грубо говоря список проверок но без подробного описания без шагов то есть чек-лист обычно используется в коллективе где либо все давно работают вместе хорошо знать либо ну какие-то некрупные [музыка] грубо говоря задачи Когда нужно протестировать примеру то есть простые то есть новичку не дадут по чек-листу что-то тестировать вряд ли мне кажется такая если вся документация тестовая в чек-листах Что же делать придется новичку читать чек-листы если придется
00:35:56 - 00:37:17
Ну вот критерии того что сложные проверки Допустим мы не можем описать чек-листами можем это верно помимо сложности самой проверки мы должны понимать сколько у нас человек в команде допустим тестирование кому эти чек-листы в принципе нужны То есть если у нас команда маленькая мы только один это наверное если мы разбираемся своих собственных листах они никому не понадобятся Но если у нас команда большая или мы знаем что он скоро увеличится допустим вы работали в маленьком стартапе он получил финансирование вам говорят Мы
00:36:37 - 00:37:55
расширяемся будет помощник наниматься скоро будет еще что-то или самого начала когда приходим говорят у нас большой проект Тогда наверное больше подойдут потому что будет много людей которые не в курсе системы неопытные Им будет в них разбираться проще к листа вот Ну ладно хорошо Что такое баг-репорта из чего он состоит но бак Report это описание ошибки то есть в отличие от с кейсов бак Report есть краткое описание подробное написано воспроизводимость указанные важные срочность [музыка] скриншоты окружения которого произошло и
00:37:16 - 00:38:52
если указывается только фактически что должно отработать по моему указывается Как должно быть что по факту получилось ожидаемые фактически результат еще мы из кейса можем взять шаги для воспроизведения Естественно предусловием да только в которой еще мы дописываем фактическое поведение ошибку можно сказать хорошо обсудим жизненный цикл баг-репорта Да что с ним вообще происходит обычно у нас Но мы завели баг-репорт допустим Какой следующий шаг над ним работы кто что делает но открыт он будет грубо
00:38:11 - 00:39:46
говоря то есть мы его завели на кого-то из тестировщиков назначили тоску так мы проверяем нужно проверить [музыка] воспроизвести этот баг посмотреть в чем проблема мы как тестировщики завели этот баг на кого же он назначается потом на одного тестировщиков и представим себе что он согласен со всем что действительно есть бак он его чинит допустим исправляет что-то входит что дальше происходит но получается что он очень нужно проверить так тестировщик которые заводил бак отлично если бак починили тогда что
00:39:04 - 00:40:42
происходит То есть если бак починит его нужно закрыть потому что он справа А если нет Если нет то его нужно переоткрыть она открыт заново так называется состояние и назначить Ну естественно чтобы его исправлять Хорошо тогда спорный момент могут возникнуть Ну если Вы снова исправит и вы будете проверять в принципе чего спорного он либо починили его Со второй попытки или встретились десятый или нет спорный момент могут возникать Когда у нас допустим что например мы бак завели и разработчик не хочет учинить вообще
00:40:07 - 00:41:27
смотрят на него и говорит не буду чинить и ставит какой-нибудь статус вот какой статус Может поставить например который будет означать чинить Ну допустим может быть такое что не срочный бак То есть у него есть какие-то более на него навалили навесили кучу ТАСС который нужно еще вчера сделать не срочность определяется приоритетом на табличке он перемещается статус от этого особо не меняется есть другие принципы по которым может поменяться статус например тогда может быть что не знаю если это был сайт какого-то магазина
00:40:47 - 00:41:59
Носков магазин закрылся сайт больше функционирует проект закрылся Значит уже и задач нет на рынке труда я не буду работать вот не хочу вот бывает допустим статус дублики Говорит есть уже такой бак поэтому этот я не буду чинить такой же есть и Вот тебе ссылка на него и занимается как хочешь Что тогда в этой ситуации перед тем как заводить бак нужно проверить если такое существует или нет изначально нужно но так получилось что проверяли а там тысячу открытых багов и что-то как-то было полдня не захотелось перепроверять весь
00:41:28 - 00:42:58
бы клок багов и просто завели на всякий случай и вот нашли такой же что происходит и посмотреть что было в предыдущем который уже заведен так и тогда один нужно убрать получается сравнить их правильно сравнить если уже был такой бак посмотреть исправлен он или нет Если он исправлен ну то есть предыдущий но не заводить удалить А если он неисправлен пускать вот у тебя в том баги Ну ты его не доделал еще доделывали давай правильно тот доделывай давай этот свой который дубликат он просто закрывается и
00:42:16 - 00:43:32
прилинковывается потому что тот еще не доделал А если тот доделал был когда-то и так получилось что бак опять появился такое бывает там напутали при когда заливали изменения в коде вроде починили А через неделю он опять всплывает потому что ну так в Континенте integration системе что-то пошло не так тогда нужно сказать Да тот бак был пофикшен он появился Опять поэтому давай-ка мой Вот этот новый так кроме дубликата что у нас еще бывает у нас еще бывает что программист говорит [музыка] Не могу воспроизвести
00:42:54 - 00:44:11
То есть он выполняет шаги которые указаны в баге и у него ожидаемое поведение совпадает с реальным А у тебя нет это тоже статус при котором программист Как бы говорить я чинить не буду к на три продюсер мне не воспроизводится что в этом случае происходит надо перепроверить тогда переоткрытие попробовать пройти по своим шагом потому что может быть где-то ошибка Если все у тебя воспроизводит надо проверить может он воспроизводит на другом окружении потому что на разных окружениях может по-разному производиться не
00:43:35 - 00:44:48
воспроизводится кроме окружения Что может быть еще не так [музыка] окружение что мы включаем в себя в том числе может быть система не то может быть версии системы не то окружение так получается что посмотрел еще бывает разная версия коды то есть Может быть так что тестировщик смотрит на одной версии приложения программист на другой И поэтому они по сути смотрят на разные приложения и на одной версии кода воспроизводится на другой нет хорошо вот допустим есть ситуации бак завели программист либо сразу
00:44:15 - 00:45:47
отказывается учинить либо после нескольких попыток он говорит так у меня не воспроизводится все отстанет меня роман Я короче занятой Важный человек не буду Я больше ничего чинить а у тебя бабку ты уже проверил сто раз Ну воспроизводится и у него есть какая-то проблема системы надо что-то с ней делать Что ты будешь делать с этим ничего не воспроизводится и больше ты мне его не отправляй отвлекаешь важного человека Отважные работы Если я перепроверил а у него нет Я тогда пойду скажу такая ситуация или
00:45:15 - 00:46:37
выше в зависимости потому что значит делать [музыка] Так кто там повыше то идет дальше про Бакт туда пойдем Ну Project продакты Проджект это немножко разные Project Manager PM Ну тогда вот к нему идем и он как бы отвечает за проект он может быть не в курсе конкретных технических вещей в проекте Ну за ним последнее слово кто что делает и в этом случае он может вмешаться и допустим либо он скажет что типа Ну скажешь что баг действительно не воспроизводится вроде как Или он не так важен его можно убрать куда-то А может
00:46:01 - 00:47:24
разработчику сказать Смотри бак важный вот мне тестировщик доказал что он воспроизводит собак давай-ка Ты постараешься и починишь и он будет делать мужу некуда деваться он уже не сможет отнюдь тут Почему дама тема поднимаем потому что очень часто новички теряются на проекте и не знают как поступить в такой ситуации А многие опытные программисты не пользуются неопытности новичка и начинают его как бы так отпихиваться от него не мешайся Да и в этой ситуации некоторые допустим Junior тестировщики они начинают в
00:46:49 - 00:48:04
агрессию начинает ругаться Вот еще что-то А это ни в коем случае делать не надо всегда надо помнить что у нас есть Project Manager который в итоге за которым последнее слово и все подобные вопросы все идут к нему а он уже решает Что делаем хорошо Давай обсудим разные виды приложений в принципе вот мы можем попасть на рынок и нас возьмут проект где мы будем тестировать какой-то из видов приложений Вот какие виды приложения ты в принципе знаешь есть один приложение это веб-приложение это сайты которые мы Тестируем в
00:47:31 - 00:48:46
браузере какие-то есть какие мобильные как они называются Ну не знаю Яндекс еда та же самая какая-то не знает приложение Ну да просто у нас Ну мобильное приложение еще какие не знаю может его просто не понимаю Не знаю У нас есть технически технически несколько видов приложений сейчас их можно выделить можно сказать три есть нативные приложения это они же еще иногда называются десктопными приложениями это приложение которое запускаются на конкретном устройстве либо компьютер либо это смартфон и работают чисто из самого устройства
00:48:15 - 00:50:01
без подключения к интернету как правило там есть подключение к интернету но не совсем для того чтобы работало приложение для того чтобы данное подгружались немножко другое есть у нас вы приложение у которых принцип работы Такой что они работают веб-серверы и открываются через браузер и есть еще один вид приложений гибридные которые одновременно могут являться часть этого приложения написано на нативном языке часть логика допустим приложение может находиться на сервере вот Можешь ли ты вот рассказать В чем разница
00:49:15 - 00:50:32
непосредственно допустим в тестирование этих трех видов приложений или особенности тестирования Ну если допустим это приложение которое отправляет данные на сервер постоянно не подгружает периодически то есть грубо говоря то там по-другому расскажи начнем с веб-приложений Какие особенности тестирования в приложении чего есть в приложении Чего нет в других видов приложений Как это влияет на тестирование приложение работает только с Интернетом правильно понял получается Интернет пробили она не работает Следовательно
00:49:53 - 00:51:20
там происходит обмен данными так то есть я так полагаю что это тестированию идет Все дело тестирование API тестирование на отказ восстановления если мы Интернет отламываем да То есть можно проверить как он работает нагрузочная на сервер так То есть можно накидать допустим тот же самый филлер кучу народу и проверить да можно нет Что ещё в приложении [музыка] допустим разные может быть установка требуется для приложения нет нативные приложения в чем у них особенность будет тестирование альтернативные что-то я не припомню
00:50:42 - 00:52:03
Может только что обсудили что есть десктопные Они же нативные десктопные они на компьютер устанавливаются нательные то же самое на телефон сейчас и приложение которое на компьютер устанавливают их тоже часто называют нативными это как бы уже более принятый термин в чем у них фишка приложение которое если который на смартфон например Или например на смартфон представим себе что приложение мы проверяем который на смартфон чем особенности тестирования особенности работы есть пару секунд сообразить можно
00:51:49 - 00:53:01
сделать глубокий вдох на реальном собеседовании когда вопрос ставится в тупик никто не торопит ту же секунду отвечает всегда можно чуть-чуть передохнуть взять кружечку с водичкой туда глотнуть и подумать это не возбраняется Нет наверное не отвечу на этот вопрос хорошо Хорошо я понял надо будет почитать Я рекомендую так для себя сделать построить табличку и по определенным критериям выписать все три вида приложений нативные гибридная веб какие-то будут критерии Требуется ли установка нативного требуется допустим гибридного
00:52:39 - 00:54:05
требуется Веба нет требуется ли разрешение на обновление приложения он активного требуется у гибридного и веб нет требуется ли для работы приложение подключения к интернету гибридного требуется он активного нет И вот и так далее вот выписать и потом Глядя на эту табличку можно быстро сообразить и как они работают и как бы можно было их лучше протестировать Хорошая идея потому что в реальной жизни на реальных собеседованиях часто вам скажут вот мы на собеседуем на нативное например приложение на Android
00:53:26 - 00:54:59
протестировали и даже не зная что конкретно за приложение у них будет уже будет понятно в голове Какие виды тестирования будут к нему применяться и на собеседование это можно сразу выдать более хороший ответ потому что будет сразу все понятно какие-то могут быть проблемы особенности и так далее Поэтому вот эти разные виды приложения надо для себя осознавать хорошо [музыка] да Хорошо тогда по процессам разработки будет последний вопрос Если знакомство вот со с крамом с канбаном с чем-то еще я представляю что
00:54:12 - 00:55:45
такое жире был аккаунт То есть я даже заводил бак репорты Так ну багри порт это понятно Вот А вот когда с принтами это идет грубо говоря двухнедельный может больше может грубо говоря создается планирование разработка потом демонстрация внедрение если короче а по-моему не будем про кабан про скрам чуть поподробнее названо все примерно хорошо вот про каждый этап подробно вот планирование вначале спринта что у нас происходит Какой объем работ нужно выполнить задание то есть естественно обговаривают это
00:55:10 - 00:56:45
выставляется время они начинают работать А вот объем работ объем работ который будет выполнен он как В чем выражается что конкретно в этот Объем работы не знаю допустим нужно написать [музыка] чат-бона какого-нибудь примеру я не знаю или Ну задача задача конкретная задача вот самой доски их выбирают Откуда их берут есть там есть такое понятие это вот карман в котором лежат все задачи У нас есть Black Lock спринта и бы клок всего проекта И вот во время планирования из бэк Лога проекта из всей кучи задач
00:56:10 - 00:57:28
которые запланированы на проект берут задачи влог спринта какой-то часть этих задач и помимо того что выбираются задачи что происходит еще с этими задачами возможности задачи либо это Story Point и либо это просто время указывается сколько займет Это задача предположительно Вот и уже после того как указывают трудозатраты на задачу и тогда берут или не берут Вот хорошо в процессе спринта какой там происходит процесс допустим к примеру идет у нас двухнедельник с принтами к примеру дальше идет ежедневные грубо говоря на
00:56:55 - 00:58:20
которых ты говоришь что делать Вчера И что будешь делать сегодня планирование обсуждение того что получается избы клубы грубо говоря что-то можно взять глубоко глубоко вот ответили короткий вопросом про делики ответ отличный все не надо больше придумывать закапываю сам себя да да слишком проблема такая Мне кажется что я все не до конца чего-то нет такой проблемы наоборот иногда слишком много сверху фантазии бывают все правильно дейлики что было вчера Что будем сегодня делать и какой-нибудь там может быть
00:58:00 - 00:59:13
если вопрос назрел который не получается лично с кем-то выявить вот допустим вопрос с багом который туда-сюда летает Да вот мы чуть раньше обсуждали там разработчик не хочет чинить вы хотите самое время чтобы поднять этот вопрос наружу в конце спринта что происходит непосредственно трудности чтобы неплохо улучшить вот отлично ответ правильно все супер и кроме ретроспективы что еще в конце еще Груминг Я помню такое слово но оно даже перспективы это когда разбор актуальности тоже задач происходит
00:58:39 - 00:59:51
не будем лучше еще у нас кроме ретроспективы бывает непосредственно релиз приложение вот и еще бывает так называемая перед релизом демон То есть когда мы заказчику потенциальному либо это менеджмент если у нас продуктовая компания либо это реальные заказчики если у нас мы показываем что мы собственно сделали Типа что-то такого видео это демонстрация или демон хорошо Ладно супер в принципе мы обсудили все что я хотел за наш Собес как раз где-то в час мы уложились сейчас это обычное время для нормального собеседования
00:59:27 - 01:00:55
Вот какие есть замечания но первое что я прошу это некоторые определения простые просто выучить например определение четкое тестирование потому что у вас получается что вы иногда пытаетесь его как бы додумать в процессе не только тестирования еще другие и допустим цели тестирования да вместо Да долго мне если какой-то вот теоретический вопрос простой просто выучите там самая короткая определение из какого-нибудь там самого популярного сайта если хочется например тестирование это там проверка соответствия между ожидаемым
01:00:18 - 01:01:38
фактическим поведением программы все выучить Чтобы не думать об этом потому что на собеседовании когда Вам приходится вы переживаете за ответ и приходится что-то в голове у себя собирать по кусочкам можно засыпаться а вот тестирование то-то все ответили на вопрос не волновались потому что вы выучили вот такого рода вещи потом цель тестирования как раз таки да Найдите какую классификацию которая удобнее для вашего понимания запомните и чтобы там забуксовали по видам тестирования в принципе мы обсудили большое количество видов
01:00:58 - 01:02:20
тестирования помним что про ящики Да у нас не только важно куда У нас есть доступ но и важно что мы покрываем тестами белый ящик кот черный ящик требования бизнес требования мы не стали обсуждать но Я рекомендую для себя повторить соотношение есть тестирование очень часто тоже могут спрашивать если плохо помнятся регрессивно и смог Да только Цените лучше не называть санитарным потому что очень многих от этого припекает называется Цените Цените Да не знал что в некоторых книжках так и написано бывает
01:01:40 - 01:03:08
Значит короче логично что можно так называть лучше не называть лучше не называется Цените вот статистика динамическая тоже да вспоминаем В чем разница потому что не смогли ответить по уровням тоже в итоге ответили но как-то сначала забуксовали не помню не знаешь там компонентная интеграционная системная тоже надо повторить тест-план хорошо чек-лист принципе тоже хорошо нормально Ты с кейс в ТСК мы обсудили что там базовые поля есть да там шаги ожидаемое поведение название там на самом деле еще бывают предусловие
01:02:31 - 01:03:50
пост условия комментарии еще какая потому что без них то никак на самом деле без предусловия Вполне себе можно и в реальной жизни на реальных проектах очень редко пользуются Бреды пост условиями потому что они нужны только там где проект имеет какую-то особенную сложность и вы тестируете не просто какой-то сайт по продаже Носков который мы сегодня много раз обсуждали а тестируйте какую-нибудь допустим сервис который объединяет там допустим работу нескольких банков на каком-то очень низком уровне и вот там вот очень
01:03:20 - 01:04:26
сложно Все вот там полезно применять такие вещи в базовых приложениях соцсети интернет -магазины что-то еще не так часто это используется просто на собеседовании могут придраться в этом забыли Поэтому лучше их помнить для меня так по жизненному циклу баг-репорт до вспомнить тоже в чем у нас был затык в каких случаях какие статусы ставят программист если он не хочет сразу чинить бак то есть Canon 3 produce не могу воспроизвести дубликат уже такой был еще у него может быть статус вон Ду не буду делать не буду делать Почему Потому что
01:03:57 - 01:05:22
например часть приложения в котором вы нашли бак скоро будет удалена или полностью переписана и чинить бесполезно потому что ее все равно скоро полностью переделывает Вот четко нужно понимать это частая История это бывает хорошо есть разные схемы в интернете они не всегда хорошие но в принципе мы сегодня это обсудили несколько раз и я думаю запомнилось можно их посмотреть и для себя изучить принцип работы гибридных приложений нативных Кто они это одно и то же просто название разные вот понять в чем их разница в работе и
01:04:49 - 01:06:08
соответственно как это повлияет на тестирование очень важный тоже именно практический вопрос будет чем заняться сегодня да да А в остальном в принципе вот так более-менее но подготовка требуется еще конечно я к вам еще запишусь потом когда подготовились Если вы конечно будете проводить еще еще мне такие которые говорили но еще пока никто не вернулся это не запрещено если это не запрещено считаю что это просто вот я знаю вы проводите такие записи еще по моему Вадим Кензов Я видел на YouTube там тоже
01:05:34 - 01:06:54
проводит даже что-то похожее там вместе собираются в 3 тестировщиками Ну тут уже Я рекомендую все-таки постараться по возможности ходить побольше на реальное собеседование потому что они вас закаляют все-таки Когда приходишь на так называемый мог собеседование как у нас сегодня Ну немножко меньше волнения все а попадаешь на реальная ладошки потеют под проступает намного страшнее и вот чем чаще ходишь именно на реальность собеседование тем лучше как раз таки вот это вот сопротивление стрессу нарабатывается вот во-вторых есть шанс
01:06:16 - 01:07:31
что вы попадете таки на работу и знаете собеседование будет ходить не просто чтобы опыт набивать Да ну и есть шанс что ну пройдете собеседование а ведь ради этого все в итоге делается То есть я как раз над этим работаю Вот появилась такая возможность попробовать пока ещё не было Просто реальных собесов Вот и Мне прям интересно это Поэтому я думаю что я вернусь всё-таки когда подлечу хорошо Хорошо буду ждать Вот буду ждать Окей на сегодня все Спасибо что пришли я надеюсь тетрадочку все записали Вот и Если уж сильно захочется то
01:06:56 - 01:08:18
конечно можно до свидания Спасибо огромное хорошего дня пожалуйста Роман давай пока Ну как он собеседование стоит заметить что Роман довольно сильно волновался и часто очень сильно спешил ответить на вопрос прежде чем хорошо Подумайте из-за этого некоторые ответы были не совсем корректны также есть еще одна особенность его ответа в том что он часто отвечал шире на вопросы чем требовалось на реальном собеседовании Старайтесь отвечать именно на тот вопрос который Вам задают и растекаться в различные рассуждения
01:07:43 - 01:09:02
философии при ведении примеров только тогда когда вас об этом напрямую просят Спасибо что посмотрели собеседование всего хорошего пока
[музыка] Всем привет У нас сегодня новое собеседование на Junior а с нами Роман Он проходил где-то какое-то обучение на тестировщика уже и подготовился смотрим собеседование Итак всем привет сегодня с нами Роман начинающий специалист по тестированию Роман в двух словах о себе что ты хочешь узнать какой у тебя есть опыт Если есть и так далее Ну тут Роман Мне 36 лет опыта как такового прям что-то в тестировании У меня нет помимо курсов которые приходил двухмесячные бирж труда так называемый у нас городе
00:00:01 - 00:01:40
вот ожидание вообще хотелось бы попасть войти грубо говоря выбор тестировщика Ну на профессию тестировщика пал потому что мне сама концепция нравится то есть обидно когда ты открываешь какое-то приложение на смартфоне или на компьютере что-то не работает то есть это такая Кошмар получается грубо говоря конечное звено такое который перед тем чтобы выпустить качественные приложения какое-то или контент грубо говоря то есть грубо говоря помогаешь людям чтобы придется нервничать вам вместо этих людей в процессе тестирования
00:00:56 - 00:02:22
Хорошо тогда начнем с базовых понятий и углубимся дальше Скажи пожалуйста что такое тестирование по-твоему тестирование это способ оценить качество продукта грубо говоря понять что он работает как написано как соответствует ожиданиям допустим клиент или заказчика что там все правильно сделано откуда еще мы можем брать ожидания помимо клиента или заказчика есть же спецификация то есть Обычно когда начинают разрабатывать продукт то есть вносится что и как должен работать так а вот бывает такое что спецификации
00:01:37 - 00:03:13
нет откуда еще требования Можно взять можно было бывают но создаются для этого специально приезжайте пути выявления требований грубо говоря существуют то есть каких-то то есть чтобы понять Вообще как должно что работать вот бывает вот я вам из реальной практики говорю То есть приходит заказчик в компанию говорит сделайте мне интернет-магазин у него спрашивают как он говорит сделайте мне хорошо сделайте хорошо вот чтобы было хорошо Я бизнесмен продаю мужские носки Я не знаю Как должен выглядеть интернет-магазин мне
00:02:26 - 00:03:46
надо чтобы было Вот как у всех не хуже а то и Лучше сделайте хорошо говорят Ну конечно за ваши деньги мы сделаем вам хорошо а потом начинают программисты как-то это делать Вот на что бы вы ориентировались таком случае я бы наверное посмотрел посмотрел бы как лучше сделать у конкурентов Например у конкурентов Да по-моему как раз один из источников выявления требований Да это как бы везде озвучивается почему-то Я смотрел в разных лекциях по-разному не везде указывается что можно так но вообще почему нет ну когда на практике
00:03:08 - 00:04:23
сталкивается с разными ситуациями тут тоже приходится придумывать что-то У конкурентов можно взять Ну у других интернет-магазинов которые продают мужские носки или типа того А еще Откуда мы можем взять можно провести какой-то Анкетирование например должно выглядеть собраться программистами как мы будем это реализовывать заказчик ничего не сказал что нужно чтобы было круто менеджер говорит сделайте фонтен что создает задачу в системе джира в ней ничего не написано Кроме слов сделайте хорошо а программисты Они читают такие А
00:03:48 - 00:05:09
ну я знаю как сделать хорошо Я даже спрашивать ни у кого не буду сделаю вот как я считаю правильным на самом деле еще одним источником может являться Как ни странно здравый смысл Потому что часто когда мы взаимодействуем с приложением и о некоторых вещах Ну не задумываемся по умолчанию Ну например мы понимаем что если мы находимся на сайте и перемещаемся по нему то наверное он ни на какой странице не должен падать этот сайт да то есть Логично но в документации это может не быть то есть там не может быть не
00:04:32 - 00:05:38
написано на каждой странице тут сайт не должен падать там тут сайт не должен падать вот ну мы знаем что так должно быть поэтому это знание оно переносится в тестовую документацию в требования в тесте в наши то есть не обязательно в требованиях писать к продукту но в проверках можем указать например мы знаем что пользователи если на нашем сервисе пользователи регистрируются пользователи иногда забывают а в требованиях заказчик не указал что надо чтобы была возможность пароль восстанавливать но используя здравый
00:05:04 - 00:06:18
смысл да мы знаем что любой пользователь может забыть пароль и чтобы этого не произошло мы должны функцию восстановление пароля все-таки примотать то есть требования Мы должны как-то дополнить наши Вот и соответственно ориентируясь на это мы можем как-то дополнять требования уже из своей собственной головы исходя из здравого смысла то есть И вот это понимание Это не просто какой-то теоретический Аспект который Надо выучить это вот Вас конкретно спасет на первом месте работы где придет заказчика скажет сделайте мне
00:05:42 - 00:06:59
хорошо чтобы не теряться можно это держать в голове хорошо Какие цели тестирования можно назвать [музыка] чтобы он был устойчивый надежный качественный продукт выпустить по большому счету Ну на самом деле есть несколько классификаций целей тестирования выделяется в разных источниках по-разному есть там понимание цели в широком смысле в узком смысле такие такие и Я рекомендую все-таки их где-то выучить обычно их там 3-4 там например есть такая классификация верификейшн или дар Red detection это мы проверяем что у нас сам процесс
00:06:21 - 00:07:53
разработки идет хорошо то есть выполняются все цели вовремя сдаются задачи то есть мы же как тестировщик не только находим возможные проблемы в самом продукте мы еще можем подсвечивать проблемы в самом процессе разработки например мы можем видеть что задачи которые должны реализовываться в первую очередь почему-то откладываются а задачи которые не так приоритетные разработчики с удовольствием берут и делают и мы понимаем что в итоге к релизу у нас будет сделано то что мы не особо торопимся Да и не будет сделано то что
00:07:23 - 00:08:38
нам очень нужно чтобы было сделано вот и В таких случаях Мы это можем подключить project-менеджер это велификейшн valetation это мы уже проверяем что программное обеспечение соответствует ожиданиям заказчика пользователя и так далее Вот и третий экшн это выявление непосредственно ошибок и репорт багов это одно из классификаций из трех шагов бывает многие другие лучше четко где-нибудь выучить и прочитайте либо то что я сейчас рассказал либо какой-то еще вариант их много нету единого но тем не менее
00:08:00 - 00:09:20
хорошо обсудим виды тестирования Какие известные виды функциональные тестирование Я знаю функциональная и и еще было какое-то Ой там очень много классификации очень много разных видов Да как бы то есть по большому счету Просто бывает там по доступу коду тестирования по уровням тестирования все правильно Да так Ну вот какие-нибудь конкретные виды можно обсудить например тестирование локализации Что в себя включает и о чем это Ну локализации как я понимаю это то есть мы должны к примеру тот же самый иностранный какой-то сайт
00:08:41 - 00:10:21
локализовать в нашей стране Что значит локализовать перевести на наш язык адаптировать адаптировать а что кроме языка меняется при переключении допустим страны на сайтах что может еще меня что еще если это сайт то есть какой-то где что-то можно купить то могут быть разные платежные системы Я думаю как-то это тоже локализации платежные системы вряд ли будет зависеть Вот время время тоже оно как само то время не поменяется потому что в каждой стране бывает так что несколько часовых поясов а поменяется формат
00:09:43 - 00:11:04
то есть допустим есть 12 часов формат там и пим до полудня после 24-часовой как у нас там в СНГ дата мы пишем день месяц год на западе часто пишут в Америке месяц день год вот потом вес например [музыка] да да вот это все учитывается в тестирование локализации при переключении что все должно меняться хорошо тестирование инсталляции что можно сказать тестируспилляции Тестируем инсталляции Если честно не слышал хорошо надо себе пометить и почитать там у нас что-то такого не было будет теперь это касается нативных
00:10:28 - 00:12:06
приложений и гибридных которые требуют установки бывают всякие особенности Когда вы устанавливаете обновляете и удаляете приложение 3 основные действия хорошо кросс-браузерное тестирование что-то браузерами когда в разных браузерах можно одно и тоже проверить будет [музыка] одна и та же функция допустим функции как правило будут работать проблема разных браузеров в том что отрисовки иногда бывает разная то есть Они по-разному читают код страницы в плане вида его и Бывает так что на одном браузере отображается
00:11:34 - 00:13:03
страница Ну понятно хорошо а на другом просто буквально то есть кроссплатформенная Что такое Но это на разных платформах получается тогда если только а по форме это что такое [музыка] повторить записать себе повторить хорошо тогда про ящики разноцветные что-нибудь известно белого серого и черного ящика на что вот за ящики получается тестирование белого ящика это по-моему с доступом кодом Если не ошибаюсь черного ящика без доступа А вот серия так понял что наполовину нигде не видел чтобы применяли где-то
00:12:31 - 00:14:22
конечно серым ящиком действительно есть определенные проблемы потому что разные авторы которые теорию развивают тестирование по-разному его описывают мы сейчас обсудим по поводу белого ящика есть доступ коду Да ну тут как правило дело не в доступе в кода в понимании то есть мы учитываем код когда мы Составляем какой-то тестовый сценарий А что мы покрываем тестами при белом ящике покрываем тестами тоже код то есть тесты которые написаны методом белого ящика это Юнит тесты это мы как ручные тестировщики их не пишем их пишут
00:13:44 - 00:15:10
разработчики и они Фишка в том что эти тесты они покрывают конкретные модули кода То есть когда пишутся Юнит тесты не учитывается общая бизнес логика приложение берется маленький участок кода и как бы маленький автопроверки которые пишут тестировщики они покрывают ими собственные кусочки приложения а при тестировании черным ящиком мы покрываем тестами бизнес-требования это уже дело мы ручные тестировщики читаем требования и в соответствии с ними пишем Как должно работать приложение и Тестируем по нашим этим
00:14:40 - 00:15:51
при тестировании серым ящиком мы пытаемся тестировать чем-то средним что можно сюда привнести пример Какой например тестирование бэкенда отдельно от frontendo нас веб-приложение есть фронт часть сайт как мы видим есть бэкент сервер и мы можем руками через какую-нибудь программу составлять запросы и отправлять их на сервер с одной стороны мы код сервера не знаем и код сервера Мы тестами не покрываем с другой стороны и бизнес логику Мы полностью не повторяем потому что у нас нету funt and получается
00:15:18 - 00:16:35
что-то такое среднее про серый ящик хорошо так есть у нас еще помимо ручного тестирования есть еще автоматизированное что можно про него рассказать не сталкивался на самом деле у нас был там ответвление что Вселенной [музыка] создавали какой-то грубо говоря на сайте Кликаешь чего-то и это заливали в пайчарн это было все поверхностно Так это отлично Я не спрашиваю не прошу сейчас код писать на питоне в пайчарме делать селением Я просто спрашиваю что это вообще Каким образом оно выделяется очень часто на каких-то проектах как я
00:15:56 - 00:17:33
понял бывает допустим к примеру 80 процентов тестирования фронта там и 20 бак или там 60 на 40 грубо говоря авто тестами Ну ты можешь чтобы не писать каждый раз вручную поменялись допустим это какие-то параметры транс новые параметры внес Нажал кнопку У тебя все заработало проще вот вас спрашивают правда тестирование на реальном собеседовании вы говорите автотестирование - это способ тестирования когда тесты пишутся в виде программы Да вот этих автотестов на каком-то языке программирования то есть
00:16:54 - 00:18:00
на собеседовании спрашивают от общего в частности То есть если вас будут глубже копать например А вот как это применяется как это тут можно рассказывать Значит у меня там есть опыт или там Я знаю что можно написать там на языке питон используется пайчам есть селением этой библиотека для тестирования веб- приложений через UI это всё можно Но обычно на собеседование просто хотят узнать что в принципе знаете что такое есть автоматизация тестирование Это значит что мы пишем автотесты на языке программирования и получается что мы
00:17:29 - 00:18:29
пишем программу которая тестирует другую программу и всё это бывает достаточно просто тут попроще Окей хорошо есть у нас позитивные и негативные сценарии тестирования вот какая между ними разница но позитивный это когда проверяются происходит проверка должна работать система грубо говоря логично Ты должен залогиниться если по большому счету а негативно мы Тестируем негативные варианты развития событий например Если ты не видел пароль тебя не должно запускать нужно проверить что реально тебя не залогинишься
00:18:01 - 00:19:35
а какой ожидаемое поведение обычно бывает что ты не должен залогиниться без пароль негативное тестирование правильно Это правильно А вот как вы думаете еще вот просто вы на сайте пытаетесь вести неверные данные да нажимаете кнопку там Пусти меня Да там залогин что обычно система она просто не пускает или что-то еще должна быть ошибку там зависимости от того что написано опять же Ну как она должна какое-то результат при разных вводе разных данных конечно конечно если там написано что должна быть
00:18:53 - 00:20:12
Неверный логин пароль там Попробуйте заново то должен какую кнопку не написано это вот оно не должно но тут о чем мы говорили 20 минут назад о том что иногда надо включать здравый смысл если в требованиях не написано что не должна быть показана ошибка это не значит что она не должна быть показана Это значит что кто-то просто может быть Не додумал потому что ошибки Это очень важно без ошибок мы с толку сбиваем конечного пользователя он просто не знает что он неправильно ввёл логин и пароль допустим и он сидит перед
00:19:36 - 00:20:38
ним ничего не происходит И что он будет делать Вот так что не все так просто хорошо есть у нас еще такая градация как статическая и динамическое тестирование с изменениями Если не ошибаюсь повторить записать тетрадочку повторений разницу четкую статическое тестирование это без запуска программы которую мы Тестируем динамическая с запуском Какие виды статического можно назвать что мы можем статистически тестировать так любую программу офлайн грубо говоря А как мы оффлайн будем тестировать вот у нас есть приложение сервер не работает
00:20:07 - 00:21:30
к примеру То есть я сталкивался с такой ситуацией мониторинг вакансии тестировщика у нас так это одно откликнулся то есть там было предприятие которое занимается какие-то микросхемы то ли чего изготавливает и когда мы прислали подходите тестовое задание Вот программу скинули программу грубо говоря она была не онлайн Она просто программа была открываешь там можно вести какие-то данные не в онлайне Дело не в том подключен или в интернет или нет Дело в том что запускается ли программа в принципе в
00:21:05 - 00:22:32
процессе тестирования или нет например вот телефон же у вас есть в нем есть фонарик А фонарик это тоже программа И когда вы нажимаете на кнопочку фонарик происходит работа кода которая идет к датчику лампочки он включается это уже динамическое тестирование А статическое тестирование в нашем случае это Например тестирование требований То есть у нас еще программы нет которую запустить можно но мы можем протестировать к ней документацию почитать ее внимательно найти какие-то в ней недочеты пробелы до что допустим у нас текст
00:21:52 - 00:23:04
ошибки не написано Хотя наша логика говорит что должно быть или еще что-то вот эта статическое тестирование как только вы программу запустили ее код отрабатывает Ваши действия это уже динамическое тестирование просто тического бывают кроме как тестирование документации например когда программист пишет код в программе вот пайчарм упоминали да что происходит до того как вы сбил телепроект пайчарм может сам подчеркивать проблемы с синтаксиса языка и логических взаимосвязи То есть он может сказать вам что о переменная
00:22:28 - 00:23:50
возвращайте не того Типа или пытаетесь вызвать функцию которая не существует Но код при этом даже еще не запущен это по аналогии с программой Word допустим Где вы пишете текст и так далее То есть текст тестируется статические и в данном случае код тестируется статический без запускать [музыка] новые знания в копилку OK [музыка] про уровни тестирования что-нибудь известно там Юнит тестирование сначала потом еще какой-то уровень потом еще какой-то уровень еще еще иногда называют тестирование по степени взаимодействия компонентов
00:23:12 - 00:24:41
[музыка] модульная вот тестирование это одно и то же модульное потом тестирование Так блин надо их разбить вспомните все функциональные функциональные не надо это не функциональный функционально это есть три или четыре уровня зависимости того где написано вот модульные компонент на это первый уровень это у нас Что такое Ну когда модуль это тестирование Когда проверяешь взаимодействие каких-то модулей между собой нет Роман один без взаимодействия когда взаимодействие между модулями какой-то уровень как он называется
00:24:09 - 00:25:38
[музыка] интеграционная интеграция А когда у нас все модули выстроены в одну как бы цепь и мы можем тестировать приложение целиком системы получается правильно системные подготовиться хорошо известно что-нибудь про техники тест дизайна Ну да есть класс эквивалентности разбиение пластиковые граничные значения потом попарно и тестирование так еще какие у нас там есть Ну ладно давайте поговорим про класс эквивалентности Как мы можем создавать проверки Да тестовые в соответствии с техникой допустим Не знаю есть у нас не знать 4
00:25:00 - 00:26:46
возрастных групп меру то есть начнем с общего Зачем нам нужно вот это эквивалентное разделение нужно протестировать какой-то окно ввода данных примеру в банковском приложении или где-нибудь и туда это и он должен принимать данные к примеру там от одного там до 65 лет кому-то кредиты выдавать какие-то возрастные ограничения к примеру есть если ты будешь грубо говоря 12345 на каждый год по одной проверки Но это замучаешься проверять на самом деле Вот и поэтому проще разбить на какие-то либо ну как бы
00:26:17 - 00:27:39
классики валентности грубо говоря на разбить на то что одни и те же данные сейчас сформулировать количество тестов короче правильно минимизировать количество тестов путем объединения входных данных входных параметров в определенные класс и тогда мы можем взять по одному параметру из каждого класса и таким образом сократить количество тестовых сценариев потому что мы подразумеваем что Если уж одна проверка прошла из одного класса то из этого класса все остальные проверки Окей про анализ граничных значений Вот
00:27:08 - 00:28:35
например у нас есть какой-то интервал позитивных данных например мы можем вести число от 10 до 100 сколько у нас будет проверок и какие соответствии вот с этой техникой тест дизайна Но получается от одного до 100 от 10 до 100 допустим насколько я помню часто ошибки на границах получается будет 9 10 11 и границы и 101 199 получается 6 проверок А зачем нам три проверки для того чтобы оценить каждую границу Почему не две например вот значение 10 и 100 в нашем они ходят внутрь границы или нет они позитивные или негативные
00:27:56 - 00:29:51
Зачем нам проверять 11 90 то и получается Я лишь не лишние Короче я накидал Почему Да ничего так многие делают потому что забывают что вот эти самые границы они не находятся в каком-то третьем состоянии они либо входят либо не входят это час Отлично так тогда поговорим дальше про тестовую документацию Какие виды теста документации известны [музыка] чек-лист Отлично Что такое тест-план и из чего он состоит тестированию описывает стратегии которые разрабатывается критериев грубо говоря до окончания есть
00:29:04 - 00:30:54
какой-то примеру тот же самый модуль который нужно протестировать Обычно он пишет какие проверки сделать как это программа а вот вам приходилось писать нет план писал они в конце там был он такой этот коротенький был так скажем видео созвон и скидывали но он был совсем коротенький я потом посмотрел как настоящий тест планы выглядят образцы Ну я бы не назвал Ну на самом деле ты планы бывают разные если грубо говоря работа на каком-то там предприятии где очень много формальных движений происходит там
00:30:22 - 00:31:42
тест-план будет выглядеть как дипломная работа в Университете но если если придется работать в каком-нибудь стартапе маленьком и в принципе никто не будет требовать от вас тест-план вы можете его создать для себя или для небольшой группы людей и он действительно может быть маленьким на одну на две страницы Это не проблема Это нормально Вот и следа может не быть Как ни странно когда Джуниор находит работу начинающий профессионал да то очень большой шанс попасть в стартап в маленький Где вы будете первым
00:31:08 - 00:32:17
тестировщиком и вот вы придете и спросит что будем делать дальше план Нам нужен У вас А вам надо будет его написать и все надо понимать будет как вы написать Зачем он нужен и так далее вот поэтому конечно лучше уметь его писать самому Даже если он маленький это не страшно если он корявенький страшненький это все не главное главное что в нем содержится то что должно быть тест-плане значит можно добавить можно если только получится написать Вот или где-то почитать перед этим как его лучше писать в принципе было перечислено
00:31:42 - 00:32:57
что в нем содержится но есть этот самый есть вопросы к нему я помню были типа что будем тестировать [музыка] все верно можете назвать критерии начала тестирования [музыка] готовность хорошо А еще какой-нибудь но подумать наличие должно быть тестовой документация должна быть в наличии как правило Хорошо хорошо замечательно всегда конечно бывает вообще должна быть какая-то документация в наличии по любому может быть может не быть может быть такой критерий начала может его не быть Как пример критерия Да отлично то
00:32:20 - 00:33:41
есть не всегда в каждом тестовом плане допустим будет такой критерий Ну достаточно просто знать что такое может быть а какие окончания тестирования какие-нибудь Я думаю что должно быть готова На мой взгляд написано же то что тестировать грубо говоря какой-то или модуль продукт должна быть написано Чтобы понимать тестирование раньше тем лучше но тем не менее все равно если уже чего-то есть критерии окончания тестирования помимо того что функционал должен работать как следует еще какие бывают критерии окончания
00:33:17 - 00:34:35
[музыка] надо выгонять продакшн просто все же сроки горят Не знаю бывает еще устанавливают допустим требования к количеству к наличию багов определенного приоритета Могут могут указать например что можно заканчивать тестирование если нет активных блокеров или критиков багов а допустим Если майнеры есть то есть а иногда могут указать что не должно быть никаких открытых вот любого приоритета хорошо В зависимости проекта с плана то есть мы обсуждаем то что может быть в критериях начала критериях окончания тестирование
00:34:13 - 00:35:46
что будет по факту это уже надо в реальном проекте смотреть невозможно конечно что это такое Что все включает [музыка] грубо говоря тестовая проверка одна То есть пишется с целью что одна проверка какого-то допустим то есть не знаю Ну проверка что что сценарий проверки какой-то проверки то есть грубо говоря чайник Там что кнопка нажимается хорошо а как Из чего состоит из Какие в нем бывают [музыка] потом описание должны быть Шаги по воспроизведению и фактически результат Ну что получилось [музыка]
00:35:02 - 00:36:52
хорошо есть у нас еще чек-лист он Для чего Нам нужен лист это грубо говоря список проверок но без подробного описания без шагов то есть чек-лист обычно используется в коллективе где либо все давно работают вместе хорошо знать либо ну какие-то некрупные [музыка] грубо говоря задачи Когда нужно протестировать примеру то есть простые то есть новичку не дадут по чек-листу что-то тестировать вряд ли мне кажется такая если вся документация тестовая в чек-листах Что же делать придется новичку читать чек-листы если придется
00:35:56 - 00:37:17
Ну вот критерии того что сложные проверки Допустим мы не можем описать чек-листами можем это верно помимо сложности самой проверки мы должны понимать сколько у нас человек в команде допустим тестирование кому эти чек-листы в принципе нужны То есть если у нас команда маленькая мы только один это наверное если мы разбираемся своих собственных листах они никому не понадобятся Но если у нас команда большая или мы знаем что он скоро увеличится допустим вы работали в маленьком стартапе он получил финансирование вам говорят Мы
00:36:37 - 00:37:55
расширяемся будет помощник наниматься скоро будет еще что-то или самого начала когда приходим говорят у нас большой проект Тогда наверное больше подойдут потому что будет много людей которые не в курсе системы неопытные Им будет в них разбираться проще к листа вот Ну ладно хорошо Что такое баг-репорта из чего он состоит но бак Report это описание ошибки то есть в отличие от с кейсов бак Report есть краткое описание подробное написано воспроизводимость указанные важные срочность [музыка] скриншоты окружения которого произошло и
00:37:16 - 00:38:52
если указывается только фактически что должно отработать по моему указывается Как должно быть что по факту получилось ожидаемые фактически результат еще мы из кейса можем взять шаги для воспроизведения Естественно предусловием да только в которой еще мы дописываем фактическое поведение ошибку можно сказать хорошо обсудим жизненный цикл баг-репорта Да что с ним вообще происходит обычно у нас Но мы завели баг-репорт допустим Какой следующий шаг над ним работы кто что делает но открыт он будет грубо
00:38:11 - 00:39:46
говоря то есть мы его завели на кого-то из тестировщиков назначили тоску так мы проверяем нужно проверить [музыка] воспроизвести этот баг посмотреть в чем проблема мы как тестировщики завели этот баг на кого же он назначается потом на одного тестировщиков и представим себе что он согласен со всем что действительно есть бак он его чинит допустим исправляет что-то входит что дальше происходит но получается что он очень нужно проверить так тестировщик которые заводил бак отлично если бак починили тогда что
00:39:04 - 00:40:42
происходит То есть если бак починит его нужно закрыть потому что он справа А если нет Если нет то его нужно переоткрыть она открыт заново так называется состояние и назначить Ну естественно чтобы его исправлять Хорошо тогда спорный момент могут возникнуть Ну если Вы снова исправит и вы будете проверять в принципе чего спорного он либо починили его Со второй попытки или встретились десятый или нет спорный момент могут возникать Когда у нас допустим что например мы бак завели и разработчик не хочет учинить вообще
00:40:07 - 00:41:27
смотрят на него и говорит не буду чинить и ставит какой-нибудь статус вот какой статус Может поставить например который будет означать чинить Ну допустим может быть такое что не срочный бак То есть у него есть какие-то более на него навалили навесили кучу ТАСС который нужно еще вчера сделать не срочность определяется приоритетом на табличке он перемещается статус от этого особо не меняется есть другие принципы по которым может поменяться статус например тогда может быть что не знаю если это был сайт какого-то магазина
00:40:47 - 00:41:59
Носков магазин закрылся сайт больше функционирует проект закрылся Значит уже и задач нет на рынке труда я не буду работать вот не хочу вот бывает допустим статус дублики Говорит есть уже такой бак поэтому этот я не буду чинить такой же есть и Вот тебе ссылка на него и занимается как хочешь Что тогда в этой ситуации перед тем как заводить бак нужно проверить если такое существует или нет изначально нужно но так получилось что проверяли а там тысячу открытых багов и что-то как-то было полдня не захотелось перепроверять весь
00:41:28 - 00:42:58
бы клок багов и просто завели на всякий случай и вот нашли такой же что происходит и посмотреть что было в предыдущем который уже заведен так и тогда один нужно убрать получается сравнить их правильно сравнить если уже был такой бак посмотреть исправлен он или нет Если он исправлен ну то есть предыдущий но не заводить удалить А если он неисправлен пускать вот у тебя в том баги Ну ты его не доделал еще доделывали давай правильно тот доделывай давай этот свой который дубликат он просто закрывается и
00:42:16 - 00:43:32
прилинковывается потому что тот еще не доделал А если тот доделал был когда-то и так получилось что бак опять появился такое бывает там напутали при когда заливали изменения в коде вроде починили А через неделю он опять всплывает потому что ну так в Континенте integration системе что-то пошло не так тогда нужно сказать Да тот бак был пофикшен он появился Опять поэтому давай-ка мой Вот этот новый так кроме дубликата что у нас еще бывает у нас еще бывает что программист говорит [музыка] Не могу воспроизвести
00:42:54 - 00:44:11
То есть он выполняет шаги которые указаны в баге и у него ожидаемое поведение совпадает с реальным А у тебя нет это тоже статус при котором программист Как бы говорить я чинить не буду к на три продюсер мне не воспроизводится что в этом случае происходит надо перепроверить тогда переоткрытие попробовать пройти по своим шагом потому что может быть где-то ошибка Если все у тебя воспроизводит надо проверить может он воспроизводит на другом окружении потому что на разных окружениях может по-разному производиться не
00:43:35 - 00:44:48
воспроизводится кроме окружения Что может быть еще не так [музыка] окружение что мы включаем в себя в том числе может быть система не то может быть версии системы не то окружение так получается что посмотрел еще бывает разная версия коды то есть Может быть так что тестировщик смотрит на одной версии приложения программист на другой И поэтому они по сути смотрят на разные приложения и на одной версии кода воспроизводится на другой нет хорошо вот допустим есть ситуации бак завели программист либо сразу
00:44:15 - 00:45:47
отказывается учинить либо после нескольких попыток он говорит так у меня не воспроизводится все отстанет меня роман Я короче занятой Важный человек не буду Я больше ничего чинить а у тебя бабку ты уже проверил сто раз Ну воспроизводится и у него есть какая-то проблема системы надо что-то с ней делать Что ты будешь делать с этим ничего не воспроизводится и больше ты мне его не отправляй отвлекаешь важного человека Отважные работы Если я перепроверил а у него нет Я тогда пойду скажу такая ситуация или
00:45:15 - 00:46:37
выше в зависимости потому что значит делать [музыка] Так кто там повыше то идет дальше про Бакт туда пойдем Ну Project продакты Проджект это немножко разные Project Manager PM Ну тогда вот к нему идем и он как бы отвечает за проект он может быть не в курсе конкретных технических вещей в проекте Ну за ним последнее слово кто что делает и в этом случае он может вмешаться и допустим либо он скажет что типа Ну скажешь что баг действительно не воспроизводится вроде как Или он не так важен его можно убрать куда-то А может
00:46:01 - 00:47:24
разработчику сказать Смотри бак важный вот мне тестировщик доказал что он воспроизводит собак давай-ка Ты постараешься и починишь и он будет делать мужу некуда деваться он уже не сможет отнюдь тут Почему дама тема поднимаем потому что очень часто новички теряются на проекте и не знают как поступить в такой ситуации А многие опытные программисты не пользуются неопытности новичка и начинают его как бы так отпихиваться от него не мешайся Да и в этой ситуации некоторые допустим Junior тестировщики они начинают в
00:46:49 - 00:48:04
агрессию начинает ругаться Вот еще что-то А это ни в коем случае делать не надо всегда надо помнить что у нас есть Project Manager который в итоге за которым последнее слово и все подобные вопросы все идут к нему а он уже решает Что делаем хорошо Давай обсудим разные виды приложений в принципе вот мы можем попасть на рынок и нас возьмут проект где мы будем тестировать какой-то из видов приложений Вот какие виды приложения ты в принципе знаешь есть один приложение это веб-приложение это сайты которые мы Тестируем в
00:47:31 - 00:48:46
браузере какие-то есть какие мобильные как они называются Ну не знаю Яндекс еда та же самая какая-то не знает приложение Ну да просто у нас Ну мобильное приложение еще какие не знаю может его просто не понимаю Не знаю У нас есть технически технически несколько видов приложений сейчас их можно выделить можно сказать три есть нативные приложения это они же еще иногда называются десктопными приложениями это приложение которое запускаются на конкретном устройстве либо компьютер либо это смартфон и работают чисто из самого устройства
00:48:15 - 00:50:01
без подключения к интернету как правило там есть подключение к интернету но не совсем для того чтобы работало приложение для того чтобы данное подгружались немножко другое есть у нас вы приложение у которых принцип работы Такой что они работают веб-серверы и открываются через браузер и есть еще один вид приложений гибридные которые одновременно могут являться часть этого приложения написано на нативном языке часть логика допустим приложение может находиться на сервере вот Можешь ли ты вот рассказать В чем разница
00:49:15 - 00:50:32
непосредственно допустим в тестирование этих трех видов приложений или особенности тестирования Ну если допустим это приложение которое отправляет данные на сервер постоянно не подгружает периодически то есть грубо говоря то там по-другому расскажи начнем с веб-приложений Какие особенности тестирования в приложении чего есть в приложении Чего нет в других видов приложений Как это влияет на тестирование приложение работает только с Интернетом правильно понял получается Интернет пробили она не работает Следовательно
00:49:53 - 00:51:20
там происходит обмен данными так то есть я так полагаю что это тестированию идет Все дело тестирование API тестирование на отказ восстановления если мы Интернет отламываем да То есть можно проверить как он работает нагрузочная на сервер так То есть можно накидать допустим тот же самый филлер кучу народу и проверить да можно нет Что ещё в приложении [музыка] допустим разные может быть установка требуется для приложения нет нативные приложения в чем у них особенность будет тестирование альтернативные что-то я не припомню
00:50:42 - 00:52:03
Может только что обсудили что есть десктопные Они же нативные десктопные они на компьютер устанавливаются нательные то же самое на телефон сейчас и приложение которое на компьютер устанавливают их тоже часто называют нативными это как бы уже более принятый термин в чем у них фишка приложение которое если который на смартфон например Или например на смартфон представим себе что приложение мы проверяем который на смартфон чем особенности тестирования особенности работы есть пару секунд сообразить можно
00:51:49 - 00:53:01
сделать глубокий вдох на реальном собеседовании когда вопрос ставится в тупик никто не торопит ту же секунду отвечает всегда можно чуть-чуть передохнуть взять кружечку с водичкой туда глотнуть и подумать это не возбраняется Нет наверное не отвечу на этот вопрос хорошо Хорошо я понял надо будет почитать Я рекомендую так для себя сделать построить табличку и по определенным критериям выписать все три вида приложений нативные гибридная веб какие-то будут критерии Требуется ли установка нативного требуется допустим гибридного
00:52:39 - 00:54:05
требуется Веба нет требуется ли разрешение на обновление приложения он активного требуется у гибридного и веб нет требуется ли для работы приложение подключения к интернету гибридного требуется он активного нет И вот и так далее вот выписать и потом Глядя на эту табличку можно быстро сообразить и как они работают и как бы можно было их лучше протестировать Хорошая идея потому что в реальной жизни на реальных собеседованиях часто вам скажут вот мы на собеседуем на нативное например приложение на Android
00:53:26 - 00:54:59
протестировали и даже не зная что конкретно за приложение у них будет уже будет понятно в голове Какие виды тестирования будут к нему применяться и на собеседование это можно сразу выдать более хороший ответ потому что будет сразу все понятно какие-то могут быть проблемы особенности и так далее Поэтому вот эти разные виды приложения надо для себя осознавать хорошо [музыка] да Хорошо тогда по процессам разработки будет последний вопрос Если знакомство вот со с крамом с канбаном с чем-то еще я представляю что
00:54:12 - 00:55:45
такое жире был аккаунт То есть я даже заводил бак репорты Так ну багри порт это понятно Вот А вот когда с принтами это идет грубо говоря двухнедельный может больше может грубо говоря создается планирование разработка потом демонстрация внедрение если короче а по-моему не будем про кабан про скрам чуть поподробнее названо все примерно хорошо вот про каждый этап подробно вот планирование вначале спринта что у нас происходит Какой объем работ нужно выполнить задание то есть естественно обговаривают это
00:55:10 - 00:56:45
выставляется время они начинают работать А вот объем работ объем работ который будет выполнен он как В чем выражается что конкретно в этот Объем работы не знаю допустим нужно написать [музыка] чат-бона какого-нибудь примеру я не знаю или Ну задача задача конкретная задача вот самой доски их выбирают Откуда их берут есть там есть такое понятие это вот карман в котором лежат все задачи У нас есть Black Lock спринта и бы клок всего проекта И вот во время планирования из бэк Лога проекта из всей кучи задач
00:56:10 - 00:57:28
которые запланированы на проект берут задачи влог спринта какой-то часть этих задач и помимо того что выбираются задачи что происходит еще с этими задачами возможности задачи либо это Story Point и либо это просто время указывается сколько займет Это задача предположительно Вот и уже после того как указывают трудозатраты на задачу и тогда берут или не берут Вот хорошо в процессе спринта какой там происходит процесс допустим к примеру идет у нас двухнедельник с принтами к примеру дальше идет ежедневные грубо говоря на
00:56:55 - 00:58:20
которых ты говоришь что делать Вчера И что будешь делать сегодня планирование обсуждение того что получается избы клубы грубо говоря что-то можно взять глубоко глубоко вот ответили короткий вопросом про делики ответ отличный все не надо больше придумывать закапываю сам себя да да слишком проблема такая Мне кажется что я все не до конца чего-то нет такой проблемы наоборот иногда слишком много сверху фантазии бывают все правильно дейлики что было вчера Что будем сегодня делать и какой-нибудь там может быть
00:58:00 - 00:59:13
если вопрос назрел который не получается лично с кем-то выявить вот допустим вопрос с багом который туда-сюда летает Да вот мы чуть раньше обсуждали там разработчик не хочет чинить вы хотите самое время чтобы поднять этот вопрос наружу в конце спринта что происходит непосредственно трудности чтобы неплохо улучшить вот отлично ответ правильно все супер и кроме ретроспективы что еще в конце еще Груминг Я помню такое слово но оно даже перспективы это когда разбор актуальности тоже задач происходит
00:58:39 - 00:59:51
не будем лучше еще у нас кроме ретроспективы бывает непосредственно релиз приложение вот и еще бывает так называемая перед релизом демон То есть когда мы заказчику потенциальному либо это менеджмент если у нас продуктовая компания либо это реальные заказчики если у нас мы показываем что мы собственно сделали Типа что-то такого видео это демонстрация или демон хорошо Ладно супер в принципе мы обсудили все что я хотел за наш Собес как раз где-то в час мы уложились сейчас это обычное время для нормального собеседования
00:59:27 - 01:00:55
Вот какие есть замечания но первое что я прошу это некоторые определения простые просто выучить например определение четкое тестирование потому что у вас получается что вы иногда пытаетесь его как бы додумать в процессе не только тестирования еще другие и допустим цели тестирования да вместо Да долго мне если какой-то вот теоретический вопрос простой просто выучите там самая короткая определение из какого-нибудь там самого популярного сайта если хочется например тестирование это там проверка соответствия между ожидаемым
01:00:18 - 01:01:38
фактическим поведением программы все выучить Чтобы не думать об этом потому что на собеседовании когда Вам приходится вы переживаете за ответ и приходится что-то в голове у себя собирать по кусочкам можно засыпаться а вот тестирование то-то все ответили на вопрос не волновались потому что вы выучили вот такого рода вещи потом цель тестирования как раз таки да Найдите какую классификацию которая удобнее для вашего понимания запомните и чтобы там забуксовали по видам тестирования в принципе мы обсудили большое количество видов
01:00:58 - 01:02:20
тестирования помним что про ящики Да у нас не только важно куда У нас есть доступ но и важно что мы покрываем тестами белый ящик кот черный ящик требования бизнес требования мы не стали обсуждать но Я рекомендую для себя повторить соотношение есть тестирование очень часто тоже могут спрашивать если плохо помнятся регрессивно и смог Да только Цените лучше не называть санитарным потому что очень многих от этого припекает называется Цените Цените Да не знал что в некоторых книжках так и написано бывает
01:01:40 - 01:03:08
Значит короче логично что можно так называть лучше не называть лучше не называется Цените вот статистика динамическая тоже да вспоминаем В чем разница потому что не смогли ответить по уровням тоже в итоге ответили но как-то сначала забуксовали не помню не знаешь там компонентная интеграционная системная тоже надо повторить тест-план хорошо чек-лист принципе тоже хорошо нормально Ты с кейс в ТСК мы обсудили что там базовые поля есть да там шаги ожидаемое поведение название там на самом деле еще бывают предусловие
01:02:31 - 01:03:50
пост условия комментарии еще какая потому что без них то никак на самом деле без предусловия Вполне себе можно и в реальной жизни на реальных проектах очень редко пользуются Бреды пост условиями потому что они нужны только там где проект имеет какую-то особенную сложность и вы тестируете не просто какой-то сайт по продаже Носков который мы сегодня много раз обсуждали а тестируйте какую-нибудь допустим сервис который объединяет там допустим работу нескольких банков на каком-то очень низком уровне и вот там вот очень
01:03:20 - 01:04:26
сложно Все вот там полезно применять такие вещи в базовых приложениях соцсети интернет -магазины что-то еще не так часто это используется просто на собеседовании могут придраться в этом забыли Поэтому лучше их помнить для меня так по жизненному циклу баг-репорт до вспомнить тоже в чем у нас был затык в каких случаях какие статусы ставят программист если он не хочет сразу чинить бак то есть Canon 3 produce не могу воспроизвести дубликат уже такой был еще у него может быть статус вон Ду не буду делать не буду делать Почему Потому что
01:03:57 - 01:05:22
например часть приложения в котором вы нашли бак скоро будет удалена или полностью переписана и чинить бесполезно потому что ее все равно скоро полностью переделывает Вот четко нужно понимать это частая История это бывает хорошо есть разные схемы в интернете они не всегда хорошие но в принципе мы сегодня это обсудили несколько раз и я думаю запомнилось можно их посмотреть и для себя изучить принцип работы гибридных приложений нативных Кто они это одно и то же просто название разные вот понять в чем их разница в работе и
01:04:49 - 01:06:08
соответственно как это повлияет на тестирование очень важный тоже именно практический вопрос будет чем заняться сегодня да да А в остальном в принципе вот так более-менее но подготовка требуется еще конечно я к вам еще запишусь потом когда подготовились Если вы конечно будете проводить еще еще мне такие которые говорили но еще пока никто не вернулся это не запрещено если это не запрещено считаю что это просто вот я знаю вы проводите такие записи еще по моему Вадим Кензов Я видел на YouTube там тоже
01:05:34 - 01:06:54
проводит даже что-то похожее там вместе собираются в 3 тестировщиками Ну тут уже Я рекомендую все-таки постараться по возможности ходить побольше на реальное собеседование потому что они вас закаляют все-таки Когда приходишь на так называемый мог собеседование как у нас сегодня Ну немножко меньше волнения все а попадаешь на реальная ладошки потеют под проступает намного страшнее и вот чем чаще ходишь именно на реальность собеседование тем лучше как раз таки вот это вот сопротивление стрессу нарабатывается вот во-вторых есть шанс
01:06:16 - 01:07:31
что вы попадете таки на работу и знаете собеседование будет ходить не просто чтобы опыт набивать Да ну и есть шанс что ну пройдете собеседование а ведь ради этого все в итоге делается То есть я как раз над этим работаю Вот появилась такая возможность попробовать пока ещё не было Просто реальных собесов Вот и Мне прям интересно это Поэтому я думаю что я вернусь всё-таки когда подлечу хорошо Хорошо буду ждать Вот буду ждать Окей на сегодня все Спасибо что пришли я надеюсь тетрадочку все записали Вот и Если уж сильно захочется то
01:06:56 - 01:08:18
конечно можно до свидания Спасибо огромное хорошего дня пожалуйста Роман давай пока Ну как он собеседование стоит заметить что Роман довольно сильно волновался и часто очень сильно спешил ответить на вопрос прежде чем хорошо Подумайте из-за этого некоторые ответы были не совсем корректны также есть еще одна особенность его ответа в том что он часто отвечал шире на вопросы чем требовалось на реальном собеседовании Старайтесь отвечать именно на тот вопрос который Вам задают и растекаться в различные рассуждения
01:07:43 - 01:09:02
философии при ведении примеров только тогда когда вас об этом напрямую просят Спасибо что посмотрели собеседование всего хорошего пока
01:08:27 - 01:08:49