Списки и Сценарии

Списки и Сценарии (здесь и далее по тексту -- Лектио) -- это часть урока Суть Проверки Работ. В Брацкой Школе, уроки делятся на так называемые лектио, каждое из которых состоит из микролекции и одного или нескольких заключительных вопросов. Урок, в свою очередь, относится к практическому семинару Выбор Профессии.

Материалы

Предшественник этого Лектио -- Заранее или по Ходу.

Текст

Списки и Сценарии

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

В тестировании цифровых систем, пошаговые инструкции проведения тестов традиционно называются "сценариями" (test case). Сценарные тесты обыкновенно пишутся на основе пользовательских историй (user story). Пользовательские истории -- это один из форматов требований. Стандартный формат такого требования к системе состоит из трёх секций:

1. Имея права (описывается пользователь или системная роль того, кто получит выгоду от функционала),
2. я хочу (описывается желаемый функционал),
3. чтобы (описывается выгода, которую функционал создаст для пользователя).

Стандартный сценарий теста формируется на базе сценария требования. Вот, например, формат "Дано-Когда-Тогда" (Given-When-Then или GWT):

1. Дано: (описывается начальное состояние сценария),
2. Когда: (описывается последовательность конкретных действий, которое совершает пользователь),
3. Тогда: (описывается то, что система должна сделать в ответ на описанную выше последовательность действий).

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

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

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

Разработчики могут создавать свои форматы. Брацки Техсовет, например, совмещает сценарии и спецификации.

А теперь, выберите, пожалуйста, лучшее завершение следующего предложения. Судя по тексту выше, для плановой проверки Брацких Ферм лучше всех подойдёт:

Варианты

спецификация. / сценарий. / ситуативный тест. / натуральное тестирование.

Следующее лектио -- Тестировка Изделий

Термины

Функциональное Тестирование, Нефункциональное Тестирование, Требования, Регрессионное Тестирование, Прогрессионное Тесирование

Экзамен

Вопросы экзамена

Какое из приведенных ниже утверждений является правильным: --

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