В этой статье мы подробно рассмотрим методы повышения тестового покрытия и расскажем, как можно увеличить объем тестирования, достигнув лучших результатов и при этом сэкономив время.
БЕСПЛАТНО СКАЧАТЬ QA КНИГИ можно в телеграм канале "Библиотека тестировщика"
Содержание:
Тестовое покрытие и покрытие кода
Как убедиться, что все протестировано
Советы по повышению тестового покрытия
На что влияет тестовое покрытие?
Что такое тестовое покрытие?
Тестовое покрытие – это концепция, которая отвечает на два важных вопроса: “Что и в каком объеме мы тестируем?” То есть, она определяет, какие части системы подвергаются тестированию и сколько тестов необходимо для их покрытия.
Тестовое покрытие играет ключевую роль в обеспечении контроля над качеством процесса тестирования и помогает QA-инженерам в разработке тестов, охватывающих компоненты, которые были упущены ранее или еще не были проверены.
Большинство команд основывают свои метрики покрытия только на функциональных требованиях. Это вполне логично, так как главной целью любого приложения является выполнение необходимых функций. Если приложение не соответствует функциональным требованиям, то его производительность, безопасность или удобство использования теряют свою значимость.
Это также применимо и к нефункциональному тестированию. Необходимо следить за тем, чтобы все нефункциональные требования были реализованы и протестированы. Как раз для этого и используется метрика тестового покрытия.
Тестовое покрытие и покрытие кода
Тестовое покрытие часто путают с покрытием кода. Несмотря на их сходство, они имеют существенные различия. Рассмотрим оба этих понятия более подробно.
Покрытие кода связано с практикой юнит-тестирования, выполняемого разработчиками, где каждый фрагмент кода тестируется хотя бы один раз. Это означает, что каждая часть программы должна быть протестирована, чтобы убедиться, что она работает правильно.
Тестовое покрытие заключается в проверке каждого требования хотя бы одним тестом и, в отличии от покрытия кода, является ответственностью команды QA.
Толкование термина “покрытое требование” может различаться в зависимости от его определения каждой конкретной командой.
Например, некоторые команды называют требование покрытым, если для него разработан хотя бы один соответствующий тест-кейс. Другие команды могут рассматривать требование как покрытое, если хотя бы один член команды был назначен на его проверку. Или же требование может считаться покрытым, если все связанные с ним тест-кейсы успешно выполнены.
- Если есть 10 требований и создано 100 тестов – в случае, если каждое из всех 10 требований проверяется хотя бы одним позитивным тестом из 100 – это можно назвать достаточным тестовым покрытием на уровне дизайна.
- Если из созданных тестов выполняется только 80 и они проверяют всего 6 требований, можем утверждать, что 4 требования не покрыты, несмотря на то, что выполнено 80% всех тестов. Этот пример показывает покрытие на уровне выполнения.
- Если только 90 тестов, связанных с 8 требованиями, имеют назначенных тестировщиков, в то время как остальные требования остались без внимания, мы можем утверждать, что покрытие по прикреплению составляет 80% (8 из 10 требований).
Также важно определить, когда проводить расчет покрытия. Если начать расчет покрытия слишком рано, множество требований останутся непокрытыми. Поэтому обычно рекомендуется дождаться последней сборки перед проведением итоговых расчетов тестового покрытия.
Мой опыт
Когда мой стаж работы в индустрии тестирования ПО составлял всего 2 года, я считал, что незнание некоторых основ тестирования – это нормально, ведь этому можно научиться с опытом.
Я был прав – и одновременно неправ.
Прав потому, что с опытом вы учитесь видеть более широкую картину, понимаете истинное значение “критических ситуаций” и приобретаете понимание потребностей конечного пользователя.
Ошибся, потому что ни один из вышеперечисленных навыков не обязательно зависит от опыта, их можно и даже нужно развивать с самого начала обучения. Я осознал это очень поздно, что и побудило меня написать эту статью.
На одном из собеседований, я столкнулся с следующей ситуацией:
Меня спросили: “как вы понимаете, что тестовое покрытие является полным?”
“Хмм… Я убеждаюсь в этом, если тестирую каждую функциональность”, – сказал я.
“То есть, вы хотите сказать, что когда вы протестируете все функциональные возможности, вы будете уверены, что охватили максимум продукта с точки зрения тестирования?” – ответил интервьюер.
“Хмм… ну… хмм… да, потому что при тестировании всех функциональных возможностей, появляется уверенность в правильном поведении продукта”, – подтвердил я.
“Я согласен, но мой вопрос в том, даст ли это вам уверенность в том, что ваше тестовое покрытие полное?” – парировал интервьюер.
Этот вопрос побудил меня задуматься глубже о понятии “тестового покрытия”.
Типы тестового покрытия
Покрытие продукта
Когда мы оцениваем тестовое покрытие в контексте продукта, наша главная задача – определить, какие части продукта были протестированы, а также выявить те области, которые остались без должного внимания.
Пример 1:
Если мы тестируем “нож” как продукт, то важно не ограничиваться только проверкой его способности резать овощи или фрукты. Существуют и другие аспекты, на которые необходимо обратить внимание. Например, удобство его использования – пользователю должно быть удобно держать его в руке.
Пример 2:
Если вы тестируете приложение “Блокнот”, то, конечно, необходимо проверить его основные функции.
Но также важно уделить внимание и другим аспектам, чтобы убедиться в полноте тестового покрытия. Необходимо проверить способность блокнота сохранять работоспособность, если одновременно запущены другие подобные приложения, предоставление пользователю понятных сообщений об ошибках, легкость и удобство использования, а также, при необходимости, наличие справочного материала.
Если эти сценарии не будут рассмотрены, то нельзя утверждать, что тестовое покрытие приложения будет полным.
Покрытие рисков
Важно определить, какие риски связаны с продуктом или приложением и провести тестирование, чтобы убедиться, что они учтены. Покрытие сопутствующих рисков играет важную роль в тестовом покрытии. Нельзя считать продукт протестированным, пока не проверены связанные с ним риски.
Пример 1:
Если во время тестирования самолета испытатель скажет вам, что внутренняя система самолета полностью проверена и исправно функционирует, но при этом тестирование его способности к реальным полетам не было проведено – какова будет ваша реакция?
Определение специфичных рисков, связанных с использованием продукта и их последующее тщательное тестирование – вот что подразумевается под покрытием на уровне рисков.
Пример 2:
При тестировании eCommerce-сайта тестировщик учел множество различных факторов, однако не обратил внимание на риск, связанный с одновременным использованием сайта большим количеством пользователей. Этот неучтенный риск проявился в день проведения большой акции на сайте, что привело к негативным последствиям.
Покрытие требований
Качественная разработка продукта становится неактуальной, если она не соответствует требованиям клиента. Поэтому особенно важно уделять внимание покрытию на уровне требований.
Пример 1:
С волнением готовясь к семейному торжеству, вы заказали у портного платье и попросили пришить на его вырезе синие пуговицы.
Во время пошива платья портной решил, что пуговицы на вырезе будут смотреться плохо, поэтому вместо них он пришил кайму золотистого цвета. В день примерки недовольный клиент, безусловно, выразил свое недовольство и обвинил портного в нарушении его требований.
Пример 2 :
При тестировании приложения чата тестировщик уделил внимание всем важным аспектам, таким как общение нескольких пользователей в группе, общение двух пользователей независимо друг от друга, наличие всех эмоджи, немедленная отправка обновлений пользователю, но забыл свериться с требованиями, где четко говорилось, что при общении двух пользователей должна быть доступна опция видеозвонка.
Клиент рекламировал приложение для чата, утверждая, что оно позволяет осуществлять видеозвонки. Можете представить, как привлеченные рекламой пользователи разочаруются, когда обнаружат, что не могут общаться по видеосвязи.
Полезные практики
1. Понимание области работы:
Прежде всего, команда QA должна полностью разобраться в объеме работы и состоянии продукта на данный промежуток времени, чтобы определить, потребуются ли дополнительные тесты.
2. Оценка назначений и процессов выполнения:
Важно убедиться, что все тест-кейсы назначены исполнителям и выполняются.
Как убедиться, что все протестировано
- Установите приоритеты для требований и направляйте свою энергию туда, где она наиболее необходима
- Следите за изменениями в каждом релизе
- Внедрите автоматизацию тестирования
- Используйте инструменты управления тестированием
- Эффективно распределите задачи, выделив лучшие ресурсы на критически важные задания. Дайте новичкам шанс изучить больше, чтобы получить свежий взгляд на рутинные для вас задачи
- Ведите чек-листы для всех ваших задач и других активностей
- Больше взаимодействуйте с командами Dev/Scrum/BA, чтобы лучше понимать поведение приложения
- Отслеживайте все циклы сборки и фиксов
Советы по повышению тестового покрытия
1. Обмен ресурсами: обменивайтесь задачами между членами вашей команды. Это поможет повысить вовлеченность и предотвратить неравномерную концентрацию знаний.
2. Тестирование совместимости: обеспечьте тестирование вашего приложения в различных браузерах и на разных платформах.
3. Ответственность: доверьте тестировщикам ответственность за определенные модули или задачи, при этом обеспечив контроль и поддержку. Это поспособствует развитию ответственности и поощрит творческий подход к работе.
4. Сроки: знание сроков релиза до начала фазы тестирования поможет в эффективном планировании.
5. Общение: оставайтесь на связи с разработчиками и другими командами на протяжении всего цикла разработки продукта, чтобы быть в курсе текущих событий.
6. Матрица требований (RTM): ведите матрицу требований, чтобы команда и клиенты знали об актуальном состоянии продукта и выполнении требований.
На что влияет тестовое покрытие?
- Оно помогает эффективно определить приоритеты задач тестирования.
- Предотвращается утечка требований.
- Упрощается анализ влияния.
- Упрощается определение критериев окончания тестирования.
Заключение
Не всегда верно, что если тестировать больше, то результаты будут лучше. Важно иметь четкую стратегию тестирования, ведь без нее можно потратить много времени впустую, так и не достигнув уверенности в качестве продукта. При структурированном подходе к тестированию, вы сможете стремиться к достижению максимального покрытия требований без ущерба для качества продукта.
Оставляйте свои комментарии и мнения о статье. Как обычно, мы будем рады получить обратную связь.
Перевод статьи “Test Coverage In Software Testing (Tips To Maximize Testing Coverage)”.