Что такое тест: ТЕСТ | это… Что такое ТЕСТ?

Опубликовано автором

Содержание

Про Тестинг — Тестирование — Тест План или план тестирования

 ► в закладки  

Раздел: Тестирование > Тестовые Артефакты > Тест План (План тестирования)

Тест план (Test Plan) — это документ, описывающий весь объем работ по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования, до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков с вариантами их разрешения.

Каждая методология или процесс пытаются навязать нам свои форматы оформления планов тестирования. Предлагаю вам, как пример, шаблоны тест планов от RUP (Rational Unified Process) и стандарт IEEE 829:

  1. Test Plan Template RUP
  2. Test Plan Template IEEE 829

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

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

  1. Что надо тестировать?
    • описание объекта тестирования: системы, приложения, оборудования
  2. Что будете тестировать?
    • список функций и описание тестируемой системы и её компонент в отдельности
  3. Как будете тестировать?
    • стратегия тестирования, а именно: виды тестирования и их применение по отношению к объекту тестирования
  4. Когда будете тестировать?
    • последовательность проведения работ: подготовка (Test Preparation), тестирование (Testing), анализ результатов (Test Result Analisys) в разрезе запланированных фаз разработки
  5. Критерии начала тестирования:
    • готовность тестовой платформы (тестового стенда)
    • законченность разработки требуемого функционала
    • наличие всей необходимой документации
    • . ..
  6. Критерии окончания тестирования:
    • результаты тестирования удовлетворяют критериям качества продукта:
      • требования к количеству открытых багов выполнены
      • выдержка определенного периода без изменения исходного кода приложения Code Freeze (CF)
      • выдержка определенного периода без открытия новых багов Zero Bug Bounce (ZBB)
    • …

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

Далее, чтобы документ приобрел более менее серьезный вид, предлагаем дополнить его следующими пунктами:

  • Окружение тестируемой системы (описание программно-аппаратных средств)
  • Необходимое для тестирования оборудование и программные средства (тестовый стенд и его конфигурация, программы для автоматизированного тестирования и т.д.)
  • Риски и пути их разрешения

Чаще всего на практике приходится сталкиваться со следующими видами тест планов:

  1. Мастер Тест План (Master Plan or Master Test Plan)
  2. Тест План (Test Plan)
    , назовем его детальный тест план)
  3. План Приемочных Испытаний (Product Acceptance Plan) — документ, описывающий набор действий, связанных с приемочным тестированием (стратегия, дата проведения, ответственные работники и т. д.) (Шаблон плана приемо-сдаточных испытаний от RUP)

Явное отличие Мастер Тест Плана от просто Тест Плана в том, что мастер тест план является более статичным в силу того, что содержит в себе высокоуровневую (High Level) информацию, которая не подвержена частому изменению в процессе тестирования и пересмотра требований. Сам же детальный тест план

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

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

Для увеличения ценности вашего тест плана рекомендуется проводить его периодическое рецензирование со стороны участников проектной группы. Это можно сделать просто договорившись между собой или же реализовать в виде «процедуры утверждения». Как пример, приведем список участников проектной группы, утверждение которых мы считаем необходимым:

  • Ведущий тестировщик
  • Тест менеджер (менеджер по качеству)
  • Руководитель разработки
  • Менеджер Проекта

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

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

Наверх


 

Что такое тест-кейсы? Как писать тестовые случаи, связанные с программным обеспечением?

Содержание

Что такое тест-кейсы?

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

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

Различные типы тестовых случаев:

Существуют различные типы тестовых случаев.

  1. Тестовый пример функциональности – Тестовые случаи функциональности, как следует из названия, используются для анализа того, работает ли система должным образом или нет. Команда QA отвечает за написание функциональных тестовых случаев. Этот тип тестирования может быть выполнен, как только команда разработчиков сделает первую функцию приложения доступной для тестирования. Например, проверка того, может ли пользователь загрузить изображение профиля. 
  2. Тестовый пример интеграции – Тестовые примеры интеграции используются для анализа того, правильно ли взаимодействуют различные модули приложения друг с другом. Группа тестирования отвечает за разделение областей, которые должны пройти интеграционное тестирование. С другой стороны, команда разработчиков помогает с написанием интеграционных тестов. Например, проверка того, появляется ли страница входа в систему, когда мы нажимаем кнопку «Войти» на главной странице. 
  3. Тестовый пример юзабилити – Тестовые случаи юзабилити, также известные как задачи или сценарии, представляют собой случаи, когда тестировщики представляют высокоуровневые сценарии или задачи для выполнения вместо пошаговых инструкций по выполнению теста. Эти тестовые примеры используются для анализа того, как пользователи обычно подходят к приложению и используют его. Например, проверить, может ли пользователь добавить более одного товара в свою корзину на веб-сайте онлайн-покупок, и как это работает?

Тестовый случай против тестового сценария:
Тестовый кейсСценарий тестирования
Тестовый пример — это набор действий, выполняемых для проверки определенной функции или функциональности приложения.Тестовый сценарий — это любая функциональность приложения, которую можно протестировать.
Тестовый пример фокусируется на том, как тестироватьСценарий тестирования фокусируется на том, что тестировать
Тестовый набор включает этапы тестирования, данные и ожидаемые результаты тестирования.Сценарий тестирования включает сквозную функциональность, которую необходимо протестировать.
QA и команды разработчиков несут ответственность за написание тестовых случаев.Тестовые сценарии просматриваются бизнес-аналитиками или бизнес-менеджерами.
Это помогает в исчерпывающем тестированииЭто помогает в гибкой методологии тестирования личности в целом.
Это требует больше времени, усилий и ресурсовЭто требует меньше времени и усилий по сравнению

Как писать тест-кейсы?

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

  1. Идентификатор тестового случая – Каждый тестовый пример должен быть представлен уникальным идентификатором. Это облегчает и делает более удобным их понимание и различие между ними. 
  2. Описание тестового примера – Каждый тестовый пример должен иметь надлежащее описание, состоящее из важных деталей, таких как тестируемая функция, модуль или функция и что должно быть проверено. 
  3. Предварительные условия – Мы также накапливаем условия, которые необходимо учитывать при выполнении теста.
  4. Шаги тестирования – Чтобы иметь возможность правильно выполнить тест, вы должны правильно понимать, как запускать этот конкретный тестовый пример. Итак, напишите шаги по выполнению тест-кейса легким и понятным языком. 
  5. Информация о тесте – Соберите данные, необходимые для выполнения контрольного примера, точным и кратким образом. Соберите эти данные в четкий и всеобъемлющий документ. 
  6. Желаемый результат – Объясните желаемые результаты тестового примера. Например, при нажатии кнопки входа пользователь будет успешно авторизован на веб-сайте. 
  7. Почтовые условия – Это условия, которые должны быть соблюдены при успешном выполнении тестового примера. 
  8. Фактический результат – Это результаты, которые мы получаем после выполнения тестового примера. На основе этих результатов мы узнаем, прошел тест или нет. 
  9. Статус — Наконец, мы определяем статус тестового примера как пройденный или неуспешный на основе фактических результатов, которые мы получаем от выполнения тестового примера. Если мы получаем желаемые результаты, тест помечается как пройденный, если нет, он помечается как проваленный. Если тест не пройден, он проходит через жизненный цикл ошибки, которую разработчики исправляют.

Важные советы по написанию тестового примера:

Вот несколько советов, которые следует учитывать при написании тестового примера:

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

Не забудьте поделиться этим постом!