SDLC,STLC, требования, баг. Курс по тестированию ПО #тестирование #тестировщик #бесплатноеобучение

Угу. Вот сегодня у нас тема - это опять мы продолжаем тестирование программного обеспечения, но сегодня будем более подробно рассматривать жизненный цикл тестирования, жизненный цикл разработки, что такое требования, почему возникают баги и роль тестировщика на проекте. Вот.

Да, план занятия я уже, в принципе, проговорила. А начнём с того, что такое жизненный цикл разработки. У нас любое программное обеспечение проходит определённые этапы, определённые стадии, да.

Жизненный цикл разработки включает в себя как раз этапы, которые проходит продукт, да, о которым я уже сказала, да, при этом на каждом этапе выполняются различные действия, каждый этап имеет свой результат. А любое любой продукт начинается с идеи. А тут можно встретить, это один из примеров того, как может выглядеть жизненный цикл разработки.

А где-то пишется, что начинается с планирования, где-то с анализа, сбора анализа требований. Но тем не менее всё равно я обычно говорю всем, да, и считаю, что всё-таки начинается с идея, потому что без идеи, как бы, мы не можем ничего запланировать. Как только у нас появилась идея продукта, идея проекта, уже после этого как раз-таки идёт планирование, сбор, анализ требований, прорабатывается архитектура, прорабатывается дизайн проекта, а после чего уже есть у нас какие-то определённые требования, с которыми мы можем идти к разработчикам.

Соответственно, далее идёт разработка, а после этапа разработки происходит тестирование. Если у нас всё хорошо протестировано, нет никаких дефектов, соответственно, идёт развёртывание и после этого может быть этап поддержки. А тут в множество, в большинстве случаях вы можете встретить, что этапа поддержки у нас в жизненном цикле не будет.

А почему это так? Потому что поддержка осуществляется на не на всех проектах. А некоторые заказчики просто могут вести поддержку с со стороны своей команды.

И мы можем выступать как аутсорсинговая, да, так называемая компания Outff, то есть просто люди, которые их наймут для того, чтобы им разработали проект. А дальнейшее уже пользование и поддержка будет на стороне клиента, того, кто заказал у нас этот продукт. А вот дальше, э, так как у нас все проекты, все продукты проходят определённые жизненные этапы, у нас есть различные модели разработки програмного обеспечения, но все они, в принципе, объединёны тем, что каждый из этих моделей проходят одни и те же этапы, одни и те же ну да, короче, одни и те же этапы жизненного цикла.

А разделяется у нас водопадная модель, как раз-таки в ней все этапы идут последовательно, именно так, как вот я в предыдущем, да, говорю, на предыдушм слайде у нас было написано. И тестирование подключается только после разработки, только после того, когда уже у нас будет продукт. Здесь у нас очень большая цена ошибки, потому что если мы будем возвращаться после этапа тестирования на этапы выше, например, на этап разработки либо ещё выше на этап анализа и проработки требований, у нас будут очень большие затраты и трудозатраты, и материальные затраты, потому что нужно будет заново все эти этапы проходить, нужно будет заново это всё прорабатывать.

А далее, V-образная модель. В V-образной модели м я, наверное, сразу вам буду показывать даже на картинках, на примерах. А вот, как я и говорила, в водопадной модели у нас каждый этап идёт последовательно.

В V-образной модели у нас каждый этап проходит через тестирование. То есть у нас появляются требования, мы их протестировали, а, появились, ну, тут, конечно, требования прямо на множество структур разделено. Это тоже мы проговорим чуть дальше.

Вот. Но тем не менее, опять же, возвращаемся [смех] к этому. А появились требования, проработали, появился дизайн, мы его протестировали, посмотрели, что буду ещё пользователям будет удобно с этим работать.

А, пришли на этап разработки, точно так же проработали, всё хорошо, идём дальше. А, соответственно, тоже мы, получается, как бы как будто бы этап тестирования пропускаем, потому что он здесь сразу на вот этой вот V-образной модели весь есть. А следующее - это у нас спиральная модели разработки.

