Тестирование требований и документации
В работе тестировщика часто встречается различная документация: описывающая требования к системе, руководства пользователя, руководства по эксплуатации, руководства по установке и т.д.
Требование (requirement) - описание того, какие функции и с соблюдением каких условий должно выполнять ПОв процессе решения полезной для пользователя задачи.
При тестировании требований тестировщик должен обладать знаниями в предметной области, для которой писались требования. Иначе тестировщик может просто не увидеть ошибки в требованиях или, наоборот, внести ошибку, не зная о чём хотели сказать.
При тестировании требования проверяются на наличие следующих критериев:
● Завершённость
● Атомарность
● Непротиворечивость
● Однозначность (недвусмысленность)
● Выполнимость
● Обязательность
● Прослеживаемость (трассируемость)
● Модифицируемость
● Проранжированность
● Корректность и проверяемость
Остальные типы документации описывают уже реализованное ПО и проверяется на актуальность, корректность и однозначность.
Завершённость
Требование является полным и законченным с точки зрения предоставления в нём всей необходимой информации, ничто не пропущено потому как “это же очевидно”.
Типичные проблемы:
● Отсутствуют нефункциональные составляющие требования или ссылки на соответствующие нефункциональные требования. Например: “Пароли должны храниться в зашифрованном виде” — каков алгоритм шифрования?
|
|
|
● Указана лишь часть некоторого перечисления. Например: “Экспорт осуществляется в форматы PDF, PNG и т.д.” — что понимается под “и.т.д.”?
● В тексте требования есть неоднозначные отсылки. Например: “см. выше” вместо “см. Раздел 123.45.b”.
Атомарность
Требование является атомарным, если его нельзя разбить на отдельные требования без потери завершённости и оно описывает одну и только одну ситуацию.
Типичные проблемы:
● В одном требовании содержится несколько независимых. Например: “кнопка Restart не должна отображаться при остановленном сервисе, окно Log должно вмещать не менее 20-ти записей о последних действиях пользователя” — здесь зачем-то в одном предложении описаны совершенно разные элементы интерфейса в совершенно разных контекстах.
● Требование допускает разночтение в силу грамматических особенностей языка. Например: “если пользователь подтверждает заказ и редактирует заказ или откладывает заказ, должен выдаваться запрос на оплату” — здесь описаны три разных случая, и это требование стоит разбить на три отдельных во избежание путаницы. Такое нарушение атомарности часто влечёт за собой возникновение противоречивости.
|
|
|
● В одном требовании объединено описание нескольких независимых ситуаций. Например: ”когда пользователь входит в систему, должно отображаться приветствие; когда пользователь вошёл в систему, должно отображаться имя пользователя; когда пользователь выходит из системы, должно отображаться прощание» — все эти три ситуации заслуживают того, чтобы быть описанными отдельными и куда более детальными требованиями.
Непротиворичивость
Требование не должно содержать внутренних противоречий и противоречий другим требованиям и документам.
Типичные проблемы с непротиворечивостью:
● Противоречия внутри одного требования. Например: “после успешного входа в систему пользователя, не имеющего права входить в систему…” — тогда как он успешно вошёл в систему, если не имел такого права?
● Противоречия между двумя и более требованиями, между таблицей и текстом, рисунком и текстом, требованием и прототипом и т.д. Например: “712.a Кнопка Close всегда должна быть красной» и «36452.x Кнопка Close везде должна быть синей» — так всё же красной или синей?
● Использование неверной терминологии или использование разных терминов для обозначения одного и того же объекта или явления. Например: “в случае если разрешение окна составляет менее 800x600…» — разрешение есть у экрана, у окна есть размер.
|
|
|
Однозначность (недвусмысленность)
Требование описано без использования жаргона, неочевидных аббревиатур и расплывчатых формулировок и допускает только однозначное объективное понимание. Требование атомарно в плане невозможности различной трактовки сочетания отдельных фраз.
Автор требований может быть уверен, что описывать детали требования не нужно, потому как это “очевидно”, “интуитивно”. Однако сколько людей, столько и мнений. Тот, кто написал требования вкладывает в требование один смысл, а на каждом из последующих этапов( разработки, тестирования, документирования) возникнут новые смыслы. Обязательно уточняйте требования, где нет однозначности.
Типичные проблемы с недвусмысленностью:
● Использование терминов или фраз, допускающих субъективное толкование. Например: “приложение должно поддерживать передачу больших объёмов данных” — насколько “больших”?.
● Утрированный пример требования, звучащего очень красиво, но совершенно нереализуемого и непонятного: “В случае необходимости оптимизации передачи больших файлов система должна эффективно использовать минимум оперативной памяти, если это возможно”. Вот лишь небольшой перечень слов и выражений, которые можно считать верными признаками двусмысленности:
|
|
|
○ адекватно (adequate),
○ бытьспособным (be able to),
○ легко (easy),
○ обеспечивать (provide for),
○ какминимум (as a minimum),
○ бытьспособным (be capable of),
○ эффективно (effectively),
○ своевременно (timely),
○ применимо (as applicable),
○ есливозможно (if possible),
○ будетопределенопозже (to be determined, TBD),
○ померенеобходимости (as appropriate),
○ если это целесообразно (ifpractical),
○ но не ограничиваясь (butnotlimitedto),
○ быть способно делать что-либо(capabilityof),
○ иметь возможность (capabilityto),
○ нормально (normal),
○ минимизировать (minimize),
○ максимизировать (maximize),
○ оптимизировать (optimize),
○ быстро (rapid),
○ удобно (user-friendly),
○ просто (simple),
○ часто (often),
○ обычно (usual),
○ большой (large),
○ гибкий (flexible),
○ устойчивый (robust),
○ по последнему слову техники (state-of-the-art),
○ улучшенный (improved),
○ результативно (efficient).
● Использование неочевидных или двусмысленных аббревиатур без расшифровки. Например: “доступ к ФС осуществляется посредством системы прозрачного шифрования” и “ФС предоставляет возможность фиксировать сообщения в их текущем состоянии с хранением истории всех изменений” — ФС здесь обозначает файловую систему? Точно? А не какой-нибудь «Фиксатор Сообщений»? или «фантазия сумашедшего»?
● Формулировка требований из соображений, что нечто должно быть всем очевидно. Например:
“Система конвертирует входной файл из формата PDF в выходной файл формата PNG” — и при
этом автор считает совершенно очевидным, что имена файлов система получает из командной строки, а многостраничный PDF конвертируется в несколько PNG-файлов, к именам которых добавляется «page-1», «page-2» и т.д. Эта проблема перекликается с нарушением корректности.
При тестировании на однозначность нужно проверять “ветвистость” требований, то есть если есть условия и исключения - проверять, что все они прописаны и не было упущений, которые можно трактовать по-разному.
Выполнимость
Требование технологически выполнимо и может быть реализовано в рамках бюджета и сроков разработки проекта.
Типичные проблемы с выполнимостью:
● Так называемое “озолочение” (goldplating) — требования, которые крайне долго и/или дорого реализуются и при этом практически бесполезны для конечных пользователей. Например: ”настройка параметров для подключения к базе данных должна поддерживать распознавание символов из жестов, полученных с устройств трёхмерного ввода”.
● Технически нереализуемые на современном уровне развития технологий требования. Например: “анализ договоров должен выполняться с применением искусственного интеллекта, который будет выносить однозначное корректное заключение о степени выгоды от заключения договора”.
● В принципе нереализуемые требования. Например: “система поиска должна заранее предусматривать все возможные варианты поисковых запросов и кэшировать их результаты”.
Обязательность
Если требование не является обязательным к реализации, оно должно быть просто исключено из набора требований. Если требование нужное, но “не очень важное”, для указания этого факта используется указание приоритета. Также исключены (или переработаны) должны быть требования, утратившие актуальность.
Типичные проблемы с обязательностью и актуальностью:
● Требование было добавлено “на всякий случай”, хотя реальной потребности в нём не было и нет.
● Требованию выставлены неверные значения приоритета по критериям важности и/или срочности.
● Требование устарело, но не было переработано или удалено.
Дата добавления: 2018-08-06; просмотров: 4149; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!