5 Основных Атрибутов Тестирования Требований
Большинство багов берут свое начало именно с требований. Чтобы уменьшить количество последующих багов в проекте, лучше всего ввести в процесс разработки этап тестирования требований, который должен быть завершен до начала собственного написания кода.
Такие баги, исходящие из требований, довольно дорого исправлять, и с течением времени стоимость будет расти только в геометрической прогрессии. К счастью, в команде разработки всегда есть человек, который знает продукт на все 100% (ведь этот проект и есть его работа) и это тестировщик ПО.
Давайте разберем следующие 5 ключевых атрибутов тестирования требований.
Завершенность
Требование должно содержать всю необходимую для разработчиков и не только информацию.Требование также должно включать все ключевые детали, раскрывающие нужды пользователей.
Для того, чтобы тестирование требований было более эффективны, используйте, так называемый, эвристический подход к тестированию. Эта стратегия позволяет определять проблемные места в проекте, даже с точки зрения тестирования требований.
Эвристики могут быть полезны в определении типа ошибки, ее частоты, места ее возникновения, а также эвристики помогут выявить пробелы в требованиях.
Вы можете использовать эвристики как способ напоминания о необходимости тестирования чего-либо в приложении, например, SFDPO:
- Структура: Что это?
- Функция: Что оно делает?
- Данные: С чем оно работает?
- Платформа: Что его поддерживает?
- Операции: Как оно будет использовано?
Вы можете придумать свои собственные эвристики и применять их ко всему приложению, а также к отдельным модулям и для анализа требований. Например, в моем текущем проекте мы создали шаблоны чек-листов для каждого типа функциональности.
Через некоторое время команде нужно реализовывать аналогичные модули, но с помощью готовых шаблонов тестировщикам не нужно будет изобретать велосипед заново при необходимости тестирования требований.
Допустим, вы ранее протестировали метод оплаты, называемый «кредитная карта». Для тестирования нового метода, называемого «счет», вы можете повторно использовать некоторые чек-листы, используемые ранее для тестирования метода «кредитной карты». Нужно создавать чек-листы для каждого типа задач, чтобы не забывать тестировать требования к ним.
Например, для всплывающих окон нужно использовать эвристику SPACES. SPACES расшифровывается как:
- Несколько всплывающих окон: Есть ли проблемы со всплывающими окнами? Как вы должно действовать в случае, если будут 2 или более всплывающих окна?
- Локации: Где должны быть размещены всплывающие окна? На главной странице? На лендинге? На странице вывода результатов поиска?
- Аутентификация: Всплывающие окна видны всем, или только авторизованным пользователям?
- Закрытие: Чтобы закрыть всплывающее окно, пользователям нужно кликнуть на его фон? Или нужно нажать на значок закрытия всплывающего окна?
- Ввод: Поддерживается ли кнопка ввода при отправке формы внутри всплывающего окна?
- Режим: Всплывающее окно появляется снова? И если так, то когда (После входа/выхода из учетной записи, после чистки кэша, через 2 недели)?
Если вы пропустили что-то в тестировании требований, включите данную функцию в ваш чек-лист, чтобы не пропустить ее больше при тестировании аналогичной функциональности. В большинстве случаев эвристический подход значительно более эффективен, чем слепое тестирование.
Однозначность
Требования должны быть „прозрачными”, недвусмысленными, понятными для всех.
Двусмысленность требований возникает в том случае, если несколько интерпретаций требования являются правильными. Любая идея или утверждение, значение которых нельзя окончательно установить, будут двусмысленными. Конечно, многое зависит и от опыта читающего такие требования. Для избежания подобных случаев, рекомендую включить определение терминов (обычно используемых в спецификациях требований) в глоссарий.
Контекст также может играть определенную роль в устранении двусмысленности. Например, один и тот же отрывок из требований может казаться двусмысленным в определенном контексте, и недвусмысленным без контекста.
Не делайте собственные выводы, если что-то непонятно или имеет двусмысленный подтекст. Поговорите с бизнес-аналитиком или владельцем продукта.
Корректность
Все утверждения должны быть верными, правдивыми и иметь смысл.
Тестирование системы на наличие неверных требований – трата времени, денег и усилий. Насколько правильно поставлено требование? Это действительно то, что требуется от системы, или кто-то допустил ошибку при написании требований?
Логичность
Требования не должны противоречить другим требованиям. Каждое требование должно полностью соответствовать документации заказчика, а также внутренним и внешним стандартам.
Обратите внимание на общую формулировку в ваших требованиях. Например, если все кнопки „Подтвердить” должны быть синего цвета во всем приложении, поместите данное требование в список „опасных требований”, а затем проанализируйте остальные требования на наличие противоречий.
Это поможет категоризировать требования. Например, вы можете определить все требования, касающиеся кнопок, всплывающих окон, полей и так далее в одну категорию, а затем проанализировать их всех на наличие противоречий.
Распределите все требования, начало которых вы можете проследить в других, и проанализируйте такие требования. Довольно часто несоответствие можно обнаружить в требованиях более высокого уровня, где требования низких уровней из других областей могут противоречить друг другу.
Проверяемость (тестопригодность)
Должен быть способ проверить, соответствует ли реализация требованиям. Можно ли проверить, что требования выполнены? Как это проверить и какие данные/инструменты вам нужны?
Обслуживать тестируемые приложения довольно легко, и этот процесс будет менее дорогостоящим. К тому же шанс, что именно такое приложение будет удовлетворять потребности пользователей, намного выше. Вот почему тестируемость так важна для поддержки приложения.
Другие атрибуты хороших требований
Хорошие требования должны быть прямыми, в строгой форме, без неопределенностей и двусмысленности. Каждое требование должно быть измеримо с точки зрения важности, с точки зрения достижения результата. Требования также должны быть полными, без каких-либо противоречий. Другие атрибуты хороших требований:
- Неизбежность
- Приоритет
- Трассируемость
- Краткость
Но все они, так или иначе, перекликаются с теми атрибутами, которые я описала выше.
Тестирование требований поможет вам сделать ваши требования более понятными. Этот тип тестирования экономит много времени и усилий по обеспечению качества разработки.
Тестирование требований должно быть завершено до начала итерации, и разработчики не должны писать код до тех пор, пока все требования не будут протестированы.
Пресекайте баги на корню. Тестируйте требования.
Если вас интересует сфера тесирования ПО, вы имеете базовые знания, но хотели бы стать более эффективным специалистом, то приглашаем на курсы тестирования ПО в Минске.
Комментарии
Отправить комментарий