Разработка сценариев тестирования

Стандартный

Решил поделиться схемой разработки testcase’ов, которой пользуюсь сам. Не претендую на полноту и уникальность, сейчас меня такой подход полностью устраивает. Возможно, кто-нибудь сможет извлечь из него что-то полезное и для себя. Собственно, процесс разработки сценариев тестирования состоит из четырех этапов:

  1. Определение требований к ПО
  2. Группировка требований по приоритету
  3. Определение use-case’ов
  4. Разработка сценариев тестирования на основе определенных use-case’ов

1. Определение требований к ПО

Для начала выполнения тестирования необходимо знать и понимать требования, предъявляемые к разрабатываемому продукту. Источниками требований служат:

  • Техническое задание
  • Спецификации (Software Requirements Specification, Design Specification и пр.)
  • Команда проекта
  • Заказчик
  • Конечные пользователи

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

2. Группировка требований по приоритету

После того как требования определены, имеет смысл сгруппировать их по приоритету. Можно использовать три уровня приоритета:

  • Главные требования
  • Важные требования
  • Дополнительные требования

Делать это полезно по следующим причинами:

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

3. Определение use-case’ов

Для удобства разработки сценариев тестирования полезно сначала определить все возможные сценарии использования. Сделать это можно, используя требования. Т.е. берем требование и анализируем какие сценарии использования оно может «генерировать». Так же часто в спецификациях указываются сценарии использования, правда не все возможные. Разработка test-case’ов на основе use-case’ов — один из самых простых методов. Для него не нужно знать какие угрозы качеству существуют для ПО, какие бывают классы дефектов и т.п. С другой стороны, данный метод достаточно эффективен, т.к. он опирается на сценарии работы конечных пользователей.

При определении сценариев использования полезно руководствоваться следующими идеями:

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

Этапы определения требований и use-case’ов не обязательно должны быть формализованными. Достаточно перед разработкой test-case’ов взять лист бумаги и карандаш и набросать перечень требований и use-case’ов, для которых будут написаны эти test-case’ы.

4. Разработка сценариев тестирования на основе определенных use-case’ов

После того, как определены use-case’ы, можно приступать к разработке сценариев тестирования. Разработка test-case’ов выполняется в три этапа:

  1. Выделение граничных значений и классов эквивалентности.
  2. Составления списка проверок на основе полученных классов и граничных значений.
  3. Составление checklist’а со списком test-case’ов для занесения в него результатов выполнения тестов.

Разработанные сценарии в checklist удобно группировать по use-case’ам, которые они тестируют. Кроме того, при работе со сценариями тестирования полезно придерживаться следующих рекомендаций:

  1. Детализация test-cases. Не нужно подробно расписывать каждый шаг. Это слишком дорого. Уходит много времени на написание. Достаточно более-менее детально зафиксировать что нужно проверить (Но квалификация тестировщиков должна быть выше). Другими словами, подробность test-case’а должна быть не избыточной.
  2. Для удобства распараллеливания работ для каждого компонента или типа тестирования имеет смысл создавать свой checklist. Это избавит от проблем при редактировании одного документа несколькими людьми. Кроме того, с такими checklist’ами можно будет оценить состояние каждого компонента в отдельности. Так же, с такой организацией checklist’ов будет проще закреплять за каждым тестировщиком его часть работ.
  3. Форма записи test-case’ов может быть любой: excel-таблица, документ word и т.д. Главное чтобы форма хранения была удобной и не создавала лишних проблем.

В итоге получается такая связь: Требование →Use-case →Test-case. Следующим в цепочке может быть дефект. Если для каждого звена в цепи сохранять ID требования, можно будет отслеживать текущее состояние требований (например, степень протестированности и количество дефектов в реализации).

Т.к. данная схема завязана на use-case’ы, то лучше всего она подходит для функциональных тестов. Для других видов тестирования, возможно, надо будет придумать что-то другое.

Реклама

Разработка сценариев тестирования: 2 комментария

  1. Добрый день,
    Считаю немного неверным изначальный подход к решению проблемы. Я бы для начала сделал декомпозицию продукта, а потом уже проводить анализ и приоритезацию «фич». Ведь может потребоваться, для начала, выпустить набор «фич» из разных частей продукта, и будет очень легко выделить набо тестов необходимый для этого. Use-case’ы — вы выделите возможные сценарии использования, а что затронет невозможные сценарии, непредпологаемые исходы? Я бы здесь использовал, так называемые тестовые идеи, те то что по вашему важно проверить, на чем продукт может завалиться и это необязательно будут сценарии использования. Сценарии использования охватывают лишь часть того, что нужно проверить.

  2. Добрый день! Спасибо за комментарий.
    Декомпозиция продукта на части безусловна полезна, я и сам так поступаю и храню тест-кейсы отдельно для каждого компонента. Т.е. сначала идет группировка по компонентам, потом по use-case’ам. Но на мой взгляд, это больше относится к организации хранения тест-кейсов. Например, если продукт небольшой, то декомпозицию можно не проводить.
    По поводу негативных тестов. Классы эквивалентности как раз позволяют рассмотреть возможные варианты некорректного ввода. Часть негативных тестов это даст. Но вот про использование программы не по назначению я дейститвельно не написал :) Видимо, при анализе возможных use-case’ов следует держать в голове целиком «неправильные» варианты использования.

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s