Списки и Сценарии — различия между версиями

Материал из Брацка Правки
Перейти к: навигация, поиск
(Текст)
Строка 10: Строка 10:
  
 
===Текст===
 
===Текст===
:<p><strong>Списки и Сценарии</strong></p><p>Команды разработчиков цифровых систем используют различные форматы заранее подготовленных планов тестинга. Чаще других встречаются пошаговые инструкции проведения тестов и тестовые спецификации.</p><p>В тестировании цифровых систем, пошаговые инструкции проведения тестов традиционно называются "сценариями" (test case). Сценарные тесты обыкновенно пишутся на основе пользовательских историй (user story). Пользовательские истории -- это один из форматов требований. Стандартный формат такого требования к системе состоит из трёх секций:<ol type="a"><li><code>Имея права (описывается пользователь или системная роль того, кто получит выгоду от функционала),</code></li><li><code>я хочу (описывается желаемый функционал),</code></li><li><code>чтобы (описывается выгода, которую функционал создаст для пользователя).</code></li></ol></p><p>Стандартный сценарий теста формируется на базе сценария требования. Вот, например, формат "Дано-Когда-Тогда" (Given-When-Then или GWT):<ol type="a"><li><code>Дано: (описывается начальное состояние сценария),</code></li><li><code>Когда: (описывается последовательность конкретных действий, которое совершает пользователь),</code></li><li><code>Тогда: (описывается то, что система должна сделать в ответ на описанную выше последовательность действий).</code></li></ol></p><p>Сценарий как требования, так и теста, обычно имеет название или другой идентификатор. Утверждения теста описываются простыми предложениями в формате "одно подлежащее, один глагол, одно сказуемое". Каждая секция может иметь несколько утверждений. Каждое утверждение пишется на новой строке. Связка "и" применяется в начале строки для второго и каждого последующего утверждения одной секции.</p><p>Так как сценарий создаётся от имени пользователя, сценарные форматы сложно применить к серверным, а не не пользовательским фунционалам. Пошаговая инструкция также не опишет тех тестов, ожидаемые результаты которых относятся к качеству, не измерениям. Тестирование на удобство пользования, например, может оценивать возможность пользователя самостоятельно создать последовательность шагов. Наконец, квалифицированные тестировщики могут не нуждаться в точных деталях сценариев и затраты на их создание необоснованы.</p><p>Тестовые спецификации могут использоваться как там, где сценарные тесты неприменимы, так и вместо них. Простые тестовые спецификации выглядят как маркированный список характеристик или функций, опросной лист, дефектная ведомость, или карта контрольных проверок.</p><p>Разработчики могут создавать свои форматы. Брацки Техсовет, например, совмещает сценарии и спецификации.</p><p><i>А теперь, выберите, пожалуйста, лучшее завершение следующего предложения.</i> Судя по тексту выше, :</p>
+
:<p><strong>Списки и Сценарии</strong></p><p>Команды разработчиков цифровых систем используют различные форматы заранее подготовленных планов тестинга. Чаще других встречаются пошаговые инструкции проведения тестов и тестовые спецификации.</p><p>В тестировании цифровых систем, пошаговые инструкции проведения тестов традиционно называются "сценариями" (test case). Сценарные тесты обыкновенно пишутся на основе пользовательских историй (user story). Пользовательские истории -- это один из форматов требований. Стандартный формат такого требования к системе состоит из трёх секций:<ol type="a"><li><code>Имея права (описывается пользователь или системная роль того, кто получит выгоду от функционала),</code></li><li><code>я хочу (описывается желаемый функционал),</code></li><li><code>чтобы (описывается выгода, которую функционал создаст для пользователя).</code></li></ol></p><p>Стандартный сценарий теста формируется на базе сценария требования. Вот, например, формат "Дано-Когда-Тогда" (Given-When-Then или GWT):<ol type="a"><li><code>Дано: (описывается начальное состояние сценария),</code></li><li><code>Когда: (описывается последовательность конкретных действий, которое совершает пользователь),</code></li><li><code>Тогда: (описывается то, что система должна сделать в ответ на описанную выше последовательность действий).</code></li></ol></p><p>Сценарий как требования, так и теста, обычно имеет название или другой идентификатор. Утверждения теста описываются простыми предложениями в формате "одно подлежащее, один глагол, одно сказуемое". Каждая секция может иметь несколько утверждений. Каждое утверждение пишется на новой строке. Связка "и" применяется в начале строки для второго и каждого последующего утверждения одной секции.</p><p>Так как сценарий создаётся от имени пользователя, сценарные форматы сложно применить к серверным, а не не пользовательским фунционалам. Пошаговая инструкция также не опишет тех тестов, ожидаемые результаты которых относятся к качеству, не измерениям. Тестирование на удобство пользования, например, может оценивать возможность пользователя самостоятельно создать последовательность шагов. Наконец, квалифицированные тестировщики могут не нуждаться в точных деталях сценариев и затраты на их создание необоснованы.</p><p>Тестовые спецификации могут использоваться как там, где сценарные тесты неприменимы, так и вместо них. Простые тестовые спецификации выглядят как маркированный список характеристик и функций, опросной лист, дефектная ведомость, или карта контрольных проверок.</p><p>Разработчики могут создавать свои форматы. Брацки Техсовет, например, совмещает сценарии и спецификации.</p><p><i>А теперь, выберите, пожалуйста, лучшее завершение следующего предложения.</i> Судя по тексту выше, :</p>
  
 
===Варианты===
 
===Варианты===

Версия 20:50, 31 января 2021

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


Материалы

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

Иллюстрации

Текст

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

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

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

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

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

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

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

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

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

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

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

Варианты

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

Термины

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

Экзамен

Определения

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

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

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