В спиральной модели разработки у нас, как правило, присутствует только четыре этапа разработки. Это как раз-таки проработка проработка наших целей, проработка наших требований. А тут есть этап анализа рисков, а, соответственно, разработка и планирование будущего спринта.

Вот как раз-таки получается, когда у нас проработка целей, проработка сценариев, у нас здесь есть промежуточные результаты, да, какие-то. То есть мы идём, каждый этап у нас идёт просто как вот спираль за спиралью, а на этапе анализа рисков. Соответственно, каждый из нововедений будет анализироваться.

На этапе разработки у нас там на промежуточной версии как раз-таки идёт и разбиение на более мелкие задачи, и проектирование, соответственно, и внедрение, и тестирование, и так далее по спирали. Вот. Потом следующее у нас ещё есть инкраментальная и итеративные модели.

Насколько я знаю, насколько часто это встречала, их обычно рассматривают совместно. Но тем не менее итеративная модель - это когда у нас проект разбивается на итерации, на какие-либо циклы разработки, в каждом из которых создаётся работоспособная часть продукта. А, то есть, например, вот у нас есть какой-то большой-большой продукт, да, там, например, Так, кого мы взям, ну, какой-нибудь софт, не знаю, там для, может быть, медицинского даже оборудования.

В общем, ладно, больший, короче, софт. А мы возьмём, к примеру, сначала проработаем полностью всё, что будет относиться к там пользовательской части. А, к примеру, там это будет какой-то либо личный кабинет, да?

Сначала сделаем его полностью. Вот этот вот кусок кода проработаем, сделаем всё, выпустим в в люди, да, выпустим на продакшн и после этого приступим к другому куску кода. А при когда мы будем, если мы будем работать при инментальной модели разработки, у нас здесь будет проект создаваться по частям.

Э-э, даже, наверное, наверное, даже не на не на примере проекта можно сделать, к примеру, мм, даже вот пример картины, да. Если мы начнём работать как вот по инкременной модели рисовать эту картину, мы сначала нарисуем какой-нибудь чертёж, потом на следующей, ээ следующим инкрементом, как бы следующей части у нас будет это уже добавление цветов. И там следующий, третий этап, например, это будет уже проработка полностью всех текстур и всего остального.

Так, и здесь я выделила, тоже несла её как бы в модель разработки, поскольку это AG, у нас считается как гибкая модель разработки. Но тем не менее, если почитать документацию, если посмотреть абсолютно всю историю создания там Аджайла, да, всё-таки это будет как гибкий подход именно к управлению проектами и разработке программного обеспечения. А что в себя это включает?

Как правило, чаще очень часто это, во-первых, спрашивают на собеседованиях. Во-вторых, большинство проектов работают всё-таки, как раз-таки, опираясь на Agile работает по скраму. Мм.

У нас что это такое? Давайте с этого начнём. По сути, это как бы считается как философия или же группа методологий.

Agile, в частности, Скрам, он как раз таки в себе включает итеративную и инкрементальную модель разработки, поскольку здесь у нас проект делается, разбивается на множество маленьких частей, они делаются итерациями. А как правило, это если мы работаем по скраму, чаще всего двухнедельные у нас итерации будут. Вот.

Мм, и мы будем вот разработанный функционал поставлять уже нашим конечным пользователям. У нас есть несколько принципов от Джайла. Тоже очень интересная, в общем, эта вся штука в том плане, что если брать у основные принципы, у нас один из самых таких, наверное, основных - это то, что удовлетворение потребности клиента через раню вот эту вот непрерывную поставку продукта а очень важна.

Плюс здесь делается акцент именно на уже сотрудничество между всеми участниками проекта. И, э, ещё один такой из самых главных, наверное, принципов, это то, что у нас гибкость и готовность к изменениям, а, важнее важнее, чем, э, так, а, важнее, чем, в принципе, у нас все вся работа. А, о'кей.

