Мне просто хочется быть «принятым» Часть 2 [Перевод]

 Продолжение статьи о приемочном тестировании. Далее автор рассматривает критерии готовности, типы приемочных тестов с разных точек зрения, а также понятие мета-приемки — словом, все базовые аспекты UAT, с которыми должен быть знаком аналитик.

Критерии готовности

Я обычно рекомендую установить критерии готовности для пользовательских историй до того, как они готовы к «спринту». С точки зрения приемочного тестирования, я обычно ищу что-то вроде этого:

• Не менее 3-5 и не более 10 приемочных тестов для одной истории.
• Из них 1-2-3 должны быть направлены на выявление функционального поведения.
• Из них 1-2 должны быть направлены на выявление нефункционального поведения.
• Поищите также положительные и отрицательные тесты; например, на определение условий ошибок.
• По возможности тесты должны быть количественными.
• Каждый тест должен быть независимым.
• Я принимаю около 10 приемочных тестов для одной истории, потому что большее их количество начинает выглядеть как функциональные тесты.
• Тесты не должны быть процессуально ориентированы, например, контроль владельца продукта как один из приемочных тестов.

 

При определении критериев готовности я был максимально исчерпывающим. В реальной жизни лишь некоторые из них подойдут либо будут использоваться в принципе. Я обнаружил, что установление критериев готовности может быть невероятно полезной практикой в улучшении качества вашей работы.

 

Как функционирует приемочное тестирование?

Прежде всего, я не думаю, что вы можете точно оценить историю без указания ее приемочных критериев. Например, эпосы, которые попадались мне, зачастую их не имеют, однако они оцениваются. Но мы не говорим о данных оценках; история будет переоцениваться после того, как мы разобьем ее на части и составим так называемые дочерние истории. И для этих историй, безусловно, будет разработано приемочное тестирование.

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

Если мы вернемся к нашему примеру пользовательской истории, то если история была слишком большой, то мы могли бы разделить ее на части по определенным приемочными тестами границам. Например, основные атрибуты в одной части, и подстрочные и надстрочные индексы в хедерах и футерах в другой.

 

Владелец продукта

В конечном счете, приемочные тесты играют на руку владельцам продукта. Они представляют собой механизм для общения на основе приоритетных ценностей бизнеса. Они также являются признаком завершенности пользовательских историй. Лично мне нравится подход, при котором команда приносит свою историю, вне зависимости от того, завершена ли она, а владелец продукта проверяет и саму историю, и приемочные тесты, а затем окончательно принимает пользовательскую историю. Так что с этой точки зрения, приемочные критерии являются условиями завершенности пользовательской истории.

 

META-приемка

Я слышал о понятии мета-критерии приемки, которые присутствуют во всех историях, которые пишет организация. Они, как правило, типичны для требований определенной сферы. Например, в прошлом я работал в EMC, и там было документально утвержденное мета-требование что ни одна функция (а также ни один прецедент, история, свойство) не должны искажать данные. Компания EMC производит устройства хранения данных, поэтому такой мета-критерий был необходим.

Так что же, это необходимо упоминать в каждой пользовательской истории? Мы решили, что ответ должен быть «нет». То, что мы бы документировать его в качестве критерия мета-приемки, должно быть частью приемочного тестирования. Я часто вижу организации, описывающие эти требования для нефункционально ориентированных критериев приемки, особенно в таких областях, как безопасность и производительность.

 

Технические пользовательские истории

Еще одна область, где акцент на приемочных тестах действительно поможет при написании вашей истории — это технически ориентированные истории. Это могут быть истории сосредоточены на рефакторинге, инфраструктуре, инструментах, исправлении ошибок, тестировании инфраструктуры — практически все, что представляет техническую ценность для команды, но не является непосредственно частью требований заказчика.

В случае с такими историями, критерии ориентированы на более глубокое понимание аспекта истории, связанного с разработкой. Вот пример технической истории:

Пользователь, который проходит аутентификацию, должен иметь возможность авторизоваться через веб-приложение, чтобы управлять своим аккаунтом через Интернет.

Давайте потратим немного времени на написание приемочных тестов. Вот несколько идей:

1. Убедиться, что все веб-запросы проходят через уровни служб и получают ответ в течение 2-х секунд.
2. Убедиться, что протоколы аутентификации HTTP, Radius SecureID и LDAP поддерживаются.
3. Убедиться, что тайм-аут аутентификации происходит через 25 секунд.
4. Убедиться, что 2-фазные вопросы (в общей сложности 3) представлены через каждые 3-5 попыток входа.
5. Убедиться, что 2-фазные вопросы применяются после 3-го неправильного ввода пароля.
6. Убедиться, что максимальное количество попыток для введения пароля – 5.

Я надеюсь, вы поняли, насколько полезными являются приемочные тесты и поняли разницу между двумя их типами на моих примерах.

 

Заключение

На  написание этой статьи меня вдохновил мой коллега – Martin Acosta. Он написал мне с просьбой прояснить вопрос насчет приемочного тестирования. И тут я осознал, что этот пробел мне необходимо заполнить.

Я также надеюсь, что моему коллеге данная статья также показалась интересной. Как и остальным читателям.