Проектирование программного обеспечения:

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

Вот что вам нужно:

• Поля ввода для имен пользователей и паролей

• Кнопка отправки

• Способ сообщить пользователю, если он ввел свои данные неправильно

• Способ восстановления забытых данных

• Способ регистрации учетной записи, если у пользователя ее еще нет.

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

Итак, достаточно ли этого?

А что, если вы хотите написать что-то вроде поведенческого теста? Как перевести то, что написано выше, в шаги пользователя? И достаточно ли такой подход "короткого теглайна" говорит вам о том, как пользователь на самом деле выполняет эти действия? Задумывались ли вы о том, что происходит после того, как пользователь успешно вошел в систему? Помогает ли такой подход размышлять подобным образом?

Мы знаем, что нам нужно, но как это воплотить в хорошо спроектированную функцию?

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

Что такое критерии приемки?

Критерии приемки — это неоправданно расплывчатое название набора шагов, которые описывают, как пользователь может взаимодействовать с конкретной функцией. Они написаны в формате, использующем шаги Given, When, и Then , и сопоставлены с действиями пользователя. Благодаря этому их легко преобразовать в поведенческие тесты. Разработка функции таким образом также является отличным способом выявления других вещей, которые могут понадобиться для ее работы.

Пример критериев приемки для вашей формы входа в систему может выглядеть следующим образом:

Given I have an account registered with <app>
And I am viewing the login form
When I enter correct login details
Then I should be logged in
And I should see the homepage

Given определяет некое предварительное условие для выполнения действия. When определяет действие. Then определяет результат действия. Мы также можем использовать  And  для дополнения любого из этапов, внося дополнительные условия. Этот подход логичен, понятен и прост. Каждый из этих этапов точно объясняет, что должно произойти в сценарии.

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

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

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

Как написать хороший AC?

Итак, вы решили написать этот продукт, но как сделать это правильно? Приведенная выше функция входа в систему очень проста, но более сложные концепции могут привести к путанице в AC, поэтому важно помнить о следующих вещах:

1. Пишите с точки зрения пользователя

Это правило номер один. Критерии приемлемости - это совсем не о том, каким образом вы, как разработчик, могли бы взаимодействовать с чем-то. И не о том, как вы хотите, чтобы кто-то взаимодействовал с чем-то. Необходимо представить себя самым бестолковым и раздраженным существом на планете — пользователем. Потому что именно он будет возиться с вашей "замечательной" формой входа в систему.

2. Простота

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

3. Понятный язык

Этот пункт связан с пунктом 2 и напрямую влияет на него. Пишите AC простым языком. Одно из главных преимуществ такого подхода заключается в том, что он может быть понятен нетехническим людям. Инструмент, способный описать функцию для любого человека и одновременно управлять реализацией/тестированием, бесценен. Сложный же язык будет этому препятствовать.

4. Не заостряйте внимания на деталях реализации

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

5. Не будьте техническими специалистами

И снова этот пункт связан с предыдущим. Не упоминайте алгоритмы, машинное обучение или то, что митохондрии - это источник энергии клетки. Это не имеет отношения к делу.

Достаточно ли AC как такового?

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

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