Как увеличить тестовое покрытие (test coverage)?

Перевод статьи “Test Coverage In Software Testing (Tips To Maximize Testing Coverage)”.

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

Друзья, поддержите нас вступлением в наш телеграм канал QaRocks. Там много туториалов, задач по автоматизации и книг по QA.

Содержание:

• Что такое тестовое покрытие?
• Тестовое покрытие и покрытие кода
• Мой опыт
• Типы тестового покрытия
• Как убедиться, что все протестировано
• Советы по повышению тестового покрытия
• На что влияет тестовое покрытие?
• Заключение

Что такое тестовое покрытие?

Тестовое покрытие – это концепция, которая отвечает на два важных вопроса: “Что и в каком объеме мы тестируем?” То есть, она определяет, какие части системы подвергаются тестированию и сколько тестов необходимо для их покрытия.

Тестовое покрытие важно для контроля качества тестирования. Оно помогает QA-инженерам создавать тесты для компонентов, которые могли быть пропущены или еще не проверены.

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

Это также применимо и к нефункциональному тестированию. Необходимо следить за тем, чтобы все нефункциональные требования были реализованы и протестированы. Как раз для этого и используется метрика тестового покрытия.

Тестовое покрытие и покрытие кода

Тестовое покрытие часто путают с покрытием кода. Несмотря на их сходство, они имеют существенные различия. Рассмотрим оба этих понятия более подробно.

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

Тестовое покрытие заключается в проверке каждого требования хотя бы одним тестом и, в отличии от покрытия кода, является работой QA-команды.

Толкование термина “покрытое требование” может различаться в зависимости от его определения каждой конкретной командой.

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

• Если у вас есть 10 требований и создано 100 тестов – в случае, если все 10 требований проверяются хотя бы одним позитивным тестом из 100 – это можно назвать достаточным тестовым покрытием на уровне дизайна.
• Если из созданных тестов выполняется только 80, и они проверяют всего 6 требований, можем утверждать, что 4 требования не покрыты, несмотря на то, что выполнено 80% всех тестов. Этот пример показывает покрытие на уровне выполнения.
• Если мы создали 90 тестов, связанных с 8 требованиями, в то время как остальные требования остались без внимания, мы можем утверждать, что покрытие по назначению составляет 80% (8 из 10 требований).

Также важно определить, когда проводить расчет покрытия. Если начать расчет покрытия слишком рано, множество требований останутся непокрытыми. Поэтому обычно рекомендуется дождаться последней сборки перед проведением итоговых расчетов тестового покрытия.

Мой опыт

Когда мой стаж работы в области тестирования ПО составлял всего 2 года, я считал, что незнание некоторых основ тестирования – это нормально, все придет с опытом.

Я был прав – и одновременно неправ.

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

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

На одном из собеседований, я столкнулся со следующей ситуацией:

Меня спросили, как я понимаю, что тестовое покрытие является полным?”

“Я убеждаюсь в этом, если тестирую каждую функциональность”, – сказал я.

“То есть, вы хотите сказать, что когда вы протестируете все функциональные возможности, вы будете уверены, что охватили максимум продукта с точки зрения тестирования?” – спросил интервьюер.

“Да, потому что при тестировании всех функциональных возможностей, появляется уверенность в правильном поведении продукта”, – подтвердил я.

“Я согласен, но мой вопрос в том, даст ли это вам уверенность в том, что ваше тестовое покрытие полное?” – спросил интервьюер.

Этот вопрос побудил меня задуматься глубже о понятии “тестового покрытия”.

Типы тестового покрытия

Тестовое покрытие может иметь различное значение в разных контекстах. Давайте рассмотрим эти контексты поочередно:

Покрытие продукта

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

Пример 1:

Если мы тестируем “нож” как продукт, то важно не ограничиваться только проверкой на то, может ли он нарезать овощи и фрукты. Существуют и другие аспекты, на которые необходимо обратить внимание. Например, удобство его использования – пользователю должно быть удобно держать его в руке.

Пример 2:

Если вы тестируете приложение “Блокнот”, то, конечно, необходимо проверить его основные функции.

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

Если эти сценарии не будут рассмотрены, то нельзя утверждать, что тестовое покрытие приложения полное.

Покрытие рисков

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

Пример 1:

Если во время тестирования самолета тестировщик скажет вам, что внутренняя система самолета полностью проверена и исправно функционирует, но при этом тестирование его способности к реальным полетам не было проведено – какова будет ваша реакция?

Определение рисков, связанных с использованием продукта и их тщательное тестирование – вот что подразумевается под покрытием на уровне рисков.

Пример 2:

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

Покрытие требований

Качественная разработка продукта становится неактуальной, если она не соответствует требованиям клиента. Поэтому особенно важно уделять внимание покрытию на уровне требований.

Пример 1:

С волнением готовясь к семейному торжеству, вы заказали у портного платье и попросили пришить на его вырезе синие пуговицы.

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

Пример 2 :

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

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

Как убедиться, что все протестировано

• Убедитесь, что тестировщики полностью понимают все требования к продукту.
• Установите приоритеты для требований и направляйте свою энергию туда, где она более необходима.
• Следите за изменениями в каждом релизе.
• Внедрите автоматизацию тестирования.
• Используйте инструменты управления тестированием.
• Эффективно распределите задачи, выделив лучшие ресурсы на критически важные задания. Дайте новичкам шанс изучить продукт, чтобы получить свежий взгляд на рутинные для вас задачи.
• Ведите чек-листы для всех ваших задач.
• Больше взаимодействуйте с командами Dev/Scrum/BA, чтобы лучше понимать поведение приложения.
• Отслеживайте все циклы сборки и исправлений.

Советы по повышению тестового покрытия

1. Обмен ресурсами: Распределите задачи между членами вашей команды.

2. Тестирование совместимости: обеспечьте тестирование вашего приложения в различных браузерах и на разных платформах.

3. Ответственность: доверьте тестировщикам ответственность за определенные модули или задачи, при этом обеспечив контроль и поддержку. Это поспособствует развитию ответственности и творческого подхода к работе.

4. Сроки: знание сроков релиза перед началом тестирования поможет в эффективном планировании.

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

6. Матрица требований (RTM): ведите матрицу прослеживаемости требований, чтобы команда тестирования и клиенты знали об актуальном состоянии продукта и выполнении требований.

На что влияет тестовое покрытие?

• Помогает эффективно определить приоритеты задач тестирования.
• Предотвращает утечку требований.
• Упрощает определение критериев окончания тестирования.

Заключение

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

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