Я владелец продукта в гибкой команде. Я, когда я делаю приемочное тестирование ПО, обычно отмечаю, чтобы попробовать некоторые крайние случаи Для меня не редкость, когда я что-то открываю, и затем я передаю это разработчикам. Меня отталкивает один из разработчиков, когда я отвергаю его истории. Он говорит, что это несправедливо, поскольку я не указываю крайние случаи и то, как программа должна отвечать в критериях приемлемости, поскольку он имеет тенденцию кодировать только то, что я описываю в истории. Я посоветовал ему спросить меня, когда он сталкивается с любыми крайними случаями во время кодирования, но он считает, что не его задача продумывать крайние случаи, это мое, и я должен написать новые истории для следующего спринта.
В свою защиту, я не знаю его дизайн для истории до тех пор, пока он его не реализует, поэтому сложно перебрать все возможности (конфигурация будет в БД или в файле свойств?). Для простоты, скажем, у нас есть история, чтобы добавить разделение в приложение калькулятора. В идеальном мире SCRUM я должен был бы добавить «сценарий деления на ноль» к критериям приемлемости, или он должен работать над этими случаями по мере его развития, чтобы приложение не взорвалось 5/0? Чтобы быть ясным, в этом случае я бы не принял, если приложение сильно упало на 5/0, но я бы прошел, если оно регистрирует, печатает DIV0, или любой другой способ обработки ошибки ... только до тех пор, пока это не не врезаться
Ответы:
Я думаю, что ответ заключается в том, что вы оба должны думать о своем собственном наборе крайних случаев. Он, как разработчик, должен обрабатывать крайние случаи, которые специфичны для данных, например, происходит ли сбой приложения при любом вводе пользователем, 5/0, безусловно, попадает в эту часть спектра. Разработчик должен спросить вас о том, что вы считаете соответствующим сообщением об ошибке, когда ввод данных, являющийся частью взаимодействия с пользователем, приводит к чему-то недопустимому.
Ваша часть спектра - деловая сторона вещей. Как должен вести себя калькулятор, если учетной записи пользователя не разрешено использовать кнопку деления? Как он должен вести себя, когда учетной записи разрешено использовать операцию Mod, но нет доступа к функции разделения?
Важное послание, которое, я думаю, вам необходимо донести до всех членов команды, и которое вы должны принять, заключается в том, что вы все в одной команде. Если продукт не завершен, продукт не завершен, и виновата команда, а не какой-либо конкретный участник.
источник
Команда должна работать вместе, а не иметь мантру типа «Не моя работа, не моя ответственность».
Критерии приемки принимаются в виде:
Как правило, принятие бизнеса обычно отвечает на вопрос:
Эта функция будет иметь ряд требований, ориентированных на бизнес, например, если я нажму эту кнопку, я ожидаю, что это действие произойдет. В нем будут перечислены ожидаемые бизнес-сценарии и ожидаемое поведение, но он не будет охватывать все возможные случаи.
Ожидается, что требования к бизнесу должны быть определены до итерации, чтобы в рамках обеспечения качества можно было разработать любые технические требования, не связанные с бизнесом. Обеспечение качества должно разрабатывать как разрушительные, так и крайние случаи по мере необходимости.
Оба набора требований должны быть рассмотрены до начала любой сюжетной работы, чтобы можно было получить формальную оценку и обязательство для единицы работы. Как только это будет сделано, можно продолжить работу над этой функцией / историями. На этом этапе всем ясно, что нужно делать как с деловой, так и с технической точки зрения.
История достигает окончательного одобрения, как только члены команды бизнеса и обеспечения качества подписывают эту историю. Это должно происходить во время итерации как для принятия бизнеса, так и для обеспечения качества. Это определение выполненного (DoD), которое указывает на то, что можно начать дополнительную работу над сюжетом.
Любые новые результаты могут быть зарегистрированы как дефекты или дополнительные всплески истории. В идеальном мире этого никогда не произойдет, но в действительности обычно происходит какое-то «открытие», возникающее при работе над функцией / историей. Это естественно.
Команда должна работать вместе (бизнес, QA, разработчик) , чтобы хэш из любого туманного типа обнаружения требований. Если это ловко, все они должны сидеть за одним столом, чтобы способствовать общению и быстрому решению любых вопросов, которые могут возникнуть. Это должно пойти примерно так:
QA:
DEV:
БИЗНЕС:
DEV:
Или, если это большая работа, новая история добавляется в отставание. Команда все еще может принять оригинальную историю, так как она отвечает всем первоначальным требованиям, а затем выбрать следующую историю в следующей итерации.
источник
Написание программного обеспечения, которое ведет себя надежно в условиях неправильного или неоднозначного ввода, является важной частью работы разработчика программного обеспечения.
Если ваши разработчики этого не видят, включите дополнительные нефункциональные требования в спецификацию требований, в которых это требование явно указано, и предоставьте своим разработчикам пример процесса тестирования, чтобы они могли самостоятельно применить этот процесс перед отправкой своего окончательного варианта. код для обзора.
В любом случае приемочные испытания должны быть неотъемлемой частью любого документа с требованиями. Если в требовании также не указаны критерии для принятия, это не является обязательным требованием; это желание.
источник
Здесь произошло то, что вы обнаружили ценность . Входное значение не задумывалось о том, когда была написана история (и критерии приемлемости) или когда был написан код. Если это не является частью критериев приемлемости, у вас нет оснований отвергать историю.
Что мы будем делать в моей команде:
Преимущество здесь в том, что вы вынуждены задуматься о том, является ли исправление этой ошибки следующим самым важным делом. Это может быть или не быть достаточно важным для исправления, но важно учитывать его значение.
Конечно, вам все еще нужно найти способ побудить разработчиков (и вас самих) изучить эти крайние случаи заранее. Если ваша команда разработчиков не тратит время на разбивку историй, предложите им провести детальное планирование, прежде чем начинать работу над ними.
источник
Некоторые наблюдения:
Я не знаю вашу рабочую культуру или процесс, но для меня отказ от истории - серьезный шаг. Если бы я был разработчиком, я бы также дал толчок этому, поскольку это записанное действие, которое плохо отражается на мне и на команде.
Несправедливо с его стороны ожидать, что вы знаете все крайние случаи. Но в то же время несправедливо ожидать от него такого. Каждое изменение сопряжено с риском, и когда проблемы обнаруживаются, вам нужно работать вместе, как команда, чтобы решать их.
Вам не нужно знать дизайн. Это может быть полезно знать дизайн, чтобы сделать начальные догадки о том, какие истории легче или сложнее для управления отставанием. Но избегайте ловить разработчика в свой дизайн, когда вы пишете истории. Это высасывает все удовольствие, когда вы просто голосовая клавиатура для ПО.
Похоже, что вы, ребята, должны поработать над улучшением процесса и поработать над созданием команды. Некоторые вещи, которые я мог бы предложить для процесса:
источник
Требования должны быть четкими и краткими. Если их нет, то происходит именно то, что случилось с вами. Это ваша вина, и худшее, что вы можете сделать при определении требований, это предположить что-то.
Вы конкретный пример, про деление на ноль. Если вы не указали, что хотите регистрировать ошибку, не жалуйтесь, если разработчик напечатает 100 как результат.
Но в таких случаях я просто восполняю недостающие пробелы и передаю их разработчику. В конце концов, ошибки в требованиях действительно случаются.
источник