[0:00]Продолжаем наш курс по тестированию ПО, это второй урок. В прошлом, напомню, мы с вами говорили о том, что такое тестирование ПО, что с ним делать, как это есть, переживать, если так можно сказать. В этом уроке я хочу поговорить о том, как вообще тестируется ПО, да, то есть как этот процесс происходит. И тут мы с вами упираемся в модель разработки, да, то есть которая сейчас открыта у меня. Почему так происходит? Не стоит забывать, что тестировщик - это участник команды разработки. И в этой команде есть несколько людей, да, то есть не только тестировщик, это разработчик. Скорее всего, в команде есть ещё кто-то. Это может быть, например, продуктовый менеджер, проектный менеджер, бизнес-аналитик, ну, в общем-то, ещё какие-то люди. В этом случае есть какая-то команда, которая работает над проектом. И и эта команда, она работает в каком-то в каком-то формате, в каком-то стиле, если так можно сказать. Это называется модель разработки программного обеспечения, или ещё можно встретить название SDLC. Сейчас я выбрал те модели, которые наиболее популярны, наиболее известны, и, в принципе, встречаются. Соответственно, это водопадная модель, многие про неё слышали, такая, ну, разберём сейчас ещё с вами чуть-чуть попозже. Соответственно, V-образная, инкрементальная, спиральная, гибкая и модель хаоса. Среди этих моделей на сегодняшний день самые популярные, которые реально можно встретить - это, конечно, гибкая модель. Гибкая модель - это Agile и его, скажем так, один из его форматов, это Scrum. То есть в основном сейчас все работают по Scrum-у, Scrum - это некоторая часть Agile-а, соответственно, самый популярный формат методо моделей разработки. Менее популярная модель - это водопадная модель. Она тоже встречается, она существует, по ней, возможно, вам придётся работать. Где-то можно встретить, скажем так, не совсем Scrum, можно встретить его некоторые черты, и чаще всего вот эти вот черты, они будут напоминать вам инкрементальную модель. В каком-то смысле. Хотя в чистом виде V-образная модель, инкрементальная модель, спиральная модель, ну, очень сложно встретить, чтобы где-то на проекте вы с ней, вам с ней пришлось работать. А вот модель хаоса - это, наверное, самая любимая модель. Так, привет, ещё один лектор. А модель хаоса - это самая наверное, любимая и популярная модель разработки у многих компаний. Мы поговорим о ней чуть-чуть позже. Давайте для начала поговорим с вами про то, что такое водопадная модель. Окей, я переключил на свой слайд по водопадной модели, и выделил, по сути, четыре этапа. Как вы видите, это проектирование, кодирование, тестирование и эксплуатация. Несложно себе представить, просто по названию, что происходит на каждом, на каждом этапе. Соответственно, можно, когда вы будете что-то читать, встретить в водопадной модели больше этапов. Но суть этого не поменяется. У меня вот в этой схеме некоторые этапы, по сути, сгруппированы просто, да. Давайте разбираться. Первый этап - проектирование. Любой проект начинается с того, что кто-то чего-то придумал. Есть какая-то идея, и на эту идею начинают что-то накладывать. Например, появилась идея создать интернет-магазин. Окей, надо создать интернет-магазин, ну, что это будет за интернет-магазин, как он будет работать, нужен дизайн, сайт разработать, нужны какие-то модели сделать, макеты, соответственно, занимаемся проектированием. Сделали, переходим там на этап какой-то подготовки документации, технических требований. Окей, сделали, идём дальше. Переходим непосредственно к разработке, к кодированию, происходит там, сидят разработчики, всё это дело программируют. Запрограммировали, перешли на этап тестирования, сидят тестировщики тестируют. Оттестировали, вывели в эксплуатацию, идёт эксплуатация, поддержка эксплуатации этого проекта. В этой модели не подразумевается, что вы можете вернуться на шаг назад. В этой модели подразумевается чёткое исследование плану, чёткое исследование документации. Как правило, ещё на этом этапе определяются сроки, бюджеты, ну, в общем-то, эта модель удобна для разработки определённого софта, определённого. А предположим ракетостроительство, да, нужен софт для ракеты, которая полетит в космос. Вы заранее должны понимать, что это будет, как это будет работать, и, наверное, 90% работы будет происходить на этом этапе, только потом будет произведена действительная разработка, выведен этот продукт. Вы не сможете разработать часть какую-то. То же самое с ПО для например, военной промышленности, да, ну, вы вряд ли будете разрабатывать, не знаю, систему ПО, из серии, ну, сейчас, не знаю, в модели хаоса. Ну, как бы, мы её ещё не разобрали, но я думаю, вы представляете, хотя бы как-то, что это такое. Соответственно, эта модель, она имеет место на жизнь, она хорошая, на самом деле, она довольно адекватная, применяется уже не так много, и её многие не любят. Во многом потому, что это достаточно дорогое удовольствие. Дорогое в плане, если вот здесь накосячили, а на этапе планирования очень любят косячить, будем откровенны, то пройдёт этап кодирования, получит зарплату разработчики, да. Пройдёт этап тестирования, возможно, что-то найдут, и если уж не дойдёт до эксплуатации, нужно будет вернуться на этап проектирования, снова над этим работать, перейти к кодированию и так далее, идти дальше. То есть это довольно дорого, не очень удобно. Но применяется. Окей, водопадная, она же каскадная модель, ещё её называют. В общем-то, в двух словах это выглядит так. Ничего сложного или сверхъестественного в ней нету. Окей, следующая модель - V-образная. Или W-образная. В нашем случае W не значит Waterloo, да. Окей, вот таким образом она выглядит. Есть определённые этапы, на каждом этапе происходит определённые действия, да. А вернусь на секунду к водопаду. Мы, как тестировщики, с вами работаем только на этом этапе. Больше мы с вами ничего не делаем в если проект, на котором вы находитесь, работает по водопадной модели, да. То есть вы должны понимать, что ваша работа будет только тогда, когда разработчики всё разработали, отдали вам код. Всё. Окей. V-модель. Чем-то похожа, на самом деле, на предыдущий этап. Ну, тут нужно понимать, что каждому этапу разработки, по сути, а разработки именно документации. Всё-таки, смотрите, идут создаются, идёт подготовка бизнес-требований. Бизнес-требований, ну, типа там, хочу интернет-магазин, чтобы в нём была корзина и всякие там вещи. А потом идут функциональные требования, да, там начинается история про то, какими функциями должен обладать этот магазин, какие у него будут, в принципе, возможности. Окей, потом идёт архитектура системы. Нужно понимать, на чём будет держаться этот магазин, да, то есть какие будут выбраны системные или инфраструктурные решения. Окей, разобрались. А, не знаю, выбрали WordPress, да, или OpenCart, начали работать на OpenCart-е. Перешли на архитектуру, на этап архитектуры компонентов, уже более прикладной уровень перед разработкой, для понимания того, что разрабатывать и как разрабатывать. Перешли на этап разработки, и дальше, поднимаясь по этой модели, у нас начинается тестирование, и тестирование в нашем случае существует, да, для каждого этапа подготовки. То есть, например, была архитектура компонентов, есть модульное тестирование. Модульное тестирование - это пока ещё не тестировщик. Модульное тестирование - это пока ещё разработчик. Будем разбирать виды, поймём, почему. Дальше, была архитектура системы, появилась интеграционное тестирование, проверили архитектуру системы. А, всё окей, перешли дальше на функциональное тестирование, опять же, будем разбирать виды, будем об этом говорить, но пока в рамках методологии, да. Проверили функциональные требования, всё окей, перешли на уровень приёмочного тестирования, проверили всё в рамках бизнес-требований, выпустили продукт. Здесь удобство в чём? Мы можем на этом этапе найти какие-то косяки, вернуться к архитектуре компонентов, исправить, вернуться на разработку, перейти сюда. То есть мы можем по этому треугольнику с вами побегать. Это более-менее дёшево. С каждым этапом это становится дорого, дороже, дороже и дороже, да. То есть интеграционное тестирование, нужно вернуться на этап архитектуры системы, пересмотреть. Окей, изменили архитектуру, пересмотрели архитектуру, понимаете, с каждым этапом усложняется проект, он становится дороже и за время на него потраченного, и зарплату сотрудников в том числе. Дальше происходит всё то же самое, да, то есть этот механизм, он существует. Ну, если приёмочная мы не прошли, пришли к уровню бизнес-требований, сказали: "Ребята, делаем новый продукт, ваш вариант говно". Как вы понимаете, тоже не самый классный вариант, он почти не используется, но про него любят рассказывать. Давайте перейдём к инкрементальной модели. Так, я её сейчас увеличу. В чём идея инкрементальной модели? Инкрементальная модель - это тот самый случай, как в истории про слона. Когда нам нужно съесть слона, мы едим его по частям. А в чём суть? Существует некая идея. Ну, допустим, некий большой, большой проект. Давайте возьмём за идею социальную сеть ВКонтакте. А хотим сделать. Делать сразу весь ВКонтакте очень-очень-очень много, и он выйдет у нас через 10 лет, когда мы его закончим, а может, и через 20. Зачем так делать, если мы можем сделать его кусочками, выпустить его кусочками и потом потихоньку этот проект как бы собрать. Так это и работает. Есть идея, эту идею выкинули на планирование, разбили её по кусочкам, взялись за какой-то кусочек, за первый. Ну, предположим, идею, не знаю, личных страниц, да, решили вот люди будут заходить и просто создавать какую-то личную страницу, показывать себя миру, вот визитку свою делать, предположим. Добросали требования, сделали проект, закинули в разработку. Пошло развёртывание. Здесь подразумевается то, что мы выпустили этот релиз, и уже после выпуска релиза мы тестируем то, что там как бы уже работает на продакшене. Сделали оценку того, что происходит, и перешли снова на планирование. То есть на планировании мы разобрались с результатом оценки того, что происходит сейчас на продакшене и с тем, что мы дальше будем делать. Ну, например, добавляем следующим там, подумали, прикинули, наверное, надо всё-таки сейчас добавить там чаты, а не музыку. Ну, допустим, да, то есть у нас уже есть идея, мы уже понимаем, что мы хотим делать, но делаем это с вами по частям. Сначала мы запускаем первую, возможно, основную часть. Первая часть может быть не только маленькой или главной, но, скорее, именно то, за что можно зацепиться, что-то основное. Сделали её и работаем дальше, добавляем потихоньку новые этапы. Это инкрементальная модель. Я могу вот здесь изменить название с инкрементальной модели на другую модель. А, так, я её не записал. Я её не записал, прошу прощения. Помимо инкрементальной модели существует ещё одна модель, которая очень на неё похожа. Это итеративная модель. Дело в том, что если я здесь изменю название с инкрементальной на итеративную, схема не поменяется. А будет происходить всё то же самое, но с одним отличием. Когда мы говорим именно про итеративную, подразумевается, что наша идея сама по себе изначально маленькая. Ну, например, мы такие сидим и говорим: "А давайте сделаем функцию, не знаю, программу, которая будет заниматься обменом сообщений". Мы её сделали, прошли эти этапы, запустили, протестировали, оценили, понимаем, что люди хотят не только обмениваться сообщениями, люди хотят иметь свой крутой профиль, в который можно что-нибудь добавить. Сделали, прошли круг, подумали: "Надо дать людям возможность пользоваться музыкой". Сделали, подумали и получился ВКонтакте, да. Результат как бы не поменялся, но есть некий такой философский подтекст разных, да, у этих моделей. Окей, давайте перейдём к спиральной, и самая непонятная, пожалуй, самая странная, что ли. Есть некая спираль. А, я же про тестирование должен сказать обязательно. Инкрементальная и итеративная модель подразумевает тестирование вот на этом этапе. И для этой модели это нормально, да. То есть вам не нужно вклиниваться на другие этапы, но такое возможно, когда сам тестировщик может быть привлечён к некоторым этапам. Например, к оценке, к планированию, к требованиям, к проектированию. Ну, к разработке нет, да. То есть может быть привлечён, если он сидит и ничего не делает на работе. Но в основном всё тестирование происходит здесь.
[14:45]Окей, спиральная модель. Это немножко более сложная модель для понимания. Есть некие две оси, ось Y, ось X. И подразумевается, опять же, некие, ну, возможно, итерации, но в данном случае не совсем итерации. А, спираль у меня получилась довольно странная. Я тут описывать текстом не стал, что происходит, чтобы, скорее, рассказать словами. Работает это так. А, допустим, у нас появилась некая идея. Мы её запланировали. Вот, то есть вот эта четверть, да, вот это вот, то есть у нас с вами есть некий квадрат, он разделён на четыре четверти. Есть четверть планирования. Мы, у нас появилась какая-то идея, мы вот, в общем, допустим, с вами в этом этапе находимся. Этап планирования прошли. У нас появился некий вот такой этап, анализ рисков, который мы раньше с вами не встречали. Вот, он именно в этой модели прям это суть, можно сказать, спиральной модели, по моим ощущениям. А, в этой четверти происходит на каждом, скажем так, кругу нашей спирали происходит оценка рисков. В данном случае у нас ещё пока при планировании. Дальше, мы переходим в четверть разработки. И здесь пока ещё не разработка кода. Здесь, скорее, разработка ещё будет, может быть, планы или условия каких-то, да. То есть здесь была идея, мы подумали, что идея очень хорошая, нехорошая, но вроде нормальная идея. Вроде есть даже что-то похожее на рынки, да. Давайте разработаем проект этой идеи. Вот здесь прошла разработка этой идеи. Потом у нас идёт оценка. Оценка этого плана. Мы подумали: "Хороший план, хорошая идея, всё круто. Давайте, давайте идти дальше", да. То есть у нас пошёл следующий круг нашей спирали. И вот так, продолжая этот круг, мы как бы потихоньку раскручиваемся. Мы каждый раз проходим через планирование нашего всего этапа, по сути. Мы проходим через анализ рисков, именно уже на новом кругу нашей спирали: разработка и оценка. Хорошо. По этой модели почти никто не работает, к сожалению. Она, кстати, по поводу этой модели, где будет работать тестировщик? А здесь. В основном работа тестировщика будет находиться на этапе разработки. В анализе рисков тестировщик может участвовать, но маловероятно, это работа немножко другой специальности. На этапе планирования тестировщик может участвовать, но тоже, скорее всего, не будет. На этапе оценки тоже как бы, скорее всего, нет. Этап разработки здесь - это именно та часть, где тестировщик участвует. Просто участвовать он будет. Разработка - это не только написание кода. Вы можете разрабатывать как сам план, вы можете разрабатывать тест-кейсы, вы можете разрабатывать программы, да. То есть по этой спирали мы идём и, в общем-то, к чему-то приходим.
[18:47]Итак, Scrum. А Scrum, я говорю именно про него, как про гибкую модель, потому что Agile, как Agile, используется, ну, редко, если не сказать, что он не используется, в принципе. А вот Scrum - это то, по чём работают многие команды, ну, или, во всяком случае, пытаются это делать. Scrum - довольно удобная модель, и она имеет свои черты от других моделей, которые мы с вами уже рассмотрели. Скорее всего, вы будете работать именно по Scrum-у. Что здесь есть такого у нас интересного, в принципе? Вы видите то, что у нас есть в этой схемке старт, планирование, разработка, тестирование, демонстрация, внедрение, как опционально. И вот этот вот круг, да, вот этот вот круг, он как бы работает постоянно. Потом мы с вами показываем спринт, ну и типа идём дальше. А в чём суть? Scrum состоит из довольно многих частей. Известен в основном своими спринтами. Как правило, спринт - это некое количество дней. Ну, например, две недели. За две недели вам необходимо что-то сделать вашей команде. То есть не думайте сейчас про себя чисто как про тестировщика, думайте про свою команду, в которой вы работаете. У вас в команде есть разработчики, у вас есть бизнес-аналитики, у вас есть кто-то ещё. Скажем так, есть такой артефакт, некий бэклог. Есть бэклог всего проекта, например. Есть бэклог спринта. Предположим, в вашем проекте, во всём вашем проекте, есть некие идеи, задачи, которые необходимо сделать, и их 250 штук. За две недели вы не сделаете 250 штук, но, возможно, вы сделаете пять. Почему бы и нет? Вы выбираете пять задач на свой спринт. Эти пять задач должны быть выполнены. А подразумевается, что эти пять задач относятся не только к разработчикам, не только к тестировщикам. Это задачи команды, которая она должна сделать. А тут задача Scrum-мастера. Scrum-мастер - это, как правило, некая роль члена команды, который управляет всеми этими процессами. Это сложно. Идеальный Scrum - сложный. Идеальный Scrum, где вы смогли спланировать работу тестировщика, разработчика, бизнес-аналитика в две недели, чтобы они друг за другом работали, были взаимо скажем так, взаимо не простаивали - это довольно сложный процесс. Как правило, так не происходит. Как правило, есть некие элементы Scrum-а, из которых состоит действительно работа. Элементы спринта. То есть разработчики идут своим чередом, потом за ними идут тестировщики. Так происходит на практике, да. То есть свои спринты у них немножко. Либо тестировщик просто подстраивается, подстраивается под то, что происходит на проекте. Ну, например, тестировщик понимает, что первую неделю спринта он будет тестировать то, что было разработано в предыдущем спринте разработчиками, а во вторую неделю спринта он будет тестировать то, что было разработано в первую неделю разработчиками. Вот такой более-менее рациональный подход. То есть здесь будет место тестировщика именно вот в этой части. Окей, мы с вами поговорили про то, что есть бэклог, из которого берутся задачи, и вы идёте в спринт. Спринт переводится сейчас так, как, ну, схватка, да, то есть некий такой спортивный интерес, когда вы ввязались в эту двухнедельную свою двухнедельный спринт, чтобы достичь какой-то конкретной цели. Окей, прошли две недели, и у вас есть какой-то результат. Во-первых, перед спринтом у вас определённо были некие встречи, да. То есть здесь появляются те вещи, про которые вы наверняка слышали, как различные митинги, планирование, какие-то Agile церемонии, это всё, по сути, просто встреча. Наши, не знаю, родители назвали это планёрками, возможно. Встреча перед спринтом, вы встретились, обсудили, что будем делать на этом спринте. Начался спринт. В конце спринта встретились, обсудили итоги этого спринта. Закончился спринт, соответственно, обсудили. Ну, то есть в конце или в начале следующего спринта можно обсудить, как прошёл предыдущий. Вынести некие уроки, что-то на обсуждение, да, то есть как он прошёл, может быть, были какие-то проблемы, может быть, можно что-то улучшить. И пошли в новый спринт. Постоянно, постоянно, постоянно. Вот здесь встречается то, то, что мы уже говорили, инкрементальные модели, её элементы, и итерации, да, то есть спринт, по сути, - это некая итерация. И в то же время вы, почему инкрементальная модель, то есть вы берёте некий кусочек того, что вам нужно сделать, и в спринте вы это заканчиваете. Цель спринта - по итогу, в результате выдать какой-то видимый результат своей работы. Это довольно важный элемент спринта. Именно через две недели у вас должно быть что показать. Грубо говоря, чтобы вы могли привести демку. То есть, чтобы вы могли демонстрацию заказчику сделать результатов двух работ. Если у вас в спринте только работы из серии поправили какую-то там версию, логику, но показать вы ничего не можете, значит что-то пошло не так. Вот есть такой нюанс спринтов. Окей, что важно знать про Scrum? А во-первых, про церемонии, которые есть. Я уже сказал вам про планирование. Ещё есть Daily-митинг. Это ежедневный, ежедневный митинг, ежедневная, так называемая, планёрка, можно так сказать. На которой каждый участник команды должен ответить на три вопроса. Что я сделал вчера, что я буду делать сегодня и какие у меня возникли проблемы. Ну и в конце ретроспектива, как некое подведение итогов спринта, того, что было сделано. Это основные три церемонии, которые вам прям нужно знать про Scrum. Следующая важная вещь, которую вам нужно знать - это роли, которые есть в команде. И традиционно в Scrum-е роли у команды делятся на два типа - это свиньи и куры. А это название пошло от такого интересного анекдота. Давайте расскажу. Встретились курица и свинья, и курица говорит: "Свинья, а давай откроем ресторан". Свинья говорит: "Почему бы и нет? А как мы его назовём?" Курица говорит: "Давай назовём его яичница с беконом". Свинья говорит: "Так не пойдёт". "Почему?" - отвечает курица. "А, понимаешь, курица, если мы вот так назовём, получается, что я буду вовлечена в этот процесс полностью, а ты лишь частично". Не самый смешной анекдот, но довольно забавный. А в чём суть? Свиньи - это те, кто полностью вовлечены в этот проект. Курицы - это те, кто вовлечены в проект лишь частично. Давайте поговорим с вами про так называемых свиней, да. А, во-первых, это Scrum-мастер, либо же ещё Scrum-мастера называют менеджер, да, то есть менеджер проекта, проектный менеджер. А человек, который управляет процессами. Второй человек - это Product Owner. Как правило, он есть в Scrum-е. Это непосредственно владелец продукта. Это может быть как заказчик, либо конкретно выделенный человек, организация заказчика, либо ваша организация, если это продуктовая организация, которая отвечает именно за сам продукт. Ну, и третью роль можно выделить как участник команды разработки. Это может быть разработчик, тестировщик, архитектор, бизнес-аналитик, ну, в общем-то, дизайнер, и могут быть ещё некоторые люди, которые, ну, в общем-то, просто встречаются, просто в разных организациях вам могут ещё кого-нибудь приставить и сказать, вам с вами будет работать, будет тоже что-то полезное делать, например, заниматься маркетингом для конкретного проекта. Как правило, команда состоит из пяти-девяти человек. Редко больше, это, скорее, в порядке исключения. Меньше тоже вряд ли. Ну, пять - это такое нормальное число.
[30:03]Кто же такие куры? Куры - это, во-первых, пользователи. Они не участвуют в разработке, но они участники в каком-то смысле проекта, потому что они этим пользуются. Ну, и есть так называемые стейкхолдеры - это люди, которые инициировали этот проект. Они не участвуют, но они принимали участие в инициации, скорее всего, принимали участие в неких встречах, которая была в целом по проекту. Возможно, они будут принимать итоговый результат. Но в рамках проекта они не свиньи, они куры. Ну, а теперь про модель хаоса. А суть её - это суть её в том, что ваша главная задача - это всегда решать самую важную задачу в первую очередь. И, как вы могли догадаться, большинство команд работают именно по этому принципу, особенно перед релизом, особенно когда появляются дефекты. Ищем самую приоритетную, самую важную задачу, которую определяет, ну, скорее всего, заказчик, а по его целям, по критичности, возможно, если это дефекты, ну, по разным критериям определяют наиболее важную задачу. И она решается в первую очередь. А и так на протяжении всего проекта. Модель хаоса существует, по ней работают, по ней разрабатывают проекты, и вполне даже на стартапе можно жить с такой моделью. Ничего там глобально страшного нету, слушайте, ну, есть теория, что жизнь зародилась по модели хаоса, да. Это нормально. А это не очень удобно, это постоянно на стрессе, непонятно, что делать, непонятно, когда делать, и это приводит к дикому выгоранию. Как тестировщику, на этой модели вы нужны будете непонятно когда, непонятно зачем, непонятно для чего. А, но, скорее всего, вы будете нужны, потому что у них всегда будет всё гореть, и всегда нужно будет что-то проверить. Возможно, вы даже порой не будете дорабатывать, будет просто уходить фича в релиз, такое может быть. Но, как я говорил, сейчас популярен Scrum, и это круто. По Scrum-у работать удобно. В общем-то, цель этого урока была донести у меня, а, до вас, а, как происходит тестирование. В чём суть? Вы - участник команды. Команда работает по какой-то методологии. В соответствии с этой методологией вы подключаетесь на определённом этапе. Чаще всего вы будете работать по Scrum-у. Это означает, что вы, скорее всего, будете принимать участие на всех этапах. Какие есть этапы, какие основные? Первый этап - это идея. А на этом этапе тестировщик особого участия не принимает. А на этапе идеи кто-то придумал, что он что-то захотел и пришёл только в вашу организацию, чтобы это заказать. Следующий этап - это проработка, анализ требований, как таковых, выяснения их разработка некой документации. И тут вы уже можете, как тестировщик, подключиться для того, чтобы начать заниматься тестированием требований. Здесь вы уже будете принимать участие в идеальном варианте. Может быть, не будете. Это плохо. Если тестировщик не принимает участие в анализе требований, не тестирует требования, это плохо. И первое, что вам нужно будет сделать в вашей работе, первое, чему нужно будет научиться, и что мы с вами скоро будем в наших уроках проходить - это именно тестирование требований. Дальше, после тестирования требований происходит передача этих требований в на разработку, где уже начнут разработчики писать код. Вы в этот момент, пока разработчики пишут код, пишете свои тестовые сценарии, ваши кейсы, вы готовите различные артефакты, вот можно чек-листы, да. То есть вы готовите свою документацию тестовую, по которой вы будете потом уже тестировать непосредственно сам проект. То есть это ваш следующий этап, это то, опять же, что мы с вами дальше будем проходить. А тестовые артефакты. А окей, разработчик разработал продукт, вам его отдали на тестирование. У вас уже готова документация, по которой вы тестируете. Вы приняли проект на тестирование и проводите непосредственно само тестирование. Окей, а есть разные этапы тестирования, о чём мы будем говорить после, да. Вот именно уже с самого этапа непосредственного тестирования. И когда вы протестировали, вы даёте резолюцию, то есть вам нужен отчёт о проведённом тестировании или дать просто резолюцию о том, что продукт готов, продукт не готов, чтобы продукт либо отправили в релиз, либо что-то ещё. Есть промежуточные этапы во всём этом - это заведение дефектов. Они же баги, да. Я не выделяю это как отдельный этап, потому что, ну, это не отдельный этап, он на каждом этапе встречается. Ну, то есть на каждом этапе можете завести дефект. А, вот, собственно так. Именно так происходит процесс тестирования. Более подробно мы будем разбирать этот процесс в следующих уроках, когда будем конкретно из этих этапов разбирать. Давайте, чтобы немного закрепить эти знания, а, вы напишите в комментариях свои идеи. А меня интересует несколько вещей. Мы сейчас с вами говорили про методологию, а, методологию разработки. А я думаю, что V-образная, инкрементальная модель, в принципе, не особо нам интересна, как и спиральная. А вот, например, гибкая модель, модель хаоса и водопадная - вполне. А я бы хотел, чтобы вы в комментариях написали, как вы считаете, а какие преимущества у Scrum-а, почему люди работают именно по Scrum-у. А не по модели хаоса или, можете выбрать, например, водопадную модель, да. То есть какие у Scrum-а преимущества? А, обязательно напишите в комментариях. А я постараюсь это прочитать, как это прокомментировать, да, может быть, кто-то ещё из ваших коллег, а потому что этот же вопрос вы очень даже можете встретить на собеседовании. Если вы сейчас об этом подумаете, а вам потом будет проще. Не стесняйтесь, пишите свои идеи, даже если они кажутся вам самыми, возможно, дерзкими. Ничего страшного. Окей, на этом давайте заканчивать, переходить к следующему уроку.
