Теория тестирования
Тестирование требований: свойства хорошего требования и как их проверять
Тестирование требований – это анализ требований до того, как по ним начнут писать код: тестировщик ищет в них пробелы, противоречия и формулировки, которые нельзя проверить. Хорошее требование полное, непротиворечивое, корректное и однозначное, его можно проверить и реализовать за разумные деньги, легко изменить и проследить до тестов и багов. Проще всего начать с попытки сразу написать по требованию тест-кейсы: если тест не складывается, требование нужно уточнять.
- 3 уровня
- бизнес-требования, пользовательские и требования к продукту
- Статическое тестирование
- по ISTQB требования проверяют без запуска программы
- Бесплатно
- урок с заданиями в моём базовом курсе
Уровни требований
Урок я начинаю с поговорки: театр начинается с вешалки, а процесс разработки – с требований. Без них непонятно, что хотят получить бизнес и пользователь, и браться за работу не с чем. Требования делят на три уровня. На собеседовании их часто просят назвать и объяснить, поэтому к каждому стоит подобрать свой пример.
Бизнес-требования
Цель, ради которой создаётся продукт: какую пользу он принесёт и как на нём заработать. Пример из урока: компании нужен сайт, который будет продвигать её продукцию.
Пользовательские требования
Задачи, которые пользователь решает с помощью продукта. На том же сайте он регистрируется, общается и ищет информацию о продукции.
Требования к продукту
Как всё это будет реализовано с точки зрения разработки, с учётом бизнес- и пользовательских требований. Они делятся на функциональные, то есть что система должна делать, и нефункциональные, то есть как она должна это делать. Первые проверяет функциональное тестирование, вторые – многочисленные виды нефункционального.
Свойства хорошего требования
Допустим, аналитик или владелец продукта собрал информацию у заказчика, оформил требования в виде user story, и тестировщика позвали на рецензирование. Проверять требование нужно по свойствам хорошего требования, то есть по требованиям к самим требованиям. В уроке разобраны основные из них, но встречаются и другие.
Завершённость
В требовании есть вся информация, которая нужна разработчикам, тестировщикам и остальным, кто будет с ним работать. Чтобы его понять, не приходится искать ответы в других требованиях.
Непротиворечивость
Части требования не спорят друг с другом. Типичный случай – макет интерфейса не совпадает с текстом критериев приёмки. Требование не должно противоречить и другим требованиям к системе. Найдя противоречие, тестировщик пишет аналитику.
Корректность
Требование точно говорит, что должно делать приложение. Фраза "система принимает валидные данные" не годится: нужно указать, что считается валидным, например буквы, цифры, десятичные дроби, спецсимволы или их сочетание.
Недвусмысленность
Все понимают требование одинаково. Двусмысленное требование я сравниваю с цифрой на столе: один человек видит шестёрку, а другой, сидящий напротив, видит девятку.
Проверяемость
Выполнение требования можно однозначно проверить. Если не хватает инструментов или знаний, стоит спросить более опытного тестировщика или разработчика. Если проверить требование нельзя в принципе, об этом говорят аналитику или владельцу продукта и вместе ищут другой способ реализовать функцию.
Выполнимость
Требование реализуемо за разумные время и деньги. Здесь стоит вспомнить золочение (gold plating): функцию, которая требует долгой разработки, дорогих инструментов и сил всей команды, а пользы приносит мало. О таком требовании спрашивают бизнес, нужна ли функция на самом деле.
Модифицируемость
Набор требований легко менять, не трогая требования в других местах. Поэтому ссылок из одного требования на другие по возможности избегают, и тогда правка проходит быстро и почти не задевает систему.
Прослеживаемость
У требования есть идентификатор, по которому его связывают с другими требованиями, тест-кейсами и баг-репортами. Если в приложении доставки поменяли требование о минимальной сумме заказа, по его идентификатору сразу видно, какие тест-кейсы и автотесты нужно обновить и какие баги по нему ещё открыты.
Проранжированность
У требования есть приоритет. Если функция нужна заказчику прямо сейчас, её делают первой.
Как тестировать требования
В программе ISTQB проверка требований относится к статическому тестированию. Программу при нём не запускают и читают сами документы: требования, пользовательские истории, спецификации. Дефект, найденный в требованиях, исправляют правкой текста, а в готовом продукте тот же дефект стоит переделки кода и повторных проверок.
Придя на проект, стоит первым делом узнать, где хранятся требования: в трекере вроде Jira или Azure DevOps, в спецификациях в Word или на вики в Confluence. Там же выясняют, как требования меняются, кто за них отвечает и к кому идти, если что-то непонятно.
Чтобы работать с требованиями было проще, помогут несколько приёмов.
Сразу писать тест-кейсы
Получив требование, попробуйте написать по нему тест-кейсы. Если проверки не придумываются, требование, скорее всего, непроверяемо. Его обсуждают с аналитиком, чтобы тот уточнил у заказчика формулировку или саму необходимость функции. Например, в требовании банка написано: "Переводы между своими счетами проходят без комиссии". Уже на первых кейсах возникают вопросы: что, если счета в разных валютах, есть ли лимит на сумму, считается ли своим счёт клиента в другом банке. Ответов в требовании нет, и вопросы уходят аналитику до того, как написан код.
Задавать вопросы
Это самый простой способ. Уточняющие вопросы задают аналитику, владельцу продукта или заказчику, если к нему есть доступ, и стесняться их не нужно. Если требование чему-то не соответствует, так и пишут, что его нужно переделать.
Рисовать интеллект-карту
Большое требование раскладывают на функции, а каждую функцию на части помельче. На такой карте (mind map) лучше видно, что написано в требовании и чего в нём не хватает. Рисовать можно в программе или просто на листе бумаги.
Описывать варианты использования
Use case перечисляет действия пользователя и реакцию системы на каждое из них. С ним легче заметить сценарий, о котором в требовании забыли.
Рецензировать
Тестировщик выступает рецензентом чужого требования. Рецензирование бывает формальным и неформальным, и так же проверяют тест-кейсы. В программе ISTQB описаны четыре распространённых типа: неформальное рецензирование, пошаговый разбор, техническое рецензирование и инспекция.
Откуда берутся требования и как они выглядят
Собирает требования обычно бизнес-аналитик, а в небольших компаниях эту работу может делать и QA-инженер. Для этого беседуют с заказчиком, пользователями или фокус-группой, наблюдают за тем, как люди работают в существующем продукте, который предстоит улучшить, изучают похожий сайт конкурента или описывают требования сами, опираясь на здравый смысл.
К тестировщику требования приходят в разном виде, и проверять по свойствам хорошего требования нужно любой из них.
Диаграмма вариантов использования
Схема с действующими лицами (актёрами) и тем, что каждый может сделать в системе. В уроке это система с квизами: администратор входит в неё, добавляет, удаляет и обновляет квизы, управляет студентами и выходит, а студент регистрируется, входит, проходит квизы и смотрит результат.
User story
Пользовательская история из трёх смысловых частей: кто, чего хочет и зачем. Пример из урока: "Как участник конференции, я хочу регистрироваться онлайн, чтобы регистрироваться быстро и снизить количество бумажной работы". К истории пишут критерии приёмки (acceptance criteria), и тестировщик придумывает тест-кейсы к каждому из них. Такой формат распространён в Scrum, хотя руководство по Scrum его не упоминает.
Макеты
Шаблоны экранов от UI/UX-дизайнера: какие поля есть на экране, что в них вводить, какие сообщения появляются при ошибке ввода. Обычно макеты рисуют после текстовых требований, но иногда их приносит сам заказчик.
Схема
Блоки приложения и описание того, что должно быть на каждой странице.
Клочок бумаги
В стартапах и маленьких компаниях без аналитиков требование бывает парой строк в духе "хочу то-то и то-то". Сейчас это редкость, но пугаться такого не стоит.
Спецификация
Большой документ с требованиями, который пишут бизнес-аналитики, если этого требует заказчик или так устроен процесс в компании. Требования в нём проверяют по тем же свойствам.
Пример: разбор user story
Ниже учебный пример по мотивам user story из урока. Критерии приёмки придуманы для разбора, и в них нарочно оставлены типичные ошибки.
История: как участник конференции, я хочу регистрироваться онлайн, чтобы регистрироваться быстро и снизить количество бумажной работы. Критерии приёмки: 1) на форме есть поля "Имя", "Email" и "Телефон"; 2) участник вводит валидные данные и нажимает "Зарегистрироваться"; 3) после регистрации участнику быстро приходит письмо с подтверждением; 4) остальное как в старой форме регистрации, см. REQ-12. На макете у формы есть ещё поле "Компания".
Непротиворечивость
Макет и первый критерий расходятся: поле "Компания" есть только на макете. Вопрос аналитику: нужно ли это поле и обязательно ли оно.
Корректность
Слова "валидные данные" ничего не говорят разработчику. Нужно описать допустимые символы и длину имени, формат email и телефона.
Проверяемость
"Быстро" проверить нельзя. Нужен срок, например письмо приходит в течение пяти минут.
Завершённость
Не описано, что будет при повторной регистрации на тот же email и при пустых полях. Без этого не написать негативные тест-кейсы.
Модифицируемость
Четвёртый критерий ссылается на другое требование. Если старую форму поменяют, изменится и это требование, и никто этого не заметит.
Что дальше
Вопросы уходят аналитику одним списком. Когда он уточнит формулировки у заказчика, по каждому критерию пишут тест-кейсы: позитивный сценарий регистрации и негативные на неверный ввод.
Видеоурок, шпаргалки и тренажёр
Я разбираю требования в двадцать шестом уроке курса "Тестировщик с нуля" на YouTube: уровни требований, способы их выявления, свойства хорошего требования, приёмы проверки и формы, в которых требования приходят к тестировщику. В бесплатном базовом курсе по тестированию тема идёт уроком "Анализ требований", и после теории в нём есть задания.
Шпаргалка по требованиям собирает уровни, свойства и частые дефекты с примерами, а в конце предлагает найти дефект в требовании. В тренажёре нужно сопоставить свойства хороших требований с примерами, где они нарушены. Новые карточки он генерирует под вашу предметную область, например финтех или игру.
Курсы по теме
Вопросы и ответы
Что такое тестирование требований?
Проверка требований до начала разработки: тестировщик ищет в них пробелы, противоречия, двусмысленности и формулировки, которые нельзя проверить, и задаёт вопросы аналитику. По ISTQB это статическое тестирование, программу при нём не запускают.
Какие есть свойства хорошего требования?
Завершённость, непротиворечивость, корректность, недвусмысленность, проверяемость, выполнимость, модифицируемость, прослеживаемость и проранжированность. Пример нарушения: требование "система принимает валидные данные" некорректно, потому что в нём не сказано, какие данные валидны.
Какие бывают уровни требований?
Бизнес-требования описывают цель, ради которой делают продукт, пользовательские – задачи, которые пользователь решает с его помощью. Требования к продукту описывают, как это реализовано, и делятся на функциональные (что система делает) и нефункциональные (как она это делает). Уровни требований часто спрашивают на собеседовании.
Как тестировщику проверить требования?
Прочитать требование и пройтись по свойствам хорошего требования, попробовать сразу написать по нему тест-кейсы, задать уточняющие вопросы аналитику или владельцу продукта, разложить требование на интеллект-карте или описать варианты использования. Более формальный способ – рецензирование.
Что такое user story и критерии приёмки?
User story – короткое описание функции от лица пользователя: кто он, чего хочет и зачем, например "как участник конференции, я хочу регистрироваться онлайн, чтобы регистрироваться быстро". Критерии приёмки перечисляют условия, при которых функция считается готовой, и тестировщик пишет тест-кейсы к каждому из них.
Что такое золочение требований?
Так называют функцию, которая стоит много времени и денег, а пользы приносит мало (gold plating). Такое требование нарушает выполнимость, и тестировщик спрашивает у бизнеса, действительно ли функция нужна.
Посмотреть программы курсов
Программа каждого курса открыта целиком: видны все модули, уроки и число шагов.