- Определение
- Чем отличается от покрытия кода
- Виды
- Цели
- Как повышается покрытие
- Преимущества и недостатки этого подхода
- Хорошие практики
- Как добиться оптимального покрытия
- Еще несколько советов
- Практический взгляд на тестовое покрытие
- Формула тестового покрытия
- Список инструментов
Определения
Тестовое покрытие (test coverage) — количественная мера плотности покрытия требований или кода. Покрытие требований выражается в процентном отношении покрытых требований к их общему количеству.
Покрытие кода подразумевает оценку количества кода, выполненного при тестировании, оценивается чаще покрытие условий/переходов в коде, как наиболее полезный показатель покрытия.
Тестовое покрытие vs покрытие кода
Эти понятия часто путают, ввиду их логической близости. Однако:
- Покрытие кода тестами чаще относится к юнит-тестированию; показывает, насколько юнит-тесты покрывают все части кода; за покрытие кода отвечают разработчики
- Тестовое покрытие обычно подразумевает тестирование требований (хотя бы по одному разу); тестовое покрытие — сфера ответственности тестировщиков
| Покрытие кода | Тестовое покрытие (покрытие требований) | |
|---|---|---|
| Когда применимо | Когда код приложения выполняется во время тестирования, и нужно оценить, насколько код покрыт тестами | Когда планируют и оценивают покрытие с точки зрения требований |
| Цель | Мониторинг автоматизированных (чаще всего юнит-) тестов | Более практичный метод оценки тестирования |
| Подтипы | — Покрытие функций — Покрытие операторов — Покрытие ветвлений — Покрытие условий — Покрытие строк | В следующем пункте, а также: — покрытие по выполнению — покрытие по количеству задействованного персонала — покрытие на уровне дизайна |
Тестовое покрытие определяется каждой командой индивидуально, исходя из особенностей проекта.
В целом принято считать, что требование покрыто, если для него существует хотя бы один тест-кейс.
Иногда считается, что требование покрыто, если хотя бы один тестировщик задействован в его тестировании. Или, если выполнены все тест-кейсы, связанные с этим требованием.
Виды тестового покрытия
Если есть 10 требований, и для них написаны 100 тестов, и ни одно требование не осталось без теста, можно назвать это приемлемым тестовым покрытием уровня дизайна.
Если 80 тестов написано и всего 6 требований «отработаны» ими — то, хотя 80% объема тестирования выполнено, 4 требования остались не покрыты. Это покрытие уровня выполнения.
Если лишь 90 тестов, относящихся к 8 из 10 требований, имеют прикрепленных тестировщиков, значит тестовое покрытие по прикреплению составляет 80% (8 из 10 требований).
Как видим, понятие тестового покрытия достаточно широкое, кроме того существуют другие методики оценки. Наиболее часто (и наиболее удобно) использовать тестовое покрытие требований.
Если покрытие оценивается слишком рано в жизненном цикле, будет много непокрытых требований. Обычно рекомендуется оценивать покрытие на этапе последнего билда (Last Build, обычно после финального регрессионного тестирования). Тогда покрытие требований будет более корректным.
Цели
- Определить требования, не покрытые тест-кейсами
- Создать новые и более качественные тест-кейсы
- Создать количественные метрики покрытия как непрямой техники контроля качества (и оценки работы тестировщиков)
- Определить «бесполезные» тест-кейсы, не повышающие покрытие
Как повышается тестовое покрытие
- Применением техник статического анализа — просмотром и инспекцией кода, пошаговым разбором (walkthrough)
- Преобразованием дефектов, найденных исследовательским тестированием, в тест-кейсы.
- Продуманной автоматизацией на всех уровнях
- Покрытие функциональных тестов — подбором соответствующих методик управления тестированием под руководством квалифицированных лидов
Преимущества тестового покрытия
- Улучшает общее качество продукта
- Помогает сделать акцент на критически важных частях приложения
- Точнее определяет непроверенные части кода
- Помогает идентифицировать особо опасные каскадные баги
- Улучшает управление таймингами, масштабом и стоимостью тестирования
- Способствует предотвращению дефектов на раннем этапе цикла
- Совершенствование логики приложения
- Определение «пробелов» в требованиях, неудачных тест-кейсов, и других проблем на уровне модуля и выше
Недостатки
- (Пока что) не существует инструментов автоматизации абсолютно всех возможных пользовательских действий и ситуаций, и многие операции, влияющие на тестовое покрытие, выполняются вручную (автоматизации не подлежат). Поэтому для достижения целевого тестового покрытия требуется много рутинных действий оценки требований и написания тест-кейсов.
- Показатель тестового покрытия позволяет отслеживать функции (требования) и сопоставлять их с тест-кейсами. Это не так просто, поэтому часто случаются ошибки.
Хорошие практики
- Команда должна хорошо понимать масштаб проекта и его состояние в данный момент
- Применять матрицу отслеживания требований (RTM)
- Тщательно контролировать присвоение задач и их выполнение
Как обеспечить оптимальное тестовое покрытие
- Каждый тестировщик в QA-команде должен быть заранее информирован о требованиях и будущих процедурах
- Придерживаться приоритетов и сосредоточиться на главном
- Знать, что изменилось в новом релизе, чтобы отработать эти изменения
- Постоянно совершенствовать автоматизацию в проекте
- Умело пользоваться средствами управления тестированием (test management systems)
- Распределение задач — направить лучших тестировщиков на важные задачи; а неопытных новичков на второстепенные
- Делать чеклисты задач (и других активностей) при нехватке времени (то есть всегда)
- Если команда работает по DevOps/Scrum/BA, плотнее общаться с разработчиками
- Поддерживать порядок в системе управления тестированием и баг-трекинговой системе
Еще советы
- Воспитывать у команды чувство собственности и причастности — джуны должны иметь, по возможности, некую свободу действий, а также помощь лидов и мониторинг, чтобы у них крепчала ответственность за продукт и тяга к экспериментам и новым методикам
- Дедлайны — устанавливать дедлайны релизов, не переоценивая возможности команды
- Коммуникация — поддерживать хорошую коммуникацию с разработчиками и другими командами в и между циклами релиза
- RTM-матрица, чтобы команда, а также стейкхолдеры и клиенты знали о состоянии продукта и выполнении требований
О типах тестового покрытия с практической точки зрения
Покрытие продукта
В этом подходе внимание команды сфокусировано на том, какие части продукта были протестированы, а какие остались.
Пример 1. Когда тестируют нож как «продукт», не обращают внимание, хорошо ли он режет фрукты и овощи; тестируется лишь способность владельца правильно и безопасно им пользоваться. Следовательно, тогда покрытие продукта «нож» неполное.
Пример 2. Тестируют продукт — приложение Блокнот для ПК. Есть требования:
- Приложение корректно работает, если одновременно запущены другие подобные приложения
- Блокнот не падает, когда пользователь делает в нем что-то необычное;
- Пользователь получает корректные сообщения об ошибках, и предупреждения;
- Пользователю понятно происходящее в приложении;
- Приложением легко пользоваться, управление интуитивное;
- А также есть доступ к справке.
Нельзя считать, что приложение имеет хорошее покрытие продукта, пока не протестированы самые важные сценарии использования.
Покрытие рисков
Немаловажный аспект в QA: продукт не может считаться протестированным с точки зрения покрытия рисков, пока они не устранены.
Пример 1. Тестируется самолет. Все полностью проверено, кроме безопасности для пассажиров — и это неприемлемо. Нужна идентификация рисков, специфичных для продукта.
Пример 2. При тестировании сайта магазина одежды тестировщик отработал каждую функцию, но не смог (забыл) протестировать ситуацию большого количества одновременных пользователей. Это скажется в день больших скидок, когда количество пользователей вырастет в десятки и сотни раз.
Покрытие требований
Если продукт хорошо разработан и тщательно протестирован — все кроме требований клиента, то продукт по факту бесполезен. Покрытие требований является ключевым.
Пример 1. Вы просите портниху сшить вам штаны с красивыми синими пуговицами. Вы пойдете в этих штанах в важное место и на вас будут обращать внимание. Но портниха решила пришить эти пуговицы в ряд на груди, и еще добавить золотую бахрому. Конечно, клиент будет возмущен, потому что портниха не выполнила заранее сформулированные требования.
Пример 2. При тестировании чата, тестировщик позаботился о всех важных пунктах, например протестировал общение множества пользователей одновременно в группе, двух пользователей чатящихся независимо, все эмотиконы, проконтролировал что обновления вовремя отправляются пользователем, и так далее. Но он забыл посмотреть в документ требований, в котором ясно говорится, что если двое пользователей чатятся одновременно, у них должен быть доступен видеозвонок. Клиенты, привлеченные рекламой нового чата, и рассчитывающие что там есть видеозвонки доступные в любой момент, будут разочарованы, они будут чувствовать себя обманутыми.
Формула тестового покрытия
В общем случае, нужно две вещи:
- Количество строк исходного кода
- Количество строк кода, покрытых тест-кейсами
Нужно поделить второе на первое и умножить на 100. Эта простая «древняя» формула дает понятие о тестовом покрытии. Например, если есть 100 строчек кода компонента, и 50 строчек покрыты имеющимися тест кейсами, тестовое покрытие составляет 50%.
Однако, «считать по строчкам» , почти вручную, нерационально и неудобно, поэтому используются инструменты, автоматически формирующие показатели тестового покрытия в удобном виде.
Выше видим тестовое покрытие в репорте.
Инструменты оценки тестового покрытия
| Инструмент | Чем хорош |
|---|---|
| Smartbear Zephyr | Легкая интеграция с Jira, Jenkins, Confluence |
| Xray | Автоматизированная матрица сверки требований |
| TestRail | Опции сравнения результатов в разных тестовых окружениях |
| PractiTest | Реюзабельность, настраиваемый интерфейс |
| ReQTest | Уведомления по назначению дефектов |
| TestPad | Удобная работа с тестовыми артефактами |
| TestMonitor | Простой интерфейс и управление тестированием, особенно дефектами |
| Qase | Быстрый |
| TestLink | Удобное управление и логи событий по каждому действию с тестовыми артефактами |
| Tarantula | Матрица отслеживания с показом причин задержки по отдельному дефекту |
***