Если хочешь получать эксклюзивный контент и быть в курсе новых видео, загляни ко мне на бусте. Там я регулярно выкладываю новые ролики, которые не всегда выходят на YouTube. Также у нас есть закрытые чаты, где можно общаться, задавать вопросы и делиться идеями.

Поддержи мой канал и стань частью нашего дружного сообщества. Ссылка в описании. Угу.

Так, если мы пойдём дальше, для чего вообще всё это надо? Почему мы вообще начинаем об этом говорить? О всех методологиях и о все жизненном цикле продукта, а и как мы будем сюда тоже входить как тестировщики, да?

У нас есть несколько уровней обеспечения качества во время жизненного цикла, во время разработки программного обеспечения. Очень часто вы могли встречать такие аббревиатуры, как UA, как QC и там тестинг. Если мы будем говорить именно об уровнях обеспечения качества, когда мы говорим о QA - это у нас обеспечение качества во время всего процесса разработки программного обеспечения на всех этапах, начиная от анализа требований, а заканчивая поддержкой.

А если мы говорим о QC, то это этап, это именно как бы контроль качества, контроль заявленного уровня качества, когда мы будем подключаться к тестированию в крузеном цикле разработки только на этапе тестирования. До этого мы не будем видеть продукта, до этого мы не будем вообще не знать о требованиях, ничего, только будет получаться тогда, когда мы уже будем иметь какой-то готовый продукт, который можно будет потрогать. А, а вот само тестирование, сам тестинг, он как бы совместно является частью вот QC, да, как я уже написала в принципе, и выполняется одновременно тоже на этапе тестирования.

Но здесь у нас главная задача протестировать продукт уже на конечном наборе тестов, которые у нас будут. И, как правило, если читать теорию, если смотреть какие-то даже заграничные материалы, скажем так, у нас и тестировщики тоже должны разделяться на эти три уровня. Вот.

И получается, э, каждый из за каждый из этих уровней должен отвечать определённый человек. У нас должен быть тестнженер, должен быть QFC инженер, должен быть QA инженер. Но по факту на практике я бы не сказала, что есть какое-то разделение именно в работе.

Но тем не менее мы всё равно давайте проговорим, кто отвечает за какие этапы и что он будет делать. А тест-инженер, он же в принципе тестер, он же тестировщик, будет создавать и проходить тесткейсы, выявлять, локализировать баги, будет работать, да, вместе с QC на этапе уже как раз-таки тестирования, когда у нас будет готовый продукт. Я бы сказала так, что это даже по сути человек, который без опыта в тестировании приходит на свою первую работу, потому что ему особо много задач и не дают.

А когда мы уже переходим на этап QC, когда мы становимся как раз-таки QC инженером, он же может быть ещё и тестлит, а тут мы уже начинаем как раз-таки тоже стап тестирования, но здесь мы уже будем а на нас будет уже больше обязанностей лежать, и мы будем выявлять недостатки продукта после разработки. Здесь уже конкретно будет работа тоже с требованиями. Э, мы будем не только локализировать, да, там дефекты, которые мо, возможно, нам придут откуда-то, но и сами полностью изучать проект, даже без написанных тестейсов, основысь на каком-то своём предыдущем опыте.

А, и можем параллельно также ещё и писать документацию. Мм, а QA - это человек, который уже будет стоять немножечко уровнем выше. Его главная задача будет не только э отвечать за качество продукта, но и прорабатывать именно процессы разработки и тестирования.

Можно сказать, что это будет, в принципе, это должен быть человек, который уже управляет людьми, который управляет теми же QC и то есть тестировщиками. Ну, как я уже сказала выше, да, по факту QA QA инженер - это человек, который в себе совмещает именно вот этих вот три роли и в большинстве случаев начинает свою работу как раз-таки от этапа анализа требованиям и заканчивает уже проработкой, там, поддержкой и тестированием и всем остальным. То есть полностью работает на всех этапах жизненного цикла разработки.

