Home

Автор: Юлия Нечаева

Ревьюер: Вячеслав Панкратов

Стандартный жизненный цикл программного обеспечения делится на этапы:

1. возникновение и исследование идеи;
2. анализ требований и проектирование;
3. программирование;
4. тестирование и отладка;
5. ввод программы в действие;
6. эксплуатация и сопровождение;
7. завершение эксплуатации.

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

Идея –> требования –> разработка –> тестирование –> релиз.

Итак, требования первичны, до того, как пустить продукт в разработку, разработчики должны четко представлять себе, ЧТО они должны разработать.

Это же ЧТО должны быть готовы тестировать команда тестировщиков к моменту передачи им продукта. Это ЧТО должно быть переводом бизнес-идеи и желания заказчика на детальный язык проектной команды. Это ЧТО должно быть одно для всей команды в любой момент времени.

Это ЧТО создается в результате анализа требований – этапа жизненного цикла программного обеспечения, во время которого требования заказчика уточняются, формализуются и документируются. Оно может (и будет) меняться в течение процесса разработки, но оно должно поддерживаться всей командой и любые изменения должны утверждаться заказчиком.

С теорией закончили, приступим к практическим исследованиям.

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

Жизненный цикл требований при таком подходе следующий:

Бизнес-идея заказчика –> описание требования ПМом или, что реже, аналитиком –> поступление в разработку –> реализация –> поступление реализации в тестирование.

Слабые стороны:

• требования не детализированы с нужной степенью детальности (пример: требование «пользователь должен быть способен оплатить заказ кредитной картой» не описывает ни сам процесс этой оплаты, ни процесс валидации кредитной карты, ни дальнейшую судьбу пользовательских денег);
• требование не проанализировано всей командой на предмет разрабатываемости, тестируемости, непротиворечивости, однозначности и полноты (пример: требование «покупатель должен быть способен оплатить заказ кредитной картой. Максимальная сумма заказа – 1 000 000 $». Внешние API для оплаты позволяют проводить транзакции на сумму не более 50 000$. Требование невыполнимо»);
• требование может быть понято различными группами проектной команды по-разному;
• разработчики реализуют требование на основании своего видения, которое основано НЕ на понимании бизнес-логики. Часто требование преобразовывается под давлением выбора метода реализации и поступает в команду тестирования, имея мало общего с начальным желанием заказчика;
• команда тестирования тестирует приложение не на основании первоначальных требований, а на основании их реализации. При этом, если изначальные требования были покрыты тестами, то эту работу приходится переделывать. (пример: «покупатель должен быть способен оплатить заказ кредитной картой». Разработчики позволяют пользователю вводить название кредитной карты, номер и прочую атрибутику в пустые поля. Валидация идет лишь на наличие достаточной суммы на счете. Тестировщики пишут тесты, основанные на встроенном списке кредитных карт и пре-валидации номера и секьюрити кода до отправки данных на внешний API. Тесты оказываются ненужными, так как реализация отлична от ожидаемой.)

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

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

Такой процесс можно описать схемой:

ПМ – de-jure ответственен за КОГДА? ЧТО?, de facto – за «объяснить заказчику, почему на выходе получилось не то, что он хотел, и почему возникло такое непонимание требований командой»

QC – de-jure ответственны за качество, de facto – за нахождение ошибок

Dev – de-jure ответственны за КАК? , de facto – ещё и за ЧТО?)

Причина возникшей ситуации – отказ от тестирования требований.

Что можно изменить в таком процессе? Где взять ресурсы для предварительного анализа требований при отсутствии аналитического отдела?

Ответ: поручить анализ и доразработку требований команде тестирования. У неё на это есть время, желание и способности.

Получим следующий жизненный цикл требования:

Желание заказчика –> описание требования ПМом ­­­­­­­–> поступление требований в тестирование –> тестирование требований на корректность, непротиворечивость, целостность, однозначность, полноту и тестируемость –> выяснение спорных моментов с заказчиком –> определение методов реализации совместно с командой разработки, тестирование требований на реализуемость –> поступление в разработку –> поступление реализации в тестирование.

Сильные стороны:

• команда тестирования анализирует требования не только с точки зрения реализуемости и тестируемости, но и с точки зрения бизнес-логики, основываясь на целях заказчика и удобстве конечного пользователя; (пример: своевременное выявление необходимости пре-валидации номера кредитной карты в вышеописанном примере повлечет за собой разработку изначально правильного функционала, не приведет к потере написанных тестов, повысит корректность работы конечного приложения, удобство конечного пользователя и удовлетворенность заказчика);
• в случае спорных вопросов или нехватки информации заказчику на выбор предоставляются сценарии реализации, описанные с точки зрения конечного пользователя, а не с точки зрения программной реализации, что увеличивает вероятность адекватного ответа (пример: в вышеописанном примере вопрос «какие кредитные карты должно поддерживать приложение? Нам необходимо это знать для реализации пре-валидации номеров» приведет к куда более точному ответу заказчика, чем «как должна работать оплата заказов)»;
• своевременно заданные и правильно сформулированные вопросы заказчику предотвращают ситуацию, когда желания заказчика изначально были понятны неправильно (пример: в вышеописанном примере заказчик, возможно, считает пре-валидацию номеров кредитных карт очевидной, так как именно так реализовано большинство приложений, существующих на рынке. А возможно, он даже не знает про валидацию, но отловив случай с необрабатываемым неправильным введением названия карты (MatserCard), он явно будет недоволен);
• метод реализации выбирается совместно с командой разработки на основании критериев, важных для заказчика, а не по степени удобства разработки;
• тестами покрываются уже протестированные требования с известными методами реализации, что приводит к большей степени покрытия и повышению качества продукта;
• анализ вероятностей появления ошибок в различных частях приложения позволяет перераспределить ресурсы по задачам на начальном этапе с целью предотвращения часто возникающих ситуаций с «тушением пожаров» и «латанием дыр.» (пример: если система пре-валидации кредитных карт будет реализована с использованием юнит-тестов, то это, безусловно, увеличит время на реализацию этого функционала, зато снизит время на тестирование (достаточно будет проверки лишь по одному валидному и невалидному сценарию для каждого вида карт) и снизит вероятность появления ошибок в этом, одном из наиболее важных для приложения, модуле.)

Такую организацию процесса можно описать схемой:

ПМ – ответственен за КОГДА?

QC – ответственны за ЧТО?, КАК? качество этого ЧТО

Dev – ответственны за реализацию ЧТО методом КАК.

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

Время:

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

Желание:

No comments. Во-первых, это интересно, во-вторых – динамично, в третьих – ответственно. На мой взгляд, этих критериев достаточно для мотивирования команды тестирования.

Способности:

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

Выигрыш при такой организации процесса затрагивает абсолютно все аспекты разработки продукта:

• команда разработки получает детальные, четкие, обоснованные, реализуемые требования, что предотвращает ситуацию, когда неправильно понятые изначально требования приводят к необходимости переделывать;
• команда тестирования получает возможность покрывать тестами утвержденные всей командой и заказчиком требования, что предотвращает ситуацию, когда написанные тесты не соответствуют реализации;
• ПМ получает возможность более гибко управлять ресурсами и временем разработки продукта, что обеспечено ранним выявлением «узких мест», своевременным согласованием с заказчиком спорных моментов;
• заказчик получает продукт, который полностью соответствует его желаниям и бизнес-процессам.

Так что, доверьте требования команде тестирования – и они будут реализованы так, как надо с точки зрения заказчика, а именно удовлетворение заказчика и является конечной целью любой проектной команды.

Обсудить в форуме