|
|
| Строка 28: |
Строка 28: |
| | | | |
| | <p>Другой пример, проверка этого самого лектио, которое Вы сейчас читаете или слушаете, может тестировать различные требования к её тексту, объёму, количеству слов в предложениях, соответствие нормам русского языка и так далее. Однако только Ваше понимание разницы между приёмкой и проверкой может подтвердить, что лектио готово. Если большой процент учащихся не будут осознавать разницу, то требования необходимо будет пересмотреть и лектио надо будет обновить.</p> | | <p>Другой пример, проверка этого самого лектио, которое Вы сейчас читаете или слушаете, может тестировать различные требования к её тексту, объёму, количеству слов в предложениях, соответствие нормам русского языка и так далее. Однако только Ваше понимание разницы между приёмкой и проверкой может подтвердить, что лектио готово. Если большой процент учащихся не будут осознавать разницу, то требования необходимо будет пересмотреть и лектио надо будет обновить.</p> |
| − |
| |
| − | Критерии приемки: цели, форматы и передовой опыт
| |
| − |
| |
| − | Успех любого проекта зависит от способности команды разработчиков удовлетворить потребности своих клиентов. Коммуникация между клиентом и командой разработчиков играет жизненно важную роль в предоставлении решения, которое соответствует требованиям продукта и рынка. Проблемы возникают, если клиенты слишком расплывчато объясняют свои потребности, а команда не может понять четких требований и, в конечном итоге, стоящую за ними бизнес-проблему. Представьте, что вы просите свою команду разрешить пользователям искать продукт в книжном онлайн-магазине по категориям. Вы ожидаете, что у вас будет понятный интерфейс со ссылками на категории, по которым можно щелкнуть по ним (например, фантастика, научная литература, историческая литература и т. Д.). После двух недель разработки вы получите функцию панели поиска, где пользователи должны вводить категорию, которая им интересна, вместо просмотра предварительно перечисленных категорий. Хотя это тоже работает, вашей первоначальной целью было раскрыть все доступные категории и позволить пользователям исследовать дальше.
| |
| − |
| |
| − | Это когда качественная документация по программному обеспечению может помочь избежать проблемы. Пользовательские истории и критерии приемки (AC) как основные форматы документирования требований. Пользовательская история - это описание функции на естественном языке. Обычно он сопровождается критериями приемлемости.
| |
| − |
| |
| − | Критерии приемлемости (AC) - это условия, которым должен соответствовать программный продукт, чтобы его принял пользователь, заказчик или другая система. Они уникальны для каждой пользовательской истории и определяют поведение функции с точки зрения конечного пользователя. Хорошо написанные критерии приемки помогают избежать неожиданных результатов в конце этапа разработки и гарантировать, что все заинтересованные стороны и пользователи удовлетворены тем, что они получают.
| |
| − |
| |
| − | Критерии приемки - функциональные требования самого низкого уровня
| |
| − |
| |
| − | Критерии приемки - это функциональные требования самого низкого уровня.
| |
| − | Критерии приемки основные цели
| |
| − |
| |
| − | Разъяснение требований заинтересованных сторон - задача высокого уровня. Чтобы сделать цели AC более ясными, давайте разберем их.
| |
| − |
| |
| − | Детализация объема функции. AC определяют границы пользовательских историй. Они предоставляют точные сведения о функциональности, которые помогают команде понять, завершена ли история и работает ли она должным образом.
| |
| − |
| |
| − | Описание негативных сценариев. Ваш AC может потребовать, чтобы система распознала небезопасный ввод пароля и помешала пользователю продолжить работу. Неверный формат пароля - это пример так называемого негативного сценария, когда пользователь вводит неверные данные или ведет себя неожиданно. AC определяет эти сценарии и объясняет, как система должна реагировать на них.
| |
| − |
| |
| − | Настройка общения. Критерии приемки синхронизируют видение клиента и команды разработчиков. Они обеспечивают общее понимание требований: разработчики точно знают, какое поведение должна демонстрировать функция, а заинтересованные стороны и клиент понимают, чего от нее ждут.
| |
| − |
| |
| − | Оптимизация приемочного тестирования. AC являются основой приемочного тестирования пользовательской истории. Каждый критерий приемки должен подвергаться независимому тестированию и, таким образом, иметь четкие сценарии успешности или неудачи. Их также можно использовать для проверки истории с помощью автоматических тестов.
| |
| − |
| |
| − | Оценка характеристик. Критерии приемки определяют, что именно должно быть разработано командой. Как только у команды появятся точные требования, они могут разбить пользовательские истории на задачи, которые можно правильно оценить.
| |
| − |
| |
| − | Иногда ваши критерии могут быть указаны как пример поведения системы:
| |
| − |
| |
| − | Пользовательский формат критериев приемки
| |
| − |
| |
| − | Простой набор AC для надежных паролей от Марка Левисона для agilepainpainrelief.com
| |
| − |
| |
| − | Этот подход дает четкие рекомендации по тестированию функций паролей.
| |
| − | Ответственные роли и как создаются критерии приемки
| |
| − |
| |
| − | Некоторые критерии определяются и записываются владельцем продукта при создании бэклога продукта. А остальные могут быть дополнительно указаны командой во время обсуждения пользовательских историй после планирования спринта. Строгих рекомендаций по выбору ответственного за написание критериев нет. Клиент может задокументировать их, если он или она имеет достаточные знания в области технической документации и документации продукта. В этом случае клиент согласовывает критерии с командой, чтобы избежать взаимных недоразумений. В противном случае критерии создаются владельцем продукта, бизнес-аналитиком, аналитиком требований или менеджером проекта.
| |
| − |
| |
| − | как создать критерии приемки
| |
| − |
| |
| − | Процесс начинается с определения приоритетов пользовательской истории и заканчивается согласованием деталей со всей командой.
| |
| − | Основные проблемы и лучшие практики написания критериев приемки
| |
| − |
| |
| − | Критерии приемки выглядят так, как будто их очень легко написать. Несмотря на их упрощенные форматы, написание текста представляет собой проблему для многих команд. Давайте подробнее рассмотрим передовые методы, которые помогут избежать распространенных ошибок.
| |
| − |
| |
| − | Документируйте критерии перед разработкой. Критерии приемки должны быть задокументированы до начала фактической разработки. Таким образом, команда, скорее всего, заранее уловит все потребности клиентов. Вначале достаточно установить критерии для небольшого количества пользовательских историй, чтобы заполнить бэклоги для двух спринтов (если вы практикуете Scrum или аналогичный метод). Они должны быть согласованы обеими сторонами. Затем задокументированные критерии приемки используются разработчиками для планирования технического процесса.
| |
| − |
| |
| − | Не делайте AC слишком узким. Критерии приемлемости могут быть слишком конкретными, поскольку для разработчиков практически нет маневра. Чтобы избежать этого, помните, что AC должен выражать намерение, но не окончательное решение. Более того, узкий AC может быть лишен множества действий пользователя, которые не рассматриваются.
| |
| − |
| |
| − | Держите ваши критерии достижимыми. Эта точка близко пересекается с предыдущей. Эффективные критерии приемки определяют разумный минимальный объем функциональности, которую вы можете предоставить. Но если вы поддаетесь описанию всех мелких деталей, есть риск, что ваша команда застрянет на сотнях мелких задач.
| |
| − |
| |
| − | Держите переменный ток поддающимся измерению и не слишком широким. Широкие критерии приемлемости делают историю пользователя расплывчатой. Эффективные критерии приемки должны определять объем работ, чтобы разработчики могли правильно спланировать и оценить свои усилия.
| |
| − |
| |
| − | Избегайте технических подробностей. Как мы уже упоминали, критерии приемки должны быть написаны простым английским языком. Это сделает их ясными и понятными для всех: ваши заинтересованные стороны или менеджеры могут не иметь технического образования.
| |
| − |
| |
| − | Достигайте консенсуса. Одна и та же проблема может быть решена по-разному командой и заинтересованными сторонами в зависимости от их точки зрения. Убедитесь, что вы сообщили свой AC заинтересованным сторонам и достигли взаимного согласия. То же самое и с членами команды. Каждый должен просмотреть AC и подтвердить, что он понимает и согласен с каждой строкой.
| |
| − |
| |
| − | Напишите тестируемый AC. Это позволит тестировщикам убедиться, что все требования соблюдены. В противном случае разработчики не поймут, завершена ли пользовательская история.
| |
| − | Последнее слово
| |
| − |
| |
| − | Не пренебрегайте критериями приемлемости, поскольку они просты и доступны для решения нескольких проблем одновременно. Они документируют ожидания клиентов, предоставляют точку зрения конечного пользователя, уточняют требования и предотвращают двусмысленность и, в конечном итоге, помогают контролю качества проверять, были ли достигнуты цели разработки. Независимо от того, используете ли вы методы Agile или нет, обязательно выберите лучший формат или поэкспериментируйте со своими собственными. Для разных типов пользовательских историй и, в конечном итоге, функций могут потребоваться разные форматы, поэтому рекомендуется тестировать новые, которые работают на вас.
| |
| | | | |
| | ===Термины=== | | ===Термины=== |
Критерии Приёмки (здесь и далее по тексту -- Лектио) -- это часть урока Суть Приёмки Работ. В Брацкой Школе, уроки делятся на так называемые лектио, каждое из которых состоит из микролекции и одного или нескольких заключительных вопросов. Урок, в свою очередь, относится к практическому семинару Выбор Профессии.
Материалы
Предшественник этого Лектио -- Тесты Приёмки.
Иллюстрации
Текст
Критерии Приёмки
Критерии приемлемости (acceptance criteria или AC) -- это набор стандартов, который применяется для принятия решения о готовности чего-либо к передаче, применению или употреблению. Речь может идти о готовности различных вещей от одной характеристики изделия до предмета контракта.
Критерии приемлемости выполненного требования формируются исходя из требования.
и, потому, завершению разработки.
изделия или другого продукта к передаче заказчику, конечным пользователям или уполномоченному органу. Если итоги приёмочных тестов сравнить с оценками, критерии приемлемости будут проходным баллом. Критерии приемлемости устанавливаются заказчиком и принимаются подрядчиком.
это условия, которым должен соответствовать программный продукт, чтобы его принял пользователь, заказчик или другая система.
Критерии приемлемости - это критерии, которым должна удовлетворять система или компонент, чтобы быть принятыми пользователем, покупателем или другим уполномоченным органом.
Наконец, некоторые Проверки зависят от использования продуктов конечными пользователями и их производительности.
Специально организованное Тестирование может затрагивать конкретные проблемы или области, требующие улучшения. Например, рабочее тестирование продукта оценивает функциональность рабочих продуктов, производительность тех команд, которые их разработали, и/или другие результаты разработки. Юзабилити-тестирование направлено на поиск областей для улучшения и удобства пользовательского опыта (UX). Приемочные испытания проводятся для проверки того, соответствует ли разработанная система требованиям завершения, обычно называемым критериями приемки. То есть готов ли продукт для следующей эксплуатации.
Большинство Ручных Тестов включает в себя контроль того, соответствует ли рабочий продукт его требованиям, поиск ошибок, проблем с пользовательским интерфейсом и/или областей для улучшений при ручном выполнении действий на веб-сайте, мобильном приложении или другом приложении конечного пользователя.
Другой пример, проверка этого самого лектио, которое Вы сейчас читаете или слушаете, может тестировать различные требования к её тексту, объёму, количеству слов в предложениях, соответствие нормам русского языка и так далее. Однако только Ваше понимание разницы между приёмкой и проверкой может подтвердить, что лектио готово. Если большой процент учащихся не будут осознавать разницу, то требования необходимо будет пересмотреть и лектио надо будет обновить.
Термины
- Верификация, Валидация, Проверка, Приемка, Требования
Вопрос(ы)
- Исходя из выше описанного текста: Проверка отвечает на вопрос, был ли разработан правильный продукт, так как он решает проблемы, которые должен был решить. -- Правда/Неправда
- Следующее лектио -- Что Есть Отчетность
