Привет! Я Екатерина Васильева, инженер-тестировщик ГК «Солар». В нашей работе есть извечный вопрос, как сделать тестирование быстрым, качественным и эффективным. И знаете, что помогает? Правильная организация процесса. В «Соларе», например, мы активно используем концепции 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 в тестировании ПО.
Прежде чем брать в спринт новую задачу, ответьте на следующие вопросы:
Вопросы для формирования DoR | ||
| ➕ | ➖ |
Что помогает решить реализация задачи? | Делает функционал лучше/понятнее/удобнее/эффективнее | Качество функционала особо не изменится |
Какая потребность в реализации? | Заказчику критично присутствие этой функции | Возможно, когда-то в будущем кому-нибудь из заказчиков пригодится |
Проведено согласование задачи со всеми причастными лицами? | Да, все причастные к задаче лица, подтвердили необходимость реализации задачи | Решение о принятии задачи в работу было принято узким кругом лиц |
Какая пользовательская история? | История прозрачная, отражает близкое к реальному поведение пользователя | Пользовательская история не ясна или отсутствует |
Есть ли дополнительные пути реализации задачи? | Нет, только проработка задачи напрямую поможет решить проблему | Есть возможность решить проблему иным менее трудозатратным путем |
Какой КПД от решения задачи? | Затраченные силы окупятся внушительным вкладом в функциональность продукта | Полученный результат будет мал в сравнении с затраченными усилиями |
Какие технические требования к задаче? | Технические требования ясны всем задействованным лицам | Технические требования размыты, не имеют конкретики |
Имеется ли время для выполнения задачи? | Задача заведена в спринт, для нее выделено время | Для задачи выделено недостаточно времени |
Имеются ли дефекты, препятствующие выполнению задачи? | Дефектов нет, либо они некритические | Есть блокирующие дефекты |
Тестовое окружение определено? | Да | Нет |
Тест-дизайн согласован и одобрен? | Да | Нет |
Вопросы для формирования DoD | ||
➕ | ➖ | |
Все тест-кейсы успешно пройдены? | Тест-кейсы пройдены полностью и успешны | Имеются неуспешно пройденные тест-кейсы |
Выполненная задача соответствует заявленным требованиям? | Да, представляемые требования полностью реализованы в ходе исполнения задачи | Полученный результат разнится с заявленными требованиями |
Пользовательская история воспроизведена в полной мере? | Описанная история была полностью воспроизведена | Не удалось в полной мере воспроизвести пользовательскую историю |
Екатрина Васильева
инженер-тестировщик 1-й категории ГК «Солар»