[0:00]Приветствую вас в этом уроке и говорить мы будем, как вы уже поняли, про тест-план. Мы идём с вами последовательно. Мы в прошлом уроке говорили про требования, тестирование требований. То есть, вы на проекте получили требования, вы изучили эти требования и перед тем, как приступить непосредственно к тестированию, необходимо планирование, необходимо сделать план, по которому и будут проходить тесты. Планирование бывает довольно разное. И, возможно, кто-то слышал фразу из серии того, что это план никому не нужны, да, а само по себе планирование имеет большую ценность. И это действительно так. А план штука крайне полезная. Если пользоваться им правильно, да, в нужное время, в нужном месте, и, в общем-то, делать это адекватно, тогда план станет вашим хорошим помощником. Если делать план ради плана, то получите, естественно, какая-то ерунда. И, а так как многие, кто смотрит этот курс изначально рассчитывают на то, что они закончат курс и пойдут работать джуниор-тестировщиками, могут подумать: а джуну же план делать никто не даст? И как бы нет, и джуну тоже могут дать делать план. А-а это вполне себе может быть. Это не что-то сверхъестественное, это не что-то там неадекватное, что не сможет сделать, не знаю, а-а никто, кроме человека, который 5 лет работал тестировщиком, и в конце концов он созрел, чтобы спланировать свою работу. Нет, вы в любом случае планируете то, что вы делаете, вы не делаете что-то на бум. В любом случае есть какой-то план действий. И чтобы понимать, что делать, было бы неплохо разобраться, как этот план выстраивается и какие они вообще бывают. Поэтому давайте разберёмся. А стандартное классическое разбитие тест-планов на три вида, точнее на два вида - это планы мастер-план, ну и чаще сейчас начал встречаться третий вид - это план приёмо-сдаточных испытаний. Эти планы отличаются друг от друга. Давайте начнём справа. План приёмо-сдаточных испытаний — это довольно простая штука. Вы можете такую встретить очень много где, особенно в стройке, например. То есть выполнена какая-то работа, приходит заказчик, принимает выполненную работу. Фактически, это некий акт приём, э-э, не знаю, приёма-сдача, да, то есть акт вот сдачи выполненных работ. Вот это, в принципе, про него. А-а, что вы, как тестировщик, можете в данном случае сделать? Вы можете для этого плана подготовить набор проверок, который необходимо провести. От вас могут это попросить, да, то есть какой может быть, мм, ну, от ситуации, опять же, это может быть прописано, например, в мастер-плане или в другом плане. А под приёмо-сдаточное испытание может быть подготовлен, например, минимальный набор, а-а, требований, минимальный набор проверок, который необходимо провести, типа как смог-тесты. Про виды мы будем говорить ещё в следующих уроках. Это может быть расширенный какой-то приёмочный набор из тестов. Он может быть разный, это может оговариваться отдельно, например, на этапе каком-то предыдущем. А-а, но да, то есть вас могут попросить подготовить такую вещь. В этом прямо ничего сложного нет. Скорее всего, сюда нужно будет просто запихнуть набор проверок, который лучше всего подойдёт под конкретную ситуацию. Вот и всё, собственно говоря. Дальше. Два вида планов: мастер-план и непосредственно план. Про мастер-план обычно говорят, что это вещь, так, скажем, высокоуровневая, в которой не пишут особо ничего подробного. А-а, ещё есть интересный момент. Очень часто мастер-план - это единственное, что, в принципе, из планов есть на проекте, и больше как бы ничего и нет. В чём его особенность? А-а, представьте себе, что вы изучили требования, ммм, и вам нужно начинать работать. Ну, вы не пойдёте просто идти и, не знаю, писать тест-кейсы ничего. Ммм, даже когда вы будете писать тест-кейсы, вы будете на что-то, мм, на что-то, мм, оборачиваться, да, на что-то оперировать, может быть, о чём-то думать, как бы это вообще сделать, какие проверки вообще проводить, может быть, в какую сторону двигаться. И это, вообще, идёт всё про обычный план, про который мы поговорим чуть-чуть позже. Мастер-план, он, я написал несколько вариантов того, что туда может входить. Например, требо, требования к заводимым дефектам. То есть, а-а, требования могут, э-э, иметь в виду, что, а-а, дефекты, которые вы заводите, например, обязаны иметь summary, обязаны иметь приоритет, обязаны иметь severity или не обязаны, например. Здесь может быть, например, а-а, в требованиях заявлено то, что низкий приоритет, если у дефекта, то он не заводится. Низкая критичность не заводится, да, то есть требования к заводимым дефектам. Например, дефекты по вёрстке не заводятся. То есть такие критерии могут быть. О'кей, условия принятия сборки. Про что идёт речь? Здесь про смог-тесты фактически. То есть вы можете заранее в плане прописать, а-а, что вы принимаете сборку только в случае, если она, например, э-э, ну, там, не знаю, рабочая. Прям рабочая, 100%. Естественно, так, э-э, никто не делает. Вы можете заявить, что, например, вы принимаете сборку только в виде ссылки, э-э, на GitHub, например, да, или, например, вы принимаете сборку для работы с, ммм, не знаю, для того, для раз-проект, который можно развернуть под Виндой, например, под, э-э, там, не знаю, под десятый. То есть какие-то условия, как вы будете принимать, в каком виде вы будете получать эту сборку, как вы потом будете с ней работать. А-а, пример: тестовое окружение ваше, допустим, а-а, чисто Windows. У всех тестировщиков чисто Windows, вы тестируете под него. Проект может быть подготовлен не только под Винду, а, например, под маки. Но, а-а, в рамках своего тестирования вы проводите тестирование только под Винду, под маки не проводите, маки оставляются на потом, они просто тупо не в приоритете. И вам нужна сборка под Винду, с ней вы будете проводить тестирование, ну, например, сейчас, да, вот на этом этапе. Хорошо. А-а, дальше. Критерии принятия продукта к релизу. То есть фактически вы описываете, в какой момент, а-а, вы будете заканчивать тестирование. Ну, например, это может быть что-то из серии, а-а, полного покрытия тестами, там, заявленного функционала, да, там, может быть, например, а-а, критерий такой: отсутствуют, а-а, критичные и блокирующие дефекты или, там, ну, определённые там градации выстроить. Это для примера, опять же, да? Может быть, и вполне себе вариант, где у вас прописано, что каждое требование должно быть покрыто минимум десятью тестами, все тесты должны быть пройдены, а-а, там, без ошибок, без дефектов, да? Если это есть, значит, можно выводить в релиз. То есть какие-то критерии должны быть описаны. Инструменты. Заранее есть смысл обговорить, чем пользоваться. Например, для тестирования API вы говорите: будем пользоваться SoapUI. А-а, все умеют пользоваться Postman. Никто не умеет пользоваться SoapUI. А-а, но, допустим, на этом проекте решили так. И это хорошо, что об этом поговорили заранее, потому что дальше можно проработать момент, чтобы обучить команду работать с SoapUI-ем и не потом не страдать просто из-за этого. Для этого делается мастер-план, да, то есть какие-то такие, хмм, целевые вещи, действительно, более высокоуровневые, так можно сказать, чем в обычном плане. Теперь давайте поговорим про обычный план. А-а, обычный план делается всегда. Всегда. Он всегда есть, но не всегда на бумаге. А-а, да, можно так сказать про тестировщика, про эту профессию, что, знаете, можно рядом с этой профессией написать: а-а, без бумажки ты букашка. Ну, например. Тестировщики много работают с документацией. А-а, но конкретно план не всегда может быть написан на бумаге, он может быть в голове. Может быть, точнее не быть конкретной необходимости его прям написать. Вопрос стоит, кому он нужен? Если на проекте вашему заказчику нужен план, вам нужно отчитаться, соответственно, его нужно сделать. Если кто-то из менеджментского состава хочет от вас этот тест-план, естественно, его нужно написать. Если этот тест-план, в принципе, никому не нужен, а нужен только вам, то, естественно, вам нужно решить, нужен ли он вам, в принципе. Почему он может быть нужен конкретно вам, как тестировщику? Во-первых, на этапе планирования, именно планирования, вы уже, хмм, сам проект сможете разложить для себя по полочкам. Понять, что вы будете тестировать, как вы будете тестировать, у вас, возможно, появятся какие-то вопросы заранее, которые можно обсудить и определиться, что с ним сделать. Это круто сделать заранее, потом будет понятнее. Это первое. Второе. Ваш план никогда не должен быть статичным. План - это динамичная штука. То есть в процессе вашей работы вполне нормально, что вы возьмёте этот план, перепишете, измените, там, и так далее и тому подобное. Ну и ещё будет круче, если вы зафиксируете версии плана, и впоследствии сможете отследить, что менялось. Это поможет ещё и в том случае, когда проект закончится, вы будете работать на следующем, и у вас останется ваш опыт работы над этим планом, вы учтёте то, что вы не проработали в этот раз. Следующее. Ваш план фактически, если вы за ним следите и вы его ведёте, это практически готовый отчёт о тестировании. Вы, ну, практически сможете его просто перенести в отчёт, добавить туда несколько моментов, изменить формулировки, у вас готовый отчёт. Вы уже всю работу для себя сделали, что, по-моему, очень круто. Давайте теперь поговорим про то, что туда входит. То есть зачем он нужен? Я думаю, понятно, да? То есть зачем он нужен, даже тогда, когда от вас его не требуют. Надеюсь, понятно. Теперь что туда вообще пишут? Есть классический, хмм, вариант, что писать в тест-план. И обычно это шесть критериев. То есть что надо протестировать, что мы будем, действительно, тестировать, как мы будем это делать, когда мы будем это делать. И последние две вещи - это критерии сдачи, критерии приёмки. Это, как бы, классические, а-а, критерии для плана. Дело в том, что вы можете его, точнее в него, вносить, по сути, всё, что душе угодно, абсолютно любые вещи, если они туда просятся или есть такие пожелания или необходимость. Это нормально. Ну, то есть вполне нормально туда вносить, в принципе, всё, что угодно. Есть шесть классических вещей. Я я давайте с вами поделюсь тем, как, из каких вещей состоит, скорее, мой тест-план. Возможно, на него вам ориентироваться будет проще. Первое - это перечень работ. Давайте я помечу это здесь, чтобы у нас с вами было это на экране. Как это сделаем? Давайте выведем панельку. Так, это не та панелька, а где панелька, которая мне нужна? Вот она. Давайте напишем. Ну, вот как-то так сделаем, давайте. Напишем сюда перечень работ. А-а, что это такое, зачем это нужно? Давайте вернём, пока просто оставим. О'кей. Перечень работ. Сюда нужно написать те области, которые будут протестированы. И сюда же можно написать области, которые не будут протестированы, такое может быть. Например, давайте возьмём за пример обычный сайт, а-а, и, например, м-м, ваша область тестирования, то, что вы непосредственно делаете, это внешняя часть сайта. Я имею в виду, допустим, это вёрстка, и ваша задача - протестировать вёрстку. Соответственно, ваш перечень работ - это работа, по сути, над тестированием вёрстки, там, дальше можно разбивать на, там, разные экраны, разные устройства может быть, да, то есть разные платформы. Но логику работы, а-а, делает, например, другая команда или вообще другая компания, да, у вас совместный проект. Вы её не делаете, вы её не тестируете. В таком случае вы можете прописать перечень работ, который вы будете выполнять и который вы не будете. Например, вы можете прописать, что тестирование будет проводиться только вёрстки и не будет проводиться функциональное интеграционное тестирование. Ну, это опять же из видов, которые мы будем в будущих уроках обязательно проходить. А-а, это история про это. Перечень работ, которые будут выполняться. Следующий, давайте я его напишу: критерии качества и оценки. Критерии качества. Что это такое? Так как вы работаете, а-а, над этим проектом, вы тестировщик, нужно как-то оценить вашу работу, даже если вы делаете сами, это сами для себя. Нужно установить определённые критерии, по которым будет определяться, как вы отработали вот в конкретном данном случае. И будет здорово потом сделать то же самое на следующем проекте и сравнить свои результаты: улучшились они, ухудшились, да, то, что на это повлияло. Критерии качества будут хорошим для этого подспорьем. Как провести критерии качества? На самом деле, это такая большая, хорошая, полноценная тема, очень часто даже, действительно, для менеджеров команд. Если какие-то простые варианты можно взять, а-а, ну, например, хмм, критерии качества могут быть, а-а, ошибки, которые были найдены уже на этапе релиза, да? Допустим, там, не знаю, если были найдены, скажем, так, вы ведёте проект, да, проект перешёл в релиз, и вы ещё тестируете его уже на релизе, как он отрабатывает. И если вот вы на этапе тестирования релиза было найдено какое-то количество ошибок, соответственно, они могут пойти в критерии качества, как, скажем так, в понижающий коэффициент. Почему вы их не нашли, да? А-а, их можно соотнести, например, с объёмом выполняемых, выполняемых тестов. И, ну, пропорционально, да, то есть сделать пропорции. Либо их можно соотнести, например, с количеством заявленных требований, да, то есть заявлено было 100, не знаю, 100 функциональных требований, было найдено два дефекта внутри функциональных требований. Ну, к примеру, такое соотношение может быть. Можно сделать дополнительный критерий качества не на уровень пропущенных ошибок, а сделать на уровень вашей работы с дефектами, понимания вообще, что такое дефекты, потому что или вашего умения написать баг-репорт. То есть проверить уровень, а-а, количество тех дефектов, которые вы завели, но они были отклонены по какой-то причине. Это не очень хорошо, на самом деле, для тестировщика, но такое может быть, надо понимать, что такое всегда будет. Но считать количество таких вот вещей тоже нужно. А-а, в общем, критерии качества могут быть разные, это действительно тема больше для лидов. Но вы тоже можете для себя определённые критерии установить, где-то по своим каким-то внутренним ощущениям. И придерживаться, вас, ммм, вас это будет сподвигать на то, чтобы вы работали лучше, если вы сами себе будете ставить какие-то критерии качества и стараться их улучшать. Это крутая практика. Следующая - это оценка рисков. Оценка рисков. А-а, опять же, вопрос сложный, честно скажу, и он больше, на самом деле, для, скажем так, хорошая, правильная оценка рисков - это, скорее, вопрос лидов. Но вы тоже можете это сделать в определённой мере. Вам нужно подумать, какие риски могут быть связаны с работой. Что это чаще всего может быть? Во-первых, ваши навыки. Нужно подумать, если в этом проекте области, в которых вы или члены команды не квалифицированы. И нужно ли их доучить? Возможно, вам нужно заложить дополнительное время или дополнительные деньги на то, чтобы подготовить кого-то из команды на работы с каким-то инструментом или с каким-то механизмом. То есть это риски не уложиться, возможно, в сроки, возможно, ну, если вы об этом просто даже не подумаете, если команда не будет готова. Другие риски - это возможная замена участника команды, возможно, замена тестировщика. Человек может заболеть, сейчас это актуально, да, много людей болеют в последнее время. Может уйти в отпуск, то есть нужно в идеале убедиться, что человек не уходит в отпуск на какой-то период времени, либо если уходит, то заложить, возможно, его время проработать этот момент. Заболеть, уйти в отпуск, уволиться, в конце концов. А-а, опять же, стоит подумать над тем, есть ли кто-то в отделе, возможно, кто сможет заменить этого человека, а-а, по его функционалу. Возможно, и смысл прописать, что, хмм, или стоит подумать заранее о том, чтобы взять ещё одного человека, который будет готов сюда подключиться, возможно, взять его, как джуна, чтобы он страховал, набрался скиллов и смог как-то заменить. То есть идея именно вот в этом. Риски могут быть и другие. Например, риски, связанные с тестированием, могут находиться в зоне инфраструктуры. То есть если вы понимаете, что проект завязан на мобильные устройства, но у вас нету реальных мобильных устройств, возможно, нужна их закупка. А-а, то есть эмуляторы могут не помочь. А-а, то есть риски должны продумываться вот в этих областях. Как их продумать, не имея опыта, хмм, сложно. Можете просто оперироваться на то, что я вам рассказал. Это довольно популярные риски, которые, с которыми можно столкнуться. Менее популярные - это уже вопрос опыта, который к вам со временем придёт. Ну, либо вы просто будете читать хорошие книги и статьи и научитесь этому не на опыте других, точнее не на своём, а на опыте других, станете более квалифицированным специалистом. Давайте дальше, документация. Давайте напишем документация.
[18:52]Документация. О'кей. Этот раздел подразумевает, что вы пропишете, какую документацию вы будете использовать. Ну, например, вы заранее подумаете о том, вы будете использовать тест-кейсы или чек-листы. Возможно, если вы понимаете, что вы будете использовать, допустим, тест-кейсы, вы можете заранее проработать шаблон для такого тест-кейса или для того же чек-листа вы можете проработать какие-то критерии для него или, опять же, какой-то шаблон. Почему бы и нет? В плане работ, в плане с работой с документацией стоит подумать не только о том, какие будут использоваться документы. Например, нужен ли отчёт, не нужен, да, там, тест-кейсы, чек-листы, что-то выбираем, делаем какие-то шаблоны для этого, если это необходимо. Вы должны понимать, что это вообще необходимо или нет, да, то есть это основы плана, да, что туда мы пишем. А-а, хорошо. А-а, прописать вот эти вот вещи. Стоит подумать даже, а-а, над тем, а-а, как часто должны, например, ваши тест-кейсы пересматриваться. Будете ли вы делать ревью кейсов внутри команды? То есть такие взаимодействия тоже стоит прописать в документации. Ещё, а-а, я бы написал сюда, хмм, добавил бы, а-а, приёмку. Например, тест-кейсы, если в команде работают джуны, скорее всего, необходимо, чтобы кто-то принимал и, возможно, и смысл прописать, что прямо в плане, то, что тест-кейсы должны быть приняты, а-а, там, специалистом, возможно, в какие-то сроки, чтобы это уже было заранее регламентировано, а не превратилось в, ну, я пока не отправил, я пока не посмотрел. Почему? Ну, нигде не было написано, как бы, мне было не до этого, была другая работа. Нет, всё в плане есть. Отлично, выполняем, понимаем, когда и как. Следующее - тестовая стратегия. Вы можете увидеть в различных местах, а-а, варианты, что тестовая стратегия - это что-то над тест-планом. Нет. Это не что-то над тест-планом, это часть тест-плана, ваша тестовая стратегия. Что она из себя представляет? В тестовой стратегии вы прописываете стратегию того, как вы будете тестировать. Вы можете здесь выбрать, во-первых, или прописать методы, которыми будете тестировать. Тот же самый чёрный, белый, серый ящик, да? Мы их отдельно не разбирали, но это, скажем, не самая сложная тема, будем об этом говорить позже, но, опять же, методы. Можно здесь прописать уровни тестирования, которые будут проводиться. Опять же, поговорить и про end-to-end тесты, про UI-ные, про интеграционные, там, про другие вещи. Можно здесь прописать виды тестирования, которые будут проводиться. В стратегии можно разбить, опять же, а-а, проект по модулям. Для модуля прописать наборы, а-а, ну, наборы, я имею в виду, виды тестов, которые будут проводиться для конкретного модуля. То есть стратегия она должна быть в тест-плане, и в ней нету чего-то прям сложного. А-а, вам нужно просто определиться, какие модули, как будут тестироваться, каким методом и при при, и какие виды тестирования туда будут входить. Это основное. В стратегии можно прописать и другие вещи, например, а-а, по поводу регресса. А-а, можно прописать, будет ли регрессионное тестирование или нет. Ну, понятно, что будет. Можно прописать объём регрессионного тестирования, да, то есть какие тесты, а-а, какие, хмм, тест-кейсы, например, с какой, а-а, с какой, с каким приоритетом попадут в регрессию, да, то есть это можно прописать в стратегии. А-а, можно прописать в метрики, точнее, в стратегии, а-а, то, как вы будете отслеживать ваши дефекты.
[23:04]А-а, я имею в виду то, что вы завели дефект, и вам нужно, чтобы разработчик этот дефект обработал и вам вернул.
[23:18]А-а, всё просто, ну, стандартно, всё просто. Но, что может быть, а-а, на практике? Разработчик вам вернул, например, этот дефект, вы должны его принять и начать над ним работать. Ну, по идее. А-а, вы можете прописать, во-первых, сроки, в которые вы должны принять этот дефект. Вы можете прописать сюда вещи, связанные, ну, скажем так, регламентировать, да, вы можете это регламентировать. Здесь же вы можете регламентировать такую вещь, как, а-а, часто этим грешат, а-а, вам отдают исправленный дефект, но это исправление ещё не установлено. То есть разработчик, а-а, внёс исправление, отправил их на то, чтобы их установили, например, на тестовую машину, да, ну, назовём это так, на тестовую машину. Но ещё не установили. Но он уже пофиксил, он уже закинул на вас дефект. Опять же, здесь история про работу с дефектами в стратегии. Вы можете принять этот дефект на себя на, там, на 24 часа, на, не знаю, на несколько дней, на неделю, не отправляя обратно на разработчика, ожидая внесения, занесение вот этого вот исправления на тестовый контур, на тестовую вашу машину. Либо, например, прописать то, что такие вещи не принимаются, они обратно отправляются на разработчика, и вы уже ждёте на себя исправление дефекта только тогда, когда оно установлено уже на вашу тестовую машину, на ваш тестовый контур. Давайте дальше. И поговорим про ресурсы.
[24:50]Следующий этап в плане должен быть ресурсы. Ресурсы могут быть человеческие, могут быть, соответственно, аппаратные, ну, и программные. А человеческие. Сколько и кого нам нужно, да? А-а, два тестировщика, один автоматизатор, к примеру, и их нужно лидить. А лид нужен, не знаю, на 25%. Ну, ресурсы. Человеческие. Соответственно, аппаратные. Нужны ноуты, нужны Айфоны, нужны, там, не знаю, ещё что-нибудь. Нужно об этом поговорить. Программные. Нужны, не знаю, там, лицензии на SoapUI, на Postman, возможно, ну, на Postman нету, ладно, на SoapUI я не помню, если лицензия, ну, то есть какие-то такие вещи. Нужны программы, например, для работы с базой данных, а-а, опять же, возможно, какие-то специальные, возможно, им нужны лицензии, возможно, их нужно установить на компьютер, потому что их сейчас нету. То есть прописать, какие понадобятся, да, то есть заранее подготовиться, чтобы это у вас уже было. Следующий, расписание. Простыми словами, расписание. Расписание фактически - это, хмм, вы приблизительно, да, вы понимаете объём работ,
[26:11]сколько на ту или иную часть у вас потребуется времени. И в какие даты, через какие промежутки дней у вас будут контрольные точки, что этот объём выполнен или должен был выполнить в этот срок, и как бы нужно идти дальше. В процессе, скорее всего, всё изменится. У вас подвинутся даты вперёд или назад - это постоянно будет происходить. Но вы будете на что-то хотя бы рассчитывать, а потом с этим работать.
[26:41]О'кей, расписание написали. Молодцы. Давайте поднимемся вверх. Увидим вот такой большой объём всего. А-а, и прямо сложного ничего нет. Я думаю, вы обратили внимание, что многие вещи завязаны здесь именно на опыте. Но самое примечательное в этом то, что даже с небольшим опытом, не имея опыта в работе в тестировании, а просто житейским бытовым опытом, вы можете что-то донаписать в любом из этих пунктов. И это уже здорово. В следующий раз вы напишите туда больше, у вас будет больше опыта, вы, возможно, что-то ещё почитаете, посмотрите, вы напишите больше, вы улучшите свой тест-план. В любом случае, он вам поможет. Даже потом сделать отчёт, да, то есть это хороший инструмент, полезный. В конце концов, инструмент. А-а, поэтому не стесняйтесь писать тест-план, даже если вы джун. А ещё лучше, просите время на подготовку тест-плана. А-а, и ещё один момент. Скорее всего, и очень часто, вы вряд ли в самом начале попадёте на проект с самого начала. То есть проект, скорее всего, уже будет идти. Возможно, там уже будет тест-план. Ничего страшного. Тест-план - это прекрасный инструмент, а-а, за который можно сесть тогда, когда вам нечем заняться. Ну, бывает так, что вы сделали всё, что нужно, вы ждёте кого-то, вы можете сесть и написать свой тест-план, даже на ту работу, которую вы сейчас уже делаете. Тест-план всё равно переписывается в процессе, он дополняется и изменяется в процессе. Взяли, донаписали. А-а, что вы сейчас делаете, возможно, даже описали. Он потом превратится в ваш отчёт, а когда вы будете работать над следующим проектом, у вас уже будут свои наработки и опыт, вы и сделаете его потом. Так что, делайте, не стесняйтесь. Ещё, а-а, подписка на канал на Ютубе не обязательна. Вообще, в принципе, не рекомендую подписываться, если вы не собираетесь становиться тестировщиками и просто случайно сюда попали поинтересоваться. Подпи, если вы подпишитесь, у вас может быть проблема, вам придётся периодически смотреть мои видео, потому что они будут появляться в вашей ленте. Не самая хорошая идея, да, если вы не хотите становиться тестировщиками. Но если уж вы до сюда досмотрели, то можно хотя бы лайк под видео поставить, потому что урок хороший. Ещё. Если вы хотите больше знаний или чаще их получать, есть подписка на бусте, я оставлю ссылку под этим видео. Бусте - это формат платной подписки. Там больше видео я выкладываю, потому что снимаю их чаще, чем выкладываю на Ютубе. Там за небольшую сумму этот подписка на месяц, вы можете смотреть все видео, которые там есть. Там есть курсы, которые вообще на Ютубе не попадёт, например, по постману. Фу, на Ютубе. А, которые есть на Ютубе, он не попадёт на YouTube, то есть это платный курс по Postman, который там есть, и ещё будут появляться. Так что по подписке можете подписаться, посмотреть все видео, которые не выйдут или ещё не вышли на YouTube. Ну, и учитесь, ребят, давайте переходить к следующему уроку. Пока.