Вот. А кроме этого, мм, так как у нас QA - это всё-таки человек, который отвечает за процессы разработки, нам следует более подробно поговорить о жизненном цикле именно тестирования. А я думаю, картинку многие ещё с вчерашнего вечера видели, да, с прошлого занятия, а, но мы особо не задерживались.

В общем, основные этапы тестирования программного обеспечения. Как это вообще всё взаимосвязано с жизненным циклом разработки? А когда мы говорим о жизненном цикле разработки, вспоминаем, что у нас есть этап тестирования.

И вот этот этап тестирования в себе несёт ещё вот этих вот семь этапов, да, семь шагов, которые нам необходимо выполнить во время этого тестирования. А если мы возьмём разработку по методологии, например, терфла, когда у нас каждый этап будет идти один за другим, вот мы у нас появилась идея, мы проработали требования, уже там сделали весь дизайн, сделали, разработали сам продукт, и после этого у нас как раз-таки наступает этап вот тестирования. Здесь, когда мы приходим на этап тестирования, мы тоже начинаем с анализа требований, потому что нам необходимо изучить, как работает продукт, посмотреть, что мы будем тестировать, выделить критические сценарии, проработать всё, что нам необходимо будет тестировать на этом этапе.

После этого, после того, как мы уже изучили требования, мы составляем план тестирования. А здесь мы прописываем, что будет тестироваться, определяем, какие цели у нас есть, определяем объём, ресурсы, которые нам необходимы. Возможно, нам потребуется больше людей, возможно, потребуется какой какая-нибудь инфраструктура, а даже банальное железо, да, возможно, наш компьютер, который там у тебя есть, на котором ты работаешь, он не потянет.

Поэтому там, возможно, требуется запросить новый. Это всё прописывается в тестплане. Это всё прорабатывается во время планирования тестирования.

А после того, как мы это всё прорабатывали, проработали, оценили риски, которые могут возникнуть во время тестирования, сформировали расписание, в какой последовательности, какие фичим, какие функционали мы будем проверять, какие-то скейсы проводить. Мы приступаем к написанию тестовой документации. Здесь уже полностью прорабатываются сценарии, по которые будем тестироваться.

Мы пишем тесткейсы, чек-листы, э прописываем последовательность действий для проверки, мм, то есть мы полностью должны на этом этапе структурировать процесс тестирования и охватить все возможные сценарии, которые у нас будут. А после этого мы приступаем к настройке тестовой среды. А тут я уже, по-моему, в прошлый раз тоже немножко говорила о том, что есть два момента, как мы можем эту тестовую среду настраивать.

Либо сами, либо нам это делает кто-то из команды, либо разработчики, либо стопs, девопсы. Вот. То есть получается, мы должны подготовить наше окружение к максимально приближённым пользовательским условиям.

Если у нас есть какое-то требование, что у пользователя, к примеру, для проведения там тесткейса должно быть, э, пять заявок на аккаунте, значит, до этапа тестирования мы должны создать какой-то определённый аккаунт, в котором будет пять заявок. И так по всем тесткейсам, которые нам необходим. То есть полностью подготавливаем для себя тестовую среду, подготавливаем для себя тестовые данные.

А после этого мы проводим выполняем тест, да, проведение теста по подготовленным сценариям с подготовленными тестами данными. А как только мы закончили этот процесс, как только мы закончили выполнять тесты, у нас как раз-таки наступает этап анализа, э, результатов прогонов и подготовки отчётности. Что мы здесь делаем?

Если мы нашли какие-то баги, мы, соответственно, заводим э отчёты о найденных дефектах, да, отчёты о найденных багах. Мм, после этого, после того, как их уже, получается, разработчики исправят, пофиксят, а мы их перепроверяем. И после этого можем написать, что проект готов к запуску либо не готов к запуску.

