Feature List

Протестировать можно только реализованные вещи. Нет, строго говря, это не правда, и даже более того, вредная неправда. Тестировать надо бы начинать задолго до того, как чтото реализовано. Но сейчас не об этом. Сейчас о тестировании софта. Вот он, свеженький, только из билд-машины, еще тёплый, HEAD revision. И руки тянутся его помучить... А мучить мы будем фичи.

Все что реализовано я буду называть фичами. Слово это от англиццкого забугорного feature и обозначает "особенность" в самом грубом переводе. Нефункциональные требования тоже должны быть реализованы, согласны? И их реализация - тоже фича.

Пункто нумре два - фичи можно скучковать. Кучи фич ;) тоже можно сгруппировать при желании. Да и фича может состоять из подфич. Для каждого уровня названия придумывать замучаешься. Поэтому - просто фича. И эти фичи удобненько так складываются в дерево, не всегда правда, бывает что это граф с циклами, но не будем пока о плохом. Фича в данном случае может быть отдельным требованием, пользовательской историей, набором функций, удобством использования и даже цветовой гаммой или документацией пользователя. Важно только одно - она должна быть реализована.

Как водится - пример. Блокнот. У него есть фичи - редактирование, сохранение, чтение, сами продолжайте. У редактирования есть фичи копирование, вставка, удаление, набор текста... Сам блокнот тоже может быть фичей в каком либо приложении. Обращаю внимание, фичи, это не обязательно требования. Фича - это то чем пользователь, извините за тавтологию, пользуется. Вобщем, можно считать следующую фразу определением. Фича реализует потребность пользователя.

Теперь о качестве. Софт должен содержать набор фич для решения определенной пользовательской задачи, иначе пользователь софтом пользоваться не будет. Фичи должны выполнять свои функции в соответствии с ожиданиями пользователя, иначе последствия те же самые. Отсюда следует два простых вывода:
Чтобы качественно подготовить софт для пользователя

1. Нам нужно знать набор фич, необходимый для решения пользовательской задачи (предусмотренный для реализации в софте).
   
2. Нам нужно знать ожидания пользователя от этих фич. Замечу, некоторые ожидания пользователя могут быть зафиксированы как требования.

Хорошо, когда проект идет по канонам разработки, когда документируются требования, когда документация поддерживается в актуальном состоянии, когда всегда есть пиво в холодильнике... Наверное так бывает, но я не встречал. Поэтому, собственно, "некоторые" и "могут" выделены. Так что, первым делом, надо бы составить набор фич, которые в софте (будут) реализованы. Такой список серьёзно облегчит задачу планирования, ну и готовьтесь к тому, что этот список никогда не будет закончен. Это нормально, живой документ в живом проекте. Есть даже такой признак, если документ какое то время (не помню точно, кажется год) не меняется - он не работает.
Получив список фич можно начинать эти фичи приоретизировать, оценивать сроки их тестирования, разбирать и восстанавливать требования, готовить тесты, говорить тосты, и вообще, многое станет понятней. Так что удачи и
С наступающим новым годом, коллеги!