Критерии качества требований с примерами (Часть 1.)
В идеальном мире тестирование должно идти на всех этапах жизненного цикла ПО, начиная с проектирования, когда никакого продукта еще нет, а есть только описание того, что заказчик хочет получить. Это описание может называться спецификация, техническое задание (ТЗ) или просто требования.
Требования проверяются на соответствие критериям качества. Часто этот процесс описывают как отдельный вид тестирования — тестирование требований.
Понятие критериев качества требований скорее относится к бизнес-анализу, чем к QA. В разных источниках можно встретить разные наборы критериев. При написании этой статьи я руководствовалась своим опытом и тремя хорошими книгами:
1. «BABOK» Международного института бизнес-анализа. Ссылка.
2. «Тестирование программного обеспечения. Базовый курс.» Святослава Куликова Ссылка.
3. «Разработка требований к программному обеспечению» Карла Вигерса и Джой Битти. Ccылка.
На изображении ниже можно увидеть, что во всех трех источниках есть семь одинаковых критериев качества. По моему опыту, знания этих семи критериев достаточно для QA-инженера, они и будут разобраны в этой статье. Оставшиеся пять критериев будут приведены во второй части статьи.
ПОЛНОТА (или «завершенность»).
Каждое требование должно содержать всю информацию, необходимую для его понимания, не оставлять пробелов или недомолвок. Этот критерий относится и к бизнес- и к техническим требованиям.
Пример 1: «Пользователь может загрузить данные в формате PDF, CSV и т.д.» Неясно, какие ещё форматы поддерживаются помимо указанных. Что подразумевается под «и т.д.»?
Полное требование: «Пользователь может загрузить данные в форматах PDF, CSV и JSON.»Пример 2: «Приложение должно работать на всех популярных мобильных платформах.» Неясно, какие платформы считаются «популярными».
Полное требование: «Приложение должно поддерживаться на платформах Android версии 10.0 и выше, iOS версии 13.0 и выше.»Пример 3: «Система должна обрабатывать запросы с высокой производительностью.» Не указано, что конкретно подразумевается под «высокой производительностью» (какие показатели важны).
Полное требование: «Система должна обрабатывать до 1000 запросов в секунду с задержкой не более 200 миллисекунд.»
НЕПРОТИВОРЕЧИВОСТЬ (или «согласованность»).
Требования не должны противоречить друг другу. Обнаружение несоответствий может быть крайне затруднительным, если требования к одной и той же функциональности продукта находятся в разных местах.
Пример 1:
-«Пользователь должен быть автоматически разлогинен после 15 минут бездействия.»
— «Пользователь должен оставаться в системе до тех пор, пока не завершит редактирование документа.»
Первое требование подразумевает автоматический выход по истечении времени, а другое не допускает выхода во время работы над документом.
Непротиворечивые требования: «Пользователь должен быть выведен из системы через 15 минут бездействия, за исключением времени активного редактирования документа.»Пример 2:
-«Отчет должен генерироваться и отправляться пользователю мгновенно.»
— «Генерация отчета может занимать до 30 минут в зависимости от объема данных.»
Первое требование обещает мгновенную обработку, тогда как второе указывает на значительную задержку, создавая неопределенность в ожиданиях.
Непротиворечивые требования: «Отчет должен генерироваться мгновенно при малом объеме данных и отправляться в течение 30 минут при большом объеме.»
КОРРЕКТНОСТЬ
Под корректностью понимается точное соответствие запросам пользователей и бизнеса. Это означает, что требования должны полностью удовлетворять нужды заинтересованных сторон, которые будут использовать эти требования для достижения конкретных целей.
Пример 1: «Пользователь должен быть в состоянии настроить двухфакторную аутентификацию для повышения безопасности»
Это требование к пользователю, а не к программе. Мы делаем продукт и можем диктовать ему требования, но не можем контролировать состояние его пользователей.
Корректное требование: «Приложение должно поддерживать двухфакторную аутентификацию и предоставлять пользователю возможность включить эту функцию в настройках безопасности.»Пример 2: «После завершения загрузки файла пользователь должен увидеть пагинацию с сообщением о том, что загрузка прошла успешно.»
Пагинация относится к разбиению контента на страницы, что не имеет смысла в контексте завершения загрузки файла. Вместо этого должно быть указано, что пользователь должен увидеть сообщение о том, что загрузка прошла успешно.
Корректное требование: «После завершения загрузки файла пользователь должен увидеть уведомление о том, что загрузка прошла успешно.»
НЕДВУСМЫСЛЕННОСТЬ (или «однозначность»)
Русский язык, как и любой другой, может содержать двусмысленности, которые обычно проявляются в двух формах: когда одно требование можно интерпретировать по-разному и когда разные люди понимают одно и то же требование по-своему. Тестирование требований помогает выявить такие проблемы, хотя полностью исключить двусмысленность невозможно. Важно, чтобы требования были сформулированы однозначно, без жаргона, аббревиатур и неясных фраз, чтобы не возникало различных трактовок.
Пример 1: «Отменить заказ может модератор и администратор сайта».
Несколько интерпретаций этого требованиях являются верными. Программист может решить, что для отмены заказа нужно решение И модератора И администратора сайта, а тестировщик решит, что для отмены заказа достаточно решения только модератора ИЛИ только администратора.
Однозначное требование: «Заказ может быть отменен модератором и администратор сайта. Для выполнения операции достаточно одного из этих сотрудников.»Пример 2: «Сервис должен быть интегрирован с СК.»
Что значит СК? Система Криптографии? Сервер Коммуникаций? Система Качества? Служба Консультирования? Что, если в компании есть все эти сервисы?
Однозначное требование: «Сервис должен быть интегрирован с Системой Контроля (СК), предоставляющей разграничение управления доступом.
ВЫПОЛНИМОСТЬ (или «осуществимость»).
Выполнимость требований в проекте определяется их возможностью быть реализованными с учетом технических, бюджетных и временных ограничений. Для оценки выполнимости можно использовать инкрементальную разработку и прототипы. Если требование невозможно выполнить, важно учитывать его влияние на проект и принимать решения о его исключении.
Пример 1: «Приложение должно распознавать и выполнять мысленные команды пользователей.»
На текущем уровне технологий нет надежных и доступных методов для чтения и интерпретации мыслей пользователей. Реализация такого функционала требует технологий, которые еще находятся на стадии научных исследований и недоступны для массового применения.Пример 2: «Приложение должно распознавать эмоции, по тексту и автоматически подбирать цветовой фон сообщения, соответствующий настроению пользователя»
Разработка такой функции потребует значительных затрат времени и ресурсов, так как потребует машинного обучения на большом объеме данных и последующего долгого тестирования. Кроме того, большинство пользователей, скорее всего, сочтут функцию избыточной и ненужной.
ПРОВЕРЯЕМОСТЬ (или «тестируемость»).
Тестируемость требований означает их способность быть проверенными через объективные тест-кейсы, которые ясно показывают правильность реализации. Неполные, несогласованные или двусмысленные требования не поддаются проверке.
Пример 1: «На некоторые товары автоматически применяется скидка 15%.»
Неясно, какие именно товары подходят под определение «некоторые», а значит, мы не сможем проверить реализацию этого требования.
Проверяемое требование: «На товары из категории 'Электроника' автоматически применяется скидка 15%.»Пример 2: «Скидка Премиум-пользователя в размере 10% применяется по возможности к заказам пользователя, имеющего статус Премиум.»
Неясно, что означает «по возможности» и как проверить наступление или отсутствие этой возможности.
Проверяемое требование: «Скидка Премиум-пользователя в размере 10% автоматически применяется ко всем заказам Премиум-пользователей.»
ПРИОРИТИЗИРОВАННОСТЬ (или «упорядоченность»).
Требования должны быть упорядочены по важности, стабильности и срочности. Важность определяет, насколько успех проекта зависит от выполнения требования; стабильность показывает, насколько вероятность изменений в требовании мала; срочность влияет на распределение усилий команды по времени. Неверно расставленные приоритеты могут привести к неэффективному распределению ресурсов, выполнению ненужной работы и нарушению сроков.
Пример 1:
»1. Пользователь должен иметь возможность переключаться между светлой и темной темой интерфейса.
2. Система платежей должна быть интегрирована с новым партнером. API партнера может меняться по мере разработки.
3. Пользователь должен иметь возможность просмотреть информацию о своих заказах»Нарушена упорядоченность по важности и срочности, так как последнее требование намного полезнее для пользователя, чем наличие светлой и темной темы. Нарушена упорядоченность по стабильности, так как интеграция с системой, чья API может изменяться, создает высокую степень неопределенности и риск ненадежной работы функции, что может потребовать значительных доработок и тестирований. Реализацию этого требования можно отложить до релиза стабильной версии API партнером.
Оставшиеся 5 критериев будут разобраны во второй части статьи.