Если, э, если проект готов к запуску, по сути, мы переходим к последнему этапу - это завершение тестирования, где у нас формируется готовый отчёт, проводится итог готовности продукта. Ещё раз, да, допустим, вот мы, у нас было 10 найдено ошибок, пять из них критических, там два таких вот не очень, и там три ещё вообще ни на что особо не влияющие, просто какие-то минорные, да, так называемые ошибки, совсем-совсем неважные. А мы это всё обязательно указываем в готовом отчёте и передаём эту эту отчётность нашему непосредственному заказчику.

И тут может быть принято решение. То есть мы должны в нашем отчёте о проведённом тестировании указать нашу как бы рецензию, готов ли, по нашему мнению продукт к запуску. Если не готов, мы так прямо пишем, мы не можем там, допустим, выпустить, потому что у нас там найдено пять ошибок очень критических там и тд и тп.

И там не предполагается возможность, допустим, в ближайшее время это исправить. А и но всё равно конечную, э, конечное слово, да, скажем так, остаётся за владельцем, остаётся за оунером проекта, который скажет: "Нет, всё равно мы можем, нам срочно нужно, срочно, срочно с горящими глазами, нам срочно нужно это всё сделать". А вот а о'кей.

Мм, так, дальше идём. А у нас ещё раз возвращаемся в самое начало, анализ требований. А чтобы мы могли дать какую-то оценку, мы все должны знать, как наш проект работает.

Поэтому на каждом проекте должны быть, к сожалению, не всегда это так, требования. А что такое вообще требования в целом? Это описание того, какие функции должны какой какие функции должно выполнять приложение для решения нужной пользователю задач и соблюдением каких-либо определённых условий условий.

А что тут может быть? Тут может быть написано, как работает приложение, что нам нужно сделать для того, чтобы выполнить заказ. То есть требования могут быть, в принципе, несколько видов.

Они могут быть функциональные, могут быть нефункциональные. В функциональные относятся бизнес-требования. А что из себя представляют бизнест-требования?

А бизнес-трелеребования из себя представляют, как правило, это обычно документ, который отражает видение и желание заказчика, но и также выражают цели, ради которой разрабатывается продукт. А, как правило, бизнес-трелебования отвечает на вопросы, зачем нам нужен продукт, какая ожидаемая польза от продукта и как бизнес либо заказчик будет получать прибыль от этого продукта. То есть, например, в бизнес-трелеребованиях может быть прописаны такие требования, как, например, необходимо создать продукт, который сможет менять цвет одежды при наведении камеры на человека, либо там нужно упросить механизм отправки приглашений сайта, либо нужно автоматизировать процесс доставки товара, э нужно автоматизировать процесс отправки писем, промокодов, ну, чего угодно.

То есть как бы сама идея и само вот это требование, что именно мы хотим сделать и какой должен у нас получиться продукт. А так сильно много про каждый из вет требования не буду рассказывать, но всё равно давайте ещё про пользовательские требования. использовательские требования.

Это по сути документ тоже документ, ну, не все будут как документы у нас. А, описывающие задачи, которые пользователь может выполнить с помощью разрабатываемого программного обеспечения. То есть тут описывается поведение системы, сценарии использования и функциональные и нефункциональные особенности системы.

А, то есть там, например, у нас может быть такое требование, как к примеру, чтобы подать заявку на участие в конкурсе, пользователь должен перейти в раздел там, к примеру, курсы и нажать на кнопку подать заявку. А при первом там заходим на страницу, у нас должно появляться окошко с городом, там с вопросом: "Это ваш город, например, да? То есть всё вот это будет описываться в в таких пользовательских требованиях.

А далее, если говорить о нефункциональных требованиях, то в системных требованиях у нас будут как раз-таки, ну, системные требования и ограничения в системе. Например, какая версия операционной системы, какой жёсткий диск, сколько памяти должно быть для этого. А в требованиях к документации.

