Наша тема - это тестовая документации. Э, так что сюда в тестовую документацию входит? У нас есть такие виды тестовой документации, как план тестирования, тестсы, чеклисты, багрепорты, отчёты о тестировании, тестовые данные тоже можно сюда отнести и матрица прослежимости требований.
По сути, это матрица трассируемости, о которой мы говорили на прошлом занятии. Давайте начнём с того, что такое тест-план. А тест-план у нас как раз-таки описывает весь объём работ по тестированию, начиная с описания объекта, стратегии, расписания критериев начала и окончания тестирования, специфических заданий, а также оценки рисков с вариантами их решения.
А что у нас должно включаться в тест-план? У нас обязательно должен быть объект тестирования, что нам нужно будет протестировать, а список функций, список тест-кейсов, которыми мы будем проводить это тестирование, а также расписание, когда мы будем тестировать, плюс критерии начала и окончания тестирования. Также, если мы говорим, в принципе, о документе как таковом, который у нас выступает одним из самых главных на этапе тестирования программы, программного обеспечения, а то он должен в себя ещё включать и, э, сколько у нас необходимо будет тестировщиков.
Возможно, нам необходимо будет привлечь дополнительные силы плюс даже вплоть до того, что там будет написано то, какое железо нам необходимое для проведения тестирования. Но на, как правило, на практике мы встречаемся с тем, что тест-планы у нас оставляются не в формате документа, а в формате просто перечня тесткейсов, которые будут проверяться, допустим, во время регресса. Мм, что это такое, как это выглядит, я покажу немножко позже.
Плюс я вам записала уже небольшое видео как раз-таки на эту тему. А, дополнительно тоже выложу в чатик, посмотрите. Вот.
А получается, так как у нас в тестовом плане не должно быть м должны быть наши стратегии, как мы будем тестировать, да, соответственно, виды тестирования там и всё остальное, чем мы будем тестировать систему, а мы обязательно пишем тесткейсы на функционал. А что такое тесткейс? Тесткейс - это, по сути, совокупность вводимых значений, ожидаемых результатов и условий, а в которых программа должна выполняться с целью проверки соответствия требований.
А что здесь должны мы писать в тесткейсе? Во-первых, у нас один тесткейс, одним тесткейсом проверяется только одна конкретная вещь, только одна конкретная функциональность. А желательно, и чаще всего у нас тест-кейсы не зависят друг от друга.
То есть один тесткейс - это одна самостоятельная проверка. А что у нас обязательно должно быть в тесткейсе? Это ID тесткейсы, то есть либо числовой номер проверки, либо же может быть название тесткейса в зависимости от того, как у вас называется проект.
Например, если у вас проект связан там с какими-нибудь товарами либо услугами, это может быть там, например, Goods и сш там 1 2 3 4 5, к примеру, номер. А после этого мы обязательно указываем название проверки. А отдельно про название, как лучше их писать, тоже расскажу чуть позже.
Предусловия здесь это такой такой пункт на самом деле плавающий. они могут быть, могут не быть, но обычно в предусловиях у нас описывается действие, которые приводят в систему состояние пригодное для проведения тестирования. А, например, у нас тест-кейс может быть такой, что мы как бы сквозной в системе, когда нам необходимо будет пройти все шаги от начала, от авторизации, там, добавления товара в корзину, а, и выкуп, выкупа товара.
А может быть такое, что мы напишем в предусловиях, что нам необходимо быть под авторизацией, зайти как авторизованный пользователь с тремя товарами в корзине, к примеру. И уже вот с этого этапа у нас начинаются только шаги для того, как мы будем проходить тесткейс. То есть в предусловиях у нас есть авторизованный пользователь, у нас есть три три товара, а в шагах уже будет написано, что перейти в корзину, а нажать на кнопку перейти к оплате, оплатить товар, ну, к примеру, и пост условия.
Это уже получается описание действий, приводящих систему в исходное состояние. То есть, например, мы можем либо отменить нашу покупку, чтобы у нас, если это какие-то тестовые, да, там данные, например, мы можем отменить покупку, либо удалить товары из корзины, либо какие-то там, если мы поменяли в настройках имя, имя либо email, то мы после прохождения этого тесткейса должны вернуть нашу систему в исходное состояние. Про шаги я уже, в принципе, тоже сказала, да.
У нас должны быть чётко описаны шаги, которые нам необходимы для проведения этого тесткейса. И на каждый шаг у нас должен быть ожидаемый результат. А если хочешь получать эксклюзивный контент и быть в курсе новых видео, заклини ко мне на бусте.
Там я регулярно выкладываю новые ролики, которые не всегда выходят на YouTube. Также у нас есть закрытые чаты, где можно общаться, задавать вопросы и делиться идеями. Поддержи мой канал и стань частью нашего дружного сообщества.
Ссылка в описании. >> А, да. Ой, господи, как мелко он получился.
Сейчас, секунду, покажу по-другому. А я здесь вот вам как раз-таки хотела привести пример тест-кейса. Почему-то оно всё съехало.
Ну ладно. А, например, у нас есть такие требования, что, э, сам тестейс у нас добавление товара в корзину, там на детальной странице товара, а на странице товара у нас присутствует кнопка в корзину. Это пример одной из как раз-таки вот этих вот MS-систем, на которых работают на реальных проектах.
А здесь пример через QA. А что мы здесь пишем? Мы здесь, да, пишем название.
Мм, может быть, в принципе, практически оно любое. И, соответственно, здесь у нас шаги, а в поле дата у нас может быть тестовые данные. Например, если у нас здесь будет авторизоваться на сайте, мы здесь можем написать, какой у нас логин, какой пароль для того, чтобы мы авторизовались на сайте.
Ну и, как видно, на каждый шаг, на каждое действие у нас есть свой какой-то определённый ожидаемый результат. А так, пойдёмте дальше. Сейчас, секунду.
Следующее у нас виды тесткейсов. Как я уже, в принципе, тоже упоминала по поводу шагов. Если у нас на тесткейс, на каждый шаг тесткейса указывается ожидаемый результат, то такой тесткейс у нас будет относиться к низкоуровневым тесткейсам.
А то есть это что такое низкоуровневый тесткейс? Тесткейс с конкретными выходными данными, ждаемыми результатами, представляет собой полностью готовый к выполнению тесткейс. А если мы пишем тесткейсы, в которых у нас будет просто перечень проверок и, например, а будет ожидаемый результат только на одно либо на два действия, на самом деле это один из видов тескейсов, который чаще всего и пишется.
То есть вот такого низкоуровневое написание а очень редко встретишь на реальных проектах. В основном это можно сказать, что перечень проверок, которые объедин объединены общим смыслом. Вот.
Также у нас есть позитивные тесткейсы, которые используют только корректные данные, проверяют, что приложение правильно выполнило вызываемую функцию и негативные тесткейсы. Здесь мы уже вводим какие-то негативные проверки, делаем. Целью у нас будет как раз-таки сломать нашу валидацию, например.
Угу. Дальше чего у нас? М, да, рока.
>> А, получается, хакеры - это, можно сказать, не тестировщики негативных тесткейсов. Нет, почему? Цель-то хакерских атак - это не сломать вообще, в принципе, систему, заполучить данные и всё остальное.
Здесь же мы должны, в принципе, проверить с помощью как корректных, так и некорректных данных нашу систему на как раз-таки на ошибки. Э, например, у нас может быть такой случай, что, мм, у нас в требованиях говорится о том, что поле email у нас не воспринимает там, не знаю, например, либо числа, да, а ты, ну, вне имейла, например, что там не должно быть цифр цифровые, там подряд, не знаю, там, например, пять или восемь штук там, ну, около десяти, а, как обычные номера. Но если ты введёшь полностью номер телефона, например, и валидный пароль, он может авторизоваться.
Если в требованиях говорится о том, что мы можем авторизоваться только с помощью а имейла, значит, мы должны авторизовываться только с с помощью имейла. И вот как раз-таки негативная проверка, негативный тестейс будет в том, что мы введём туда просто номер телефона. Вот.
Всё-таки хакерские атаки - это немножко другое, да. >> Вот. О'кей, продолжаем дальше.
Э, чего у нас не должно быть в тесткейсе? как раз-таки то, что я уже говорила, в зависимости от других тесткейсов, а нечёткой формулировки шагов или ждаемого результата. Мы чётко, при прочтении тесткейса мы должны чётко понимать, что нам необходимо сделать.
А потом отсутствие необходимой для прохождения тесткейса информации. А как бы наш тестирововщик, да, и в целом мы тоже не должны бегать потом искать, где-то её вычитывать. Всё должно быть сразу написано в нашем тестейсе, если у нас какие-то есть вводные данные, например, или нам необходимо какие-то специфические штуки выполнить.
не должно быть излишней детализации. И забыточная информация затрудняет прохождение тесткейса. Также не должно быть абстрактного названия.
То есть мы не можем назвать наш тесткейс просто добавление товара в корзину. Нам необходимо обязательно детализировать, что именно мы должны сделать, на какой странице, например, да, если у нас есть какое-то модальное окно, то мы должны написать, что добавление товара в корзину, там, например, на главной странице через там быструю корзину либо через модальное окно добавление товара. Да, у кого-то тут рука, да.
Алекс, >> а скажи, пожалуйста, а что понимать по избыточной информации? А избыточная информация, например, если опять же давай возвращаться к тем же шагам, у нас бывает такое, что мы можем описывать прямо вообще чуть ли не каждую строчку, не каждый прямо подшаг, да, потому что я видела часто примеры таких тесткейсов, когда пишут, например, зайти на главную страницу, а проверить, что у нас отображаются там, не знаю, там 10 товаров, например, на главной странице, потом следующий выбрать товар, находящийся в пятом там в списке. После этого кликнуть на этот товар, потом следующий шаг проверить, что у нас отобразилось именно это название, и вот так вот так далее.
По сути, ты можешь просто написать, что открыть сайт, а добавить товар в корзину, потому что чаще всего тебе не будет важно, какой именно товар у тебя будет добавлен в корзину. Э, там нажать на кнопку добавить в корзину перейти в корзину, проверить, что добавленный товар отображается в корзине. Вместо там пятнадцати шагов у тебя условно получается четыре.
Вот. Хорошо, спасибо. >> Угу.
И последний пункт - это по сути повеличного наклонения. То есть не должно быть сделать, написать, проверить. Сделаешь, точнее, даже просто должно бы сделать, написать, проверить, посмотреть и так далее.
А так идём дальше. М, так у меня слетели все картинки, к сожалению. Сейчас будем сразу восстанавливать.
Так, что такое тест сюты? Тест сюты - это, по сути, набор тесткейсов, которые у нас относятся к одному тестировому модулю, к одной функциональности, к при одному и тому же приоритету или одному типу тестированию. М каждый тест состоит из более чем одного тесткейса, зачастую выполняется всей пачкой в процессе тестирования.
А что мы здесь видим на этой картинке? Как раз-таки я тут вам приложила пример тест сютов. М, например, у нас есть, э, сюты, точнее, есть тесткейсы, которые у нас относятся к блоку авторизации.
По сути, сюты - это как бы папочка, можно сказать так, в которой у нас будут храниться все наши проверки. Всё, что относится к авторизации, в авторизации. Всё, что относится к корзине, будет корзине.
Всё, что относится к там в данном случае к проекту, будет в папочке проекты. И, соответственно, да, как тут говорится, чаще всего у нас, а, при проведении тестирования, при проведении регресса либо смоука мы берём всё, что находится в этом сюте. Берём просто всю папку и её, соответственно, тестируем.
Аа далее переходим к чек-листам. Э-э, в чём на самом деле здесь такое отличие от тесткейсов? Если в тесткейсах мы, а, проводим прямо детализированные проверки, а, мы проверяем каждый шаг, будет много данных, мы будем это долго проверять, то в чек-листе это будет просто перечень шагов или перечень проверок функциональности, которые позволяет убедиться, что приложение работает корректно.
А по сути чек-листы мы можем подготавливать на этапе, когда у нас ещё не готов весь функционал продукта, а когда у нас, когда мы знаем, что разработанный функционал ещё будет изменяться. В общем, тогда, когда мы не можем много потратить времени на полностью проработку а документации и на написание тесткейсов. Например, у нас вот дедлайн уже завтра, нам нужно это всё срочно проверить.
Мы можем проверить сначала по чек-листам, а потом, когда задача перейдёт уже, ну, с разработки протестирована будет, мы займёмся написанием как раз-таки тесткейсов. И по сути наши проверки из чек-листов могут быть основанием для написания тест-кейсов, потольку поскольку в чек-листах вот эти вот пункты, они будут как бы заголовками ваших будущих тесткейсов. М также здесь в чек-листах ещё выделяют специальные чек-листы и универсальные.
универсальные. Они как раз-таки подходят для всех проектов, для всех видов тестирования. А специальные будут заточены конкретно под ваш проект, конкретно под ваш функционал.
Например, если в универсальных чек-листах будет написано кстати, я туда же примеры привела. Если у нас есть форма регистрации по номеру телефона, в специальном чек-листе мы будем указывать полностью всё. Например, что мы можем авторизоваться только по российскому номеру, да?
Например, что там у нас, а, формат будет состоять из десяти, э, из одиннадцати, точнее, символов, да, и начинается только строго с плю7, потому что мы проверяем для России, а что, например, у нас тут вот 60 секунд будет время между отправками повторного кода, а что у нас код будет из шести символов и так далее, и так далее, и так далее, то в универсальном чеклисте у нас будут просто перечень проверок, что мы должны будем проверить. То есть просто там, допустим, проверить, что у нас на странице авторизации открывается находится, допустим, вот это вот поле ввода номера телефона. А при отправки там на приводе номера телефона у нас отображается правильный формат.
Отправить форму регистрации там, что у нас получаем код, который нам необходим. В общем, такое более абстрактное. А, да.
>> Вернёмся к чек-листу. А на работе он у тебя прямо так прямо так же будет выглядеть, вот как ты показала, слева и справа. >> Ну да, может быть и так.
Почему нет? У нас нету никакой стандартизации к написанию чек-листов, потому что чек-листы - это такой, э, опять же, это просто перечень проверок. Мы можем даже его оформлять в мм в том же в той же системе, в которой у нас хранятся тесткейсы.
У нас просто название будет как чек-лист для проверки того-то, того-то. И внутри чек-листа вместо вот этих вот э шагов у нас будет просто перечень проверок. То есть один там, допустим, проверить форму регистрации, второй проверить, что отображается поле вводу номера телефона, там третий проверить, что там при нажатии на кнопку отправить отправляется SMS-код.
Да. >> Хорошо. Вот по сути вот начиная с эшн и заканчивая эксперт зал, вот по сути первый первый чеклист пошёл, открыть главную страницу.
Главная страница открыта, второй чеклист пошёл, третий, четвёртый, пятый. Вот так вот. >> Не чек-лист, а проверки из чек-листа.
>> Ну мы так называем, что это общий чеклист, где есть проверка и ожидаем результат. Верно? >> Угу.
>> Хорошо, разобрались. >> Так, о'кей. Как составляется, как уже тоже сказала, один пункт, одна проверка.
А при составлении чек-листа нужно опираться на требования, чтобы не тестировать то, что не существует. Давать пунктом чек-листа название по форме общее для всех членов команды, чтобы работа с чек-листом не вызывала однозначных толкований, неоднозначных, точнее, толкований и детализировать чек-листы в зависимости от задачи. Ну, опять же, тут уже говорится больше про специальные чек-листы, поэтому их нужно детализировать.
А ещё такой момент, мм, чек-листы хороши тем, что мы можем быстро его написать, быстро по ним пройтись, проверить. Плюс у нас из-за этого, а, кстати, я писала, да, писала вот эти плюсы чек-листов и минусы чек-листов. Мы с помощью чек-листов можем уменьшить эффект пестицида, потому что постоянно будут различные данные, различные проверки, расширить тестовое покрытие, быстро написать и быстро проходить по ним.
А, а из минусов можно выделить то, что если у нас на проекте будут только чек-листы, а мы не сможем наши проверки делегировать человеку, допустим, новичку, да, там, мужут, жену, который к нам придёт на проект. Потому что человек, который не знает систему, который не знает, как с ней работать, он не сможет быстро в этом разобраться. Мм, есть здесь какие-то вопросы, может быть?
Угу. О'кей. Если вопросов нет, тогда идём дальше.
Мм, отчёты о тестировании. А, тут сразу сделаю такую небольшую оговорку. Ээ насколь я работала, в принципе, на разных проектах и, наверное, ни на одном из них я не писала прямо вот эти вот документы, отчёты.
Максимум это я делала всегда шаблоны, которые так чисто формально нужны были. Что у нас по сути должно быть вообще, что такое отчёт о тестировании, да? Это документ, в котором у нас будут подведены итоги нашим задачам, результатам тестирования, в котором будет содержаться оценка соответствующих объектов тестирования отно относительно критериев входа.
У нас здесь обычно описывается сам непосредственно э проект, а на котором будет на котором будут у нас Ой, сейчас, секундочку, отвлеклась на чат. У нас здесь будут обязате будет обязательно написан проект, э, который мы тестируем. Модуль тоже, например, это будет только отдельно модуль корзины, отдельно модуль, а, отправки заявок, отдельно модуль личного кабинета.
А, дата тестирования, тестировщик, кто проводил тестирование, также версия продукта. Обычно у нас у продукта всегда есть версионность, а, среда тестирования. Например, это может быть написано, что это у нас была девовская сборка либо релизная сборка.
А цель тестирования для чего тестируется по пунктам? Обычно расписывается объём тестирования, точно так же по пункта расписывается, сколько было, сколько нужно было пройти, какой объём протестировать, сколько было задач и тд и тп. А дальше выполнены тест кейсы и результаты.
Сколько было пройдено, какие проверки были пройдены, сколько из них, соответственно, пройдено, сколько не пройдено. А если у нас обнаружены дефекты, то точно так же здесь прямо списочком мы выписываем, там задача такая, э, название такое, какая ошибка. Ну и, соответственно, выводы и рекомендации.
выводах и рекомендациях мы пишем, что мы готовы предоставить этот продукт уже пользователям либо нет. Мм, дальше а остался момент ещё о баг-репортах. Это, наверное, последний наш пункт на сегодня.
И потом перейдём ко всем вопросам. Будем заново всё обсуждать. А что у нас такое в принципе бакрепорт?
Он же отчёт об ошибке. Это отчёт, который описывает ситуацию или последность действия, приведший к некорректной работе объекта тестирова с указанием причиной ожидаемого результата. То есть, по сути, мы нашли ошибку, мы обязательно должны её задокументировать, отправить разработчику, чтобы он её исправил.
Какие у нас здесь обязательные поля? Какие атрибуты? Обязательно ID.
Как правило, он выставляется системой автоматически, а тема, название, summary, как угодно. А обязательно должен отвечать на вопрос, что, где, когда. То есть, что у нас сломалось, где, когда либо при каких условиях, например, а что, э, кнопка добавления товара в корзину не отображается на странице товара, к примеру, да?
Описание. Тут можно м по-разному как бы трактовать, потому что я, допустим, описание на своём проекте вообще не заполняю, но в описании может быть такое тоже более подробное, чем, допустим, тема. Э тему вы кратко пишите, в описании уже там как-то более расширено.
А шаги воспроизведения, то как нам прийти к такому результату, например, перейти на главную страницу, открыть товар с там, допустим, продукт ID там 1 2 3 4 5 А, не знаю, проскролить страницу до блока, проверить отображение кнопки. Фактически результат кнопка не отображается в этом блоке, ожидаемый кнопка отображается во вложении. У нас может быть видео, могут быть скриншоты, логи, в общем, всё то, что нам потребуется для разработчика, чтобы он как можно быстрее это разобрался и исправил.
А приоритет, серьёзность вот отсюда уже с восьмого по одиннадцатый, по сути, пошли необязательные, но можно это тоже делать. Приоритет, соответственно, чаще всего будет выставлять PM. Серьёзность можем вы выставить то, как как этот баг повлияет на систему.
И статус исправлен в процессе там найден, да, там вду in progress, там по fictш в тестировании, протестирован, тд и тд. Окружение. Окружение тут точно так же.
Тут могут быть стенд, на котором был найден, сборка релизная. Просто даже написать, что там Chrome, Safari, Firefox, там, не знаю, Windows и там Windows 10 и что-нибудь ещё. А вот здесь я вот как раз-таки приложила такой небольшой пример шаблончика.
М у нас есть два варианта. В некоторых компаниях, в некоторых командах, а вот эти вот системы, как они называются, бектрекинговые, та же Джира, они чаще всего настраивают прямо поля, чтобы у нас каждое поле нашей задачки, а, в общем, каждые вот эти вот поля были отдельно и заполняли мы их отдельно. Но чаще всего, мм, как у насчается это просто название будет.
А мы выбираем тип - это баг. Да, сейчас перейдём к следующему слайду. Тип - это просто баг.
А название либо здесь, либо оно вверху на самом этом тикете, так называемом. раздел браузер, предусловие, как воспроизвести шаги поочерёдно, фактический результат, как должно быть это ожидаемый результат, ну и вложения какие-то. А у меня, например, на проекте это выглядит вот так.
То есть здесь мы указываем название, выбираем тип либо просто бак, либо фичик, в зависимости от того, где он был найден и к какому функционалу он будет относиться. Далее, вот эти вот все моменты мы не заполняем обычно, просто заполняем вот как раз-таки в описании, где нашли, на какой на какой платформе, на каком браузере. Чаще всего просто пишем десктопы, мобильные браузеры.
Предусловие, как я уже говорила, в принципе, может это быть, может не быть, тут тоже всё зависит от того, а как вы локализируете ваш бак. Если вдруг при локализации будет понятно, что это обязательные действия, тогда это нужно обязательно указать. Соответственно, шаги фактически ожидаемые.
Ну и тут я вот прикладывала видеофайлы, что потому что статические фотографии и логи особо тут не помогают. Так, ну на данном этапе это Если хочешь получать эксклюзивный контент и быть в курсе новых видео, загляни ко мне на бусте. Там я регулярно выкладываю новые ролики, которые не всегда выходят на YouTube.
Также у нас есть закрытые чаты, где можно общаться, задавать вопросы и делиться идеями. Поддержи мой канал и стань частью нашего дружного сообщества. Ссылка в описании.
