Представьте себе, что вы разработали программный продукт. Надежный, безопасный, поддерживающий многочисленные устройства и работающий одинаково хорошо в разных браузерах.
Вы запустили дорогостоящую рекламу, которая дала отличные результаты: за первую неделю число установок превысило ожидаемое количество. Отлично! Но спустя пару недель показатели резко ухудшились. Пользователи начали отказываться от продукта, при этом сообщений о критичных дефектах не поступает. В чем же дело?
Причин неудачи может быть много. Одна из них – ваш продукт не соответствует ожиданиям пользователя. Иными словами, пользователь не может решить свою задачу с помощью вашего продукта.
В таком случае, каким бы удобным, быстрым и защищенным ваш продукт ни был, его ценность для пользователя равна нулю. Избежать подобного сценария можно, если на самом начальном этапе разработки грамотно выявить пользовательские требования.
Требования важны. Без них разработка продукта будет представлять собой движение на ощупь.
Для выявления требований стоит задать следующие вопросы:
- Чего ждет от продукта пользователь?
- Как пользователь будет взаимодействовать с продуктом?
- Какие функции должны быть внедрены, чтобы пользователь мог решить свою задачу?
- Чего мы достигнем, разработав ту или иную функциональность?
Требования – это то, что будет передано команде разработки и QA, поэтому они должны быть предельно точны. Мы рекомендуем разбить всю функциональность на категории и прописать требования отдельно.
Категории требований
|
Пример
|
Интерфейс
|
Все элементы интерфейса понятны всем группам пользователей. Пользователь может совершить покупку, оформить заказ через интерфейс.
|
Производительность
|
В моменты пиковых нагрузок система должна обрабатывать 200 заказов в секунду. Прокрутка одной страницы 40-страничного документа не должна
занимать более 1 секунды.
|
Доступность
|
Вся информация в системе должны быть доступна для людей с ограниченными физическими возможностями.
Вся функциональность для людей с ограниченными возможностями должна сопровождаться детальными описаниями и подробными инструкциями.
|
Безопасность
|
Система должна проверять все входящие данные. Система должна идентифицировать права всех пользователей, пытающихся получить доступ к системе.
|
Случается и так, что собранные требования оказываются двусмысленными, содержат неясные формулировки. Это отражается на качестве документации и в конечном итоге приводит к ошибкам и дефектам, которые иногда обнаруживаются слишком поздно.
Велика вероятность, что требования ненадлежащего качества дадут о себе знать уже после релиза, когда стоимость исправления ПО в разы выше, чем на стадии разработки.
Вот почему важно профессионально подходить к выявлению и сбору требований, их передаче технической команде. Это поможет минимизировать затраты на доработки и переделки после выпуска продукта.
Специалисты по работе с требованиями: кто они?
Все чаще бизнес привлекает экспертов в предметной области для выявления требований. В IT-компаниях этими экспертами часто выступают бизнес-аналитики, которые служат посредниками между заказчиком и технической командой, погружаются в индустрию клиента, способствуют тому, чтобы финальный продукт полностью отвечал всем требованиям.
Когда требования собраны и переданы командам, продукт разработан и протестирован, остается последний шаг – это приемочное тестирование (User Acceptance Testing, или UAT).
Приемочное тестирование проводится с участием реальных пользователей. Если это невозможно по каким-либо причинам – ответственные специалисты должны представить себя на их месте.
4 главные трудности приемочного тестирования
1) UAT выполняется силами команды по функциональному тестированию
Часто из-за нехватки бюджета или недооценки важности приемочного тестирования эта задача передается функциональным тестировщикам, что сводит к нулю весь смысл данного мероприятия. Функциональные тестировщики продолжат проверять функциональные аспекты качества в отдельности. Специалисты по приемочным испытаниям же смогут оценить продукт целиком, как это будет в будущем делать пользователь.
Рекомендуем: привлекайте к приемочным испытаниям команду со знанием вашей отрасли.
Если проект выполняется силами удаленной распределенной команды, нередко коммуникация затрудняется. В результате обсуждение фич и дефектов между командами происходит недостаточно оперативно, что вызывает сдвиг в сроках.
Рекомендуем: устанавливайте надежную коммуникацию на проекте и используйте надежные инструменты для внесения информации о дефектах.
3) Поступление новых требований
Никто не может запретить заказчику ставить новые требования к продукту. Однако как быть, если новые требования появляются на этапе тестирования, и заказчик просит их учесть в ближайшем релизе?
Рекомендуем: менеджер проекта должен принимать взвешенное решение о том, есть ли возможность учесть данные требования или работу над ними стоит перенести в следующую версию. Иногда придется объяснить заказчику, что новое требование сместит сроки релиза продукта.
4) Планирование UAT
Приемочное тестирование завершает цикл разработки ПО и обычно проводится после регрессионного тестирования всего продукта. Обычно к этому моменту дело осложняется поджимающими сроками, подгоняющими менеджерами, поэтому важно, чтобы критерии приемо-сдаточных испытаний были уже разработаны.
Рекомендуем: планирование приемочного тестирования должно проходить на стадии анализа требований, то есть когда с заказчиком обсуждается будущий продукт. Уже в это время специалисты по UAT должны смоделировать реальные пользовательские кейсы, которые в будущем будут реализованы технической командой.
Заключение
Любой проект с разработкой ПО может оказаться убыточным без учета пожеланий и ожиданий предполагаемого пользователя. Цель приемочного тестирования – определить, отвечает ли созданный продукт заранее разработанным требованиям. Результаты приемочного тестирования передаются представителю заказчика, который принимает решение о выпуске продукта или его доработке.
Грамотно проведенное
приемочное тестирование помогает выпустить на рынок качественный и востребованный продукт.
Свяжитесь с нашими экспертами, чтобы узнать, что такое приемочное тестирование и получить бесплатную консультацию.
