[0:00]Привет, у нас снова урок по тестированию ПО, и это будет одна из самых важных тем в тестировании. А в теории тестирования это тестирование требований. Почему самое важное? Здесь есть несколько моментов. А мы с вами проходили этапы требований, ну и вообще этапы разработки, и требования были, по сути, в самом начале. Это тот этап, на котором, если допустить вдруг ошибку, то её легко исправить, но если на этом этапе её и найти. Если уже, скажем, пропустить какую-то ошибку на этапе требований, она пойдёт на новый этап, на следующий, исправить её уже потребуется больше сил, больше времени, ну и, соответственно, дороже. И с каждым новым этапом это всё дороже и тяжелее. То есть этап требований — это тот самый этап, когда стоит всё предусмотреть, и на него нужно довольно сильно сконцентрировать своё внимание. Это первый момент, почему это важно. Второй момент, почему это важно. А напомню, мы говорили с вами о том, что тестировщик в своей работе, по сути, делает там при тестировании. Что он делает? Он сравнивает фактический результат с ожидаемым результатом. И если фактически мы видим, то ожидаемый — это и есть требования, да, то есть, это и есть те самые требования, про которые мы сейчас будем говорить, то есть это, ну, основополагающая вещь, по сути. И мало того, что их нужно протестировать, их нужно понимать, поэтому именно о требованиях мы сейчас и будем говорить. Сейчас на экране у меня разбитие идёт на прямые и косвенные. Я его вынес в самое начало по той причине, что про такую классификацию все забывают. И книги, и графики. Пытался посмотреть, где же там ещё осталась эта классификация. Почему-то нигде не встречается. Про что здесь идёт речь? А бывают требования прямые, которые явно указаны, и явно прописаны, а бывают косвенные, которые явно не указаны, и явно не прописаны. Но так должно быть. А пример, давайте, допустим, ссылка, да, то есть, вы открываете сайт, там есть какая-то ссылка. И если вы нажимаете на эту ссылку, вы как бы понимаете, что что-то должно открыться. Вам не нужно говорить об этом, вы не будете думать о том, что, ну, может быть, и не откроется что-нибудь, да? Вы понимаете, что это прямо точно должно произойти, поэтому писать о том, что по нажатию на ссылку должно произойти открытие, как бы не нужно. Это косвенное требование. Здесь должно быть другое прямое требование о том, что должно открыться. Ну, по нажатию на эту ссылку должно открыться что-то, но именно не должно стоять вопроса, что что-то вообще должно открыться, это косвенное требование вообще, в принципе, к ссылке как таковой. Пример тот же, не знаю, крестик, да, то есть, а при нажатии на крестик должен закрыться окно. Должно оно закрыться, и ничего другого происходить не должно, и это прямо вот так должно быть, вот просто без апелляционно, это тоже пример косвенного требования. О'кей. Давайте оставим это в покое и пойдём дальше по классификацию, которую, которую вы чаще всего встретите, и по которой вам могут задавать вопросы. А вот она. Требования делятся на два типа: функциональные требования и нефункциональные требования. Вот эта классификация, по сути, это типы требований. А дальше они, в свою очередь, тоже разделяются, как вы видите, функциональные вот на вот эти вот три вещи. А функциональные, да. Ну и нефункциональные, соответственно, вот здесь приведены у меня буквально пару примеров. А тут нужно ещё понимать, что есть такая тема, как уровни требований, и фактически уровни требований - это то, что входит в функциональные требования. А поэтому мы сейчас об этом поговорим отдельно. Давайте сначала про нефункциональные. Что есть нефункциональные требования? По сути, это описание. Я здесь привёл пример по производительности. Это не относится непосредственно к функционалу, но это тоже может быть описано. Например, я написал интерфей работы, но я имел в виду интерфейсы работы.
[4:20]Сы работы. Что я имел в виду? Ну, например, а передача данных может происходить по протоколу REST или по протоколу SOAP, или ещё по какому-то интерфейсу взаимодействия программ. Мы с вами эти темы ещё не проходили, можно на другом примере даже брать не интерфейсы работы, например, а нефункциональное требование - это платформа, на которой должен работать продукт. Например, только для Айфонов, только для Андроидов или и то, и то должно быть, то есть платформа, на которой мы работаем, это нефункциональное требование, да, то есть вот такие вещи, они относятся сюда. Дальше давайте поговорим про функциональные. Это то, с чем тестировщик больше будет иметь работу, потому что, ну, откровенно говоря, прямо нефункциональщиной, ну, ну частично. О'кей, частично здесь работа тоже будет проводиться. А в зависимости от квалификации и, может быть, специфики работы тестировщика. Но большая часть всё-таки будет именно здесь. Функциональные требования делятся, по сути, на три уровня: это бизнес-требования, требования пользователей и непосредственно функциональные требования. Как их различать, как их понимать? А то, что они у меня немножко так не вровень стоят, это просто случайность, так, в этом нету глубокого смысла. О'кей, бизнес-требования. А они подразумевают требования со стороны бизнеса. Ну, например, требования со стороны бизнеса может быть, а, необходимо увеличить скорость обработки заявки в два раза. Да, то есть именно какие-то бизнес-процессы необходимо решить, вот это бизнес-требования.
[6:07]Требования пользователей. Например, а при первом посещении там, при первом входе, мм, пользователю должен должно отобразиться пользовательское соглашение, или должно отобразиться согласие а на использование куки.
[6:25]То, что относится именно на пользователя. Функциональные требования. Это уже, а, немножко про другое, это уже про то, как должна работать функция. Ну, не знаю, там, например, а пользователя можно там обновить, отредактировать, удалить, добавить, да, то есть именно работа с функционалом. То есть вот таких три уровня требований, с которыми вы будете сталкиваться. Давайте пойдём дальше. Источники требований. Пожалуй, самая интересная тема, можно её так назвать. Почему интересная? Потому что забывается, а в работе это важно. Почему важно? А вы можете ожидать, что вы, когда придёте на работу, у вас будут расписаны спецификации того, что и как должно быть, но так бывает далеко не всегда. Более того, есть проекты, на которых прям нету спецификации. Там даже в вакансиях пишут: опыт работы с там с проектами без документации, да, там то есть есть такая особенность. Так откуда брать вообще требования, если конкретных прописанных нету? И вот это вам та самая подсказка, откуда это берётся. Это источники. А давайте пройдёмся по ним. Первый источник - это непосредственно ваш заказчик. Пример: идёте, скажем так, на интервью с заказчиком, общаетесь с ним, спрашиваете, что ему надо, что он хочет, как это должно выглядеть, то есть ваш заказчик и есть ваш источник требований. О'кей. А второй - мозговой штурм, соответственно. Садится команда и устраивает этот самый мозговой штурм, как и что должно быть. Почему бы и нет? Не всегда есть заказчик, бывает, вы сами есть продуктовая команда, вы решаете, что нужно делать, или у вас есть там, не знаю, ответственный продуктов не знает, что нужно сделать, команда должна сесть и придумать. Супер. Это тоже источник придумать требования. Документы - фактически это документы. Ну, это здесь под документами я имею в виду реальные документы, спецификации, правила, нормы, ну не нормы, нормы это отдельно. Конкретную документацию, спецификацию, из которой вы берёте просто и вычитываете то, что необходимо. Это, в принципе, прекрасный источник требований, мой любимый. Фокус-группа. Подразумевается, что вы можете собрать свою целевую аудиторию, немного человек, два, три, пять, десять в одно помещение, и пообщаться с этой фокус-группой. Именно вопросами спросить что-то, что подтолкнёт именно на то, каким должен быть продукт. Естественно, это проводится специально обученным человеком, это очень важно. Следующее - наблюдение. Ну, так уж получилось, что можно просто понаблюдать за кем-то или за чем-то, и понять, что необходимо. Ну, примеры излишни. Моделирование. Интересный способ, про который забывают довольно часто. Допустим, вы не знаете, а, как что-то, а, не знаю, вы хотите, предположим, создать игру, предположим, симулятор чего-то, не знаю, готовки. Почему бы не смоделировать своё поведение или кого-то на кухне, и по этому поведению прописать требования того, что должно быть реализовано в продукте. Понимаете идею? Моделирование. Следующее - анкетирование. Подразумевается, что анкетирование проводится на большую группу людей, и на основании этих анкет выводится статистические данные, по которым уже и составляются требования. Многие не любят, не любят анкетирование, потому что считают его а, ну, не показательным, и много, особенно американских проектов, которые строились на анкетировании, просто не, а, ну, как не поплыли, не побежали.
[10:33]Не знаю даже что сказать. Прототип. Похож чем-то на моделирование, но есть своя идея. Вы не знаете, как должен выглядеть готовый продукт, вам нужно ещё это придумать, додумать, вы делаете прототип небольшой этого продукта, и пробуете его. Ваш прототип является вашим источником требований уже для создания итогового продукта. Это первый вариант работы с прототипом. Второй вариант работы с прототипом, как с макетом. Ну, например, вы хотите сделать сайт, но вы ещё не знаете, как он должен выглядеть, вы рисуете его там кружочками-квадратиками, и, в общем-то, как прототип, смотрите, а, вам становится нагляднее, и вы уже сможете сказать там: а, ну, что-то там убрать, поправить, поменять и так далее. О'кей. А, описание. Описание фактически является, а, тем источником, когда вы сами садитесь и прописываете требования на основании чего-то. На основании интервью заказчика, на основании какой-то другой полученной вами информации, где-то додумывая сами, анализируя сами что-то, вы пишете, что, а, требования, да, и уже это описание становится основным источником, по которому вы работаете. Нормы. А, специфический источник, здесь имеется в виду, что при работе с разными продуктами, в разных сферах, а, можно нарваться на то, что есть нормы законодательства, которые регулируют определённую деятельность. И эти нормы становятся источником для требований. Ну, например, там нормы законодательства заставляют или там принуждают к тому, чтобы в случае там продажи, не знаю, алкогольной, например, продукции, у вас были отметки о том, что вам 18+. Это ваш источник требования, это должно быть, вы это знаете, да?
[12:25]О'кей. А, следующий источник, тот самый, который чаще всего станет действительно основным источником, если у вас нету реальной спецификации - конкуренты.
[13:13]Посмотрели у конкурентов, сделали так же. Ну, в общем-то, то и всё. В этом и заключается источник этот, который почему-то забывается, но фактически является основным, если у вас нету реальной спецификации, по которой можно работать.
[13:34]Отлично. Переходим к характеристикам требований. Мы с вами разобрались, какие есть источники, и вы получили своё самое требование. На самом деле, характеристики требований имеют отношение в основном уже к прописанным, конкретно прописанным требованиям, спецификаций, которую вы читаете и можете анализировать. А, и анализировать вам нужно на что-то, вам нужно по каким-то характеристикам сверяться. Вот именно по этим характеристикам и стоит свериться, да, то есть проверить, подходят ли требования или нет. Они здесь перечислены, давайте проговорим с примерами, что каждый из них означает. Завершённость. А, наверное, нужен пример с завершённостью. Самый очевидный - это, а, если где-то написано и так далее, или и тому подобное, это явно незавершённое требование. Ещё может быть, а, примером, а, информация передаётся в зашифрованном виде. В каком зашифрованном виде? Как её зашифровать? Непонятно. А, там размер экрана должен подходить под все устройства. Под какие все устройства? Под все телефоны, под все телевизоры, под под какие все устройства? Следующее - это непротиворечивость, и здесь есть две грани. Во-первых, непротиворечивость должна быть в одном требовании, во-вторых, непротиворечивость должна быть между требованиями, в принципе. Что можно встретить? А, да, про ту же самую кнопку Close, да, там в одном месте написано, что она должна быть красной, в другом месте написано, что она должна быть прозрачной почему-то. А требования противоречат друг другу, фактически друг друга исключают, не пойдёт, такое быть не должно, это требование об этом. Корректность.
[16:04]А здесь имеется в виду и, мм, ваша грамотность, в том числе, и не только грамотность, здесь ещё речь идёт про, мм, корректностью можно многие вещи обозвать, да. А, что будет явным нарушением корректности? Например, если требование, которое прописано, оно относится не к программе, а к пользователю. Явный пример - это будет пользователь должен иметь возможность отправить сообщение. Ну, как бы, ну как пользователь должен иметь возможность отправить сообщение? Пользователь не должен. Это вы не делаете требования к пользователю, то есть, некорректно делать требования к пользователю. Требование должно быть к программе. О'кей. Недвусмысленность. А примером недвусмысленности - это такие, когда в требования используются фразы или слова, которые могут быть субъективно поняты разными людьми. Например, программа должна иметь возможность там передавать большие данные. Ну, какие большие данные, насколько большие, для кого какие? Ну, да, там, вот все такие вещи, типа там легко, большие, маленькие, то есть какие-то не конкретные, мм, уточнения, они приводят к недвусмысленности. Проверяемость. Здесь проще понять, потому что то, что вы просите в требованиях, нужно иметь возможность проверить. Если это вообще не проверяемо никоим образом, ну, как бы, очень странное требование, да. Атомарность. Речь идёт о том, что одно требование для одного действия. Не нужно объединять несколько требований в одно, это мешает очень и может создавать или порождать другие проблемы. Следующее - выполнимость. То есть то, что есть в требованиях, должно иметь возможность, ну, это должно быть возможно выполнить. Но речь даже не о том, что требование совершенно какое-то космическое, там, не знаю, из серии, а, что придумать, не знаю, программа должна позволять жить бесконечно. Ну, к примеру, да. А речь даже не об этом, речь о том, что, а, например, требование, мм, как бы правильно объяснить, давайте предположим, что то, что мы просим, слишком тяжело сделать, и это никому не нужно. Допустим, что сейчас у нас самое сложное? Это там VR-технологии, это возможность собрать информацию с, например, а, с, допустим, с пальцев, да. А и, например, подразумевается, что мы должны там собрать вот эту вот информацию с пальцев для того, чтобы в VR-ре напечатать текст. Ну, предположим, да.
[19:23]Но как бы у нас такие условия, что у нас игра, большая, какая-нибудь игра, не знаю, Counter-Strike, и у нас фактически там, не знаю, есть одна-единственная карта в контре, а в VR-ре, предположим, в которой вообще где-то нарисован какой-то компьютер, на котором вообще можно, по идее бы, набрать текст, но это вообще никак не относится к игровому процессу. Это очень сложно сделать, ну, достаточно сложно сделать, и это нафиг никому не нужно. Это, как сказать, критерий невыполнимости. Ну, ещё, если честно, и на адекватность, но здесь нет такого критерия. О'кей. А ну и следующий критерий - это обязательность. Вполне возможно, вы встретитесь с такими требованиями, где будет написано: Ну, можно сделать и вот это. Если будет время, то сделаем ещё и вот это. Вот если такие вещи есть, они просто удаляются и не делаются. Они даже не остаются в требованиях. Это не нужно, это не будет сделано, требование должно быть обязательно к исполнению. Отлично. Я надеюсь, что тема с требованиями вам довольно легко далась, она не сложная, но она довольно важная. И её не так сложно понять, как, может быть, сложно запомнить, что всё действительно нужно делать. Бывает сложно выбить на это время на проекте, но это прям надо уметь делать. Я рекомендую вам обязательно потренироваться. Я оставлю в описании под этим видео несколько примеров требований, которые нужно разобрать, и найти в них вот эти вот характеристики, которые неучтены, да, то есть на основании вот этих характеристик понять, где допущена ошибка в этих требованиях. В описании посмотрите, что ещё стоит сделать. Если ещё не подписаны на канал, подпишитесь на канал на Ютубе. Здесь бесплатно где-то раз в неделю, плюс-минус один день, а выходят видеоуроки по тестированию. Если вы устали ждать новых видео, есть подписка на бусти, где на несколько видео вперёд уже выложено. Записываю я видео быстрее, чем публикую на Ютубе, но публиковать на Ютубе так часто не могу из-за особенностей Ютуба. Ну, может быть, немножко ещё от желания заработать, поэтому, а, если есть желание смотреть все видео, которые у меня уже есть, то отправляйтесь на бусти, там подписка недорогая на месяц. Если не хотите платить, просто оставайтесь со мной на Ютубе и подписывайтесь на этот канал, чтобы новые видео, ну, не прошли мимо вас. Это необязательно. Если вам понравилось, просто ставьте лайк, и мне уже будет приятно. И не забывайте, вот найти в описании обязательно, а, требования, которые я оставил, и пробовать их разобрать, это будет такая практика очень полезная. Возможно, вас это не спросят на собеседовании, но в работе это то, что вам реально поможет работать. Ну, а на этом всё. Спасибо, пока.
