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

Вот что вы придумали; тебе нужно:-

  • Поля ввода для имен пользователей и паролей
  • Кнопка отправки
  • Способ сообщить пользователю, что он ввел свои данные неправильно
  • Каким-то образом восстановить забытые детали
  • Какой-то способ зарегистрировать учетную запись, если у них ее еще нет

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

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

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

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

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

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

Критерии приемлемости - это излишне расплывчатое название набора шагов, которые определяют, как пользователь может взаимодействовать с определенной функцией. Они написаны в формате, в котором используются 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

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

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

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

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

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

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

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

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

2. Простота

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

3. Простой язык

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

4. Избегайте деталей реализации.

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

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

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

Достаточно ли AC самого по себе?

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

Если вы не Adobe, то буквально не имеет значения, что вы делаете, это все равно будет дерьмом.

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

Вы можете найти больше моих материалов в моем профиле на Medium и подписаться на меня в твиттере (если хотите) @lm_writing.