Здесь у нас, кстати, может быть ещё описана, э, документация для пользователей, как пользоваться системой. В требованиях к дизайну может быть описаны там уже какие-либо пожелания заказчика, там, что, к примеру, дизайн нашей системы должен быть в цветах нашей корпоративной как бы формы, да? А вот требование к эксплуатации, как у нас должно быть должно работать приложение, как ими должно быть, как ими должны пользоваться пользователи.

Скороговорка. Вот. И давайте ещё немножко поговорим о том, почему же всё-таки требования важны.

Потому что они, во-первых, нам позволяют понять, готова ли система к выпуску, да, как она работает, в каких условиях она будет работать. А мы можем с помощью требования оценить масштаб изменений, которые будут внесены в систему. А можем оценить насколько готова система, как её быстро разрабатывают, сколько осталось, да?

А также ещё у нас бывает очень часто, мм, я, конечно, написала про конфликты между тестировщиком и разработчиком, но это скорее могут быть недопонимания, а в том плане, что, к примеру, вот вы думаете, что вы нашли какую-то ошибку в работе системы, да? А пришли к разработчику, разработчик вам говорит, что это не ошибка, это такое требование, так система должна работать. И вот, чтобы вот эти вот недопонимания разрешить, вы можете обратиться к требованиям, посмотреть, как там это работает, и уже понять, кто прав, а кто не прав.

А, но когда, конечно, у нас бывают такие моменты, что требований просто нет на проекте и все так называемые требования остаются у разработчиков, потому что они всё это написали, да, либо у разработчиков в голове, либо на каком-нибудь дизайн-макете, тут, конечно, намного сложнее, но в таком случае, чтобы разрешить такие ситуации, вам необходимо обращаться к людям, которые, скажем так, стоят выше вас. То есть это будет либолит, а, либо, возможно, менеджер какой-то проекта. А если есть аналитик, то можно, конечно, обращаться к аналитику и говорить о том, что, уважаемый аналитик, вот вы такой молодец, вы разработали, вы принесли нам задачку, но вы это не прописали в требованиях.

Почему это так? У нас запаздывают требования, либо это какая-то задача неправильная. То есть вот такие моменты тоже очень часто бывают на проектах.

Это реальная жизнь. Вот. А давайте перейдём дальше.

Э, я здесь тоже, да, привела немножко ещё примеры требований. А, наверное, сильно много заострять внимания на этом тоже не будем. можно будет попозже это всё посмотреть, почитать.

Вот. И так как мы, как тестировщики, должны тестировать, да, требования, как бы это не звучало, но тем не менее у нас мы же должны их тестировать по каким-то определённым критериям. Поэтому у нас есть э некоторые атрибуты, так называемые требованиях, по которым мы можем их проверять.

То есть каждое требование у нас должно соблюдаться, соблюдать хотя бы одно, а лучше все из вот этих вот атрибутов. То есть у нас требования должны быть атомарные. Что это значит?

Что у нас одно требование должно описывать только одну ситуацию, только одну фичу. А, к примеру, если мы говорим о том, что кнопка, э, должна с помощью кнопки IT мы должны авторизоваться, а, при там открытии формочки авторизации, то эта же кнопка, она не может нам отправлять какие-либо, не знаю, там, имейлы, не относящиеся к авторизации в этот момент. А так, непротиворечивость не должно быть внутренних противоречий другим требованиям.

То есть, да, у нас получается, если у нас говорится о том, что у нас есть функция, которая у нас вот тут вот я, конечно, примеров вам не особо привела, но тем не менее, а если у нас есть требование, которое говорится, говорит о том, что у нас в одном месте написано, что а опять же кнопка выполняет какое-либо действие, то в другом месте у нас не должно быть написано, что эта кнопка будет выполшеть другое. Недвусмысленность написана без распочатых формулировок и есть только одно понимание. О'кей.

