Подготовка к собеседованию на QA Engineer
Менторы
Специалисты своей области, которые смогут помочь вам
Middle .Net Developer
Senior Product Manager
Middle Python Developer
Ведущий программист
Backend Software Engineer (PHP)
Senior .NET/C# developer
Middle DevOps Engineer | Tbilisi, Georgia
Middle C# .NET
Senior PHP-разработчик
Middle python developer
Каналы
Полезные Telegram каналы и чаты
Транскрипция видео:
[музыка] Всем привет Сегодня у нас новая собеседение на Junior K и с нами Сергей за кадром он сказал мне что проходил какое-то обучение на qa Но уже несколько месяцев делают упор на тестирование поэтому познание может немножко хромать тем не менее я думаю что будет интересно поэтому смотрим Привет Сергей Расскажи пожалуйста немножко о себе Какой у тебя там опыт какие у тебя пожелания что ты хочешь для себя знать И вообще войти нету совсем То есть я до этого было связано со всем с другой сферой что хотел бы узнать А ну закончил Я
00:00:01 - 00:01:30
курсы И вообще тестирование просто для того чтобы не забывать Может какие-то свои слабые стороны выделить для себя Потому что ну то есть заявок отправляется номер каких-то откликов но все они никаких не было и все равно как бы она забывает хотелось бы как бы немножко Хорошо именно такой опыт мы сегодня получим Окей давай тогда начнем от простых вопросов и пойдем дальше Расскажи пожалуйста что такое тестирование если простым языком то тестирование Это проверка соответствия между фактическим результатом и ожидаемым то
00:00:55 - 00:02:24
есть когда так хорошо А ожидаемый результат мы откуда берём у нас же есть какая-то документации какая-то спецификация пожелания заказчика клиента то чтобы он хочет чтобы это работало так чтобы это выглядело так Это и будет ожидаемым результат и вот наша цель тестирования вообще заключается в том чтобы установить соответствует ли фактически результат ожидаемо то есть то что хотел получить от этого проекта или еще как-то заказчик скажем так а что делать если ты приходишь на проект тебе говорят документация у нас нету Ты говоришь А
00:01:50 - 00:03:09
что заказчик А тебе говорят А мы с ним мало общаемся занятой человек Слушай ну немножко тяжеловато рассказать но все равно есть какие-то хоть какая-то документация минимальная она все равно должна быть не там тоже специфика Нет спецификации вообще нет Есть отрывок салфетки из Барак заключали договор и он там написал сделайте мне кайфовый сайт чтобы он продавал офигенно все вы профессионалы все на вас заказчик посчитал что мы знаем технически я продаю футболки вот делаю продаю футболки я не шарю в сайтах Ни в чем вы профессионал
00:02:31 - 00:03:53
мне вас посоветовали сделайте хорошо чтобы Слушай ну можно не знаю поискать какие-нибудь источники требований Ну например там тот же Интернет коллеги я не знаю здравый смысл никто не отменял конкуренты в конце концов Ну и вот Ну много всяких моментов мы можем там не обязательно конкуренты Ну просто схожие по функциональности посмотреть да то есть мы делаем если интернет-магазин мы можем ориентироваться на то как другие интернет-магазины работают Вот и здравый смысл то есть мы как пользователь сами
00:03:12 - 00:04:29
интернет-магазинов и в принципе да технологии мы примерно понимаем как сейчас должны работать приложения и например в требованиях может быть не написано что веб-сайт не должен падать на каждой странице Да но мы это понимаем сами по себе если он падает значит очевидно что это не так нарушение ожидаемого поведения что сайт падает постоянно или там приложение нативные или еще что-то вот поэтому источников требования у нас на самом деле много и если ты устроишься в стартап в небольшие команды это очень частая история что
00:03:51 - 00:04:57
нету никаких требований вот или они очень расплывчатые и нет возможности их формально определить у заказчика приходится что-то додумывать выдумывать иногда это требует какого-то подтверждения от заказчика иногда ничего не требует заказчик говорит так я вам дал все что я хотел через три месяца жду результат всего хорошего И вот в этой ситуации приходится иногда додумывать и придумывать Хорошо ты упомянул что там целью тестирования является проверка Да там ожидаемого поведения Какие еще цели тестирования мог бы выделить
00:04:23 - 00:05:39
Ну вообще принципе то что я сказал это наверное что в принципе тестирование в том чтобы тестировщик сказал готов ли продукт к работе либо не готов а еще какими цели знаешь ой может и знаю Ну пока не могу так вспомнить Лучше там всех где-нибудь пометь по возможности Есть много разных вот этих классификаций целей обычно выделяет 3-4 штуки разные авторы они по-разному расписаны Но это вопрос спрашивают на собеседованиях на реальных и просто выучи какие-нибудь там три цели например есть классификация
00:05:04 - 00:06:34
validation verification R detaction вот сказал что английский учишь Вот как раз попробуешь например статью прочитать про такие три цели Вот то есть это первое мы при верификации мы проверяем Выполняется ли цели сроки задачи в разработке то есть мы как тестировщик улучшаем не только конечные качества продукта но мы еще стараемся улучшить процесс разработки то есть мы там подсвечиваем проблемы в разработке если допустим что-то происходит не то например там не совсем те фичи должны реализуются то есть много
00:05:54 - 00:07:11
валидешены это уже проверка соответствует ли программное обеспечение ожиданием заказчика или пользователем непосредственно выявление ошибок Ну это одна из вариантов как можно выделить или тестирование Поэтому можешь подобрать этот вариант можешь подобрать какой-то другой который проще заполнить не критично хорошо провалидацию от это я как бы знал я почему-то не сообразил что это можно отнести Ну то есть целям тестирования если как определение я это знал мы это учили и как-то так ну просто не подумал
00:06:34 - 00:07:45
что можно здесь ничего страшного Хорошо виды тестирования какие-нибудь можешь назвать Да могу назвать конечно сам-то деле их много но наверное Я рекомендую всем на реальных собеседованиях начинать самих классификаций а каждый классификации может быть несколько видов и так будет проще это будет по степени автоматизации это ручные автоматические и полуавтоматическое тестирование следующий это по объектам тестирования это у нас будет функциона на тестирование и не функциональное тестирование потом Следующие виды тестирования
00:07:10 - 00:08:33
связанные с изменениями это у нас будет Smoke Test sanity тестирование биотест и и тестирование системы или entum по-моему еще называют системное есть такое системная система еще могу вспомнить уровни тестирования это у нас модульное тестирование интеграционные тестирование приёмочная тестирование и наверное тут будет все системно просто пересекается системные приёмочная метод черного белого серого ящика Так удаленности это у нас Альфа это тестирование [смех] или может я что-то путаю Я просто может быть тоже сам забыл есть
00:07:58 - 00:09:51
альфы тестирование многое источника на самом-то деле вот ну где читал там и все они почему-то у всех по-разному то есть плюс-минус Одинаково не у кого нет И вот читаешь и начинаешь путаться То есть это то что я просто запомнил Хорошо хорошо Нет это не проблема Не страшно тут главное сами какие-то тестирования помнить классификация говорил просто потому что иногда проще сориентироваться Потому что если сразу конкретные виды называть очень часто их действительно много и ты начинаешь как бы теряться
00:09:16 - 00:10:18
Отлично На самом деле очень хорошо ответил очень много всего назвал давай про конкретные виды поговорим например про тестирование локализацию что это за тестирование локализации вообще есть условно тестирование локализации и тестирование интернационализации тестирование локализации это скажем так подгонка продукта под какие-то определенные условия то есть что под этим понимаю словно у нас какой-то интернет магазин был разработан под Российский рынок к примеру нам этот интернет магазин надо локализовать под примеру рынок Америки
00:09:51 - 00:11:13
Давайте рынок Америки возьмем и суть вообще тестирования локализации заключается в том чтобы проверить соответствует ли там какие-то например время же у нас у нас в России Беларуси будут разные не такое как в Америке размеры какие-то у нас сантиметры у них я понял да у них дюймовая система смотри тут лучше говорить не что время разное что формат формат времени потому что в каждой стране тоже Америке есть несколько часовых поясов у них даже в рамках одной страны время разное А вот как мы время отображаем что у нас
00:10:33 - 00:11:48
допустим 24 часовой формат у них 12 вот дата день месяц год они месяц день год вот такие вот вещи а та же ну та же валюта условно у нас рубли у них доллары чтобы как бы это все отображалось даже могут быть я где-то считал что если под какие-то страны даже надо соблюдать и учитывать как-то религиозные особенности это может даже там цвета еще что-то такое потому что где-то условно красный разрешен где-то красный запрещен то есть вот все эти моменты они должны быть проверены и соблюдены чтобы не соответствовали
00:11:22 - 00:12:40
стране которую локализуется продукт самое главное забыл упомянуть язык соответственно Да хорошо это по локализации и так что еще интернационализация Но интернационализация это вообще как бы это не то чтобы вот как локализация подгонка интернетается это вообще уже то есть условно вот как у нас сайты они там допустим пишутся слева направо примеру буквы а есть же там какие-то я не знаю арабские там еще какие-то сайты где могут быть там буквы сверху вниз написано то есть но под такие страны нету смысла делать локализацию так как
00:12:02 - 00:13:29
это уже полностью Ну тут Проще наверное сделать как бы новый сайт Сергей интересная мысль Я никогда не слышал про интернационализацию но как человек который тестировал локализацию арабского текста что арабский пишется справа налево и это технически Ничем не отличается то есть буквально на сайте переключаешь страну и у тебя писаться начиная с другой стороны это вообще никак не влияет вот вероятно есть какие-то более удачные примеры Вот но что касается стороны написания текста или даже сверху вниз если возьмем китайский иероглифы
00:12:50 - 00:14:14
ничего там на самом деле не меняется особо просто верстка может поехать да там Но это уже совсем другая история например слишком большой объем текста будет там где Мы не ожидали и может быть при тестировании ты увидишь что там текст наложился на другой текст или еще что-то коряво начал выглядеть вот так что прям там было что-то прям невероятно другое Лично я не встречал Ну ладно может быть мне тоже стоит прочитать протестирование интернационализации хорошо про тестирование инсталляции инсталляционное тестирование Но это по
00:13:32 - 00:14:47
моему если я не ошибаюсь это просто тестирование того вообще устанавливается это тестирование установки обновления удаления словно приложение то есть проверка его на то что она вообще устанавливается обновляется либо удаляется и как она это делает хорошо не хорошо проблема без проблем все правильно это на самом деле довольно часто как правило правильно называть эти приложения нативными потому что в оригинальной литературе в приложении которое открывается на мобильном устройстве они тоже называются мобильными приложениями
00:14:13 - 00:15:24
Поэтому лучше всего говорить нативные Да и гибридные еще есть приложение у которых частично есть нативная часть частично они тоже подходят хорошо Про кроссбраузерная кроссплатформенная что можно сказать так если я не ошибаюсь тестирование условно того как приложение работает на разных правах на разных браузерах то есть мы снова тоже У нас есть разные браузера гром хром Google еще что-то но это просто тестирование там приложение на всех этих браузерах словно заказчик хочет сказал вот чтобы мне надо чтобы
00:14:52 - 00:16:14
приложение работало на том-то том-то Ну соответственно мы должны протестировать чтобы это приложение адекватно Понятно работала на всех этих браузерах и может даже на каких-то определенных версиях то есть ни на одной версии на несколько версиях и так далее А если заказчик не говорит на каких браузерах он хочет Говорит сделайте так чтобы работало как можно больше где тогда что нам делать Ну тут наверное тоже надо опять же тут зависимости от того есть же там чем больше какими браузерами пользуются да и
00:15:33 - 00:16:41
все равно надо проверить чтобы она работала на том-то и на том-то и на том то есть по возможности максимально больше а вот у нас маленькая вот у нас стартап тот самый мужичок который нам сказал через три месяца чтобы все было огонь и ты понимаешь у тебя очень активно происходит работа И когда ты кросс-браузерное тестирование проводишь тебе по сути надо одни и те же тестовые сценарии проводить но на каждом браузере отдельно и получается буквально с каждым новым браузером у тебя удваивается работа Ну потому что надо провести все
00:16:11 - 00:17:10
те же самые тесты на новом браузере на новом и на новом и тебе бы по-хорошему что-то надо сделать чтобы наверное упростить свою работу да ты в принципе про это немножко затронул что есть определенный способ как-то это задача упростить Ну может взять опять же статистику тех браузеров которыми пользуются больше всего и не проверять но опять же если ему надо быстро и опять же не проверять там несколько версий взять допустим там три браузера и проверить третье браузера по одной версии чтобы Мы понимали
00:16:40 - 00:17:48
стабильно но работает не стабильно все-таки есть вероятность что если на этой версии оно работает адекватно возможно и на предыдущий вот тоже нормально работать Да все правильно да то есть мы просто должны посмотреть статистику Какие сейчас браузеры популярны часто еще бывает так что Клиенты приходят они допустим последний раз они уже заказывали разработку Ну допустим лет 10 назад и тогда были совсем другие браузеры популярны они говорят А мы хотим чтобы на интернет эксплореже хорошо работала А ты говоришь
00:17:15 - 00:18:17
А вот вы знаете что интернет Explorer уже не поддерживается И вообще новых версий давно не выходит давайте мы может быть пересмотрим ваш список То есть тут мы не просто слушаем заказчика мы можем свою какую-то предлагать и действительно сокращаем количество браузеров Чтобы успеть самим хоть что-то протестировать Хорошо давай поговорим про ящики разноцветные так ящики То есть у нас Black Box whitebox и greybox иногда где-то я еще по моему Куликова встречал глаз бокс как стеклянный ящик такое есть определение
00:17:46 - 00:18:54
то же самое что Да тут Наверное часть того что нет Это относится к методам тестирования и методы тестирования нам дают Понять насколько глубоко мы можем погрузиться в техническую составляющую продукта То есть если мы берем черный ящик условно представление о продукте у нас такое же как и представление У пользователя То есть у нас по сути нету доступа никуда никуда Ну кода у нас доступа нету максимум куда у нас наверное есть доступ это верстки то есть максимум белый ящик это уже скажем так когда у
00:18:20 - 00:19:44
нас полный доступ ко всему включая там тоже документацию и тот же код то есть как-то Так а Серый это что-то такое среднее никому не понятно и постоянно на эту тему и в интернете какие-то дискуссии какие-то разногласил ты тестировал сайт Да тебе разработчик такой в Скайпе кидает в другом способе общения пароль и логин к нашему гитхабу и у тебя появляется доступ к коду у тебя тут же автоматически тестирование в белый ящик превращается или как немножко не понял но ты говоришь белый черный ящик отличается
00:19:03 - 00:20:38
доступностью кода кода Вот тебе разработчик говорит Вот тебе данные Заходи на github У тебя есть доступ коду после этого что хочешь с ним делать У тебя после этого автоматически твое тестирование из чёрного ящика в белой превращается или как Нет но я к тому же Ну вот если же тестирование допустим кода его же вообще проводят получается сами разработчики по моему не тестирует И даже тестировщики по моему пишут на код Unit тесты разработчики а тестировщик он больше наверное связан Вот именно черным и
00:19:58 - 00:21:16
Серым ящиком просто тут ну как лучше отвечать да первое есть не доступ коду есть А есть понимание того как работает код то есть Дело в том что при белом ящике ты можешь код читать и ты можешь понимать как он работает и второе самое главное что выделяет эти все ящики это что покрывается тестами при белом ящике покрывается тестами код при черным ящиками тестами а Unit тесты которые прибил ящике до тесты они не учитывают бизнес-требования они просто функции в коде проверяют То есть как бы совсем маленькие части системы и
00:20:41 - 00:22:04
не проверяют систему в целом вот в чем основная разница что мы понимаем код умеем его читать разбираться и мы покрываем тестами код в Белом ящике А в черном не понимаем и тестами покрываем бизнес требования вот а серия ящик это действительно почему с ним такая проблема просто во-первых его не было изначально был только белый черный серый ящик добавили философы тестирование а потом эти философы не смогли четко договориться что считать серым ящиком и поэтому такое разнообразие большинство интервьюверов на собеседовании в
00:21:25 - 00:22:29
принципе примет ответ что серый ящик это когда мы может быть целиком не понимаем подкапотно устройство системы Да там код не можем читать так далее но при этом из системы Мы не взаимодействуем с точки зрения бизнес-логики пример можно привести тестирование допустим сервера отдельно от frontendo То есть когда мы руками пишем запросы на сервер специальной программе Таким образом мы вроде как не умеем читать не разбираемся Как там код выглядит так далее но в то же время мы руками отправляем запросы
00:21:59 - 00:23:04
которые должны в идеале формироваться на стороне фронтендо А мы пишем руками мы как бы на полпути Мы у машины открыли капот и мы двигатель не разбирали но газ мы рукой тросик дёргаем вместо того чтобы из салона нажимать на педаль получается такой серый ящик то есть мы вроде как и там и шарим внутри Ну не совсем Вот но вероятно конечно какой-нибудь другой философ тестирования Может там какой-нибудь другой пример привести в принципе понятно хорошо потом он случайно перекрасился в белый цвет но по сути это одно и то же
00:22:32 - 00:23:43
хорошо Так у нас есть ручное автоматизированное ты говорил можешь рассказать Зачем нам нужно автоматизированное тестирование о чем оно вообще суши Ну наверное автоматизирована это будет больше под какие-то может для каких-то определенных там проектов больших и так далее Ну а что это такое вообще как оно работает нести это будет регрессивное тестирование какое-то что это в принципе вот автоматизировано что что там робот Терминатор т-1000 начинает тестировать сайт или что происходит чтобы все работало Автоматизированная
00:23:12 - 00:24:29
это скажем так с помощью какой-то программы условно тут же там послан какой-то когда мы проверяем что-то какие-то запросы делали так далее постман частично автоматизированный просто достаточно сказать что это программа которую мы пишем программирования которые проверяет нашу изначальную программу которую мы Тестируем Все мы пишем код для проверки условно кода какого-то некоторые программы Они через UI проверяют то есть автоматизируют твои действия через браузер некоторые на уровне кода это unitest про которым мы
00:23:58 - 00:25:03
только что чуть раньше говорили оно разные бывает автоматизировано и есть даже небольшая Автоматизированная часть пост монета можно через JavaScript писать автоматизацию проще говоря эту программу которая проверяет другую программу и тоже пишется на языке программирования вот это вот ответ обычно достаточно вот а там уже конкретно какие есть средства библиотеки и так далее Ну не обязательно знать можно почитать конечно могут и спросить проселением пропиум про плей-райт который недавно стал популярным и так
00:24:30 - 00:25:32
далее что это вообще существует хорошо есть у нас позитивные негативные характеры тестовых сценариев можешь рассказать о чем речь Ну позитивный но условно у нас из представить что у нас есть требования в этих требованиях написано что вообще есть и как оно должно работать условно позитивное тестирование это есть проверка того что работа для но так как написано в требованиях То есть это наверное будет позитивным тестированием а негативное тестирование Но это наверное можно отнести уже сказать это больше попытка
00:25:01 - 00:26:26
поломать программу и то есть тут мы пытаемся ее поломать сделать что-то не так посмотреть адекватно ли она работает и реагирует на это либо нет то есть условно на какое-то значение будет Допустим нас стоит максимум 8 символов мы вводим все примеру программа должна то есть адекватно реагировать мы пытаемся поломать она должна отреагировать адекватно А если мы условно Великом всем символов и все обвалилось ну как бы уже понимаю что что-то здесь не так желаемое поведение обычно от эскейсов негативных
00:25:44 - 00:27:00
что мы ожидаемый ты говоришь уж система велась адекватно А что значит адекватно чаще всего когда мы говорим Ну есть Ну смотри допустим есть вот у нас даже максимум 8 символов мы вводим 7 должны были все предупреждения о том что введено там ну то есть меньше количество символов введите там 8 а если мы увели 7 и у нас все упало то есть ну это как бы будет неадекватная не показывает что не так ну то есть ошибка какая-то должна быть в качестве денег а что ещё может система делать чтобы предотвратить
00:26:24 - 00:27:30
поведение которое Ну не валидно от юзера помимо показать ошибку ты там встречался в реальности где-нибудь регистрировался последнее время ты там что-то начинаешь делать А у тебя вместо ошибки какой-то другой прикол Бывает так что в некоторых полях воды тебе просто не дают вести силу допустим есть требования там книгу Английский эти ты от тебя клавиатура на русский ты вводишь символы А у тебя на экране ничего не происходит нету вроде ошибки но ты вести ничего не можешь это как бы такая практика потому
00:26:56 - 00:28:06
что кто-то может не понять что происходит Вот но в то же время бывает же даже она не дает условно зарегистрироваться соответственно не ошибки не показывает и ничего нет ну да да то с одной стороны как бы мы пользуемся не пугаем ошибками с другой стороны если человек не очень доходчивый то он может в итоге плюнуть и развернуться Ладно есть у нас еще такая классификация как статическая динамическая тестирование если я не ошибаюсь статическая это будет без запуска этого слова просто проверка документации
00:27:42 - 00:28:59
какой-то динамическая это уже запуском кода То есть когда мы начинаем наладить по сайтам нажимать какие-то кнопочки и так далее либо же тестирование с помощью каких-то программ если я не ошибаюсь хорошо есть у нас еще уровни тестирования или еще иногда называют виды тестирования по степени изолированности компонентов Вот она начинается с модуль новая и дальше идет мы Ты уже это рассказал чуть раньше вот подробнее вот допустим интеграционное тестирование что у нас проверяет это у нас модуль так интеграционная но это вообще условно
00:28:24 - 00:29:55
проще У нас есть код код состоит код состоит Он же не целый небольшой он состоит из каких-то модулей изначально тестируется вообще тестируется эти модули А при интеграционном тестировании тестируется модули совместно там как-то друг с другом то есть один Как цитируется как взаимодействует один с другим модулем Вот это и будет операционное тестирование Окей системная и приёмочная тестирование про приёмочная приёмочная Ну рюмочная как правило это проводится на стороне заказчика то есть уже условно
00:29:13 - 00:30:30
когда мы там говорим что продукт готов как бы то есть его можно выпускать можно отдавать как правило вот он тестируется заказчиком но бывает что заказчики не тестирует как я считал насколько я знаю что на самом деле там есть документ документ который подписывается заказчику заказчик часто не тестирует его тестируешь Ты же причем еще часто бывает что ты защищает документ составляешь Волшебный под которым подписывается заказчик и ты потом по нему тестируешь документ Как называется знаешь план это если по-английски по-русски
00:29:57 - 00:31:12
план приёмочных испытаний это грубо говоря ты выписываешь Если ты их проходишь находишь баги значит продукт считается с данным его версия определенная и зачастую Ты же сам пишешь себе ты с кейсы который ты обещаешь пройти и если они пройдутся заказчика нету никаких вопросов вот заказчику документ дает Он смотрит грида Я согласен подписывает и ты проводишь вот это вот acepton с тестирования так называемая это происходит не так чтобы часто это происходит каким-то часто крупными заказчиками в очень больших
00:30:39 - 00:31:50
промежутках времени но тем не менее такое случается приходится на такую план подписывать Окей Поговорим про техники дизайна Зачем нам нужен вообще-то дизайн какие-то техники придумали что [музыка] вспомнить немножко Мы в принципе начнем вот зачем они нужны вообще суть техника дизайна заключается в том чтобы максимально уменьшить количество проверок при этом максимально покрыть тестами весь функционал Ну давай тогда да вот их много действительно есть есть самые любимые на собеседованиях техникой эквивалентного разбиения техник
00:31:15 - 00:32:43
анализа ограниченных значений без них Прям вообще не жизнь Вот расскажи про технику эквивалентного разбиения в начале как на работу да Ну вот основные до классы эквивалентности и граничное значение то есть ну вообще классные значения по моему работает вообще-то и совместно друг с другом то есть Что надо сказать я просто мы учили это все в определениях в определениях Я это помню скажи определение Так сейчас секундочку классы эквивалентности так то есть эквивалентность это своего рода равнозначность в тестирование
00:32:10 - 00:33:34
эквивалентами считается значение которое система то есть принимает и обрабатывает одинаково Это то что касается эквивалентности А класс это набор либо диапазон значений вызывающий одинаковую реакцию системы вам прям очень такой меганаучный подход зарядили прям Я бы тоже офигел себя так вот подходил и читал это все набор это множество значений которые конкретно прописано в требованиях диапазон это интервал чисел с границами Не ну Алфавит это будет относиться к набору больше все-таки определение прямо чего сложное прям даже
00:32:52 - 00:34:24
Мне прям хрустнуло в голове прямо а вот теперь давай попробуем это все да объяснить на деле в принципе начнем с эквивалентного разделения классы эквивалентности это набор одинаковых значений вот у нас есть поле ввода у нее есть определенные требования что можно вводить что нельзя Каким образом мы применяем класс эквивалентности на вводных данных поле ввода можем применить в теории Ну допустим у нас есть требования что там поле года принимает значение от 0 до 50 нам надо разбить вообще если мы смотри если мы абстрагируемся
00:34:01 - 00:35:31
именно ограниченных значений я объясню в чем проблема почему-то в принципе большинство теории англоязычные тоже классы эквивалентности хотя на самом деле на самом деле и вполне можно разбить отдельно друг от друга и себе представить и более того это на практике и происходит Итак проще это все понимать вот представим себе класс эквивалентности отдельно от анализа ограниченных значений отдельным А вот например есть поле логина Да куда мы должны вести не и вот если мы абстрагируемся От длины этого поля ввода
00:34:53 - 00:36:05
там от 0 до 50 неважно вот нет у нас какие классы эквивалентности на входные значения мы можем подать если мы От длины отойдем этого поля что у нас еще какие требования часто бывают к полю воду кроме длины от особенно символы какие-то классы валентности бывают Ну вот я бы кстати вот символы символы Я бы их отнес к набору то есть они же должны быть конкретно указаны Какие символы системы должна принимать Какие Она не должна принимать Ну не обязательно может быть просто указано все спецсимволы А какие именно
00:35:31 - 00:36:48
специфилы системы так знает Вполне себе класс эквивалентность а как еще может быть может языке какой-то язык тоже скорее не языки а буквы определенного алфавита допустим английский А какие еще классы ты можешь себе представить на клавиатуру смотри который перестал Может я бы даже отнес бы еще регистр верхний нижний регистр тоже к этому Ну это в зависимости того чувствительная ли к регистру поля допустим поле логина или поле ввода электронной почты обычно не чувствительна поле пароля чувствительно
00:36:19 - 00:37:28
А вот например цифры У нас есть цифры это тоже классика валентности отдельный и как их система воспринимает в чем как мы здесь уменьшаем количество входных параметров да мы допустим у нас требование поле вода вести английский буквы должны принимать в соответствии с классами эквивалентности не нужно использовать все английские буквы английского алфавита мы можем использовать одно или там минимальное количество этих букв если там больше чем одно и мы подразумеваем что система обработает все буквы английского алфавита
00:36:58 - 00:38:15
идентичны эквивалентно и именно такой подход деление на класс эквивалентность нам помогает сэкономить время на написание кучи ненужных проверок например английских букв цифры то же самое нам не обязательно проверять все 10 цифр из нашего клавиатуры мы проверяем одну или несколько опять же зависимости от требований Да в системе и мы подразумеваем что система обработать все требования и это классика валентность над которым мы даже часто не задумываемся Но это человеческая логика попробовали пару цифр вроде работает мы
00:37:37 - 00:38:45
же не пробуем все вот и таким образом мы сэкономим на количестве должна принимать все буквы алфавита смысл все буквы проверять что если значение то есть система принимает значение из одного класса верно то в теории и остальные значения из этого класса она тоже будет принимать Веры Именно для этого нужны класса эквивалентности но и это не гарантия не гарантия что система обработает все хорошо У меня лично опыт был такое что спец символах один СПИД символ отрабатывал неверно был бак в коде но я подходил с точки зрения классов
00:38:11 - 00:39:37
ковалентности конкретно эта спец символ не проверил а потом напротив вылез бак и я вот эту теорию рассказывал когда был разбор полетов как я мог пропустить бак то есть мы подразумеваем мы не знаем точно мы подразумеваем что все значения одного класса работают одинаково и экономим в любом случае даже если мы пропустим бак Все равно мы сэкономили кучу времени а шанс на бак минимальный вероятность ограниченных значений тут уже как бы его можно склеить классом эквивалентности но не обязательно можем и отдельного
00:39:02 - 00:40:16
рассматривать то есть длина Да количество символов на ввод в поле ввода Например у нас Мы можем вести от 10 до 20 символов цифры или всего вместе как бы ты проверил в соответствии с этой техникой Ну соответственно если у нас требование написано условно что логин там от 10 до допустим Ну то есть система принимает логин от 10 до 20 символов примеру должна принимать Но нам надо же проверить что Ну допустим 9 символов соответственно не должна принимать 9 символов и соответственно не должна принимать больше 20 символов то есть мы
00:39:45 - 00:41:06
принимаем то есть проверяем какие-то ограниченные значения может одно значение выше границы ниже границы и на границе потому что опять же в теории тестирования как правило все баги находятся на границах то есть ну и суть вообще заключается в проверке именно ограниченных значений не только потому что много багов на границе а в том что этот интервал может быть очень длинный если мы будем проверять все значения из интервала то есть Назови кейсы которые будут с 10 до 20 если у нас будет интервал просто Назови
00:40:27 - 00:41:47
9 символов 10 символов 11 символов 21 символ 20 символов 19 в твоем примере 10 и 20 позитивные проверки или в негативные в позитивные А зачем тогда нам проверять 11 и 19 если 10-20 уже внутри все все я понял да то есть новый 19 он попадает в этот класс эквивалентности в принципе его можно да не проверять немножко тут запутался можно просто взять тогда получается 9 10 21 уменьшить немножко количество проверок потому что граница она находится между этими числа они Начисли Вот это очень часто ошибка очень часто все время
00:41:05 - 00:42:45
пытаются сделать из ограниченного значения какой-то третий вариант а третий вариант не бывает что бывает на практике часто бывает на практике часто Не часто Но иногда что когда ты видишь требованиях длину интервала есть категория людей на нашей планете которые подразумевают что вот эти значения они за границей где-то в 20 процентных случаях это же по моему личному опыту в требование будет написано там можно интервал значения 10 до 20 и каждый пятый человек будет считать что 10 и 20 это уже за пределами
00:42:00 - 00:43:12
вот поэтому чтобы не было путаницы при реализации всегда нужно стараться выбивать слово включительно То есть если в требованиях написано там 10 20 100 не важно надо чтобы было указано что там от 10 до 20 значение включительно в позитивный интервал потому что иногда программист это прочитал и реализовал по-другому воспринял слова которые вроде как мы все воспринимаем одинаково слово включительно оно очень важно и на собеседованиях иногда вот если тебе на словах допустим говорят Давайте попрактикуемся да вот 10 до 20 первое
00:42:36 - 00:43:52
что спрашиваешь эти значения которые сказали это включительно позитивный интервал или нет И после получил какой-то ответ тогда уже говоришь Какие конкретные тесты ты бы поставил А так хорошо про тестовую документацию поговорим какой тут документацию тест план основное будет основного Нет все равнозначно протез план чего знаешь что знаю опять же хотел сказать основной Но это сплав это такой документ который конкретно и подробно описывает все этапы и весь процесс тестирования То есть как бы его то может входить что
00:43:14 - 00:44:53
Тестируем на чем Тестируем когда Тестируем оборудование на котором условно Тестируем наверное то есть процесс окончания тестирования процесс не процесс окончания тестирования начало фиксирование может еще что-то такое чтобы хорошо в принципе хорошо рассказал как ты думаешь какие есть критерии конкретно начала тестирования пример какой-нибудь критерии начала тестирования это наверное будет так наличие тестовой платформы законченность разработке необходимого функционала и соответственно наличие всей необходимой
00:44:27 - 00:45:51
документации критерием окончания можно отнести открыто необходимое количество там каких-то багов все тесты пройденные найденные починенные исправлены перепроверенные заканчивается Время заканчивается деньги [смех] последние два это интересно это интересно Ну ладно хорошо Как ты думаешь Кто составляет Ну вообще как бы кто вообще должен составлять Но как правило составляет тестировщик и как правило это джун но нам вот это на учебе говорили я начал потом это читать и как оказалось это так ну по-разному бывает
00:45:12 - 00:46:41
если ты придешь в крупный проект там буду тебя каком-то слит то есть план уже будет написано тебе просто с ним познакомились каждого посмотри как мы Тестируем А если ты попадаешь в случайные стартап где-то единственное тестировщик тебе говорят так Сергей Ты вчера закончил курс тестирования что нам делать И вот на тебя смотрится команда и ты такой ну сейчас мы будем тест-план писать и начинаешь всё это делать сам Вот они смотрят Ничего себе Какой умный парень Вот и Действительно это сплан желательно писать потому что это не
00:46:15 - 00:47:15
просто формальный документ хотя часто он является формальным документом опять же в каких-то крупняках Ну и он помогает и тебе и член командам во-первых ваши ожидания чтобы совпали то есть иногда нанимают тести Да и не до конца понимают чего он должен уметь делать Что должен уметь делать а в плане тестирования ты указываешь вот я буду делать это это я делать не буду Мне нужно вот это мне нужно вот это Это конечно можно на словах там в начале работы утвердить но лучше чтобы это было в виде письменном
00:46:45 - 00:47:44
виде в качестве тест-плана потому что потом в дальнейшем Если вдруг тебе этом продаете менеджер скажет судья Почему мы тестирование безопасности не проводим у нас такой потому что типа мы не собирались Я не умею и вот тест-планы тут написано Какие виды тестирования мы проводим тестирования безопасности он такого А я думал что все ручные тестировщики умеют проводить тестирование безопасность и вот мы даже подписались под этим он такой Ну ладно всё не могу все больше приставать потому что я сам подписался
00:47:15 - 00:48:14
под этим тестом то есть план это прям такой серьёзный документ который поможет не ругаться через два месяца после начала проекта и ваши ожидания у нас на защите нам надо было один из пунктов Это был сделать тест-план вот допустим как у меня было в теории мне было понятно как его делать но на практике мне не понравилось мне было тяжело мне сам не нравился как я его делал я его 10 раз переделал В итоге все равно мне не понравилось На самом деле неплохо На самом деле проблема большая тех кто первые разы пишут из клан в том что его
00:47:44 - 00:48:55
пытаются сделать слишком красивым то есть какие-то там блин заголовки содержание как дипломную работу и ты же к оформляешь это все думаешь Да зачем на самом деле ты план достаточно сделать на одной странице в Google доке в ряде случаев потому что главное чтобы он всегда содержал то что надо и все с ним ознакомились конечно бывает такое крупный заказчик он говорит а покажите ваш тест планы ты там расписываешь на 20 страниц Но если этого всего нет Если тебе нужен план именно вот для того для чего я сказал чтобы вы внутри
00:48:19 - 00:49:21
договорились что ты будешь делать одна две страницы на Google доке более-менее коряво шрифтом этого Вполне себе достаточно Это отлично работает а нам скинули шаблон 18 листов Я просто понять что с таким Тяжело да ну и мы тестировали приложение teams по моему каждый это брал себе по модуль я не мог понять куда мне вписать у меня была регистрация тестирование И еще что-то я просто не мог понять что мне писать на 18 листов в плане регистрации вот Единственное на самом деле шаблон для плана тестирования это есть такой
00:48:50 - 00:50:09
сертификат качества 829 и и 829 и там есть просто глава что должен включать свет план и там просто перечислены вопросы на которые должны отвечать бесплатно все не существует На самом деле никакого правильного шаблона ничего всё просто иногда как я сказал пытается сделать красиво чтобы заказчик увидел что ну солидная компания у них на двадцати листах ты спала ну то же самое что защита дипломной работы в университете чем толще кирпич тем больше уважения Вот но на деле план можно на коленке нафигачить и он будет работать
00:49:27 - 00:50:35
абсолютно также в принципе я вот тоже самое что ты там долгими способами там учениями я нашел это в Гугле у кого-то из тестировщиков он написал типа посмотрите это я посмотрел то есть оборудование когда Тестируем кто-то Тестируем я буквально на трех городах местах с огромными проделали все это сделал растянула вроде сказали нормально Ну окей хорошо дальше идем У нас есть для хранения тесных сценариев в тесте начнем что это такое еще стоит опять же если просто это шаги которые конкретно прописаны для
00:50:03 - 00:51:29
прохождения проверки А чек-лист это будет просто список проверок то есть там не будет конкретно ничего прописано или еще что-то просто условно проверка который надо сделать [музыка] Какие конкретно включает в себе части что-то так это ты имеешь ввиду пункты да да как Какого типа сейчас попытаюсь вспомнить Ну наверное из основного это будет какой-то айди ты с кейса это будет какое-то пригодие какое-то самое шаги фактический результат ой ожидаемый результат ожидаемый результат что ещё будет ну статус может какой-то ещё мой статус
00:50:47 - 00:52:31
пост условия какие-нибудь комментарии тут главное на собеседование на реальном не говорить что есть какие-то более важные поля какие-то менее важные иначе можно попасть на философский спорт что считать более важным что считать менее важным и забуриться в нем лучше всего для себя помнить что ты с кейсе есть шаги ожидаемый результат название все это на самом деле три реально основных поля без которых это все не работает а все остальное статус пост условия предусловие комментарии и так далее Это уже более опциональные вещи если как
00:51:46 - 00:53:01
правило там забудешь не назовешь это уже не так критично Поэтому лучше просто начинать с основных но слух не говорить что есть основные поляне основные А то если уже спросят если уже спросят со слов что разные люди считают по-разному потому что тоже там начнется кто скажет что там это основное это не основное но тут увидишь опять же если смотреть разные источники то есть всю кардинально отличается так У других так и тут какую-то надо такую золотую середину Я вот поэтому лучше вслух просто не говорить слова Есть основные
00:52:24 - 00:53:33
основные а просто начинаешь говорить так есть поля вот такие шаги ожидаемый результат название может быть еще часть авторов выделяет статус кейсы но опять же и когда ты будешь работать системами которые хранят то есть кейсы это тест Трейл и другие статус проставляется когда-то эти тесты запускаешь специальным образом по умолчанию Ну типа нет никаких статусов здесь просто хранилище с кейса вы всё который ты периодически выдёргиваешь из хранилища на запуск и они потом назад возвращаются Поэтому вот у нас есть
00:52:59 - 00:54:07
чек-листы вообще все содержит эскиз имеют сложную Зачем нам одновременно искейцы чек-листы если они вроде как об одном и том же Слушай ну тут же наверное зависимость и тут от нескольких каких-то моментов Это от уровня тестировщика будет ну то есть зависеть и от проекта то есть как бы если проект огромный какой-то большой на примере даже кого-то интернет магазина там Wildberries к примеру вряд ли там подойдет То есть как бы большой функционал конкретно ты говоришь вряд ли подойдет не вряд А тут критерий Назови Когда нам
00:53:35 - 00:54:59
подходит больше чек-листа когда тест [музыка] Может подойдет если мы будем делать какой-то там условно маленький кусочек то есть ты понимаешь Давай пойдем от практики к теории приходишь ты на проект на котором торгуют трусами со слоником мужскими вот проект тебе менеджер горит говорит Сергей у нас быстрый проект сейчас в тренде мужские трусы со слониками Короче нам надо за три месяца запилить сайт именно по продаже вот этих вот вещей Здесь три месяца на тестирование ты будешь пока единственным тестировщиком вот эти три месяца
00:54:16 - 00:55:44
какой тип хранения документации ты выберешь и почему Ну наверное вот в этом случае вы все-таки выбрал чек-листы потому что все таки проект маленький неизвестно сколько он проработает функционал его небольшой торгует условно представишь что торгует а не одной позиции какой смысл заводить во-первых он пишется дольше но во-вторых нет такого необходимого функционала а чек-листнул словно быстро набросался набросался если опять же этот проект может он схлопнется через три месяца и этот мой как бы документация которую я расписывал и
00:55:27 - 00:56:38
думал как лучше понять не написать Она просто никому не надо все правильно вот то есть просто все верно назвал что во-первых сложной системы лучше покрывать То есть у меня не чек-листами просто система наоборот второе Ты один это документация во-первых она особо никому не нужна кроме тебя во-вторых не факт что проект дольше проживет вот и всё верно Да вот стоит только самому это без примера потому что на реальномесе будет хмурый человек сидеть и говорить ну-ка Разницу мне назови и не будет примерно с
00:56:05 - 00:57:24
мужскими трусами со слониками ты потеряешься такое А какая разница если мы найдём до реального собеса и вот такой вопрос я даже вспомнил хорошо [смех] О'кей поговорим про что это такое технический документ подробно описывающий дефект и шаги его воспроизведения описание Бога Так что он включает описали Ну то есть условно Какой бак описываем какой Баг и вообще ну то есть тоже фактически Я же так фактически Ну то есть фактически ожидаемый результат условно Как должно быть и как по факту является еще что обычно бак себе
00:56:45 - 00:58:19
содержит кроме описания шагов Да фактического ожидаем результат состав то есть какие-то поляну это наверное какой-то ID будет все верите приводите и статус какой-то еще там бывает вот допустим ты увидел бак который там относится к визуальной части чтобы ты сделал помимо того что есть одна вещь которая прикладывается ко всем багам в зависимости от их вида чтобы разработчику было проще понять что там происходит вот может скриншоты видео скриншоты есть раздел оттачиваем с приложения во всех видео скриншоты есть
00:57:49 - 00:59:14
Визуальная часть могут быть логи сервера если это backend составляющая может быть что-то еще неважно вот еще бывает что есть поле автор Кто создал баг Report есть поле осане напомним сейчас висит это очень важно Тоже понять что дальше с ним делать помимо всего остального вот по поводу севере приорити тебе приходилось работать в системе жира Нет мне не приходилось но я читал что в последнее время конкретно по моему в жире нету разделения на севере приводите у них есть просто по моему приворить если я не ошибаюсь вот такое где-то Я
00:58:51 - 01:00:12
читал последние больше 10 лет Ну это есть такая особенность то что в реальных бак трекинговых системах которые ты скорее будешь пользоваться это в 90 процентах случаев будет жира нет деления на севере приводите Она есть только в теории тестирования зачем-то Хотя в реальной жизни тебе придется одновременно просто учитывать и важности приоритет и выставлять приоритет хорошо поговорим про жизненный цикл баг-репорта Вот баг-репорт ты создал что с ним дальше происходит начнем с самых простых условий когда
00:59:32 - 01:00:47
никто ни с кем не ругается Никто там не пинается все хорошо условно тестировщик доходит какой-то баг дефект заводит по крепорт назначает условно ответственного скажем так разработчика того кто будет этот бак чинить ремонтировать назначает его этот баг Report попадает на назначенного разработчика разработчик это изучает этот баг пытается воспроизвести его если у него все окей воспроизводится так далее он его чинит починил словно отправляет его обратно тестировщику тестировщик его уже повторно тестируют если
01:00:19 - 01:01:50
он видит что бак Ну то есть не воспроизводится вам почти закрывается Если же он у него воспроизводится опять То есть он опять открывает наверное заново как бак Report и опять его назначает на разработчика Ну то есть как бы ну ты там не сделал По моему это же называется ретест Если не ошибаюсь разработчик опять пытается проверить Так ну как может продолжаться как ты думаешь прям до какого-то периода то есть какого-то момента может упираться и тестировщик и как бы разработчик постоянно ругаться Пока все согласны с положением вещей он
01:01:04 - 01:02:33
может друг на друга перелетать сколько угодно время как-то решить и договориться кто-то наверное уже свыше подключается и говорит как бы Ну смотри э в принципе если никто не ругается то есть допустим Ну разработчик говорит Да это баг я чиню Я починил смотри тебе попадает ты такой ага воспроизводится почини ещё раз он такой Ага я согласен починю починил проверяйте это может продолжаться на самом вечность может проблем никакой нет разработчик он действительно Ну соглашается каждый раз что это бака И что надо починить что он
01:01:57 - 01:03:01
облажался тем более разработчики же тоже джуниорами бывают и бывает что вот он пытается они не получается И вот вы вдвоём ты же у него Он же у него и вы мучаете эту задачу это нормально то есть в этом нет проблем возникает когда допустим а разработчиков в какой-то момент говорит так у меня больше не воспроизводится я не согласен что есть какой-то открытый бак забирай его себе делай с ним что хочешь Вот тут как ты говоришь подключается кто-то свыше вот ну перед тем как кого-то свыше подключить Наверное что-то мы можем
01:02:37 - 01:03:40
проверить на всякий случай Вдруг это наш косяк Или чей-то ещё конечно ну то есть надо Ну то есть условно если он говорит что он починил и присылает А у нас он воспроизводится Ну тут же опять же надо проверить что может мы что-то сделали не так то есть какие-то там моменты опять же надо проверить Я не знаю какую-то тестовую платформу на чем чинит он условно и проверяет на чем это делаем мы можем это делать условно на Маке мы там на винде как бы может даже он делает тоже наведем и везде но у нас условно разные версии то есть вот
01:03:08 - 01:04:20
эти вот эти вот все факторы Ну то есть вот есть окружение техническое вот физическое Да там телефоны разные операционная система разная что-то еще что может быть еще разное даже может кто-то по-разному просто понимать Я не знаю какую-то документацию либо какой-то описание То есть он это понимает так ты это понимаешь так и вот опять же если есть какой-то адекватное общение между теми между тем как без ругани без ничего Ну в принципе можно как-то адекватно решить вопрос есть такой да не понимаешь шагов есть просто
01:03:44 - 01:04:49
еще один параметр который тоже очень часто встречается и поначалу джуниоры часто не придает значение версия кода то есть проблема не в том что у тебя у вас разные устройства и вы по-разному понимаете требования Бывает такое что программистом когда работает у него в первую очередь все изменения попадает на его компьютер а потом уже с помощью Continuous internation систем этот код внедряется в основную часть и вот бывает так что программист очень сильно спешит закрыть и он залил код сам себе и закрывает
01:04:17 - 01:05:23
но его код никуда не делся своего компьютера проверяешь тебя воспроизводится а дело в том что версия продукта у вас разная и в этом случае надо там проверить сказать Слушай а твой код то он уже попал куда надо вот мы проверять его не рано ли еще и он может сказать А да я забыл его запушить или я все сделал Подожди пока континента gration сервер его пережует и для всех выпустит новую версию Вот это очень частая история хорошо представим теперь ситуацию когда ты бак зарепортил А разработчик самого начала
01:04:50 - 01:06:01
пошел в отказку и сказал Не буду Не буду чинить вообще Вот какие там бывают статусы если четко статус не может сказать что может быть не так вот Нет ну может потому что этот был какой-то или может это как повторно уже дубликат надо еще тоже если мы его нашли как бы убедиться вообще было не было но все равно надо обезопасить чтобы не было потом каких-то вопросов обезопасить в первую очередь Надо иногда разработчику кажется что дубликат сначала надо убедиться действительно дубликат потому что бывает что схожая
01:05:25 - 01:06:53
составляющая схожие экран но не тот и просто разработчик поспешил назвать дубликатом мы ему пишем Нет Не дубликат потому что это совсем разные проверки если есть Если действительно дубликат мы проверяем что было с тем с оригинальным баг-репортом Если он еще открыт и в работе тогда не вопрос Мы свой закрываем как дубликат и прилинковываем его на всякий случай туда чтобы информация была побольше если же тот оригинальный уже закрыт это значит баг вернулся такое бывает в этом случае мы пишем разработку
01:06:19 - 01:07:22
это конечно дубликат того бада но тут мы вроде как починили а этот ну а бак-то Опять вернулся Поэтому давай-ка ты занимайся с моим Богом опять а тот Имей в виду опять же к нему прилинковываешься все там говоришь вот для информации тебе будет полезно и все он занимается а бывает другие причины когда разработчик говорит что типа я не буду потому что что-то Вот кроме дубликата бывает какие-то ситуации наверное не вспомню если не подскажешь А бывают бывает допустим кнутри продюсер То есть он просто типа открывает сразу
01:06:51 - 01:08:00
смотрит пытается повторить у неё не воспроизводится говорит не воспроизводит У меня все нормально сразу не потом через несколько Починок сразу тут то же самое ты тоже перепроверяешь все может быть ты поспешил может еще что-то бывает статус он был не буду делать Почему Потому что та часть приложения которые ты нашел бак изменится послезавтра он говорит Да я признаю бак но мы скоро все переделаем все перепишем или удалим нафиг этот часть функционала поэтому я чинить там ничего не буду потому что в
01:07:35 - 01:08:38
этом нет Разумеется мы лишний раз там точнее менеджер еще что-то Правда ли так далее самые частые варианты не читал бы повторю Потому что это не просто вопрос на теорию чтобы там на собеседовали это реальная жизнь ты сядешь проект тебе придет бак с подписью не буду делать И ты будешь думать чего что дальше читаю обязательно потому что вот сколько читал эти вопросы хорошо Ну и тогда последнее тема это процессы разработки Да вот Какие ты знаешь методологии разработки про какой-нибудь может быть расскажешь
01:08:06 - 01:09:50
так но на самом деле это тоже этих много методологии разработки сейчас попытаюсь вспомнить основные такие ну Первое это наверное будет водопадная она же каскадная модель потом это будет v-образная модель это будет гибкая он же еще я читал слышал про итеральную или инкрементальную еще называют спиральная и даже где-то читал про модель хаоса какой-то есть еще экстремальная программирование но наверное из основных что сейчас используется это же водопадная Же каскадная либо же отжали вот такие самые
01:09:02 - 01:10:36
основные которые сейчас есть больше конечностей водопад тоже используется в определенных проектах конечно где использу ются Но это наверно будут какие-то определенные проекты которые скажем так скажем так как бы более четко может как-то продуманы которые связаны Я бы даже сказал наверное с минимальным Ну то есть там где нужен минимальный риск это может какая-то военная отрасль медицинская Космическая какие-то такие где есть четкая Каким образом минимальный риск обеспечивается в ватерфоле почему
01:09:54 - 01:11:11
тут даже минимальный риск в плане вот имел хотел рассказать с минимальным риском может как бы даже для жизни Вот или еще для чего-то то есть а вот почему почему риск минимальная Почему риск Почему меньше Ну один из принципов какой-то есть работающий продукт мы переходим на следующий шаг только после завершения условно предыдущего здесь шаги они как бы более сказать может четко прорабатывается в принципе правильно говоришь потом между шагами как указано затруднена или отсутствует обратная связь то есть мы не
01:10:37 - 01:12:05
можем вернуться на предыдущий этап может прибежать менеджер в середине цикла разработки так мне только что позвонил Иван Иванович Он сказал что короче мы теперь не трусы со слониками продаем а короче эти самые шарики воздушные и поэтому нам надо поменять половину функционала прямо сейчас в течение вот текущего спринта и из-за этого это всё будет сделано но из-за этого всё разработка Вот так вся перевернётся и из-за того что там Придётся делать быстро быстро переключились между функционалом вероятно у нас будет много
01:11:41 - 01:12:50
багов в ватерле такое невозможно мы Разумеется можем выпускать шарики после того что мы делали до этого только когда цикл вот до конца вот поэтому получается что проблема ватерфола в том что иногда мы в конце получаем вообще не то что нам нужно потому что мы опоздали из-за того что рынок быстро меняется технология меняются и так далее но с другой стороны то что мы получили будет намного стабильнее и качественней чем то что мы получим в конце интерфолла Я даже эту статью недавно читал какие-то если
01:12:16 - 01:13:22
военные промышленность почему она даже если долго разрабатывается с этим Потому что сам процесс Он намного дольше за счет но и это опять же такая же отрасль которая условно нельзя спешить потому что Степень риска если рухнет какой-то интернет магазин Но ничего страшного если там упадет как бы ракет или спутник блин это уже это уже плохо да конечно да строение авиация медицина все обычно стараются не торопиться Тем более у них там конкуренция не такая большая как среди магазинов интернет и так далее То
01:12:50 - 01:14:07
есть у них это экономика сходится Окей Хотя вот допустим Раньше даже сейчас Microsoft говорит что они делают Windows на waterpoly хотя мы сейчас уже видим что если раньше Windows выходил раз в 4 года С новым названием с новой оболочкой совсем перепиленным то теперь маленькие порции Windows выходит Хотя раз в неделю Потому что ты пытаешься открыть компьютер он тебе говорит нет мы сначала обновимся мы добавим маленький кусочек а вот тогда уже Ты выключишься это уже на самом деле переход к такой более частой
01:13:28 - 01:14:34
разработки которые уже больше подходит понимание Окей А вожал ты говоришь это методология Но это на самом деле не так это набор Практик а в нем вот уже есть несколько методологии внутри Agile Ну сейчас помню опять же этого определения которое нам давали были это какие-то там скрам Канбан спринт планирование спринта блог продукта инкрементом что-то такое слова но это две самые популярные методологии а внутри из храма допустим есть части слов которые ты назвал ты в принципе можешь рассказать вот допустим ты попадаешь в
01:14:01 - 01:15:34
компанию или приходишь на Собес тебе говорят у нас работа по скрам идет понятно как вы работаете И вот ты можешь рассказать как работают скрам это вообще скажем так позволяющие вести совместную работу позволяет совместно работать какие там вот обряды происходит Да вот и еще состоит работа с краном по скрам не помню но наверное спринты какие-то спринт это какое-то условно промежуток времени как правило он длится от 2 до 4 недель и в этот промежуток времени команда должна выполнить работу которая
01:14:50 - 01:16:12
была ей поставлена Во время планирования класс в планирование спринта вот ты говоришь ставится работа что-то непосредственно делается а планирование вообще планирование спринта это такое событие в скраме я понимаю то есть в рамках тоже которого определяется вообще объем работ и работа Ну то есть то что надо сделать спринте То есть как бы что-то починить что-то проверить опираются задачи первая еще с этими задачами делается они набирают задачу они допустим Есть для нас принта две недели надо что-то
01:15:42 - 01:16:54
еще задачами сделать не мог просто сказать эту берем она мне нравится они еще что-то с ними делают они еще время назначают эти задачи сколько на по времени займет чтобы в итоге успели через две недели что-то сделать что дальше происходит платах планирование пришлось дальше взяли делаем когда делаете пока каждый день что происходит Ну и регулярно не обязательно каждый день наверное какие-то созвоны Что происходит в конце в принципе что было сделано что не успели сделать где были трудности может даже обсуждается какие-то моменты что
01:16:23 - 01:17:52
стоит лучше сделать как-то Ну ты чтобы был лучше продукт все правильно сказано То есть это ты между фактический результат анализируется результаты и так далее там есть слово короче которое вот и ты определение назвал определение слова ретроспектива в конце происходит это вот то что назвал подводит итоги анализирует обсуждают что можно улучшить так далее Короче слова ретро используют у нас будет запомню не слышал хорошо полезно кроме в конце ретроспективы где происходит анализ результатов что еще происходит Ну вообще
01:17:25 - 01:18:51
в конце мы получаем какой-то результат рабочий продукт То есть это он по моему Ну где-то может в учебники называется в реальности в реальности у нас происходит и происходит еще в этом одна вещь называется релиз то есть мы когда все это запилили мы все куда-то выкладываем и еще периодически у нас происходит так называемая тема демонстрашно демонстрация перед релизом нам звонить заказчик говорит Ну что ребят показывайте Как там мои эти самые поживают плоды вот и ему прям показывают экран и показывает ему мультики вот
01:18:12 - 01:19:26
смотрите какой сайт замечательно Вот Мы это можем это можем это можем как вам говорит отлично ребят работаем дальше ныряем следующий спринт происходит релиз и потом начинается Все заново опять планирование работы ежедневные деле созвоны в конце 5 ретро демо релиз вот так вот по кругу происходит вот и весь экран Хорошо Супер вообще замечательно пообщались Мне понравилось Сегодня самый длинный собеседование но хорошо время время тело незаметно хорошо продуктивно поговорили тогда мои заметки Да только что тебе
01:18:53 - 01:20:16
следует улучшить во-первых цель тестирования Да какие-то конкретные выучите там немножко просел говоришь я не очень помню любую классификацию цель и тестирования нету одной классификации которая всем понравится но лучше чтобы выучил чтобы отскакивала какая-то одна конкретная А про цветные ящики Да мы покрываем мы во-первых разбираемся под капотом если это белый ящик и не разбираемся Если черный Во вторых что мы покрываем тестами в Белом ящике мы покрываем тестами код в черном ящике мы покрываем
01:19:34 - 01:20:41
тестами требования техники с дизайна Да ты прям вспомнил эти Мега сложное определение Но тяжело было объяснить о чем речь повторяешь ищешь варианты попроще Да что разбиение мы просто все данные которые на вход делим на различные классы и все данные внутри класса равны друг с другом поэтому нет смысла абсолютно все данные из этого класса тестировать Мы берем любые Рандомные случайные из них про ограниченное значение помним что у нас когда проверяем границы нету какой-то третьей позиции то что входит либо то что не
01:20:07 - 01:21:16
входит так план принципе хорошо назвал чек-лист эскиз стараемся не говорить что у нас есть обязательные важные неважные поля просто производим произносим эти поля Какие помним так в баг-репорте тоже там можно чуть-чуть повторить какие вещи ты там забыл что есть автор что есть на кого засанена есть атачменты помимо того что назвал в жизни Повтори ситуации которые возникают в негативных случаях да то есть когда разработчик сразу отказывает тебе в проверке а в том чтобы починить код он может быть дубликат может быть вон ту может
01:20:44 - 01:22:23
быть что-то еще вот эти случаи посмотри так Ну и в принципе а остальное Окей по поводу методологии разработки действительно много чему учат что на практике чаще спрашивают и что действительно работает это waterfall да более поконкретнее начал говорить что она лучше подходит для проекта надо начинать с того почему это особенно методология Где лучше качество потому что там не происходит возвратов назад в процессе и так далее и потом приводишь пример медицинское оборудование и так далее так далее и по поводу отжали отжал
01:21:34 - 01:22:50
это не методология это набор Практик соответствует манифестом А уже в нем внутри есть методологии и чаще всего это либо скрам либо команда Вот это основа вокруг которой идея А там уже дальше можешь разматывать там вот какая-то мужчина криминальная модель Ну там тоже можно полетать Но главное для себя четко с краном камбан подать и отдельно waterfall это вот самый базовые вещи которые лучше хорошо знать остальное все супер Мне понравилось у тебя хороший Настрой на собеседовании это очень важно потому что очень многие
01:22:16 - 01:23:29
хмурятся грузятся там бывают люди ослабливаются когда там пару вопросов мне ответили про у них прям смотришь и человек уже все хочет закрыть экран уйти и остановить этот процесс вот у тебя это наверное может быть если бы что-то я бы тоже начал но конкретно просто и собирать эти определения но у нас и когда время учебы заставляли [музыка] твердили что Это основное и как бы вот какие-то определения То есть я даже Разбуди ночи Я выиграл действительно полезно выучить потому что на реальном собеседовании от волнения ты
01:22:54 - 01:24:12
можешь даже самая просто определение если ты в этом шатко помнишь вот просто Я рекомендую допустим брать определение попроще для выучить то есть нет такого что есть единая книжка со всеми определениями есть куча источников и грубо говоря если тебе понятие описание техника с дизайна тяжело дается Потому что ты можешь его выучить но ты не можешь его объяснить возьми другое попроще Найди какой другой источник попроще и тогда тебе будет проще на реальном собеседовании и не придется прям уж сильно себя там
01:23:44 - 01:24:46
насиловать каким-то сложными даже определение что такое тестирование вот есть простой вариант а есть вариант допустим из сертификации Кубина 6 строчек и ты я вот не хотел бы никому рассказывать потому что это Кошмар Зачем такой я и хотел тоже об этом сказать те которые я читал Я в принципе не понимал я их не мог запомнить какие-то определения я просто сам выписывал и даже своими словами чтобы просто их понимать как высекретам и до патентный метр тоже вообще можно голос сломать методом и я просто я когда читала истику
01:24:15 - 01:25:32
би сам когда думал может быть сдавать или нет Я сломал голову На огромном описании разницу между понятием бак дефект и ошибка Я читал это три раза потом понял что это просто вообще какая-то абсолютная сумасшедшая информация которая никак не поможет в тестировании и в реальной жизни и заказчики и работники компании и бак и дефект и ошибка это все название одного и того системе новости кубе там вот такие просто не как надо важно понимать между ними разницу и вот это вот все поэтому конечно не очень хорошо
01:24:57 - 01:26:09
заставляли учить просто запомнил все эти тоже потом Зачем мне учиться внутри Если они одинаковые по сути Или тот же с хвалите Control То есть я вообще его не понимал вообще я не мог запомнить его пока этого словно сам не написал и просто вот своими какими-то словами Ну не то есть не выучил это мы опять же пытался учить Но если звук Как по мне если заучивать просто но это не работает я пытался как-то понять вообще для чего это И что это такое Ну к сожалению там действительно есть вещи которые приходится учить и они к сожалению эти
01:25:35 - 01:26:49
вещи чисто теоретически и они на самом деле на практике другие вот в частности например [музыка] сверить и priority вот как я сказал ты попадаешь в проект в жире есть только поле приоритет если верить и приводит то отдельно не определяешь Но вот на собеседованиях это вот иногда прям как вцепится в это и это все не нужно и то же самое то что говоришь соотношение есть квалити ашурности есть Quality Control и есть понятие testing бывает такой трехуровневую пирамиды выстраивают Я не спрашивал сегодня тебя про это
01:26:13 - 01:27:14
потому что я сам не люблю эти вопросы и так далее но если не повезет на собесе можно такое услышать и придется что-то себе выдавливать и это все не имеет никакого смысла потом к твоим практическим знаниям и так далее я стараюсь спрашивать то что действительно тебе поможет потом реальной работе Ты устроишься и ты не просто будешь помнить набор абстрактных определений А будешь понимать сейчас значит спринт мне Project менеджер написал что завтра планирование значит будет то-то И ты как бы ну короче эти знания они имели
01:26:43 - 01:27:46
какой-то смысл в принципе они так что оттарабанил их на собесе тебя слава Богу взяли и все И на следующие 5-10 лет ты про них Забыл И дай Бог не спросит ты ведь не спросят Потому что когда ты станешь мидлом или сеньором там совсем другие собеседования и частично они даже будут проще чем на Junior потому что никто не будет тебя морочить идятины А вот на дженера обожает обожает выучить 10 ненужных определений наизусть это да Ну что поделать Когда у нас еще учился я даже условно какие-то определения не
01:27:14 - 01:28:19
повторял и я чувствовал что я их не забывал Может потому что мы общались постоянно на эти темы когда вот уже после учебы это вот учишь английский где-то пытаешься потом вспомнить какие-то эти определения Хотя ты их знал его казалось идеально начинаешь забывать тут на самом деле помощи одна чтобы не забывать это ходить на собесы то есть Несмотря на то что английский надо себя толкать отзываться на вакансии попадать на собесы может быть проваливать их попадать на новые и вот так по кругу тогда ты увидишь что спрашивают еще на
01:27:47 - 01:29:05
собесах вопросов на которые ты можешь ответить будет становиться все меньше в какой-то момент ты пройдешь собеседование устройств на работу и миссия пока что до собесов не доходит Ну может быть там еще надо резюме само посмотреть еще иногда важно чтобы резюме было хорошее я понял пересмотрим обязательно посмотрим проверим что-то Если хочешь этот самый можешь впустить чат добавляться вот за соточку и там кидаешь ребят мое резюмешку Гляньте что там как вам норм там Я отвечаю другие участники которые тоже там есть и Junior
01:28:26 - 01:29:41
как ты неопытная есть опытные ребята у которых тоже несколько лет опыта работы есть они тоже могут что-нибудь подсказать помочь что-то изменить и так далее все понял хорошо Окей окей спасибо тебе большое за совет буду учить какие-то моменты которые слабые повторю обязательно где-то получу запомню чтобы все было хорошо Хорошо Сергей Спасибо тебе тоже что пришел Удачи тебе в поиске работы Ну как вам собеседование мне лично очень понравилось Сергей оказался очень активным и живым собеседником и многим
01:29:04 - 01:30:21
джуниором которые ходят на собеседование Я стараюсь также посоветовать всегда проявлять какой-то активность в общении живость побольше улыбаться может быть иногда шутить и таким образом обстановка на собеседовании будет разряженный и стресса будет меньше конечно не всегда так получается иногда ваш интервью довольно строгий внимательный очень дотошный инженер которому Как говорится не до шуток и вообще все серьезно но тем не менее с большей степени вероятности такая тактика вам поможет пройти собеседование
01:29:49 - 01:31:09
Спасибо за внимание если хотите попасть на подобное собеседование переходите по ссылке из описания кролика внизу всего хорошего пока
01:30:31 - 01:30:54