[музыка] всем привет с вами николай черкасов тестировщик с многолетним опытом и основатель школы черкасов school сегодня у нас очередное собеседование начинающего тестировщика со беседуем алену она имеет определенный опыт в тестировании в проектов но не очень большой и хотела бы попробовать свои силы на junior и если вы хотите поучаствовать в подобном собеседование заполните форму по ссылке внизу в описании или напишите мне в личку как это сделала алена давайте поддержим ее лайком и добрым комментариям под видео итак смотрим
00:00:00 - 00:01:29
собеседование так итак сегодня с нами алена алена расскажи пожалуйста про себя если у тебя какой-то опыт тестирование на кого ты хочешь про сортироваться на какой уровень я хочу при собеседователей окей инженер джон вот я окончила курсы по тестирования то есть хочу проверить свои знания опыта у меня небольшой я пробовала внутри я работала с фронта стиральщика вот заводила баг репорты и все это время то есть примерно с декабря месяца я пытаюсь и для себя от нестерово веб-сайты этой свет магазины
00:00:50 - 00:02:11
тут последние с тестом задания мне попадался сайт любое я тестировал обед магазин за документация знакома писал ли чек-листы и тест кейсы но соответственно когда роботы порты супер это отлично это замечательно мобильные приложения приходилось дотировать когда нет нет этого не дошла хорошо ладно ну тогда начнем с базовых вопросов что такое тестирование тестирование это процесс который бы цель одна из которых является чтобы удостовериться что сама программное обеспечение работает так как должно соответствует ожиданиям заказчика
00:01:33 - 00:03:03
ожидания заказчика каким образом выражаются виде требований то есть он выкладывает то что он хочет принимают опишу это некие требований и яйцеклетка не нужно уже будет реализовать что делать если нету требований но скорее всего нужно как бы поговорить что именно все таки хочет и создать на том что он хочет уже этот человек который собирает это все стонали зиру и создает эти требования человек который собирает как называется менеджер менеджер хорошо а если так получилось что нет выхода на заказчика но так получилось он может
00:02:29 - 00:04:08
быть ответит когда нет на вопросы на твоем может быть не ответит тебе уже надо на основании чего то составляет тестовую документацию что-то еще может сделать откуда взять требования если так подумать то есть завистники наверное того что хочет фирмы логически не знаю там помыслить если там какая-нибудь форма что-то логически хотя бы уже какие-то сделать основное логически основной помыслит ну ты правильно говоришь это называется использовать какую-то формальную логику да то есть есть вещи которые мы априори знаем и нам не нужно
00:03:21 - 00:04:50
чтобы это было прямо четко прописано с требования потому что допустим если мы тестируем интернет-магазин мы примерно подозреваем что во всех интернет-магазинах есть корзина что есть функция оплаты просто может быть каких то нюансов мы можем не знать но тем не менее то есть мы требование можем забирать из похожих сервисов можем сами из головы выдумывать требования ну которые соответствуют общей принятому подходом например к интернет магазин хорошо хорошо ты говоришь что вот одна из целей тестирования это сравнивать ожидаемое
00:04:11 - 00:05:25
поведение с фактическим а еще какие цели тестирования ты знаешь о цели тестирования то есть даже сообщи тоже чтобы готов ли вообще продукт к релизу то есть насколько он готов вот ну я конечно не назвал ты цели это скорее всего как следствие того что ожидаемый и фактически результатах то есть минимизировать баги то есть как можно чтобы меньше было превентивный такой метод по как то есть с одной стороны мы можем находить баги и report всегда а с другой стороны мы как-то можем как ты говоришь превентивно
00:04:47 - 00:06:06
делать так чтобы багов становилось меньше а что это вот задействует такое как магия когда мы заранее что тепло но на самом деле то есть ты когда тестируешь программу ты не только багере портишь но и можешь обратную связь давать для команды разработки и например указывайте на том что вот в системе конкретно какая-то часть этой системы она может быть не очень хорошо разработанным вероятно в ней будут баги потому что как тебе кажется она права то вот и таким именно образом ты можешь помогать разработки
00:05:27 - 00:07:01
заранее обращай внимание на те места где изначально могут быть баги то есть обратная связь а для команда разработки может быть вот и также может быть обратная связь для командой не в техническом плане а в плане того что изначально хотел заказчик то есть помимо конкретных требований мы можем увидеть что заказчик например желал бы ну вот есть у него основная идея продукта ты допустим в процессе разработки видишь что по каким-то причинам в первую очередь разрабатываются части функциональности некоторые важны а которые не важны и ты
00:06:32 - 00:08:05
можешь также дать обратную связь и сказать так ребята у нас вроде багов нет все правильно но вот наша разработку что-то не нато акцентирует внимание вот заказчик хотел чтобы в первую очередь было сделано вот другое и это тоже как бы одним из атрибутов тестирования является хорошо ладно давай поговорим про вида тестирования какие-то знаешь классификации видов ну и стандартные функциональные функциональное ручная автоматизированное тестирование вот там нет это от майкл большом то есть модульное тестирование
00:07:19 - 00:08:45
интеграционное тестирование уже системы это стерн и тестирование при приемочные тестирование сама ну и хорошо много разных называла классификации что здесь у нас и приемочные модуля интеграционная а вот приемочная модульная интеграционная системная это в принципе мы обычно называем в теории уровнями тестирования ну как правило расскажи тогда подробнее о чем эти уровни самыми шорами это unicast и то есть какой то определенный один модуль тестируется вот и больше ничего не затрагивать интеграционное тоже как
00:08:05 - 00:09:33
взаимодействие двух и более модулей между собой уже тестируется вот системное от и до все полости система тестируется на е100 кратко приемочные то есть уже либо вы заказчика либо потенциальных от тех кто будет пользователей они уже тестируют насколько им подобные неудобно все ли в порядке там все ли соответствии требованиями хорошо ты как горошина это сиропе когда думаю что на каких уровнях тестирования больше всего будешь действовать скорее всего либо модульной и интеграционное модули на стоит дни это
00:08:52 - 00:10:11
умение заденет модуля это скорее всего это будет разработчики либо и системная ну и приемочные иногда хорошо что не знаешь про ящики разноцветные шары и белый черный ящик и тогда когда мы не уходим в самой системе конечно не уходим на такая не знаю какой код как у капы пишет этого здания то есть на этом в основном требование заказчика белый ящик это уже как мы уже знаем пока ты все пишется сам код понимаем эту логику и то есть мы сам от постеры абсолютно правильно все верно а слышал когда-нибудь про стеклянный ящик
00:09:33 - 00:11:20
это то же самое что и белый просто некоторых книжках он называется white суть одно и то же но вот если спросит теперь ты знаешь что стеклянная хорошо есть еще хитрый серый ящик которые всем очень сложно объяснять слышал о таком слышал она не совсем понятной границы там вроде как нужно что-то частично знать код на насколько его нужно знать не совсем это правда никому не понятно поэтому можно прочитать 10 статей и там они всегда будут друг от друга отличаться ладно какие-нибудь не функциональный виды
00:10:33 - 00:11:55
тестирования ты можешь назвать которые непосредственно не относится к тестированию основные функции системы домах например graphical user interface насколько он выглядит соответствует макету браузерное тестирование то есть мы и в самом как бы две пинты это приложение мы открываем праздник браузеров как google chrome например mozilla microsoft если мы смотрим что действительно нас все открывается все хорошо работает на разных платформах вот либо например инсталляция то есть но это скорее всего будет уже ближе к мобильном приложении
00:11:17 - 00:12:51
то есть что она действительно приложение на восстанавливается что нас она обновляется все хорошо и что мы его можем ударить вот локализации то есть то что мы например пишет ну как бы для россии да даже внутри мне кажется самой россии у нас есть разные часовые пояса отыскав что отображается время правильно локализация это не совсем правильный часовой пояс скорее в россии у нас принято один формат отображение даты потому что для россии ты стену локализации вряд ли подойдет если только ты не будешь проверять и
00:12:14 - 00:13:34
язык наших республик там тувинские какой-нибудь или пермский диалект как гривне вот а больше если мы говорим про время то именно формат отображения даты и времени вот мы просто например в сша у нас что принято у нас принято 12-часовой сутки и м и п м а в европе допустим ну в частности в континентальной европе в россию нас 24-часовой способ отображения времени вот соответственно при переключении локали формат отображения должен меняться формат даты у нас принято день месяц год а в америке принято месяц день
00:13:03 - 00:14:31
год вот и или даже год день месяце такое часто используется к кроме формат отображения даты и например языка что еще может меняться как ты думаешь если например та же самая магазина одежды это как минимум валюта то есть были до каждой страны и она разная это размерная сетка потому что она тоже разнообразная наверно хорошо достаточно в принципе ладно хорошо слышал ли ты когда-нибудь о таких видах тестирования как smaug цените и регресс услышала смог тестирование то есть и только поверхностно как тестирование
00:13:46 - 00:15:26
билда функциональности вот без углубления что бог как более менее стабильный гоните это примерно то же самое но она уже углубляется что действительно она работает функциональность нас правильно вот что как бы это же вышел бы меня уже стабильный регрессионное тестирование тестирование когда у нас выходит новая фича мы смотрим что все остальное то что было написано да и проверены она у нас стабильно и никуда не не попала что все работает все хорошо как-то интересно правило слова стабильность через все три
00:14:42 - 00:15:55
вида тестирования и в итоге я так и не понял чем они друг от друга отличаются если они все проверяют стабильности и у нас все хорошо и стабильно если смотреть на смог и шарики они проверяют одну притчу о [музыка] чем они отличаются друг от друга тогда сами проверяют одну фичу и дают стабильно смог это поверхностная проверка солите это уже более углубленная проверка программы нет именно функциональности а смог это ну да чем отличается смог оценить и что они смогут быстрее то кейса пишут пишут сюда и проверяется ну буквально
00:15:18 - 00:16:53
как бы поверхность то что все работает все таки всякий то есть работает приложение в целом хорошо а sanity это наверное про конкретную функциональность то есть смог это проверка в шире мы проверяем что все приложение более-менее в принципе работает это нам нужно чтобы сделать вывод о том что мы в принципе можем приступить к тестированию sanity это проверка конкретной функциональности в глубину это может быть как новая функциональность которую только что написали так и какая-нибудь выборная по определенному признаку вот и как раз
00:16:19 - 00:17:30
таки и когда мы проводим sanity мы не делаем вывод о том что в принципе все хорошо мы делаем вывод о том что конкретно функциональность отлично замечательно работает и готова к тому чтобы ее добавлять в общую программу кусочек вот-вот общем а regression орешкина этого же когда добавляют снова функциональной стать мы смотрим что все остальное тоже работает корректно и все остальное что что остальная стальная послал остальные функциональности может ну как бы проверили национальности добавили новую и смотрим
00:16:55 - 00:18:16
что новая функциональность не повлияло на работу уже старой функциональность значит мы прогорим старый функциональности в процессе но чтобы при добавлении новых работу старый оцените но тогда зачем 1 функциональности она из после мой как она взаимодействовать со стальными как только как она я сама а потом по крыше регрессия когда мы проверяем новой функциональности стороны проверяем так вот мы [музыка] но это немножко ошибаешься в общем регрессионное это как раз таки когда мы проверяем старую функциональность
00:17:40 - 00:19:00
который не относится к новый и мы проверяем что старая функциональность работает после того как мы добавили новую а новую мы перед этим проверяем в рамках цените тестирую то есть мы проверили смог что быстренько все более-менее целиком держится потом проверяем самую свежую функциональность а потом проверяем в рамках регрессии все остальное зачем нам в принципе вода вот такой трехуровневый подход ты знаешь отдельного мог соединить иммигрейшн взяли бы все ты с кейсы пихнули бы сразу там тысяч от эскиза до и проходили бы
00:18:39 - 00:20:00
какая разница с макс интере грешник ну это как бы поэтапно 5 сначала мы проводим смог потом сами часто помада регрессионная зачем все поэтапной тело зачем и чтобы но если мы все будем писать мне кажется просто мы можем упустить некоторые баги и ошибки что-то может неправильно работать и потом все это в этом обратно в обратную сторону копаться где что она ходить после зарплате ошибка в оборотной стороны карта c-class ну смотри у нас есть тасс кейсы они уже написано они уже написаны то есть мы ничего не можем
00:19:19 - 00:20:34
пустить у нас есть из кейса мы их по очереди проходим вот у нас допустим есть 1000 тыс кейсов не знаю этом 50 на смолк там 200 на саммите и там 750 это регресс вот у нас есть куча ты skism и зачем-то выделяем цените смог регресс и зачем-то их проходим именно по очереди по какой-то логики вот зачем мы это делаем если например мы в итоге все равно пройдем все проверки был у нас тысяч кис-кис мы бы их называли куча тэсс кейсов на я вот ты садишься и шагающих по одному зачем нам вот эти уровни билет
00:19:59 - 00:21:15
это наверное , связанность разработка и то есть пишется ну как бы постепенно идет разработка вот то есть какой то какой то написали функциональной ставите потом пока протестирует это solaris пишет новых националист проверяем уже и и вот соответственно провели поэтому идет от меньшего большему выдает проверили все хорошо у нас стабильно все работает то есть мы берем уже следующая пока мы следующую смотрим пишут след ну как бы соответственно следующих и но же как бы ног проваливай уже проверили вторую функциональность
00:20:36 - 00:22:06
проводим регрессионное тестирование что встали функциональностью на все в порядке вот и так как бы как ну запах . в процесс разработки ты правильно описала виды тестирования действительно применяются по очереди каждый раз когда у нас приходит к это новая функциональность и но суть зачем мы все-таки делим 3 ты не назвала смотри просто дело в том что мы не всегда получаем стабильный билд в принципе постройках добавим его функциональность иногда после добавления новой функциональности вообще программы
00:21:25 - 00:22:41
не открывается и нам наша задача тестировщика поставлены получаем очередную сборку убедиться в том что build вообще достоин или доступен для тестирования масштабного и поэтому нам нужно выделить отдельные кейсы которые просто по верхам проверю что программу в принципе работает потому что если она в принципе не работает нет никакого смысла проводить или грыж и углубляться в какие сложные кейсы по старым и нужно не работает цените нам нужно чтобы проверить свежую функциональность как правило почему мы
00:22:02 - 00:23:18
проверяем свежую функциональность потому что я только что добавили и в ней статистически максимальное количество багов и ну скорее всего с ней что-то не так потому что я только что добавили и мы проверяем это во вторую очередь после того как вы стены что программа в принципе работает а регрессионным и проверяем в последнюю очередь потому что шансов найти баги в регрессионных тестах намного меньше потому что регрессионной тесты это то что было когда-то цените но в предыдущем цикле разработки и мы
00:22:40 - 00:23:55
когда-то это уже проверили а потом просто сложили в чемодан храним это все и поэтому в некоторых компаниях иногда даже от регрессии отказываются чтобы сэкономить время или говорят но вы проверяете регрессию и только если время останется поэтому именно для того чтобы приоритизировать свою рабочую загрузку мы вот эти вот и придумываем уровне и в голове у все держим где мы сейчас на проекте где сейчас наша последняя фича чтобы понимать как глубоко прямо сегодня мы должны тестировать и вот это очень
00:23:18 - 00:24:32
важно именно вот паз практически точки зрения когда ты будешь работать понимать поэтому это глубоко это обсуждаем это довольно практический вопрос хорошо а есть еще деление из кейсов на позитивные и негативные проверки знаешь в чем разница позитивные проверки это то как мы ожидаем то есть мы не пытаемся сломать систему мы так как пользователь должен как бы вести себя проверяем так скажем так друзья вести себя система имена уже в негативных то есть мы нестандартно и начинаем владеть проверки так
00:23:54 - 00:25:31
в идеале конечно чтобы если мы этом не знаю пишем кейс такой чтобы программа именно сработал они положительно как-бы не про дальше не пропустила скажем вода позитивный настрой направленным то что как система работает при нормальных условиях то есть нормальный как бы там будем все значения в пределах допустимых принятия там полей например негативно это наоборот уже что положено как не должна работать просто не проверяем как система не должна работать это интересно а какой у нас ожидаемое поведение в негативных сценариях тогда
00:24:42 - 00:26:17
что компьютер взрывается или дым идет или кореи если мы смотрим калькулятор [музыка] делить на ноль у нас нельзя это будет негативная проверка то есть а душа воды со ошибка если у нас деление на ноль произошло соответственно это уже дефект то знает как бы негативная проверка оно не зависит как бы все равно положительный результат ожидаемо у нас чтобы задать свой ошибка а уже фактически это же другое а при позитивных то есть это означает по 4 выдает и тут ты правильно назвала пример а не в теории не получилось хорошо писать
00:25:34 - 00:27:02
правильным ответом будет то что мы ожидаем что пользователь который пользуется системы будет либо делать то что подразумевает системы либо то что противоречит логике системы система сама по себе она всегда адекватно должна на это реагировать вот только в случае если позитивный сценарий это какая-то там новых ну какой положительный сценарий там прошла покупку интернет-магазине что-то еще а если пользователь ведет себя так как система не хотел бы чтобы все вел туда ошибка какая-то показывается tooltip как
00:26:19 - 00:27:31
он всплывает или просто не происходит реакции системы всякое бывает а зачем нам такое деление как ты думаешь но мне кажется нужно потому что первую очередь она проводится позитивные проверки чтобы удостовериться что действительно хотя бы функциональная седана правильно все работает система реагирует вот потом уже негативная проводится то есть нахождение багов если у нас все хорошо позитивных и ошибок ничего не выдает только вы приступаем к негативным чтобы уже проверите исключить уже негативной
00:26:54 - 00:28:06
сценария а почему ну давай проверим сначала негативный а потом проверим позитивом и какая разница но это может наверное даже связаны с тем что первоначально нам не надо находить ошибки именно нам не надо ломать систему а хоть обостриться что она соответствует требованиям вот поэтому соответственно требованиям это положительное в основном позитивные позитивные проверки поэтому их проводят в первую очередь ну примерно так на самом деле в требования могут быть указаны негативность сценарий например какая
00:27:30 - 00:28:45
ошибка должна быть показано в случае негативно на самом деле проблема в том что негативных сценариев бесконечное множество их можно придумывать придумывать придумывать придумывать тут пользователь какое-то сочетание клавиш и вел тот он какой-то вирус кинул на вход тут не что-то еще и это вечно вечно вечно и ты будешь и бесконечно этим заниматься и в итоге вместо того чтобы тестировать программу будешь бесконечно придумывать негативный сценарий поэтому в индустрии как правило пишут самые частые возникающие самые базовые
00:28:08 - 00:29:10
негативный сценарий ну например юзер неправильный вел логин или пароль но это классика да то есть и как можно не предусмотреть такой случай и ты эти сценарии разумеется проверишь после того как ты проверишь позитивный сценарий вот но будет какой-то момент всегда в проекте где ты будешь останавливаться придумывать негативный сценарий и дальше двигаться в тестировании вот зачем чтобы бесконечно не генерировать сценарии негативного потому что сколько это их не генерировала все равно надет юзер который придумать то что ты в итоге
00:28:39 - 00:29:48
не предусмотришь и от того не стоит хорошо супер окей техники то с дизайна знаешь какие-нибудь классы эквивалентности граничные значения перехода состояния есть и попарно тестированные на есть попарные не применяла ладно давай с самых простых начнем вот эквивалентное разделения стоит на эквивалентно разделение такие классы внутри которых система реагирует одинаково и на любое значение внутри этого класса так может вылезти пример класса могу например у нас есть поле ввода налоги принимают значение
00:29:13 - 00:30:56
например только кириллица и латиница больше никакие другие силы то есть соответственно насколько популярности это будет первое латиница и кириллица знаки и другой класс это будет остальные спят симптомы числа и так далее до самого решен кроме кроме латинице кириллице ничего не принимают от куда уж там числа возьмутся нет этот другой класс кириллицы в латиницу портреты ты говоришь ты говоришь вот допустим из из поливода который принимает только кириллицы в латиницу и потом говоришь вот пример как мы будем
00:30:09 - 00:31:26
работать вот у нас есть класс эквивалентности допустим кириллицы ну все правильно до этого момента еще один есть класс эквивалентности то цифры и буквы символы спецсимволы там как не знает самоката . не должна принимаете и любое что мы из него увидем как бы система должна кришна не понял это класса валентности для негативных сценариев хорошо хорошо на самом деле кириллицы и латиницы они тоже не могут быть одним классом к валентности это верно это символы клавиатуры но так как и два разных алфавита это а не отдельные идут
00:30:53 - 00:32:14
не 1 лат не важно правильно хороший ответ нормально зачем нам нужен такой подход зачем нам нужно как колоска валентности вводить какой-то вот набор да там допустим символов на вход в чем смысл что минимизировать количество тестов так как на может быть ограничены во времени вот проверять каждый символ кажется там не зная если по длине то есть ты каждый раз одно и то же у нас будет очень-очень много тестов вот благодаря этому как бы мы делаем выборг внутри этого класса то есть у нас соответственно если реагирует
00:31:48 - 00:33:15
одинаково система то есть у нас тестов намного меньше уже будет а почему будет меня показать яблоки 130 ты все правильно говорит всё правильно говоришь вот но нужно а конкретно в чем здесь экономия временем будет вот мы для себя объявляем что у нас есть входные данные допустим буквенные символы и мы используем технику и к валентного разделения что в итоге вот так вот у нас есть вот реальные поле ввода учесть алфавит таким образом мой здесь вот пример из кейсов назови чтобы понять как они экономит нам
00:32:33 - 00:33:42
время и количество например в поле ввода мы вводим там на кириллице слова предположим любое без разницы какая то не почистить и сбоку на кириллица соответственно у нас система должна быть реагировать это все хорошо залогинились следующие там мы берем если нас пустое значение то есть у нас система говорит то что пустое я тебя не потащу но грубо говоря это вот и это негативный тест как вы плюс еще 1 из 1 символ а не знаем мы написали там ! . , . . и опять системно говорит ну нет неважно даже можем один знак написать
00:33:07 - 00:34:40
там два или три на любой статье малых он не пропустит соответственно как бы у нас сокращается уже тесты намного меньше нежели мы будем буква а буква п буква вы там и так далее по букве на проверяет мы можем бесконечно много сделать тест кейсов а так мы просто ввели тут я понимаю что ты говоришь просто самое главное надо сказать что нам не нужна и из каждого класса к валентности проверять все входные данные то есть допустим 5 символов нам не надо проверять все статьи нам надо срочно проверить один или несколько в
00:33:58 - 00:35:15
зависимости от того сколько у нас минимально на вход из букв нам не нужно проверять все буква алфавита проверить парочку сама хорошо и давать этаналь про анализ границ значения поговорим про что он зачем он нужен олесь граничных значений часто бывает что на границе появляются ошибки поэтому а есть такие как бы такая техника дизайн и если мы возьмем например тот же самая боль и вот а и он принимает от пятен например до 15 символов включительно вот и мы должны проверить у нас система как бы премия там например
00:34:39 - 00:36:04
два символа него если от пяти до десяти то это четыре символа той самой значение говоришь ему давали шанс теория потом нырнем сколько у нас обычно нужно нам проверок в соответствии с техникой коваленко и анализа граничное значение интервал вот у нас есть четыре вот и назови какие это 4 вот например граница минус 1 значение и верхняя граница предназначение хорошо отлично вот и теперь можно привести пример вот у нас есть интервал там от пяти до десяти какие конкретно проверки ты будешь использовать
00:35:24 - 00:37:02
проверки на четыре символа на 5 символов на 10 1 см это будет положите на 411 это будет негативно клерк а если будет интервал от 1 до миллиона сколько у нас будет один миллион миллион один если там 101 правильно правильно то есть сила этого подхода в том что не важно какой длины у нас интервал проверок всегда будет одинаково тут на самом деле есть философское вопрос сколько их должно быть по минимуму где написано 4 где-то написано 5 то есть допустим я читал что-то еще внутри интервала надо взять
00:36:15 - 00:37:33
случайное значение чтобы уж точно там все работало а так хорошо верно супер ладно давай поговорим про тест в документацию то есть план приходилось когда-нибудь писать а примерно 40 я понимаю то что читала что это такой документ где у нас есть точка входа выхода тестирования проекта расе прописана окружении на котором будет проходиться возможно там версия бил как бы вот это вот все нюансы вот ты правильно сказала примерно про точки входа-выхода это критерии начала и окончания тестирования про окружении правильно что мое
00:37:03 - 00:38:42
окружение подбираем а что мы еще ну версии build втс плане может еще не быть но убрали точный на транспортном мир сибил например а что-то мы еще можем там указать [смех] ну вот 5 пальцами есть формально стандарт отраслевые как выписать но есть теория там много чего можно можно и тестирование указать можно указать расписать каком месте допустим спринта как водитель стерни будет применяться то есть там там много ну тогда я рекомендую отдельно почитать потом в конце тогда расскажу какие там критерии начал окончании
00:37:56 - 00:39:24
тестер конкретным бываем да ладно тест кейс checklist что это такое и зачем они нужны что включаю ч клетка это набор проверок то есть без углубление набор проверок или кейс это уже более расширенно такие проверки где уже есть и у нас шаги воспроизведения и ожидаемый результат как выглядит проверка в чеклисте вот сам чек что в нем есть и [музыка] отравление вот у нас любят приборкой у надо у нас есть эскиз ты говоришь то мешок и ожидаем результат но и наверное там есть еще какое-то название чтобы вы
00:38:49 - 00:40:21
идентифицировать a checklist что такое это проверка список чеков проверок чек-лист соответственно катка каждый вот этот чек каждая проверка на содержит себе какие-то поля разные или еще чтобы ехать самому проверку я вкратце и сало как проверку что я проверяю лично моё это без углубления то вот как правило одно название в себе да там типа какая-то хрень работает данная регистрация проходит успешно там вот такими короткими этим без сложных а зачем нам в принципе для одного и того же до для описания сценариев
00:39:37 - 00:41:05
тестирования нужны эти свечи кресты то есть это как бы для одного и того же нужно но имеет разную сложность описания глубину зачем нам такая заморочка почему мы не пользуемся чем-то одним скорее всего вы тоже будет связана со мной разработкой сама то что связано с проектом применяется там где-то нужно будет прямо досконально все проверить то это будет уже соответственно пирс кейсы проводиться если где-то ты работаешь но как бы один тестировщик это понимаю что ты там будешь делать и как бы не очень
00:40:36 - 00:42:04
большой проект то мне кажется есть можно будет обойтись уже самим чек-лист он так от размера проекта зависит да допустим если ты одна допустим и тебе не надо никому расписывать какие-то сложных проверок это как бы самое такс курсе то можно сделать чек листы и правильно если в проекте ты не одна вас несколько то лучше то есть с ней делать-то ему проект достаточно большое и требует но я для себя могу написать так как меня будут понятно на другой человек если возьмет тот же саныча лист он может не
00:41:20 - 00:42:48
понять что я хотела этим сказать никакую я проверку проводила это для понимания для командной работы так скажем правда бусины друг друга понимали все все верно а еще как-то думаешь какие что может повлиять на выбор кроме размера проекта и допустим сложности не знает не приходит был количество времени допустим вот даже если проект очень сложный но у тебя просто нет времени писать тесту документации нужно тестировать но для себя как то хочется закрепите какой-то план тестирование по кому какой то там
00:42:08 - 00:43:25
сьют чтобы хоть где-то делать отметки и сама ты не запуталась что-то уже проходила что не проходила тут ты уже волей-неволей бы использовать чек-лист потому что вы быстрее писака а если время и много если проект такой вот тягуче такое всегда дает могу если спринт и длинные ты-то не каждый 2 недель у вас релиза каждые два месяца там как правило можно и доске и со написать поподробнее и так далее хорошо нормас супер [музыка] багрепорт что такое что все включает bug reports on тебя включает это идеи то
00:42:53 - 00:44:14
есть название что такое название что где и при каких условиях происходит чтобы другой человек который будет это исправлять он понял кому то же самое начало так скажем флешечка похоже ставь кейсов по этого что это окружение написано может быть какие-то предусловия то те же самые шаги воспроизведения но отличается баг репорт а от самого тест кейса это уже тем что есть фактический результат то есть к чему вот эти шаги они приводят что мы видим ее что нас не устраивает вот но и соответственно там уже на это
00:43:33 - 00:44:50
не обязательно может быть приложение видео например производится кабак либо скриншот где там это бак тоже находится ну и сам по себе как бы эта серьезность этого бага что он там может быть критически очень бака может быть но затем незначительный еще очень важно ну не критично да без это может багрепорт ну еще однако вон за самим данный момент кто работает автор потому что автор как правило это тестировщик мы которого он будет возвращаться в случае чего и которым будут вопросы порождаемое поведение тоже надо
00:44:12 - 00:45:27
упомянуть да я понимаю ты сказал такие же поляков эссе но все равно сказал практически все остальное в принципе нормально да верно действительно и по поводу серьезности это опасные слово потому что есть в теории постепенно слова приоритет а есть серьезность и а допустим в жире это поле называется приоритеты серьезности никакой нет а в каком-нибудь microsoft системе для хранения тикетов там есть и серьезности приоритет есть целая философия как эти понятие делить соответственно ты говоришь в спорте есть серьезность
00:44:52 - 00:46:18
только можем или туле цены а может быть безвестности только приоритет приоритетом же нам показывает насколько срочно нужно исправить этот баг не глав тоже он существует то есть насколько он важен этот прийти прострелить этом всегда мне кажется есть это серьезность как бы это уже это другой совершенно это насколько серьезно влияет на функциональность все правильно все верно говоришь что все так просто но сейчас да там в jiri в системе которые используют 90 по центру кейсов нет отдельно поле серьезности поэтому
00:45:39 - 00:47:07
когда ты приоритет выстраиваешь ты сразу все учитываешь и насколько он опасный насколько он мешать но на самом деле в чаще всего если бак и ломает пол системы то обычно он им имеет высокий приоритет вот обычно бывает исключительно случае до но тем ни менее хорошо замечательно так давай поговорим про жизненный цикл багрепорт а что происходит с багрепорт am в системе среднестатистической после того как ты его там завела и я уже обнаружила dacia эмаль назначаю и направляю на разработчиков чтобы он его
00:46:25 - 00:47:55
пофиксил так скажем это действительно у него тоже воспроизводит салон его exe вот отправляет обратно не то есть я уже смотрю во все дела часа перл бак и закрывается вот и реальная такая но не всегда идеально что может быть и не так бывает бывает такое что может быть это не баг это такое как бы поведение эта фича , я проверяю бывает такое что он не воспроизводит собак мне воспроизводится и тут нужно же смотреть тут либо на кассе парила я смотрю действительно ли как бы все правильный я и сделала есть вида тоже мы
00:47:09 - 00:49:02
то скорее всего тут нужно смотреть с разработчиком селе условия у нас одинаковые погружение если версия билда есть у нас разные соответственно мы и не можем понять друг друга мне кажется в крайнем случае если как бы все идеально наверное уже тут нужно будет подойти и спросить совета все правильно правильно докатим лиду если тимлида нет можно тоже мы можем написать вот и сказать что здесь такой варик и он тогда уже человека а не человек который отвечает за весь продукты скажет либо разработчику ну-ка давай-ка напряги
00:48:13 - 00:49:36
постарайся найти бака исправит либо тебе скажет ладно бак не страшный ты считаешь что что он не страшный отложи его куда они закрой но ты как профессионал тестирования не забудешь сделать в комментах там помягче кучу мне сказали его закрытие ли там отложить на самом деле вот он действовал так что будем иметь ввиду хорошо вот мы подумали о том когда у нас все хорошо потом когда у нас бар поначалу разработчик пишет он не воспроизводится в этом решали еще ноты бак типа это фича а какой еще бывает случай как ты думаешь
00:48:57 - 00:50:14
в жизни нацики багрепорт а когда дубликат скорее всего лет вы тоже тут нужно проверить увлекает каким богам а не похуй ну как бы этот баг который изначально как указывать что дубликат он закрыт или открыт и если он закрыт а это значит переоткрывает как при опенинг делает стоять перед с еще раз ты baking проводится вот если он открыт то возможно что целый это изначальный что вернусь сюда в первое что мы узнаем это что действительно был дубликат потому что иногда разработчики верят во мне показалось нечто подобное видел ты
00:49:35 - 00:51:18
пожалуйста глазами 150 открытых багов пересмотри и вот что там найдешь то есть этот вариант не подходит нам по котировкам мы говорим давай пожал ссылочку кей на дубль чтобы мы вот этим всем не занимались если же ссылочка есть ты проверяешь во-первых действительно ли дубликат потому что тоже могло показаться ну допустим там бак по поле логина ты поле пароль и проверяешь а у них разное валида не страница 1 они рядом но все-таки трасс если же ты согласна что действительно там дубликата ты как правильно сказала смотришь на
00:50:28 - 00:51:29
статус вот этого оригинального бага который был то если он еще открыт то да ты свой при ленкова ешь просто информацию добавляешь и закрываешь если же то первоначальный баг уже закрыть как пофиксили его или еще чем-то ты делаешь так как принято у вас проекте либо ты перри открываешь тот оригинальный бак если это возможно это же информацию необходимо добавляешь либо ты у своего меняется статус дубликат на нил просто кидаешь ссылку на старой бабкой и говоришь ну это уже было поэтому давайте чинить и разработчикам будет проще тут
00:50:59 - 00:52:11
уже надо смотреть как команде хорошо супер ладно давай тогда поговорим вот про что ты говорила что тестировала в приложении да и имеешь какой-то опыт в этом можешь ли ты рассказать в принципе особенности работы в приложении и от которых нужно отталкиваться когда мы выбираем разные виды тестирования да то есть но что мы должны обратить внимание именно в приложении в отличие от нативных или гибридных когда мы тестируем я есть когда смотреть приложение веб-приложения тестировал его восстановят for меня были считаю
00:51:35 - 00:53:00
регистрация и авторизация но и начинала как бы есть ли так скажу что разбивала я все для себя по модулям просто понятно а вот если мы в принципе подходим из того как вот в этих налоги работает до веб-сайт какой то ли еще что то вот если прям более как бы картину выше возьмем что мы в принципе проверяем в основном принято степени в приложении кроме и вот функциональность сама ты что она выполняет основные функции а что мы еще можем проверять мы смотрим от чего зависит работа в приложении как а именно ведь тестирование
00:52:24 - 00:53:56
подошел бы quad приложение не подошел бы допустим к достойному приложения понимает что это тестирование что еще новое приложение важно вот кроссбраузерная наверное важно уже нету browse работа тут важно дальше у нас есть еще там такие виды тестирования как тестирования на там прерывание на там албин 2 что есть на низкий интернет то есть надо смотреть на сколько у нас сильно влияет скорость интернета на работоспособность потому что у доступного но ему интернет-компаний правильно что еще может потому
00:53:13 - 00:54:38
вы до дистанционно тестер не нам нужно выбить совершенно верно от операционной системе водород может быть для приложения могут как нагрузочное тестирование объем данного пользователя входят в систему и начинает использовать [музыка] то что у нас есть много видов тестерами производительности в том числе объемное тестирование и туда все правильно сервер отдельно тестируем и тестируем что у нас скорость интернета допустим работу для нас приложений если плохая сеять из нету все эти что он показывает
00:54:09 - 00:55:35
вот тут уже негативное подключается кроссбраузерная проверяем вот но при этом мы учитываем что от железа не должно зависеть от мощности не зависит от операционной системы по сути потому что зависит от браузера до вот соответственно такие вещи надо это бы держать в голове вот и могут спросить про другие виды вот допустим про нативные да и так же ты соответствии с той же классификации для себя ты можешь также ответить какие особенности рования нативных видов приложи что установка уже нужно что от операционной системы
00:55:03 - 00:56:21
зависит от железа вот а допустим курс браузер мне нужно что браузер в нативном не работает и вот хочешь дальше можешь рассказать что еще для нативно но в общем хорошо я понял еще гибридные там тоже особенная слишко как гибридное приложение работает и времени ладно хорошо норма ладно ладно тогда давай поговорим про что поговорим про по методологии разработки и про вот это как ты себя чувствуешь проекте кто то попадаешь вот у нас есть разные методологии есть отжала методологии есть не везде да как раз начинает водопадная
00:55:43 - 00:57:29
модель и так как она там везде рисуночки сверху вниз что каждый этап он постепенно завершается первый второе и так далее так далее это возвращение к предыдущему этапу вида невозможно может быть реально где-то там но очень сложно это делать вот это есть в конце мы получаем готовый продукт по окончании всех этапов вот мы получили каблук вот так это круто мы получили продукт и мы знаем требований еда что у нас всегда я вот они разработали с требования нами анализ аналитика все это сделала и они вот у
00:56:53 - 00:58:23
нас есть уже по ними и разработчики делают когда разработка закончилась тестировщик делает из но уже все знаем что хочется скажешь зачем же мы в итоге туда какой-то аджая вы думали если булочкам начала это более гибкая методология то есть конечно нет такого четкого понятия что нам дали и все требования все больше не будут добавляться нет и по каждому принту могут добавляться требование а вот мы еще хотим вот это она еще хотим вот это и мы запускаем этот как бы гибкая и мы получаем на выходе но при
00:57:38 - 00:59:01
одном спринте этом например одна версия 2 спринт закончился мы добавляем удобно для 2 версии так далее то есть это уже более гибкой и нет такого четкого понятия как что закончился один блок и начинается четко другой и как бы связь с другим нет потушу но спринт закончился чем-нибудь каком формате [музыка] но по сути же вот эти спринт и это те же то есть подряд ведущие какие-то действия который привык к тому что программа увеличивается улучшается просто дамы более глобальными мать или мы измеряем при водопаде и в
00:58:20 - 00:59:58
конце водопада у нас как правило уходит огромный кусок программного кода а когда принтами вот этими движемся мы потихонечку прирост делаем к программе ну в итоге программа также растет просто циклы короче вот описала ты правильно отжарил подход в частности скрам про вот эти спринт и и водопад обратная связь затруднено лучше прорабатывать на каждом этапе все эти вещи там документации лучше пишет мыши них больше времени все остальное всё это верно но зачем же нам и то и другое тогда и в таком случае какой
00:59:14 - 01:00:31
вариант подхода к разработке мы применяем мне кажется это тоже зависит от проекта какой у нас проект есть проект который требует прямо все четко по полочкам модель она очень хорошо подойдет но это скорее всего может быть что нибудь связан там река с мистической не программами вот такие как медицинские а если то же самое магазин он не требует такого чёткого и каждый раз мы хотим вот такой ясно что здесь лучше подойдет уже scran гибкая будет здесь нежели там вы далее через несколько продолжительное время мы выдадим
00:59:52 - 01:01:34
обновление ну да да то есть быстрее на изменение реагирует отзывов вот чем waterfall еще нам важно насколько большая цена ошибки потому что если в интернет-магазине будет bad это не тоже самое что если ракету хорошо верно а есть еще вода или кроме с кран еще камбал слышал когда я как и название слышал да я не совсем все равно поняла различий между ними и из крама со мной от компании нет спринтов то есть это мы идет о планировании любой исходя из каждой задачей в отдельности и нет такого что четких спринтов которым либо что должно
01:00:46 - 01:02:17
быть сделано либо выкинут из блога и так далее то есть принты и могут отодвигаться они не настолько фиксированные и это имеет свои плюсы и минусы но лучше ты почитаешь тогда окей окей в принципе мы очень много всего обсудили практически все что я хотел какой мой фидбэк смотри я не рекомендую выучить какой-нибудь одно определение что это тестирование потому что так пыталась сформулировать его на ходу это не очень хорошо получилось просто выучи возьми какое простое определение самое простое то есть источник св book
01:01:36 - 01:03:04
2004 года там указано что тестирование эта проверка соответствия между ожидаемым фактическим поведением программы осуществляемый на конечно наборе тестов выбранных определенному все и тебе будет проще тебя не придется вот в стрессе там что-то пытаться придумать для себя вот по целям тестирования тоже где-нибудь есть разные классификации цели тестирования но просто мы стал говорили ты сказала что и вот одна из целей то поиск багов а потом как здесь стало сложно вот вот соответственно где нибудь возьмем
01:02:19 - 01:03:33
какой-нибудь список этих целей чтобы кроме поиска блогов было что-то счета предоставление обратной связи о качестве продукта [музыка] самому элемент как я назвала ну надо было не очень четко может быть ты знаешь я просто рекомендую повторить возьмем простую классификацию простую чтобы тебе не пришлось чтобы тебе в 1 час было понятно и все остальным видам тестирования в принципе нормалек про серый ящик можешь почитать можешь что не читать и не все интерьеры знают про сир ящик тоже не все любят про него
01:02:56 - 01:04:15
рассказывать и обсуждать поэтому до цените смолкли грешим повторить да зачем нам нужно я объяснял но все равно чтобы скрепила для себя так это хорошо уровне тестирования были хорошо техники ну norma на принципе просто надо в первую очередь их с теоретической точки зрения а потом уже пример приводить когда пример приводишь сразу кажется что вот и сейчас на примере объясню в итоге у всех такая классика хорошо так госплан почитай есть такой источник 829 стандарт качества а и буква а и и три буквы и английские
01:03:45 - 01:05:10
как на продуктах питания вот вот есть такое 829 он вообще был создан для того чтобы описать как лучше проверять в промышленности но он вполне себе подходит как источник для разработки программ обеспечения и там вот указаны вещи которые должны быть в том плане что тестировать что будет тестировать как люди критерии начала окончании вот это все как раз там расписано вот чек лист эскиз хорошо багрепорт тоже в принципе все было хорошо так это обсудили вот принципы работы приложений очень важный с практической
01:04:33 - 01:06:06
точки вопрос потому что когда ты будешь стучаться на конкретное собеседования очень сейчас программа в вакансии будет указано мы разрабатываем у нас гибридные приложения или у нас нативное приложение или у нас web приложений и когда ты попадешь на собеседовании ты уже будешь примерно понимает что те будут спрашивать исходя из того что у них есть что-то быстро стиль поэтому прочитает про принципы работы в первую очередь в приложении нативных или доступных и гибридных а потом на основании этого подумай какие бы ты виды тестер не
01:05:21 - 01:06:30
применяла каждому виду приложения какие бы не применял музыка вот на контрасте создать понимает уже действительно подход может быть разный нужно будет разный вот так и все остальное в принципе нормас а ну про канбан почитать чудо чему действительно скрама отличается потому что он не сильно отличается они с чем-то совмещены допустим канбан доска вот этому стулу и брови сдан она уже в скрам перешла и в другие места и бывают путаница почитай все в принципе у меня вопросов больше нет у тебя есть какие то вопросы
01:05:56 - 01:07:22
дайте мне надо поработать что [смех] хорошо тогда удачи тебе в повторении узких мест и нахождение работы до таких большая пожалуйста давай пока ну как вам было интересно если да то ставь лайк запусти камин и посоветую видео таким же начинающим тестировщиком хочу поблагодарить алена за участие в подобном формате собеседование и жила ей как можно быстрее получить желаемую работу также напоминаю если вы хотите участвовать в подобном собеседование заполните форму по ссылке внизу в описании или напишите мне в личку до
[музыка] всем привет с вами николай черкасов тестировщик с многолетним опытом и основатель школы черкасов school сегодня у нас очередное собеседование начинающего тестировщика со беседуем алену она имеет определенный опыт в тестировании в проектов но не очень большой и хотела бы попробовать свои силы на junior и если вы хотите поучаствовать в подобном собеседование заполните форму по ссылке внизу в описании или напишите мне в личку как это сделала алена давайте поддержим ее лайком и добрым комментариям под видео итак смотрим
00:00:00 - 00:01:29
собеседование так итак сегодня с нами алена алена расскажи пожалуйста про себя если у тебя какой-то опыт тестирование на кого ты хочешь про сортироваться на какой уровень я хочу при собеседователей окей инженер джон вот я окончила курсы по тестирования то есть хочу проверить свои знания опыта у меня небольшой я пробовала внутри я работала с фронта стиральщика вот заводила баг репорты и все это время то есть примерно с декабря месяца я пытаюсь и для себя от нестерово веб-сайты этой свет магазины
00:00:50 - 00:02:11
тут последние с тестом задания мне попадался сайт любое я тестировал обед магазин за документация знакома писал ли чек-листы и тест кейсы но соответственно когда роботы порты супер это отлично это замечательно мобильные приложения приходилось дотировать когда нет нет этого не дошла хорошо ладно ну тогда начнем с базовых вопросов что такое тестирование тестирование это процесс который бы цель одна из которых является чтобы удостовериться что сама программное обеспечение работает так как должно соответствует ожиданиям заказчика
00:01:33 - 00:03:03
ожидания заказчика каким образом выражаются виде требований то есть он выкладывает то что он хочет принимают опишу это некие требований и яйцеклетка не нужно уже будет реализовать что делать если нету требований но скорее всего нужно как бы поговорить что именно все таки хочет и создать на том что он хочет уже этот человек который собирает это все стонали зиру и создает эти требования человек который собирает как называется менеджер менеджер хорошо а если так получилось что нет выхода на заказчика но так получилось он может
00:02:29 - 00:04:08
быть ответит когда нет на вопросы на твоем может быть не ответит тебе уже надо на основании чего то составляет тестовую документацию что-то еще может сделать откуда взять требования если так подумать то есть завистники наверное того что хочет фирмы логически не знаю там помыслить если там какая-нибудь форма что-то логически хотя бы уже какие-то сделать основное логически основной помыслит ну ты правильно говоришь это называется использовать какую-то формальную логику да то есть есть вещи которые мы априори знаем и нам не нужно
00:03:21 - 00:04:50
чтобы это было прямо четко прописано с требования потому что допустим если мы тестируем интернет-магазин мы примерно подозреваем что во всех интернет-магазинах есть корзина что есть функция оплаты просто может быть каких то нюансов мы можем не знать но тем не менее то есть мы требование можем забирать из похожих сервисов можем сами из головы выдумывать требования ну которые соответствуют общей принятому подходом например к интернет магазин хорошо хорошо ты говоришь что вот одна из целей тестирования это сравнивать ожидаемое
00:04:11 - 00:05:25
поведение с фактическим а еще какие цели тестирования ты знаешь о цели тестирования то есть даже сообщи тоже чтобы готов ли вообще продукт к релизу то есть насколько он готов вот ну я конечно не назвал ты цели это скорее всего как следствие того что ожидаемый и фактически результатах то есть минимизировать баги то есть как можно чтобы меньше было превентивный такой метод по как то есть с одной стороны мы можем находить баги и report всегда а с другой стороны мы как-то можем как ты говоришь превентивно
00:04:47 - 00:06:06
делать так чтобы багов становилось меньше а что это вот задействует такое как магия когда мы заранее что тепло но на самом деле то есть ты когда тестируешь программу ты не только багере портишь но и можешь обратную связь давать для команды разработки и например указывайте на том что вот в системе конкретно какая-то часть этой системы она может быть не очень хорошо разработанным вероятно в ней будут баги потому что как тебе кажется она права то вот и таким именно образом ты можешь помогать разработки
00:05:27 - 00:07:01
заранее обращай внимание на те места где изначально могут быть баги то есть обратная связь а для команда разработки может быть вот и также может быть обратная связь для командой не в техническом плане а в плане того что изначально хотел заказчик то есть помимо конкретных требований мы можем увидеть что заказчик например желал бы ну вот есть у него основная идея продукта ты допустим в процессе разработки видишь что по каким-то причинам в первую очередь разрабатываются части функциональности некоторые важны а которые не важны и ты
00:06:32 - 00:08:05
можешь также дать обратную связь и сказать так ребята у нас вроде багов нет все правильно но вот наша разработку что-то не нато акцентирует внимание вот заказчик хотел чтобы в первую очередь было сделано вот другое и это тоже как бы одним из атрибутов тестирования является хорошо ладно давай поговорим про вида тестирования какие-то знаешь классификации видов ну и стандартные функциональные функциональное ручная автоматизированное тестирование вот там нет это от майкл большом то есть модульное тестирование
00:07:19 - 00:08:45
интеграционное тестирование уже системы это стерн и тестирование при приемочные тестирование сама ну и хорошо много разных называла классификации что здесь у нас и приемочные модуля интеграционная а вот приемочная модульная интеграционная системная это в принципе мы обычно называем в теории уровнями тестирования ну как правило расскажи тогда подробнее о чем эти уровни самыми шорами это unicast и то есть какой то определенный один модуль тестируется вот и больше ничего не затрагивать интеграционное тоже как
00:08:05 - 00:09:33
взаимодействие двух и более модулей между собой уже тестируется вот системное от и до все полости система тестируется на е100 кратко приемочные то есть уже либо вы заказчика либо потенциальных от тех кто будет пользователей они уже тестируют насколько им подобные неудобно все ли в порядке там все ли соответствии требованиями хорошо ты как горошина это сиропе когда думаю что на каких уровнях тестирования больше всего будешь действовать скорее всего либо модульной и интеграционное модули на стоит дни это
00:08:52 - 00:10:11
умение заденет модуля это скорее всего это будет разработчики либо и системная ну и приемочные иногда хорошо что не знаешь про ящики разноцветные шары и белый черный ящик и тогда когда мы не уходим в самой системе конечно не уходим на такая не знаю какой код как у капы пишет этого здания то есть на этом в основном требование заказчика белый ящик это уже как мы уже знаем пока ты все пишется сам код понимаем эту логику и то есть мы сам от постеры абсолютно правильно все верно а слышал когда-нибудь про стеклянный ящик
00:09:33 - 00:11:20
это то же самое что и белый просто некоторых книжках он называется white суть одно и то же но вот если спросит теперь ты знаешь что стеклянная хорошо есть еще хитрый серый ящик которые всем очень сложно объяснять слышал о таком слышал она не совсем понятной границы там вроде как нужно что-то частично знать код на насколько его нужно знать не совсем это правда никому не понятно поэтому можно прочитать 10 статей и там они всегда будут друг от друга отличаться ладно какие-нибудь не функциональный виды
00:10:33 - 00:11:55
тестирования ты можешь назвать которые непосредственно не относится к тестированию основные функции системы домах например graphical user interface насколько он выглядит соответствует макету браузерное тестирование то есть мы и в самом как бы две пинты это приложение мы открываем праздник браузеров как google chrome например mozilla microsoft если мы смотрим что действительно нас все открывается все хорошо работает на разных платформах вот либо например инсталляция то есть но это скорее всего будет уже ближе к мобильном приложении
00:11:17 - 00:12:51
то есть что она действительно приложение на восстанавливается что нас она обновляется все хорошо и что мы его можем ударить вот локализации то есть то что мы например пишет ну как бы для россии да даже внутри мне кажется самой россии у нас есть разные часовые пояса отыскав что отображается время правильно локализация это не совсем правильный часовой пояс скорее в россии у нас принято один формат отображение даты потому что для россии ты стену локализации вряд ли подойдет если только ты не будешь проверять и
00:12:14 - 00:13:34
язык наших республик там тувинские какой-нибудь или пермский диалект как гривне вот а больше если мы говорим про время то именно формат отображения даты и времени вот мы просто например в сша у нас что принято у нас принято 12-часовой сутки и м и п м а в европе допустим ну в частности в континентальной европе в россию нас 24-часовой способ отображения времени вот соответственно при переключении локали формат отображения должен меняться формат даты у нас принято день месяц год а в америке принято месяц день
00:13:03 - 00:14:31
год вот и или даже год день месяце такое часто используется к кроме формат отображения даты и например языка что еще может меняться как ты думаешь если например та же самая магазина одежды это как минимум валюта то есть были до каждой страны и она разная это размерная сетка потому что она тоже разнообразная наверно хорошо достаточно в принципе ладно хорошо слышал ли ты когда-нибудь о таких видах тестирования как smaug цените и регресс услышала смог тестирование то есть и только поверхностно как тестирование
00:13:46 - 00:15:26
билда функциональности вот без углубления что бог как более менее стабильный гоните это примерно то же самое но она уже углубляется что действительно она работает функциональность нас правильно вот что как бы это же вышел бы меня уже стабильный регрессионное тестирование тестирование когда у нас выходит новая фича мы смотрим что все остальное то что было написано да и проверены она у нас стабильно и никуда не не попала что все работает все хорошо как-то интересно правило слова стабильность через все три
00:14:42 - 00:15:55
вида тестирования и в итоге я так и не понял чем они друг от друга отличаются если они все проверяют стабильности и у нас все хорошо и стабильно если смотреть на смог и шарики они проверяют одну притчу о [музыка] чем они отличаются друг от друга тогда сами проверяют одну фичу и дают стабильно смог это поверхностная проверка солите это уже более углубленная проверка программы нет именно функциональности а смог это ну да чем отличается смог оценить и что они смогут быстрее то кейса пишут пишут сюда и проверяется ну буквально
00:15:18 - 00:16:53
как бы поверхность то что все работает все таки всякий то есть работает приложение в целом хорошо а sanity это наверное про конкретную функциональность то есть смог это проверка в шире мы проверяем что все приложение более-менее в принципе работает это нам нужно чтобы сделать вывод о том что мы в принципе можем приступить к тестированию sanity это проверка конкретной функциональности в глубину это может быть как новая функциональность которую только что написали так и какая-нибудь выборная по определенному признаку вот и как раз
00:16:19 - 00:17:30
таки и когда мы проводим sanity мы не делаем вывод о том что в принципе все хорошо мы делаем вывод о том что конкретно функциональность отлично замечательно работает и готова к тому чтобы ее добавлять в общую программу кусочек вот-вот общем а regression орешкина этого же когда добавляют снова функциональной стать мы смотрим что все остальное тоже работает корректно и все остальное что что остальная стальная послал остальные функциональности может ну как бы проверили национальности добавили новую и смотрим
00:16:55 - 00:18:16
что новая функциональность не повлияло на работу уже старой функциональность значит мы прогорим старый функциональности в процессе но чтобы при добавлении новых работу старый оцените но тогда зачем 1 функциональности она из после мой как она взаимодействовать со стальными как только как она я сама а потом по крыше регрессия когда мы проверяем новой функциональности стороны проверяем так вот мы [музыка] но это немножко ошибаешься в общем регрессионное это как раз таки когда мы проверяем старую функциональность
00:17:40 - 00:19:00
который не относится к новый и мы проверяем что старая функциональность работает после того как мы добавили новую а новую мы перед этим проверяем в рамках цените тестирую то есть мы проверили смог что быстренько все более-менее целиком держится потом проверяем самую свежую функциональность а потом проверяем в рамках регрессии все остальное зачем нам в принципе вода вот такой трехуровневый подход ты знаешь отдельного мог соединить иммигрейшн взяли бы все ты с кейсы пихнули бы сразу там тысяч от эскиза до и проходили бы
00:18:39 - 00:20:00
какая разница с макс интере грешник ну это как бы поэтапно 5 сначала мы проводим смог потом сами часто помада регрессионная зачем все поэтапной тело зачем и чтобы но если мы все будем писать мне кажется просто мы можем упустить некоторые баги и ошибки что-то может неправильно работать и потом все это в этом обратно в обратную сторону копаться где что она ходить после зарплате ошибка в оборотной стороны карта c-class ну смотри у нас есть тасс кейсы они уже написано они уже написаны то есть мы ничего не можем
00:19:19 - 00:20:34
пустить у нас есть из кейса мы их по очереди проходим вот у нас допустим есть 1000 тыс кейсов не знаю этом 50 на смолк там 200 на саммите и там 750 это регресс вот у нас есть куча ты skism и зачем-то выделяем цените смог регресс и зачем-то их проходим именно по очереди по какой-то логики вот зачем мы это делаем если например мы в итоге все равно пройдем все проверки был у нас тысяч кис-кис мы бы их называли куча тэсс кейсов на я вот ты садишься и шагающих по одному зачем нам вот эти уровни билет
00:19:59 - 00:21:15
это наверное , связанность разработка и то есть пишется ну как бы постепенно идет разработка вот то есть какой то какой то написали функциональной ставите потом пока протестирует это solaris пишет новых националист проверяем уже и и вот соответственно провели поэтому идет от меньшего большему выдает проверили все хорошо у нас стабильно все работает то есть мы берем уже следующая пока мы следующую смотрим пишут след ну как бы соответственно следующих и но же как бы ног проваливай уже проверили вторую функциональность
00:20:36 - 00:22:06
проводим регрессионное тестирование что встали функциональностью на все в порядке вот и так как бы как ну запах . в процесс разработки ты правильно описала виды тестирования действительно применяются по очереди каждый раз когда у нас приходит к это новая функциональность и но суть зачем мы все-таки делим 3 ты не назвала смотри просто дело в том что мы не всегда получаем стабильный билд в принципе постройках добавим его функциональность иногда после добавления новой функциональности вообще программы
00:21:25 - 00:22:41
не открывается и нам наша задача тестировщика поставлены получаем очередную сборку убедиться в том что build вообще достоин или доступен для тестирования масштабного и поэтому нам нужно выделить отдельные кейсы которые просто по верхам проверю что программу в принципе работает потому что если она в принципе не работает нет никакого смысла проводить или грыж и углубляться в какие сложные кейсы по старым и нужно не работает цените нам нужно чтобы проверить свежую функциональность как правило почему мы
00:22:02 - 00:23:18
проверяем свежую функциональность потому что я только что добавили и в ней статистически максимальное количество багов и ну скорее всего с ней что-то не так потому что я только что добавили и мы проверяем это во вторую очередь после того как вы стены что программа в принципе работает а регрессионным и проверяем в последнюю очередь потому что шансов найти баги в регрессионных тестах намного меньше потому что регрессионной тесты это то что было когда-то цените но в предыдущем цикле разработки и мы
00:22:40 - 00:23:55
когда-то это уже проверили а потом просто сложили в чемодан храним это все и поэтому в некоторых компаниях иногда даже от регрессии отказываются чтобы сэкономить время или говорят но вы проверяете регрессию и только если время останется поэтому именно для того чтобы приоритизировать свою рабочую загрузку мы вот эти вот и придумываем уровне и в голове у все держим где мы сейчас на проекте где сейчас наша последняя фича чтобы понимать как глубоко прямо сегодня мы должны тестировать и вот это очень
00:23:18 - 00:24:32
важно именно вот паз практически точки зрения когда ты будешь работать понимать поэтому это глубоко это обсуждаем это довольно практический вопрос хорошо а есть еще деление из кейсов на позитивные и негативные проверки знаешь в чем разница позитивные проверки это то как мы ожидаем то есть мы не пытаемся сломать систему мы так как пользователь должен как бы вести себя проверяем так скажем так друзья вести себя система имена уже в негативных то есть мы нестандартно и начинаем владеть проверки так
00:23:54 - 00:25:31
в идеале конечно чтобы если мы этом не знаю пишем кейс такой чтобы программа именно сработал они положительно как-бы не про дальше не пропустила скажем вода позитивный настрой направленным то что как система работает при нормальных условиях то есть нормальный как бы там будем все значения в пределах допустимых принятия там полей например негативно это наоборот уже что положено как не должна работать просто не проверяем как система не должна работать это интересно а какой у нас ожидаемое поведение в негативных сценариях тогда
00:24:42 - 00:26:17
что компьютер взрывается или дым идет или кореи если мы смотрим калькулятор [музыка] делить на ноль у нас нельзя это будет негативная проверка то есть а душа воды со ошибка если у нас деление на ноль произошло соответственно это уже дефект то знает как бы негативная проверка оно не зависит как бы все равно положительный результат ожидаемо у нас чтобы задать свой ошибка а уже фактически это же другое а при позитивных то есть это означает по 4 выдает и тут ты правильно назвала пример а не в теории не получилось хорошо писать
00:25:34 - 00:27:02
правильным ответом будет то что мы ожидаем что пользователь который пользуется системы будет либо делать то что подразумевает системы либо то что противоречит логике системы система сама по себе она всегда адекватно должна на это реагировать вот только в случае если позитивный сценарий это какая-то там новых ну какой положительный сценарий там прошла покупку интернет-магазине что-то еще а если пользователь ведет себя так как система не хотел бы чтобы все вел туда ошибка какая-то показывается tooltip как
00:26:19 - 00:27:31
он всплывает или просто не происходит реакции системы всякое бывает а зачем нам такое деление как ты думаешь но мне кажется нужно потому что первую очередь она проводится позитивные проверки чтобы удостовериться что действительно хотя бы функциональная седана правильно все работает система реагирует вот потом уже негативная проводится то есть нахождение багов если у нас все хорошо позитивных и ошибок ничего не выдает только вы приступаем к негативным чтобы уже проверите исключить уже негативной
00:26:54 - 00:28:06
сценария а почему ну давай проверим сначала негативный а потом проверим позитивом и какая разница но это может наверное даже связаны с тем что первоначально нам не надо находить ошибки именно нам не надо ломать систему а хоть обостриться что она соответствует требованиям вот поэтому соответственно требованиям это положительное в основном позитивные позитивные проверки поэтому их проводят в первую очередь ну примерно так на самом деле в требования могут быть указаны негативность сценарий например какая
00:27:30 - 00:28:45
ошибка должна быть показано в случае негативно на самом деле проблема в том что негативных сценариев бесконечное множество их можно придумывать придумывать придумывать придумывать тут пользователь какое-то сочетание клавиш и вел тот он какой-то вирус кинул на вход тут не что-то еще и это вечно вечно вечно и ты будешь и бесконечно этим заниматься и в итоге вместо того чтобы тестировать программу будешь бесконечно придумывать негативный сценарий поэтому в индустрии как правило пишут самые частые возникающие самые базовые
00:28:08 - 00:29:10
негативный сценарий ну например юзер неправильный вел логин или пароль но это классика да то есть и как можно не предусмотреть такой случай и ты эти сценарии разумеется проверишь после того как ты проверишь позитивный сценарий вот но будет какой-то момент всегда в проекте где ты будешь останавливаться придумывать негативный сценарий и дальше двигаться в тестировании вот зачем чтобы бесконечно не генерировать сценарии негативного потому что сколько это их не генерировала все равно надет юзер который придумать то что ты в итоге
00:28:39 - 00:29:48
не предусмотришь и от того не стоит хорошо супер окей техники то с дизайна знаешь какие-нибудь классы эквивалентности граничные значения перехода состояния есть и попарно тестированные на есть попарные не применяла ладно давай с самых простых начнем вот эквивалентное разделения стоит на эквивалентно разделение такие классы внутри которых система реагирует одинаково и на любое значение внутри этого класса так может вылезти пример класса могу например у нас есть поле ввода налоги принимают значение
00:29:13 - 00:30:56
например только кириллица и латиница больше никакие другие силы то есть соответственно насколько популярности это будет первое латиница и кириллица знаки и другой класс это будет остальные спят симптомы числа и так далее до самого решен кроме кроме латинице кириллице ничего не принимают от куда уж там числа возьмутся нет этот другой класс кириллицы в латиницу портреты ты говоришь ты говоришь вот допустим из из поливода который принимает только кириллицы в латиницу и потом говоришь вот пример как мы будем
00:30:09 - 00:31:26
работать вот у нас есть класс эквивалентности допустим кириллицы ну все правильно до этого момента еще один есть класс эквивалентности то цифры и буквы символы спецсимволы там как не знает самоката . не должна принимаете и любое что мы из него увидем как бы система должна кришна не понял это класса валентности для негативных сценариев хорошо хорошо на самом деле кириллицы и латиницы они тоже не могут быть одним классом к валентности это верно это символы клавиатуры но так как и два разных алфавита это а не отдельные идут
00:30:53 - 00:32:14
не 1 лат не важно правильно хороший ответ нормально зачем нам нужен такой подход зачем нам нужно как колоска валентности вводить какой-то вот набор да там допустим символов на вход в чем смысл что минимизировать количество тестов так как на может быть ограничены во времени вот проверять каждый символ кажется там не зная если по длине то есть ты каждый раз одно и то же у нас будет очень-очень много тестов вот благодаря этому как бы мы делаем выборг внутри этого класса то есть у нас соответственно если реагирует
00:31:48 - 00:33:15
одинаково система то есть у нас тестов намного меньше уже будет а почему будет меня показать яблоки 130 ты все правильно говорит всё правильно говоришь вот но нужно а конкретно в чем здесь экономия временем будет вот мы для себя объявляем что у нас есть входные данные допустим буквенные символы и мы используем технику и к валентного разделения что в итоге вот так вот у нас есть вот реальные поле ввода учесть алфавит таким образом мой здесь вот пример из кейсов назови чтобы понять как они экономит нам
00:32:33 - 00:33:42
время и количество например в поле ввода мы вводим там на кириллице слова предположим любое без разницы какая то не почистить и сбоку на кириллица соответственно у нас система должна быть реагировать это все хорошо залогинились следующие там мы берем если нас пустое значение то есть у нас система говорит то что пустое я тебя не потащу но грубо говоря это вот и это негативный тест как вы плюс еще 1 из 1 символ а не знаем мы написали там ! . , . . и опять системно говорит ну нет неважно даже можем один знак написать
00:33:07 - 00:34:40
там два или три на любой статье малых он не пропустит соответственно как бы у нас сокращается уже тесты намного меньше нежели мы будем буква а буква п буква вы там и так далее по букве на проверяет мы можем бесконечно много сделать тест кейсов а так мы просто ввели тут я понимаю что ты говоришь просто самое главное надо сказать что нам не нужна и из каждого класса к валентности проверять все входные данные то есть допустим 5 символов нам не надо проверять все статьи нам надо срочно проверить один или несколько в
00:33:58 - 00:35:15
зависимости от того сколько у нас минимально на вход из букв нам не нужно проверять все буква алфавита проверить парочку сама хорошо и давать этаналь про анализ границ значения поговорим про что он зачем он нужен олесь граничных значений часто бывает что на границе появляются ошибки поэтому а есть такие как бы такая техника дизайн и если мы возьмем например тот же самая боль и вот а и он принимает от пятен например до 15 символов включительно вот и мы должны проверить у нас система как бы премия там например
00:34:39 - 00:36:04
два символа него если от пяти до десяти то это четыре символа той самой значение говоришь ему давали шанс теория потом нырнем сколько у нас обычно нужно нам проверок в соответствии с техникой коваленко и анализа граничное значение интервал вот у нас есть четыре вот и назови какие это 4 вот например граница минус 1 значение и верхняя граница предназначение хорошо отлично вот и теперь можно привести пример вот у нас есть интервал там от пяти до десяти какие конкретно проверки ты будешь использовать
00:35:24 - 00:37:02
проверки на четыре символа на 5 символов на 10 1 см это будет положите на 411 это будет негативно клерк а если будет интервал от 1 до миллиона сколько у нас будет один миллион миллион один если там 101 правильно правильно то есть сила этого подхода в том что не важно какой длины у нас интервал проверок всегда будет одинаково тут на самом деле есть философское вопрос сколько их должно быть по минимуму где написано 4 где-то написано 5 то есть допустим я читал что-то еще внутри интервала надо взять
00:36:15 - 00:37:33
случайное значение чтобы уж точно там все работало а так хорошо верно супер ладно давай поговорим про тест в документацию то есть план приходилось когда-нибудь писать а примерно 40 я понимаю то что читала что это такой документ где у нас есть точка входа выхода тестирования проекта расе прописана окружении на котором будет проходиться возможно там версия бил как бы вот это вот все нюансы вот ты правильно сказала примерно про точки входа-выхода это критерии начала и окончания тестирования про окружении правильно что мое
00:37:03 - 00:38:42
окружение подбираем а что мы еще ну версии build втс плане может еще не быть но убрали точный на транспортном мир сибил например а что-то мы еще можем там указать [смех] ну вот 5 пальцами есть формально стандарт отраслевые как выписать но есть теория там много чего можно можно и тестирование указать можно указать расписать каком месте допустим спринта как водитель стерни будет применяться то есть там там много ну тогда я рекомендую отдельно почитать потом в конце тогда расскажу какие там критерии начал окончании
00:37:56 - 00:39:24
тестер конкретным бываем да ладно тест кейс checklist что это такое и зачем они нужны что включаю ч клетка это набор проверок то есть без углубление набор проверок или кейс это уже более расширенно такие проверки где уже есть и у нас шаги воспроизведения и ожидаемый результат как выглядит проверка в чеклисте вот сам чек что в нем есть и [музыка] отравление вот у нас любят приборкой у надо у нас есть эскиз ты говоришь то мешок и ожидаем результат но и наверное там есть еще какое-то название чтобы вы
00:38:49 - 00:40:21
идентифицировать a checklist что такое это проверка список чеков проверок чек-лист соответственно катка каждый вот этот чек каждая проверка на содержит себе какие-то поля разные или еще чтобы ехать самому проверку я вкратце и сало как проверку что я проверяю лично моё это без углубления то вот как правило одно название в себе да там типа какая-то хрень работает данная регистрация проходит успешно там вот такими короткими этим без сложных а зачем нам в принципе для одного и того же до для описания сценариев
00:39:37 - 00:41:05
тестирования нужны эти свечи кресты то есть это как бы для одного и того же нужно но имеет разную сложность описания глубину зачем нам такая заморочка почему мы не пользуемся чем-то одним скорее всего вы тоже будет связана со мной разработкой сама то что связано с проектом применяется там где-то нужно будет прямо досконально все проверить то это будет уже соответственно пирс кейсы проводиться если где-то ты работаешь но как бы один тестировщик это понимаю что ты там будешь делать и как бы не очень
00:40:36 - 00:42:04
большой проект то мне кажется есть можно будет обойтись уже самим чек-лист он так от размера проекта зависит да допустим если ты одна допустим и тебе не надо никому расписывать какие-то сложных проверок это как бы самое такс курсе то можно сделать чек листы и правильно если в проекте ты не одна вас несколько то лучше то есть с ней делать-то ему проект достаточно большое и требует но я для себя могу написать так как меня будут понятно на другой человек если возьмет тот же саныча лист он может не
00:41:20 - 00:42:48
понять что я хотела этим сказать никакую я проверку проводила это для понимания для командной работы так скажем правда бусины друг друга понимали все все верно а еще как-то думаешь какие что может повлиять на выбор кроме размера проекта и допустим сложности не знает не приходит был количество времени допустим вот даже если проект очень сложный но у тебя просто нет времени писать тесту документации нужно тестировать но для себя как то хочется закрепите какой-то план тестирование по кому какой то там
00:42:08 - 00:43:25
сьют чтобы хоть где-то делать отметки и сама ты не запуталась что-то уже проходила что не проходила тут ты уже волей-неволей бы использовать чек-лист потому что вы быстрее писака а если время и много если проект такой вот тягуче такое всегда дает могу если спринт и длинные ты-то не каждый 2 недель у вас релиза каждые два месяца там как правило можно и доске и со написать поподробнее и так далее хорошо нормас супер [музыка] багрепорт что такое что все включает bug reports on тебя включает это идеи то
00:42:53 - 00:44:14
есть название что такое название что где и при каких условиях происходит чтобы другой человек который будет это исправлять он понял кому то же самое начало так скажем флешечка похоже ставь кейсов по этого что это окружение написано может быть какие-то предусловия то те же самые шаги воспроизведения но отличается баг репорт а от самого тест кейса это уже тем что есть фактический результат то есть к чему вот эти шаги они приводят что мы видим ее что нас не устраивает вот но и соответственно там уже на это
00:43:33 - 00:44:50
не обязательно может быть приложение видео например производится кабак либо скриншот где там это бак тоже находится ну и сам по себе как бы эта серьезность этого бага что он там может быть критически очень бака может быть но затем незначительный еще очень важно ну не критично да без это может багрепорт ну еще однако вон за самим данный момент кто работает автор потому что автор как правило это тестировщик мы которого он будет возвращаться в случае чего и которым будут вопросы порождаемое поведение тоже надо
00:44:12 - 00:45:27
упомянуть да я понимаю ты сказал такие же поляков эссе но все равно сказал практически все остальное в принципе нормально да верно действительно и по поводу серьезности это опасные слово потому что есть в теории постепенно слова приоритет а есть серьезность и а допустим в жире это поле называется приоритеты серьезности никакой нет а в каком-нибудь microsoft системе для хранения тикетов там есть и серьезности приоритет есть целая философия как эти понятие делить соответственно ты говоришь в спорте есть серьезность
00:44:52 - 00:46:18
только можем или туле цены а может быть безвестности только приоритет приоритетом же нам показывает насколько срочно нужно исправить этот баг не глав тоже он существует то есть насколько он важен этот прийти прострелить этом всегда мне кажется есть это серьезность как бы это уже это другой совершенно это насколько серьезно влияет на функциональность все правильно все верно говоришь что все так просто но сейчас да там в jiri в системе которые используют 90 по центру кейсов нет отдельно поле серьезности поэтому
00:45:39 - 00:47:07
когда ты приоритет выстраиваешь ты сразу все учитываешь и насколько он опасный насколько он мешать но на самом деле в чаще всего если бак и ломает пол системы то обычно он им имеет высокий приоритет вот обычно бывает исключительно случае до но тем ни менее хорошо замечательно так давай поговорим про жизненный цикл багрепорт а что происходит с багрепорт am в системе среднестатистической после того как ты его там завела и я уже обнаружила dacia эмаль назначаю и направляю на разработчиков чтобы он его
00:46:25 - 00:47:55
пофиксил так скажем это действительно у него тоже воспроизводит салон его exe вот отправляет обратно не то есть я уже смотрю во все дела часа перл бак и закрывается вот и реальная такая но не всегда идеально что может быть и не так бывает бывает такое что может быть это не баг это такое как бы поведение эта фича , я проверяю бывает такое что он не воспроизводит собак мне воспроизводится и тут нужно же смотреть тут либо на кассе парила я смотрю действительно ли как бы все правильный я и сделала есть вида тоже мы
00:47:09 - 00:49:02
то скорее всего тут нужно смотреть с разработчиком селе условия у нас одинаковые погружение если версия билда есть у нас разные соответственно мы и не можем понять друг друга мне кажется в крайнем случае если как бы все идеально наверное уже тут нужно будет подойти и спросить совета все правильно правильно докатим лиду если тимлида нет можно тоже мы можем написать вот и сказать что здесь такой варик и он тогда уже человека а не человек который отвечает за весь продукты скажет либо разработчику ну-ка давай-ка напряги
00:48:13 - 00:49:36
постарайся найти бака исправит либо тебе скажет ладно бак не страшный ты считаешь что что он не страшный отложи его куда они закрой но ты как профессионал тестирования не забудешь сделать в комментах там помягче кучу мне сказали его закрытие ли там отложить на самом деле вот он действовал так что будем иметь ввиду хорошо вот мы подумали о том когда у нас все хорошо потом когда у нас бар поначалу разработчик пишет он не воспроизводится в этом решали еще ноты бак типа это фича а какой еще бывает случай как ты думаешь
00:48:57 - 00:50:14
в жизни нацики багрепорт а когда дубликат скорее всего лет вы тоже тут нужно проверить увлекает каким богам а не похуй ну как бы этот баг который изначально как указывать что дубликат он закрыт или открыт и если он закрыт а это значит переоткрывает как при опенинг делает стоять перед с еще раз ты baking проводится вот если он открыт то возможно что целый это изначальный что вернусь сюда в первое что мы узнаем это что действительно был дубликат потому что иногда разработчики верят во мне показалось нечто подобное видел ты
00:49:35 - 00:51:18
пожалуйста глазами 150 открытых багов пересмотри и вот что там найдешь то есть этот вариант не подходит нам по котировкам мы говорим давай пожал ссылочку кей на дубль чтобы мы вот этим всем не занимались если же ссылочка есть ты проверяешь во-первых действительно ли дубликат потому что тоже могло показаться ну допустим там бак по поле логина ты поле пароль и проверяешь а у них разное валида не страница 1 они рядом но все-таки трасс если же ты согласна что действительно там дубликата ты как правильно сказала смотришь на
00:50:28 - 00:51:29
статус вот этого оригинального бага который был то если он еще открыт то да ты свой при ленкова ешь просто информацию добавляешь и закрываешь если же то первоначальный баг уже закрыть как пофиксили его или еще чем-то ты делаешь так как принято у вас проекте либо ты перри открываешь тот оригинальный бак если это возможно это же информацию необходимо добавляешь либо ты у своего меняется статус дубликат на нил просто кидаешь ссылку на старой бабкой и говоришь ну это уже было поэтому давайте чинить и разработчикам будет проще тут
00:50:59 - 00:52:11
уже надо смотреть как команде хорошо супер ладно давай тогда поговорим вот про что ты говорила что тестировала в приложении да и имеешь какой-то опыт в этом можешь ли ты рассказать в принципе особенности работы в приложении и от которых нужно отталкиваться когда мы выбираем разные виды тестирования да то есть но что мы должны обратить внимание именно в приложении в отличие от нативных или гибридных когда мы тестируем я есть когда смотреть приложение веб-приложения тестировал его восстановят for меня были считаю
00:51:35 - 00:53:00
регистрация и авторизация но и начинала как бы есть ли так скажу что разбивала я все для себя по модулям просто понятно а вот если мы в принципе подходим из того как вот в этих налоги работает до веб-сайт какой то ли еще что то вот если прям более как бы картину выше возьмем что мы в принципе проверяем в основном принято степени в приложении кроме и вот функциональность сама ты что она выполняет основные функции а что мы еще можем проверять мы смотрим от чего зависит работа в приложении как а именно ведь тестирование
00:52:24 - 00:53:56
подошел бы quad приложение не подошел бы допустим к достойному приложения понимает что это тестирование что еще новое приложение важно вот кроссбраузерная наверное важно уже нету browse работа тут важно дальше у нас есть еще там такие виды тестирования как тестирования на там прерывание на там албин 2 что есть на низкий интернет то есть надо смотреть на сколько у нас сильно влияет скорость интернета на работоспособность потому что у доступного но ему интернет-компаний правильно что еще может потому
00:53:13 - 00:54:38
вы до дистанционно тестер не нам нужно выбить совершенно верно от операционной системе водород может быть для приложения могут как нагрузочное тестирование объем данного пользователя входят в систему и начинает использовать [музыка] то что у нас есть много видов тестерами производительности в том числе объемное тестирование и туда все правильно сервер отдельно тестируем и тестируем что у нас скорость интернета допустим работу для нас приложений если плохая сеять из нету все эти что он показывает
00:54:09 - 00:55:35
вот тут уже негативное подключается кроссбраузерная проверяем вот но при этом мы учитываем что от железа не должно зависеть от мощности не зависит от операционной системы по сути потому что зависит от браузера до вот соответственно такие вещи надо это бы держать в голове вот и могут спросить про другие виды вот допустим про нативные да и так же ты соответствии с той же классификации для себя ты можешь также ответить какие особенности рования нативных видов приложи что установка уже нужно что от операционной системы
00:55:03 - 00:56:21
зависит от железа вот а допустим курс браузер мне нужно что браузер в нативном не работает и вот хочешь дальше можешь рассказать что еще для нативно но в общем хорошо я понял еще гибридные там тоже особенная слишко как гибридное приложение работает и времени ладно хорошо норма ладно ладно тогда давай поговорим про что поговорим про по методологии разработки и про вот это как ты себя чувствуешь проекте кто то попадаешь вот у нас есть разные методологии есть отжала методологии есть не везде да как раз начинает водопадная
00:55:43 - 00:57:29
модель и так как она там везде рисуночки сверху вниз что каждый этап он постепенно завершается первый второе и так далее так далее это возвращение к предыдущему этапу вида невозможно может быть реально где-то там но очень сложно это делать вот это есть в конце мы получаем готовый продукт по окончании всех этапов вот мы получили каблук вот так это круто мы получили продукт и мы знаем требований еда что у нас всегда я вот они разработали с требования нами анализ аналитика все это сделала и они вот у
00:56:53 - 00:58:23
нас есть уже по ними и разработчики делают когда разработка закончилась тестировщик делает из но уже все знаем что хочется скажешь зачем же мы в итоге туда какой-то аджая вы думали если булочкам начала это более гибкая методология то есть конечно нет такого четкого понятия что нам дали и все требования все больше не будут добавляться нет и по каждому принту могут добавляться требование а вот мы еще хотим вот это она еще хотим вот это и мы запускаем этот как бы гибкая и мы получаем на выходе но при
00:57:38 - 00:59:01
одном спринте этом например одна версия 2 спринт закончился мы добавляем удобно для 2 версии так далее то есть это уже более гибкой и нет такого четкого понятия как что закончился один блок и начинается четко другой и как бы связь с другим нет потушу но спринт закончился чем-нибудь каком формате [музыка] но по сути же вот эти спринт и это те же то есть подряд ведущие какие-то действия который привык к тому что программа увеличивается улучшается просто дамы более глобальными мать или мы измеряем при водопаде и в
00:58:20 - 00:59:58
конце водопада у нас как правило уходит огромный кусок программного кода а когда принтами вот этими движемся мы потихонечку прирост делаем к программе ну в итоге программа также растет просто циклы короче вот описала ты правильно отжарил подход в частности скрам про вот эти спринт и и водопад обратная связь затруднено лучше прорабатывать на каждом этапе все эти вещи там документации лучше пишет мыши них больше времени все остальное всё это верно но зачем же нам и то и другое тогда и в таком случае какой
00:59:14 - 01:00:31
вариант подхода к разработке мы применяем мне кажется это тоже зависит от проекта какой у нас проект есть проект который требует прямо все четко по полочкам модель она очень хорошо подойдет но это скорее всего может быть что нибудь связан там река с мистической не программами вот такие как медицинские а если то же самое магазин он не требует такого чёткого и каждый раз мы хотим вот такой ясно что здесь лучше подойдет уже scran гибкая будет здесь нежели там вы далее через несколько продолжительное время мы выдадим
00:59:52 - 01:01:34
обновление ну да да то есть быстрее на изменение реагирует отзывов вот чем waterfall еще нам важно насколько большая цена ошибки потому что если в интернет-магазине будет bad это не тоже самое что если ракету хорошо верно а есть еще вода или кроме с кран еще камбал слышал когда я как и название слышал да я не совсем все равно поняла различий между ними и из крама со мной от компании нет спринтов то есть это мы идет о планировании любой исходя из каждой задачей в отдельности и нет такого что четких спринтов которым либо что должно
01:00:46 - 01:02:17
быть сделано либо выкинут из блога и так далее то есть принты и могут отодвигаться они не настолько фиксированные и это имеет свои плюсы и минусы но лучше ты почитаешь тогда окей окей в принципе мы очень много всего обсудили практически все что я хотел какой мой фидбэк смотри я не рекомендую выучить какой-нибудь одно определение что это тестирование потому что так пыталась сформулировать его на ходу это не очень хорошо получилось просто выучи возьми какое простое определение самое простое то есть источник св book
01:01:36 - 01:03:04
2004 года там указано что тестирование эта проверка соответствия между ожидаемым фактическим поведением программы осуществляемый на конечно наборе тестов выбранных определенному все и тебе будет проще тебя не придется вот в стрессе там что-то пытаться придумать для себя вот по целям тестирования тоже где-нибудь есть разные классификации цели тестирования но просто мы стал говорили ты сказала что и вот одна из целей то поиск багов а потом как здесь стало сложно вот вот соответственно где нибудь возьмем
01:02:19 - 01:03:33
какой-нибудь список этих целей чтобы кроме поиска блогов было что-то счета предоставление обратной связи о качестве продукта [музыка] самому элемент как я назвала ну надо было не очень четко может быть ты знаешь я просто рекомендую повторить возьмем простую классификацию простую чтобы тебе не пришлось чтобы тебе в 1 час было понятно и все остальным видам тестирования в принципе нормалек про серый ящик можешь почитать можешь что не читать и не все интерьеры знают про сир ящик тоже не все любят про него
01:02:56 - 01:04:15
рассказывать и обсуждать поэтому до цените смолкли грешим повторить да зачем нам нужно я объяснял но все равно чтобы скрепила для себя так это хорошо уровне тестирования были хорошо техники ну norma на принципе просто надо в первую очередь их с теоретической точки зрения а потом уже пример приводить когда пример приводишь сразу кажется что вот и сейчас на примере объясню в итоге у всех такая классика хорошо так госплан почитай есть такой источник 829 стандарт качества а и буква а и и три буквы и английские
01:03:45 - 01:05:10
как на продуктах питания вот вот есть такое 829 он вообще был создан для того чтобы описать как лучше проверять в промышленности но он вполне себе подходит как источник для разработки программ обеспечения и там вот указаны вещи которые должны быть в том плане что тестировать что будет тестировать как люди критерии начала окончании вот это все как раз там расписано вот чек лист эскиз хорошо багрепорт тоже в принципе все было хорошо так это обсудили вот принципы работы приложений очень важный с практической
01:04:33 - 01:06:06
точки вопрос потому что когда ты будешь стучаться на конкретное собеседования очень сейчас программа в вакансии будет указано мы разрабатываем у нас гибридные приложения или у нас нативное приложение или у нас web приложений и когда ты попадешь на собеседовании ты уже будешь примерно понимает что те будут спрашивать исходя из того что у них есть что-то быстро стиль поэтому прочитает про принципы работы в первую очередь в приложении нативных или доступных и гибридных а потом на основании этого подумай какие бы ты виды тестер не
01:05:21 - 01:06:30
применяла каждому виду приложения какие бы не применял музыка вот на контрасте создать понимает уже действительно подход может быть разный нужно будет разный вот так и все остальное в принципе нормас а ну про канбан почитать чудо чему действительно скрама отличается потому что он не сильно отличается они с чем-то совмещены допустим канбан доска вот этому стулу и брови сдан она уже в скрам перешла и в другие места и бывают путаница почитай все в принципе у меня вопросов больше нет у тебя есть какие то вопросы
01:05:56 - 01:07:22
дайте мне надо поработать что [смех] хорошо тогда удачи тебе в повторении узких мест и нахождение работы до таких большая пожалуйста давай пока ну как вам было интересно если да то ставь лайк запусти камин и посоветую видео таким же начинающим тестировщиком хочу поблагодарить алена за участие в подобном формате собеседование и жила ей как можно быстрее получить желаемую работу также напоминаю если вы хотите участвовать в подобном собеседование заполните форму по ссылке внизу в описании или напишите мне в личку до
01:06:39 - 01:08:18
нового видео пока [музыка]
01:07:32 - 01:07:50