Корректность функциональности описывается чётко и корректно. А если мы про полноту говорим, то каждое требование содержит всю информацию, необходимую для разработки. То есть, если ты читаешь какое-то требование к функциональности, у тебя не должно возникать 15 вопросов, из-за которых ты потом каждый раз пойдёшь.

Аналитика спрашивает: "А что ты имел в виду здесь? А что ты имел в виду там? " Далее, проверяемость.

Требования сформулировано так, чтобы была только однозначная проверка. Приоритетность представляет собой количественную оценку важности требования. А очень часто у нас бывает такое, что у нас требования написаны просто в одном как бы файлике, да, просто текстом, полотном, и у нас нету никаких разграничений.

Здесь говорится, в приоритетности говорится о том, что у нас должны быть приоритеты, что к примеру авторизацию мы должны должен быть более высокий приоритет, а нежели, например, исправление пользовательских данных в мм настройках кабинета. А вот потому что если у нас все требования будут одного уровня, например, там, да, что какой-нибудь там с, например, у нас будет приоритет высокий, средний, низкий, если у нас все требования будут низкого приоритета, либо среднего приоритета, либо одинаково высокий, мы не будем знать, что нам необходимо первое брать в разработку и первое брать в тестирование. А тут, по сути, точно так же самое с прослеживающ.

У каждого требования должен быть уникальный идентификатор. А, то есть просто, грубо говоря, у нас должна быть нумерация м, например, там от одного, там, не знаю, до 100, да? Чтобы мы могли ссылаться на конкретный идентификатор и не искали в вот этом вот большом-большом файлике, в большом документе какой-то определённый мзац с этим требованием.

Аа так, да, в принципе, тестирование требований. Ещё момент такой, а я бы сказала, здесь просто, наверное, самый-самый большой и главный пункт и главное правило - это то, что мы во время тестирования требования должны ставить себя на место пользователя, смотреть со стороны пользователя, насколько нам это будет удобно работать с этим приложением. Если вот, например, мы столкнёмся с каким-то, а, с какой-то ошибкой, сможем ли мы это как-то обойти, а, либо сможем ли куда мы будем это обращаться.

В общем, всё как реальный пользователь нашего продукта. Дальше, э, что ещё, какие у нас могут быть принципы? Это то, что требования лучше тестировать до разработки.

Протестировать требования могут как аналитики, так и тестировщики. То есть мы можем либо совместно с аналитиками тестировать, либо мы можем сначала сами прочитать, протестировать, проверить как раз-таки на вот эти вот атрибуты качества наших требований и после этого пойти со всеми вопросами, которые у нас возникли, пойти к аналитику и обсудить с ним, а что же не так пошло. Выявление дефектов по документации ничем не отличается от выявления дефектов по продукту.

А, да, здесь почему в такой формулировке? По сути, оно немножко совпадает с тем, что написано в первом пункте. Если мы будем тестировать требования до разработки, да, это будет по сути то же самое, если вдруг мы будем выявлять дефекты по продукту, потому что мы всё равно тестировать готовый продукт будем по каким-то критериям, по каким-то требованиям.

А если проверка требований идёт параллельно с разработкой, важно овещать разработчиков о найденных ошибках. Тут скорее будет больше относиться, если мы будем работать по аджайлу, если мы будем работать по скраму, когда у нас очень часто, что все требования появляются как раз-таки непосредственно перед разработкой, непосредственно перед спринтом. И если мы находим какие-то ошибки, мы пойдём опять же к аналитику, да, либо к тому, кто у нас в принципе так называемый держатель этих требований, уточним у них эти вопросы.

Он скажет, например, да, знаешь, а вот ты прав, тут у нас надо было так, вот так вот, я пойду там уточню у заказчика. Возвращается с ответом от заказчика, говорит, что вот мы там решили сделать немного по-другому, вот так, вот так, вот так. А разработчик уже, э, занимается этой задачей, но он, допустим, только недавно взял эту задачу разработку, он не знает, что там происходит с этими требованиями, потому что у него прописаны в задаче старые требования.

