Критерии приемки для краевых случаев

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

В свою защиту, я не знаю его дизайн для истории до тех пор, пока он его не реализует, поэтому сложно перебрать все возможности (конфигурация будет в БД или в файле свойств?). Для простоты, скажем, у нас есть история, чтобы добавить разделение в приложение калькулятора. В идеальном мире SCRUM я должен был бы добавить «сценарий деления на ноль» к критериям приемлемости, или он должен работать над этими случаями по мере его развития, чтобы приложение не взорвалось 5/0? Чтобы быть ясным, в этом случае я бы не принял, если приложение сильно упало на 5/0, но я бы прошел, если оно регистрирует, печатает DIV0, или любой другой способ обработки ошибки ... только до тех пор, пока это не не врезаться

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

Ваша часть спектра - деловая сторона вещей. Как должен вести себя калькулятор, если учетной записи пользователя не разрешено использовать кнопку деления? Как он должен вести себя, когда учетной записи разрешено использовать операцию Mod, но нет доступа к функции разделения?

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

Команда должна работать вместе, а не иметь мантру типа «Не моя работа, не моя ответственность».

Критерии приемки принимаются в виде:

• Бизнес Принятие
• Подтверждение качества

Как правило, принятие бизнеса обычно отвечает на вопрос:

• Делает ли реализованная функция то, что я хочу?

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

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

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

История достигает окончательного одобрения, как только члены команды бизнеса и обеспечения качества подписывают эту историю. Это должно происходить во время итерации как для принятия бизнеса, так и для обеспечения качества. Это определение выполненного (DoD), которое указывает на то, что можно начать дополнительную работу над сюжетом.

Любые новые результаты могут быть зарегистрированы как дефекты или дополнительные всплески истории. В идеальном мире этого никогда не произойдет, но в действительности обычно происходит какое-то «открытие», возникающее при работе над функцией / историей. Это естественно.

Команда должна работать вместе (бизнес, QA, разработчик) , чтобы хэш из любого туманного типа обнаружения требований. Если это ловко, все они должны сидеть за одним столом, чтобы способствовать общению и быстрому решению любых вопросов, которые могут возникнуть. Это должно пойти примерно так:

QA:

«Эй, разработчик, мы должны разобраться с этим конкретным сценарием. Я обнаружил, что если я введу эти данные, я получу ошибку».

DEV:

«Это не было учтено ни в одном требовании, но мы можем добавить некоторые дополнительные функции, чтобы покрыть это. Хорошо, Эй, Деловой человек, как бы вы> хотели, чтобы приложение работало в этом случае?»

БИЗНЕС:

«Давайте покажем наше стандартное сообщение об ошибке и позволим пользователю повторить попытку для этого сценария. Сколько дополнительных усилий будет тогда?»

DEV:

«Это будет легко, только дополнительный час или два. Я могу взять на себя обязательство для этой итерации. QA, пожалуйста, обновите ваши критерии принятия для этого сценария, нам не нужна дополнительная история для этого. Спасибо!»

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

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

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

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

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

Что мы будем делать в моей команде:

1. Создайте ошибку с подробным описанием ожидаемого и фактического поведения.
2. Обновите критерии приемки, чтобы новое найденное требование было задокументировано.
3. Приоритезируйте ошибку вместе со всеми другими историями и ошибками в следующей итерации.

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

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

Некоторые наблюдения:

... когда я отвергаю его истории

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

Он говорит, что это несправедливо, поскольку я не уточняю крайние случаи.

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

Я не знаю его дизайн для истории, пока он не осуществит ее

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

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

• Предложите, чтобы разработчик включил в историю время, чтобы крышка зафиксировала обнаруженные крайние случаи. Черт возьми, сделай это частью каждой пользовательской истории. Это легко защитить с помощью 0 новых ошибок. Проблема в том, что разработчик не планирует это в настоящее время. И у него нет времени, когда вы обнаруживаете проблемы. В любом случае это займет время, поэтому поместите это в историю, где это видно во время планирования.
• После тестирования (и, кстати, спасибо за тестирование!), Отправьте разработчику список обнаруженных проблем. Решение этих проблем будет идти вразрез с условием «исправления крайних случаев» удовлетворения.
• Если что-то остается незафиксированным или обнаруживается слишком поздно, решите, нужно ли продвигать историю, основываясь на том, можно ли выполнить сценарий использования. Известные проблемы и обходные пути случаются. Раскрыть их в заметках о выпуске и создавать новые истории, чтобы исправить их.
• Если в процессе есть определенная грубая точка, которая вызывает откат, измените ваш процесс! В конце концов, улучшение процесса является частью Scrum. Например, если ваш разработчик расстроен, когда вы отклоняете историю, предложите команде внести изменения в процесс, чтобы отклонение не вызвало исправлений. Выполните тестирование и исправления, прежде чем Готово и Отклонено.
• Работайте с командой и с тем, что они произвели, и используйте ее как можно лучше. Они не делают идеальную работу, как и вы. Так что планируйте это. Мои команды, как правило, были devops, поэтому у нас есть история пользователей Unplanned Support каждый спринт на возникающие проблемы ... планирование на не планируемое.

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

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

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