Март, 2015

Нужны ли тест-кейсы вашему проекту?

Опубликовано: 06.03.2015 | 7084

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

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

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

Начнем с небольшой теории..

..чтобы обозначить границы каждого подхода. Их, как вы уже должно быть догадались, два:

  1. Тестирование по готовым сценариям (тест-кейсам)
  2. Исследовательское (эксплоративное).

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


Исследовательское тестирование

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

Тестирование по тест-кейсам

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

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

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

Сравниваем!

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

Преимущества исследовательского похода:

  1. Дает больше свободы тестировщику, развивает его навыки. Позволяет поработать и развить новые техники и стратегии тестирования.
  2. Все время выделено только для проведения тестирования.
  3. Тестировщик более глубоко исследует и вникает в программный продукт.
  4. Нет дополнительных затрат на актуализацию тест-кейсов.

Преимущества сценарного подхода:

  1. Сокращение времени на освоение продукта при подключении нового сотрудника на проект. Эффективный способ быстро ввести в курс дел нового сотрудника, подключившегося к проекту, в любой момент есть возможность «вспомнить», что было сделано месяц или год назад.
  2. Тестирование проектной документации ещё до выхода первого билда.
  3. Значительное ускорение процесса регрессионного тестирования.
  4. Возможность работы специалистов менее высокой квалификации при тестировании по сценариям.
  5. Легко оценить тестовое покрытие.
  6. Контроль качества продукта с течением времени и сохранение истории работ по тестированию.
  7. Структурированный системный подход к тестированию снижает вероятность пропуска ошибки.
  8. Выполнение тестов не требует дополнительного времени на общение с разработчиками и аналитиками, работу с требованиями.

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

Недостатки исследовательского подхода:

  1. Тестировщику с небольшим опытом труднее на первых этапах работ, отсутствует наглядное представление о том, что и как тестировать.
  2. Сложности в оценке тестового покрытия, а так же в расчете временных затрат.
  3. Требуется большое количество времени для изучения продукта.

Недостатки сценарного подхода:

  1. Тестирование по тест-кейсам приглушает творчество и свободу в действиях специалиста по качеству.
  2. Вырабатываются привычки проводить шаблонные проверки, которые были описаны в сценариях.
  3. Постоянное тестирование по шаблонам для тестировщика может быть утомительно.
  4. Требует много времени на поддержку тестовых сценариев: обновление, удаление, исправление

Делаем выводы

Таким образом, и у того, и у другого похода есть видимые преимущества и недостатки. Однако, как мы видим, тестирование по тест-кейсам все же выигрывает. Но это вовсе не означает, что данный подход будет хорош для любого проекта и для любой компании. При промышленном тестировании крупных проектов использование сценарного подхода принесет вам больше пользы и будет целесообразным. Прежде чем писать тест-кейсы следует в первую очередь оценить объем и сложность проекта, необходимость автоматизации, которая становится все более популярной. Если такой анализ был проведен, внедрение тестовых сценариев на проекте будет максимально эффективным для обеспечения высокого качества продукта. А если вы работаете с небольшими мобильными приложениями, которых у вас много - тестируйте эксплоративно и пишите чеклисты, тест-кейсы только будут захламлять ваш процесс.