Home

Оригинальная публикация

Привет! Я Екатерина Васильева, инженер-тестировщик ГК «Солар». В нашей работе есть извечный вопрос, как сделать тестирование быстрым, качественным и эффективным. И знаете, что помогает? Правильная организация процесса. В «Соларе», например, мы активно используем концепции DoR (Definition of Ready) и DoD (Definition of Done) при тестировании продуктов. Эти критерии, хоть и встречаются чаще в разработке, оказались невероятно полезны и для нас, тестировщиков. Они помогают четко понимать, когда задача готова к тестированию, а когда уже можно выдохнуть и сказать: «Готово!». В итоге — никаких срывов сроков и релизы день в день. В этой статье я расскажу на примере Solar webProxy, как DoD и DoR помогают нам повысить качество тестирования и с какими трудностями мы столкнулись, внедряя эти критерии.

Что такое DoR и DoD

Definition of Ready (DoR), или, если дословно, «определение готовности», представляет собой набор условий, которым должны удовлетворять задачи прежде, чем они будут переданы в тестирование. То есть, DoR отвечает на вопрос: «Что необходимо для начала тестирования?». Вот несколько примеров:

• Под выполнение задачи выделено достаточно времени.

• Имеются в наличии ресурсы для проведения тестирования: соответствующая тестовая среда либо наличие требуемых аппаратных мощностей для тестирования.

• Компетенции сотрудников соответствуют поставленной задачи, а также распределены роли каждого задействованного в тестировании работника.

• Нет дефектов, блокирующих проведение тестирования.

• Определены критерии принятия, которые будут использоваться для оценки успешности тестирования. Да, в Definition of Ready уже немного задействуется Definition of Done, но подробнее о нем чуть позже.

• Ну и, конечно же, сформулированы требования! Понятные, ёмкие, четко написанные, согласованные со всеми заинтересованными сторонами, содержащие достаточно информации, но в то же время не перегруженные ею, с качественно проработанными пользовательскими историями и прозрачным пониманием функциональности.

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

Второй термин — Definition of Done, или «определение завершенности», фиксирует критерии, по которым можно будет определить, что задача тестирования завершена. Примерами этого могут служить:

• Тест-дизайн разработан на основе предъявленных требований и согласован.

• Тест-кейсы успешно закрыты, а требования к функциональности протестированы по описанным сценариям использования.

• Тестирование произведено для всех заявленных тестовых окружений.

• Все возникшие дефекты и критические ошибки, блокирующие проведение тестирования, исправлены.

• Нерешенные некритические ошибки отсутствуют, либо их количество сведено к минимуму, а сами они задокументированы и внесены в бэклог спринта. 

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

Какие преимущества у DoR и DoD в тестировании

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

Итак, DoR и DoD повышают прозрачность и качество процесса тестирования. Тем не менее, кроме положительного эффекта они имеют свои недостатки.

Ограничения, накладываемые DoR и DoD в тестировании

Казалось бы, чем подробнее и точнее все обозначить до начала тестирования, тем быстрее и успешнее оно пройдет. Да, но до определенной степени.

Слишком обширные и сложные для реализации критерии DoR и DoD, а также строгое следование им могут замедлить процесс тестирования. Вместо того, чтобы проговорить достаточные требования и приступить к тестам, команда будет продолжать досконально уточнять маловажные аспекты. Это будет оттягивать как начало, так и завершение тестирования.

Уже само внедрение и поддержание Definition of Ready и Definition of Done требует времени и усилий от команды — это дополнительная нагрузка, которая может сдвинуть срок релиза продукта. В особенности негативное влияние сказывается в начале работы, когда команда только привыкает к ним и вводит в систему. Возникает риск того, что команда может недооценить объем работы или не учесть все необходимые аспекты. К тому же, критерии могут изменяться в зависимости от проекта или ситуации, поэтому команда должна периодически обновлять критерии, что также затрачивает ресурсы.

