Сопровождение реализации и тестирования
Во время разработки функциональности, описанной в пользовательской истории, системный аналитик, автор, отвечает на вопросы разработчиков, чтобы помочь правильно понять ожидаемое поведение системы и предъявляемые к ней требования, а так же на вопросы тестировщиков, так как одновременно со стартом реализации начинается написание сценариев тестирования пользовательской истории.
Для более эффективного расходования времени могут быть организованы совместные звонки - Ckeckpoint, где присутствуют все заинтересованные участники команды: системный аналитик - автор, разработчики, совместно работающие над задачами реализации истории (один или несколько, в зависимости от сложности истории), Архитектор проекта, Product Owner, Lead разработки, Lead тестирования и тестировщики, которые будут непосредственно выполнять тестирование реализации. Так же для всех участников Ckeckpoint организовывается отдельный совместный чат для обсуждения вопросов реализации и тестирования этой истории.
Чем лучше написана история, тем меньше вопросов задают коллеги. Качественно написанная история экономит время системного аналитика на прояснение написанного.
Бывают случаи, когда в процессе разработки необходимо скорректировать или дополнить историю. Это может происходить по следующим причинам:
- есть пробелы в аналитике
- или в процессе реализации было найдено решение лучше, чем описано в истории.
- от Заказчика поступили пожелания или корректировки требований, не противоречащие написанному и не влияющие на сроки разработки, а так же, в исключительных случаях, другие пожелания и корректировки Заказчика (но только по согласованию в руководителем проекта).
Пробелы в аналитике, как правило, выявляются на этапе внутренней проверки истории владельцем продукта, архитектором и тестировщиком (этап Review User Story) или при согласовании пользовательской истории с заказчиком. Если аналитик вовремя передает историю на ревью и согласование, то у проверяющих и согласующих достаточно времени для проверки. Кроме того, шаг проверки вариантов тестирования, который выполняет системный аналитик, так же может стать источником корректировки и дополнения требований.
В процессе реализации может быть найдено лучшее решение. Обычно это незначительные корректировки в моделях данных (в том числе изменение названий или типов атрибутов), дополнение в явном виде алгоритмов каких-либо проверок, изменение текстов сообщений с целью сделать их более универсальными.
Если пользовательская история было скорректирована, то необходимо внести информацию об этом факте в комментарии к истории и оповестить согласующих лиц заказчика. Оформление этой информации выполняется в соответствии с требованиями, установленными регламентами проекта.
Результатом работы системного аналитика на этапе сопровождения реализации и тестирования будет следующее:
- все вопросы отвечены,
- пользовательская история актуализирована (при необходимости),
- тест-кейсы проверены,
- задачи приняты и готовы к демонстрации заказчику.
Разберем подробнее несколько важных шагов.
Проверка тест-кейсов
Тестирование и разработка требований (написание пользовательской истории) тесно связаны. Чем лучше требования, тем качественнее тесты. Чем качественней анализ тестирования (проверка текст-кейсов), тем лучше требования. Проверка тест-кейсов, подготовленных тестировщиком, необходима, чтобы удостовериться, что:
- сценарии тестирования покрывают всю бизнес-логику и все требования, содержат тесты на нетривиальные кейсы пользовательской истории,
- что требования, описанные в User Story, поддаются проверке и могут служить основой для тестирования системы.
Как говорилось выше, при написании тест-кейсов тестировщик задает вопросы системному аналитику. Отсутствие вопросов по существу работы системы (открытых вопросов, начинающихся с "почему, "где", "зачем", "как", "в какое время" и т.п.) является индикатором высокого качества пользовательской истории. Однако, следует быть бдительным, если тестировщик совершенно не задаёт вопросов, так как, более опытные тестировщики задают серию уточняющих вопросов, чтобы убедиться, что правильно поняли пользовательскую историю. В результате изучения истории они готовят тест-кейсы.
Помните, что тестирование того, что разработчики создали, - не то же самое, что тестирование того, что они должны были сделать. Так как, тестирование системы, выполненное на основе кода, может стать самосбывающимся предсказанием: система может вести себя именно так, как описано в вариантах тестирования, созданных на основе кода, но это не означает, что она соответствует потребностям пользователей. Реализацию следует тестировать на соответствие тому, что система, как записано в требованиях, должна делать, а не на предмет дизайна или кода. Если требования к системе сформулированы плохо, то тестировщики обнаружат множество требований, самостоятельно выведенных (верно или неверно) и реализованных разработчиками.
При проверке вариантов тестирования следует учитывать следующее:
- Необходимо, чтобы каждое функциональное требование можно было проследить по крайней мере в одном варианте тестирования (тест-кейсе), чтобы ни одна из ожидаемых реакции системы не осталась непроверенной.
- Тестирование должно выполняться на каждом уровне конструирования ПО, не только на уровне конечных пользователей. То есть, так как часть кода в приложении недоступна пользователям напрямую, однако она необходима для внутренних взаимодействий, то каждая функция должна удовлетворять собственным требованиям, даже если функция невидима для пользователя.
- Опытные тестировщики могут усовершенствовать тестирование, основанное на требованиях, за счёт использования дополнительных тестов, основанных на истории системы, предполагаемых сценариях использования (явно отсутствующих в пользовательской истории - редких кейсах), общих характеристиках качества и случайностях.
Приемка реализации пользовательской истории системным аналитиком
После разработки пользовательской истории аналитику необходимо самостоятельно проверить.
1) соответствует ли реализация описанию в пользовательской истории,
2) корректность работы реализации на ключевых и сложных кейсах.
В процессе проверки системный аналитик может завести баги, обнаруженные во время тестирования. Необходимо согласовать их с багами, заводимыми тестировщиком, чтобы не было повторов.
Этот этап дополняет локальное демо и в зависимости от регламента проекта может отсутствовать.
Локальное демо
Цель проведения локального демо - продемонстрировать всем заинтересованным лицам команды (состав смотри выше) реализацию и убедиться, что функциональность готова, и можно назначать срок для демонстрации заказчику. Локальное демо проводит Lead разработки. От системного аналитика на данном этапе требуется внимательно смотреть демонстрацию, чтобы убедиться в отсутствии багов, кроме того, участники могут задавать вопросы, касающиеся требований, задача аналитика - ответить на эти вопросы. Локальное демо проводится на локальной машине разработчика.
Демонстрация заказчику
Цель проведения демо - это демонстрация заказчику того, что продукт работает, как и ожидалось Локальное демо проводится в тестовой среде (на QA или DEV стенде).
Демонстрация заказчику реализации пользовательской истории - это этап сдачи-приемки функциональности заказчику. Если по результатам этого демо заказчик примет решение о готовности этой функциональности, то она будет включена в релиз. Если нет, то функциональность подлежит доработке и сроки включения в продуктивную среду зависят от времени, необходимого на доработку.
В разных проектах происходит по разному: в одних демонстрацию проводит сам аналитик, в других – другие члены команды, но присутствие аналитика на демонстрации обязательно.
Так как аналитик собирал, анализировал, документировал и исправлял после проверки требования, то если у заказчика возникают вопросы по ходу демонстрации, аналитик знает, что ответить.
Аналитик должен способствовать сдаче реализации заказчику. Если каких-то требований не было и они появились во время демонстрации, то нужно во-первых отметить это вслух, а во-вторых, зафиксировать их в протоколе, в-третьих, это требование нужно будет оформить в виде документа – в виде Change Request.
Если в процессе демонстрации был обнаружен баг, то его необходимо тоже зафиксировать, описать и совместно с Product Owner определить сроки его исправления.
На этом этапе можно оценить командный результат:
– результат на «отлично» - функциональность принята, результат на «хорошо» функциональность принята и получен список улучшений, результат на «тройку» - функциональность принята, но есть баги на исправление в релиз баг-фиксов, результат на «двойку» – функциональность не принята, зафиксированы баги, реализация будет выпилена из релиза, результат на «кол» – не успели сделать.
Проверка Deploy Checklist
Это для системного аналитика финальный этап в сопровождении User Story. Перед тем, как будет выполнен деплой нового релиза, возможно, на PROD-стенде необходимо выполнить какие-то дополнительные действия: запустить какие-то скрипты, прогрузить какие-то справочники, установить какие-то значения системным параметрам и т.п, то есть, действия, от которых зависит, что функциональность User Story будет работать корректно. Если есть такая необходимость, то такая информация вносится в Deploy Checklist. Ответственным за внесение подобной информации является Lead разработки, но аналитику следует так же проверить все ли учтено и если обнаружены пробелы сообщить Lead'у разработки.
