Прошлая часть: Техники тест-дизайна для чайников
Привет текущим и, надеюсь, будущим подписчикам. Сегодня разберемся в вопросе "Как именно тестировщики документируют проверки?"
Я бы вам наврал, если бы сказал, что в тестировании ПО отсутствует бюрократия. От компании к компании и от проекта к проекту (даже внутри одной компании) уровень этой бюрократии разнится, но тем не менее мы должны ее разобрать. Речь идет о документировании составленных проверок. Разберем сначала смысл документирования проверок прежде, чем поговорим о типах такой документации.
Представим, что у вас простой продукт, который состоит из двух частей:
- Функция регистрации.
- Функция заполнения личных данных (ФИО, данные о паспорте, о телефоне и т.д.), которая будет использоваться, когда программное обеспечение модифицируют в будущем.
На первую часть системы мы написали 50 проверок. Представим, что на вторую часть системы мы написали столько же. Итого – 100 проверок. Спустя 3 месяца приходит инициативный бизнес со своим нескончаемым желанием «поднять бабла» и предлагает сделать 3 доработки – 2 из них меняют текущие части системы, а третья добавляет новую часть системы. Мы получаем в перспективе следующую работу:
- Проверить доработку части системы №1;
- Проверить, что существующие функции в части системы №1 не сломаны;
- Проверить доработку части системы №2;
- Проверить, что существующие функции в части системы №2 не сломаны;
- Проверить разработку новой части системы №3.
Получается, что вам, как инженеру придется:
- вспомнить проверки, которые вы когда-то проводили по частям системы №1 и №2 чтобы убедиться, что они не сломаны;
- придумать проверки для новых функций частей системы №1 и №2;
- придумать новые проверки для части системы №3.
А если вы не единственный инженер на проекте? И часть системы №2 вы вообще впервые видите, а ваш коллега тестировщик в отпуске в деревне, где не ловит связь? Тогда к этому списку добавляем еще изучение документации по части системы №2.
А если эти доработки необходимо протестировать в сжатые сроки? И у вас физически не хватит времени на проведение всех проверок, но надо убедиться, что самые важные функции работают? Получается вам надо потратить время не только на то, что вспомнить проверки, но и на приоритезацию этих проверок.
А если у вас система состоит из 50 частей и все эти части так или иначе используют функциональность части системы №1? И именно часть системы №1 дорабатывается, что приводит к перепроверке всей системы? Ситуация очень даже реальная, к сожалению.
Думаю, что из всех этих риторических вопросов стало понятно, что документирование проверок не такое уж и зло, если документирование выполнено правильно (бывают случаи, когда наличие плохой тестовой документации гораздо хуже, чем ее полное отсутствие). Давайте резюмируем причины необходимости ведения и поддержки тестовой модели:
- Сохранение знаний о необходимых проверках в конкретных частях системы;
- Быстрое получение информации о наиболее приоритетных проверках в рамках конкретной части системы или системы в целом;
- Передача знаний о проводимых проверках сотрудникам, которые не работали с конкретной частью системы;
- Сохранение времени на этапах, когда надо: вспомнить ранее проведенные проверки и их приоритеты, или передать знания коллегам.
Сейчас мы и разберем варианты, которые у нас есть для документирования проверок. На реальном проекте скорее всего уже будет какой-то подход к ведению тестовой документации, а вам придется просто применять знания, полученные в этой главе.
Чек-листы
Чек-лист – это документ, содержащий список проверок, которые необходимо выполнить и ожидаемый результат к каждой проверке.
Всё достаточно просто – вы заводите документ, в котором фиксируете проверки, которые проводили или будете проводить. Примерно также, как вы составляете список продуктов, которые надо купить в магазине, но лишь с одним отличием – ожидаемым результатом у каждой покупки в магазине будет «Продукт куплен», а в чек-листе тестирования ожидаемый результат всегда разный.
Возвращаясь к главе, где мы составляли проверки к форме регистрации – мы уже практически составили полноценный чек-лист к этой форме. Добавьте к каждой проверке ожидаемый результат и чек-лист готов.
Пример:
Стоит отметить, что этими полями чек-лист может не ограничиваться и от проекта к проекту инженеры могут вести чек-листы по-разному. Могут добавлять поля с приоритетами, статусами (чтобы помечать успешно прошла проверка или нет), комментариями и так далее.
Скажу честно – с чек-листами я в работе сталкиваюсь крайне редко, но знаю от своих знакомых о проектах, где вся тестовая модель строится на чек-листах. Как и везде, в чек-листах есть свои плюсы и минусы.
Из плюсов можно отметить:
- Низкие временные затраты на составление чек-листа;
- Простота понимания проверок и их проведения для сотрудников, которые знакомы с проектом;
- Простота составления чек-листа.
Из минусов можно отметить:
- Недостаточность детализации;
- Сложность понимания проверок и их проведения для сотрудников, которые незнакомы с проектом;
- Плохо применимы на проектах с действительно сложной логикой.
Тест-кейсы
Тест-кейс – это документ, описывающий последовательность действий, конкретных условий и параметров, которые необходимо выполнить для проверки конкретной функции системы.
Этот документ более сложный и требующий больших трудозатрат, чем чек-лист. Разберем поля среднестатистического тест-кейса, с учетом того, что от проекта к проекту они могут незначительно отличаться от этого списка:
- Идентификатор – уникальный номер тест-кейса среди всех тест-кейсов в тестовой модели;
- Заголовок тест-кейса – краткое и ёмкое название проверки, отражающее её суть;
- Предварительные условия – полный список условий и настроек, которые необходимы для успешного прохождения тест-кейса;
- Входные данные – список или описание сущностей системы, которые необходимы для успешного прохождения тест-кейса;
- Автор – инженер, который создал тест-кейс;
- Приоритет – важность тест-кейса относительно проверяемой функции или системы в целом.
К эти полям тест кейса также идут шаги проверки, где каждый шаг состоит из:
- Номер шага;
- Выполняемое действие – действие в рамках конкретного шага, которое должно привести к результату, позволяющему перейти к следующему шагу;
- Ожидаемый результат – заранее определенная ситуация, которая должна произойти в результате действия для конкретного шага.
Важное замечание, на случай если вы берете информацию из нескольких источников на момент прочтения – не путайте «тест-кейс» с «тестовым запуском». Тест-кейс не имеет статуса прохождения, запомните это! Тест-кейс – это аналог шаблона на производстве, на основании которого штампуются «изделия». И вот как раз «изделия» могут получиться успешными или неудачными, а шаблон как был шаблоном – так им и остается.
Не нужно ужасаться, вспоминая количество составленных нами проверок ранее или делать выводы в стиле «чек-листы выглядят проще – буду использовать их в работе». Давайте взглянем на тест-кейс, который плюс-минус близок к реальному:
В реальности вы будете вести тест-кейсы в специальных системах таких как «Adaptavist Test Management for JIRA», «Test IT», «Allure TestOps» и т.д. Набор полей тест-кейса и логика тест-кейса от этого не меняется – а лишь изменяется удобство их ведения и визуальная составляющая. Для практики и составления своего первого «портфолио» вам достаточно будет и word’а.
Первое, на что обращаем внимание, что тест-кейс объединяет под собой не одну конкретную проверку, которую мы придумали ранее, а агрегирует несколько проверок, объединенных одной целью. В данном конкретном случае у нас было 3 проверки:
- Проверить, что поле ввода "Логин" является обязательным для заполнения;
- Проверить поле ввода "Пароль" на обязательность заполнения;
- Проверить поле ввода "Повторите пароль" на обязательность заполнения.
Если бы полей было больше 3 (например, 15) и часть из них были необязательными – проверки этих полей мы также смогли бы поместить в этот конкретный тест-кейс.
Итого - что же делаем со всеми проверками? Всё просто (нет конечно, это приходит с практикой) – агрегируем их по логике и функциональности, получая:
- Проверку успешной регистрации и возможности повторной авторизации под учетными данными;
- Проверку обязательности заполнения полей ввода (приведена выше);
- Проверка полей на чувствительность / не чувствительность к регистру;
- Проверка граничных значений полей ввода;
- Проверка доступности кнопок «Зарегистрироваться» и кнопок «Показать пароль» / «Скрыть пароль»;
- Проверка работы сервиса проверки пароля на надежность при регистрации;
- Проверка работы формы регистрации при заполнении полей не валидными данными.
Всего 7 проверок, с разными приоритетами. Да, в каждой из проверок больше шагов чем в чек-листе, но к каждой из этих проверок будет меньше вопросов. У вас возникнет гораздо меньше вопросов «Что же имел ввиду автор под этой проверкой?» в отличии от чек-листа. Да и даже если вопросы возникнут – вы всегда сможете обратиться к автору, если он еще не уволился, разумеется.
Ну и пройдемся по плюсам и минусам хороших тест-кейсов.
Плюсы:
- Подходят под проекты со сложной логикой;
- По тест-кейсам проще работать, т.к. они подробнее и проще в использовании;
- Хорошо подходят для передачи знаний между инженерами (не ограничиваясь одним лишь тестированием);
- Тест-кейсы помогают тестировать качественнее за счет полноты описания проверки;
- Создают основу для будущей автоматизации тестирования.
Минусы:
- Высокие временные затраты на создание тестовой модели;
- Сложность актуализации тестовой модели с течением времени.
Детальнее про поля тест-кейсов
Разберем каждое поле тест-кейса, чтобы окончательно закрепить как работать с этим типом документации. Делать это будем на примере тест-кейса, приведенного выше.
Идентификатор – для человека незнакомого с этим понятием или IT это непонятное поле. По определению это «Уникальный признак объекта, позволяющий отличить его от других объектов, т.е. идентифицировать». Например, ваши серия и номер паспорта являются идентификатором, так как ни у кого больше в стране не будет паспорта с такой же комбинацией цифр. Также и у тест-кейса из примера «PROJECT– 02» является уникальной комбинацией символов, которая будет только у одного документа. В каждой системе ведения тест-кейсов правила свои, но обычно система автоматически присваивает новый идентификатор, т.к. она уже знает все существующие идентификаторы. Нужен он для того, чтобы тест-кейс было сложно перепутать, легко найти и ссылаться на него. Например, «Игорь, у нас ошибка в шаге 3 тест-кейса PROJECT– 02 …».
Заголовок – «Кратко и ёмко» формулируем то, что проверяем. Каждый раз, когда вы формулируете заголовок – задавайте сами себе вопрос «А незнакомый человек поймет по заголовку суть этой проверки?». Безусловно – нужно практиковаться. Чем больше вы практикуетесь в оформлении тест-кейсов – тем лучше у вас будет получаться писать вменяемые заголовки к ним. Иногда люди практикуют добавление префикса к заголовку (в нашем примере «Форма регистрации: …» явно указывает на проверяемую часть системы), чтобы через описание было понятно к какому разделу системы относится конкретный тест-кейс.
Предварительные условия – в целом эта часть тест-кейса является опциональной, но лично я считаю хорошим тоном записывать в нее всю информацию, которая как-либо поможет при проверке и позволит совершить минимальное количество переключений с тест-кейса на какие-либо другие документы. Здесь перечисляем все необходимые настройки системы, ссылки на задачи и требования, зависимости от каких-либо внешний факторов или других объектов системы. Как минимум вы заботитесь о себе из будущего.
Входные данные – похоже на предварительные условия, но есть отличие – входные данные будут непосредственно использоваться в шагах проверке. У вас может сложиться ситуация, когда в качестве входных данных будут выступать сущности системы, у которых 10-15 параметров и вместо того, чтобы шагах тест-кейса эти параметры как-то выставлять, чтобы затем изменить, вы можете прописать эти сущности во входных данных, а затем оперировать ими в шагах. Например, «Изменить у пользователя из входных данных №2 …. и проверить …».
Автор – тот бедняга, кто тратил время на создание тест-кейса. Нужен для того, чтобы его можно вычислить и задать ему кучу вопросов, при необходимости.
Приоритет – самое неоднозначное поле. Существуют проекты, где важность таких документов как тест-кейс и баг-репорт определяется двумя полями – «Приоритет» и «Серьезность». Поле приоритет отвечает за порядок взятия в работу – сначала берем в работу тест-кейсы с приоритетом «Критичный», затем с приоритетом «Высокий», затем «Средний» и так далее. А поле «Серьезность» отвечает за важность влияния функционала на работоспособность системы и бизнес-процессов. Причем не всегда приоритет «Критичный» соответствует аналогичной серьезности – эту тему мы разберем в статье про баги. Возвращаясь к приоритету в тест-кейсе – вам необходимо подумать и скомбинировать два понятия «Приоритет» и «Серьезность» и принять решение по приоритету конкретного тест-кейса, учитывая наличие других тест-кейсов.
В расставлении приоритетов поможет разделение проверок на «позитивные» и «негативные».
- «Позитивное» тестирование – тестирование, направленное на проверку поведения системы в штатной ситуации.
- «Негативное» тестирование - тестирование, направленное на проверку поведения системы во внештатной ситуации.
Согласитесь, что среднестатистический пользователь не будет создавать логины или пароли длиной 1000 символов. Но система должна оставаться работоспособной даже в таких исключительных случаях. Получается, что позитивной проверкой будет штатная регистрация пользователя – более распространенная, более критичная для бизнеса и системы, а негативной проверкой будет ввод слишком длинных/коротких полей, попытка ввода специфических символов и так далее – менее распространенная, менее критичная для бизнеса и системы. Если один человек из десяти тысяч не сможет зарегистрироваться со своим длиннющим паролем – это не такие потери для продукта, как если 9999 пользователей не смогут зарегистрироваться штатно.
Шаги проверки – каждый шаг — это комбинация номера шага, выполняемого действия и ожидаемого результата. Если в шаге выполняется какое-то действие – оно должно приводить к какому-либо результату. Ожидаемый результат должен быть в каждом шаге, даже если он для всех очевиден. Всем своим знакомым, которых я обучал тестированию, я всегда говорил – «Ваш тест кейс должен быть написан таким образом, что бомж с улицы сможет пройтись по шагам вашего тест-кейса, если его посадить за компьютер».
Совет – старайтесь в выполняемом действии использовать глаголы совершенного вида (привет урокам русского языка из школы), отвечающим на вопрос «Что сделать?». Т.е. вместо «Пользователь вводит в поле логин значение …» использовать фразу «Ввести в поле логин значение …» - так ваш документ станет понятнее и короче.
Следующая часть: Что такое релиз? Что такое тестовый набор? Что такое тестовый запуск?
Поддержать или поблагодарить можете:
Лайком;
Комментарием;
Подпиской на канал;
#Блог_тестировщика #QA #Тестирование_ПО #Тестирование_с_нуля #Тест-кейс #Чек-лист
