При создании нового функционала ПО, команда аналитиков создает определенные технические требования, а QA отдел тестирует продукт на основе данных указаний. И, естественно, это происходит еще до того, как продукт попадает к конечному пользователю.
В данном материале речь пойдет о важных моментах, на которые стоит обращать внимание при тестировании требований к ПО.
Существует целый ряд базовых характеристик, которые в обязательном порядке должны присутствовать в технической документации на любом проекте. В нее принято включать следующее:
- Полнота изложения;
- Однозначность трактовки;
- Непротиворечивость фактов;
- Необходимость реализации;
- Осуществимость выполнения;
- Полная тестируемость.
При необходимости, данный список может содержать и больше пунктов, но эти 6 – ключевые! Далее разберем каждый из них более детально.
Полнота изложения
Спецификация любого проекта должна отвечать на вопросы: все ли описано? Не могли ли что-то пропустить? Нет ли скрытого функционала?
Дабы быстро и эффективно протестировать этот пункт, достаточно создать специальный чек-лист тестов функциональности ПО. Рекомендуется создавать подобные документы уже на стадии ознакомления технического задания (не просто прикидывать в уме возможные сценарии проверки, а документировать каждый пункт).
Естественно, что процесс написания тестов – работа трудоемкая. Но она существенным образом сэкономит вам время в будущем, так как чек-лист проверки будет готов и останется только лишь внедрить все запланированные тесты.
Однозначность трактовки
Требования продукта должны трактоваться всеми участниками одинаково. Все противоречия, которые присутствуют в техническом задании, должны быть конкретизированными для всеобщего понимания.
ТЗ не должно содержать двоякого смысла, такие моменты нужно постараться исправить. Конечно же, не стоит выискивать каждую мелочь и стараться расписывать детально самые мельчайшие функциональные блоки. Просто смысл и трактовка документа не должна вызывать противоречивой интерпретации как со стороны отдела тестирования, так и со стороны отдела поддержки/разработки.
Если документ только для внутрикорпоративного пользования, то можно пойти на компромиссы, некоторые моменты обсудить вживую. А если документ предназначен для клиента, тут придется потрудиться над детальным описанием ВСЕГО, чтобы получать как можно меньше уточняющих вопросов.
Непротиворечивость фактов
Суть требований не должна противоречить сама себе. Порой, подобное может возникнуть, когда количество требований просто аномальное. Отдел аналитики (те люди, которые создают технические задания после диалога с клиентом) просто забывает, что уже описывал функционал Х и по новой придумывает и детализирует поведение конкретного функционала. И порой, описывает совершенно другое, а не то, что необходимо.
Необходимость реализации
Очень хорошо, когда техническая документация составлена в максимально полном объеме. Но это не говорит о том, что простенький функционал нужно растягивать на 20 страниц. Пишите в ТЗ только то, что нужно, а именно:
- Основа ТЗ – разрабатываемый функционал, базовый сценарий разработки ПО, виды потенциальных багов;
- Пользовательская документация – руководство о том, как пользоваться данным ПО.
Осуществимость выполнения
Данный пункт в большей степени касается отдела разработки. Именно они должны технически убедиться в том, что разработанный ими продукт будет функционировать именно так, как этого хочет клиент и содержание технического задания.
Полная тестируемость
Есть ли возможность протестировать функционал в данный момент? О данном факте стоит задуматься заранее. Иначе будет так, что программист создал ПО, и только потом QA-специалист понимает, что текущую задачу нет возможности проверить. Либо же можно протестировать, но нет возможности создать автоматические тесты и прочее.
Оставить комментарий