И вот тут вот нужно обязательно разработчика э оповестить о каких-либо изменениях, потому что если он всё равно это сделает по старым, нам в любом случае придётся с ним потом переделывать, придётся заводить багрепорты, придётся это всё править, и это будет опять же двойная работа и твоё время, и время разработчика. А и вот я вам ещё много раз говорила про баг, баг, баг, что такое баг, да, про баг-репорты, как раз-таки один из последних моментов, что такое, в принципе, баг, в чём он заключается. Это как раз-таки ошибка в программном обеспечении, которая приводит клонению фактического поведения программы от ожидаемого.

Ожидание в мои, ожидаемое поведение программы мы как раз-таки можем взять из наших требований. А я тут привела ещё вам небольшой такой момент. Это жизненный цикл бага.

А как он проходит? То есть вот у нас, допустим, разработался новый продукт, мы его протестировали, вот мы обнаружили а этот баг, то есть мы воспроизвели ошибку. После этого нам обязательно необходимо её задокументировать, описать шаги, описать ожидаемые результаты, описать фактические результаты, приложить скриншоты.

Это тоже про то, как заводить бакрепорты, какие у нас обязательные поля должны быть, мы обсудим на следующем созвони с вами, но тоже тут хорошо. То есть мы заводим бакрепорт, отправляем её в систему, в которой у нас хранятся все карточки, где у нас ведётся разработка. Это может быть G, может быть Testril, может быть трек, может быть, ээ, что ещё там, короче, может быть много чего.

Сейчас из-за того, что у нас особо множество проектов, множество, точнее, компаний ушло и множество платформ, может быть, всё что угодно, даже какая-то внутренняя система. А после того, как мы его задокументировали, мы передали его на доработку, на исправление. В этот момент разработчик у нас устраняет дефект.

После этого нам обязательно необходимо провести повторное тестирование. А, то есть мы проверяем, что там баг устранён, что всё работает корректно. Аэ, здесь единственное я вам немножко не дорисовала, не не допоказала разветвления.

Какие здесь могут быть ещё разветления в жизненном цикле бага? После того, как мы повторно его протестировали, после того, как мы сказали, что всё, бак у нас закрывае, баг у нас устранён, его больше нет, то есть он может перейти в следующий этап - это закрытый. Но вот тут может быть такое разветление, когда мы его задокументировали, передали на исправление, разработчик может нам его вернуть в статус, допустим, там, как он называется, это prodюс.

Невозможно воспроизвести. Воспроизвести может быть невозможно по нескольким моментам. А это такой момент, что у нас не воспроизводится, потому что мы неправильно описали шаги воспроизведения, а, и нам необходимо перепроверить и опять направить его на исправление.

А либо мы, либо разработчик мог нам вернуть этот же баг с пометкой, что это не баг, а фича. Ну, то есть как раз-таки, что это не ошибка, а это такой новый функционал, но он просто не был отражён в требованиях. А, ну и в принципе ещё одно из состояний баг репорта, да, этого дефекта, то, что он может быть просто закрыт после того, как он был документирован.

А почему он может быть закрыт? Либо он очень долго лежал и ждал исправления, и в этот момент он был просто с какой-то новой функциональностью исправлен и завезён уже, а, на стенды либо вообще там уже на на продакшене, да, лежит на у пользователей. Из-за этого уже мы его можем закрыть.

Э, либо у нас поменялись какие-то приоритеты, и это всё-таки там стало не багом, а фич моменты тоже бывают. Если хочешь получать эксклюзивные контент и быть в курсе новых видео, загляни ко мне на бусте. сами регулярно выкладываю новые ролики, которые не всегда выходят на YouTube.

Также у нас есть закрытые чаты, где можно общаться, задавать вопросы и делиться идеями. Поддержи мой канал и стань частью нашего дружного сообщества. Ссылка в описании.