При применении DoR и DoD может страдать и гибкость: слишком жесткие условия могут сильно ограничить приспосабливаемость команды к изменениям. Любое изменение в пользовательской истории или в требованиях к продукту будет означать двойную работу по определению критериев DoR и DoD.

Внедрение DoR и DoD в процесс тестирования

Учитывая вышеперечисленные негативные аспекты Definition of Ready и Definition of Done, использовать их необходимо грамотно, ловко балансируя между удручающей бюрократией и продуктивным инструментом. Постепенно, по мере применения этих концепций команда станет лучше понимать, как их эффективно использовать, чтобы оптимизировать процесс тестирования.

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

• Сформулировать критерии нужно ясно и однозначно. Все участники команды должны понимать и соглашаться с критериями.

• Критерии следует регулярно пересматривать и обновлять. По мере изменения проекта и условий работы, DoR и DoD также могут требовать корректировки.

• Концепции — часть ежедневного процесса. Перед началом работы над задачей следует убедиться, что она соответствует DoR, а перед её закрытием проверить выполнение всех пунктов DoD.

• Прозрачность и доступность: документ с прописанными условиями DoR и DoD должны быть в доступе у всех членов команды.

Пример использования DoR и DoD при тестировании продукта Solar webProxy

Solar webProxy — инновационный программный сервис для безопасного доступа к веб‑ресурсам. Принцип его работы схож с межсетевым экраном: он устанавливается как промежуточный элемент в сетевую инфраструктуру и осуществляет контроль над всеми данными, которые передаются между персоналом, внутренними системами компании и внешними интернет-ресурсами. Однако в отличие от межсетевого экрана Solar webProxy обеспечивает более высокую эффективность и обладает богатым гибким функционалом для решения различных задач в сфере сетевой безопасности. Solar webProxy оснащен встроенным антивирусом, межсетевым экраном, системой категоризации веб-ресурсов и контентной фильтрации, в которой можно гибко настраивать политики доступа определенных пользователей к различным ресурсам и файлам, например, запретить сотрудникам выгружать файлы с расширением .doc во внешнюю сеть.

Расскажу, как мы на практике задействуем DoR и DoD на проекте Solar webProxy на примере разработки и тестирования одной из фич.

В рамках одного из обновлений продукта была предусмотрена возможность гибкой настройки контентной фильтрации для нераспознанных типов файлов и мониторинга взаимодействия с ними, что считается потенциальной угрозой для сетевой безопасности. Разработка новой функции в нашей команде всегда начинается с общей встречи, где присутствуют аналитики, стейкхолдеры, разработчики и тестировщики. На таких встречах, известных как PBR (Product Backlog Refinement) в рамках Scrum-методологии, команды анализируют потребность в реализации задачи. В данном случае предпосылкой стала потребность заказчика.

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

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

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

Весь вышеописанный алгоритм и этапы формирования и использования критериев DoR и DoD отражены на схеме ниже. Это лишь пример того, как мы применяем эти инструменты в команде Solar webProxy, однако их можно взять за основу и адаптировать под свои бизнес-процессы, используя как чек-лист для того, чтобы следовать концепции «готовности» и «завершенности».

Итоги применения критериев DoR и DoD в тестировании

Самый главный вопрос: как сделать тестирование в максимальном объеме в минимальные сроки? Готового ответа на этот вопрос критерии DoR и DoD не дают. Эти концепции представляют собой лишь инструменты, которые в умелых руках станут мощным подспорьем и помогут оптимизировать процесс тестирования. Попробуйте внедрить и адаптировать их под свои бизнес-процессы, и, возможно, это поможет вашему продукту успешнее и эффективнее проходить стадию тестирования.

В заключение поделюсь таблицей, которая поможет составить список критериев для применения концепций Definition of Ready и Definition of Done в тестировании ПО.

Прежде чем брать в спринт новую задачу, ответьте на следующие вопросы: