Заранее или по Ходу — различия между версиями

Материал из Брацка Правки
Перейти к: навигация, поиск
(Текст)
(Текст)
Строка 10: Строка 10:
  
 
===Текст===
 
===Текст===
:<p><strong>План или Планирование</strong></p><p>Какой тест лучше? Тот, который спланирован заранее или тот, который планируется по ходу? Когда лучше дать тестировщику пошаговую инструкцию и когда лучше не ограничивать тестировщика её рамками?</p><p>Ответы на эти вопросы зависят от многих факторов. Плюсы и минусы каждого подхода весьма похожи на плюсы и минусы  
+
:<p><strong>План или Планирование</strong></p><p>Какой тест лучше? Тот, который спланирован заранее или тот, который планируется по ходу? Когда лучше дать тестировщику пошаговую инструкцию и когда лучше не ограничивать тестировщика её рамками?</p><p>Ответы на эти вопросы зависят от многих факторов. Плюсы и минусы каждого подхода весьма похожи на плюсы и минусы заданных (Waterfall) и подвижных (Agile) разработок.</p><p>Прежде всего, подготовка плана многосложного теста -- это дорогостоящий проект. В запутанных ситуациях тестирования, когда процесс состоит из многих тестов и мало что известно о том, как они пройдут, и, главное, не предельно ясно, что должно получиться в результате теста, заранее подготовить план просто нереально.</p><p>Если же понятно, каким должен быть ожидаемый результат, как минимум заключительную часть теста спланировать вполне исполнимо. Основное правило заключается в следующем: ситуативное тестирование применяется в тех случаях, когда выполнение следующего теста неочевидно, или когда Вы хотите выйти за рамки очевидного. </p><p>Квалификация тестировщика -- это другой фактор. Если тестировщик неквалифицирован, боится задавать вопросы и не знает, что делать без инструкции, то ему лучше дать план для исполнения. Если же тестировщик квалифицирован, не боится задавать вопросов и может сориентироваться по ситуации, то он или она может без подробной инструкции обойтись.</p><p>Перспектива дальнейшей разработки -- это ещё один фактор для рассмотрения когда речь идёт и функциональном тестировании. Вложение денег и времени в написание детальной спецификации или пошаговой инструкции имеет смысл, когда написанная раз инструкция будет снова и снова прогоняться как возвратный тест.</p><p>Наконец, заранее подготовленные спецификации или сценарии тестов необходимы, если несколько сторон заинтересованы в тесте и их интересы противоречат друг другу. Классическим примером будет приёмка заказчиком готового изделия у подрядчика. Представим, что подрядчик предпочитает дальше не тратиться на дальнейшую разработку и отдать то, что уже сделано. Допустим, заказчик заинтересован получить максимум на заплаченные деньги и требует дополнительной работы подрядчика. В этом случае, написанная для приёмочного теста подробная инструкция разрешит конфликт. Если изделие проходит тест, подрядчик свою часть сделал и заказчик не может требовать чего-то большего.</p><p>Наконец, трудно совместить заданный (Waterfall) и подвижный (Agile) подход в одной разработке. Напротив, плановые и ситуативные тесты полностью совместимы. Их не только можно встретить вместе в одном проекте, но и совершающимися параллельно и даже одновременно.</p>
 
 
 
 
 
 
в сложных ситуациях тестирования, когда мало что известно о продукте, или как часть подготовки набора сценариев тестов. Основное правило заключается в следующем: исследовательское тестирование используется в тех случаях, когда выполнение следующего теста неочевидно, или когда вы хотите выйти за рамки очевидного.  
 
 
 
Ключ к обоим подходам состоял в том, чтобы избегать пошаговых инструкций по тестированию с ожидаемыми результатами и вместо этого заменить их описанием, которое давало свободу тестировщику, ограничивая при этом объем теста.
 
 
 
 
 
 
 
 
 
 
 
 
 
Вложение денег и времени в написание инструкции имеет смысл, когда разработка будет продолжена и написанная раз инструкция будет прогоняться далее как возвратный тест. Инструкции предпочтительнее, если предельно ясно, что тестируется. Наконец, инструкции необходимы, если несколько сторон заинтересованы в тесте и их интересы противоречат друг другу.</p><p>Классическим примером будет приёмка заказчиком готового изделия у подрядчика. Представим, что подрядчик предпочитает дальше не тратиться на дальнейшую разработку и отдать то, что уже сделано. Допустим, заказчик заинтересован получить максимум на заплаченные деньги и требует дополнительной работы подрядчика. В этом случае, написанная для приёмочного теста подробная инструкция разрешит конфликт. Если изделие проходит тест, подрядчик свою часть сделал и заказчик не может требовать чего-то большего.</p>
 
 
 
<p>Плановые и ситуативные тесты полностью совместимы. Их не только можно встретить вместе в любом проекте, но и совершающимися параллельно и даже одновременно.</p>
 
  
 
===Термины===
 
===Термины===

Версия 06:05, 30 января 2021

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


Материалы

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

Иллюстрации

Текст

План или Планирование

Какой тест лучше? Тот, который спланирован заранее или тот, который планируется по ходу? Когда лучше дать тестировщику пошаговую инструкцию и когда лучше не ограничивать тестировщика её рамками?

Ответы на эти вопросы зависят от многих факторов. Плюсы и минусы каждого подхода весьма похожи на плюсы и минусы заданных (Waterfall) и подвижных (Agile) разработок.

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

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

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

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

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

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

Термины

Требования, Тестовый Пример, Юзабилити-тестирование, Регрессионное Тестирование, Прогрессивное Тестирование

Вопрос(ы)

Судя по прочитанному тексту выше: Регрессионное тестирование вполне возможно для Юзабилити-Тестирования. -- Ложь\Правда
Следующее лектио -- Инструкции Тестов