Что пишут в блогах

Подписаться

Онлайн-тренинги

Конференции

Что пишут в блогах (EN)

Разделы портала

Про инструменты

.
Достаточно – это сколько? Тестирование как рассказ
09.10.2019 00:00

Автор: Джеймс Бах (James Bach)
Оригинал статьи
Перевод: Ольга Алифанова

Классический вопрос, который задают про тест-стратегию – это "А сколько тестирования достаточно?" Если вы тестируете исключительно по тест-кейсам или через автоматизацию, то ответ кажется очевидным – проделано достаточно тестирования, когда у вас закончились тесты. Однако этот ответ недостоин мыслящего тестировщика. Мыслящий тестировщик задает вопрос так, чтобы он затрагивал миссию тестирования, а не только кнопочки, которые нажимаются в процессе. Всех уже существующих тест-процедур может быть недостаточно для осуществления миссии… или же они могут быть избыточными.

Наша миссия не в том, чтобы выполнять определенный набор действий. Для большинства из нас миссия в том, чтобы узнать о продукте достаточно важной информации, чтобы наши клиенты (в основном разработчики и менеджеры) могли принимать информированные решения.


Тестирование как рассказ

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

К примеру, я как-то раз тестировал процесс установки сложного продукта. Моей миссией было оценить и каталогизировать все изменения, которые продукт проводил в системах, где устанавливался. Моим первым шагом был анализ процесса установки. Затем я создал его диаграмму, определил, как тестировать его важные части, и нашел способы делать это при разумно контролируемых условиях. Я пришел к выводу о продукте, который логически вытекал из тестирования, а затем проверил этот вывод, чтобы убедиться, что каждая его часть была доказана и поддержана проведенными тестами. Мне было нужно, чтобы мой отчет был хорошей, убедительной историей, поэтому я попытался представить, как моя аудитория может его раскритиковать. Где моя история слабовата? Как она может оказаться ложной? Я провел дополнительные тесты, чтобы исключить альтернативные гипотезы. Я прогнал тесты неоднократно, чтобы повысить уверенность в том, что полученные результаты были связаны с контролируемыми мной процессами и переменными, а не со случайными событиями.

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

Короткая история может быть такой же законченной, как и роман.

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

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

Сюжетные линии тест-истории

Полная тест-история отвечает на следующие вопросы: Каков статус продукта (бага, и т. д.)? Как вы это узнали (тест-стратегия, включая информацию о тест-покрытии и оракулах)? Насколько хорошим было тестирование?

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

Один из способов упрощения тест-истории, который применяется множеством тестировщиков – это прятки среди тест-кейсов. Их история выглядит как "я написал тест-кейсы, я прогнал тест-кейсы. Кейсы прошли". У этой истории нет содержания. Она слишком общая, и, как я считаю, скучна и безответственна. Вы можете больше! Поговорите о том, что значат эти кейсы. Что они покрывают? Какие риски вы исследуете с их помощью?

Концепция тест-истории – это не только отчетность. Она также помогает вам управлять собой. Она помогает решать, когда нужно остановиться. И поэтому в мире Rapid Software Testing тест-история и занимает центральное место.

Обсудить в форуме