Are Test Plans a Waste of Time? by Andrew Schiano
Должно быть вы, как и
многие тестеры, ненавидите тестовые планы. Большинство тестеров попадают в три
группы: Группа A
– не любит написание тестовых планов, Группа B – думает, что тестовые планы это
трата времени, и Группа C
– думают, что обе группы A
и B
правы.
Начнем с группы A. Некоторые тестеры не любят
написание тестовых планов, потому что им просто не нравиться писать. Их неприязнь не столько в том, что они пишут,
а с связано тем фактом, что они вообще что-то пишут. Возможно, писанина не
подходит их естеству. Один тестер в ответ сказал мне, «Я пишу как
третьеклассник». Это не удивительно, что
он не любит их писать – мы хотели бы делать вещи, в которых мы хороши.
Некоторые тестеры не любят
написание тестовых планов, потому что они не совсем тестеры – они разработчики,
работающие в тестировании. Они бы предпочли,
если бы кто-то другой анализировал функциональную спецификацию, написал
тестовый план, и сказал им точно, что им необходимо автоматизировать.
Как у многих тестеров,
все мои предыдущие места работы были в программировании. Я думал, написание
плана тестирования это просто – пока я не увидел мой первый шаблон тестового
плана. Тестирование производительности?
Стрессовое тестирование? Дальне магистральное тестирование? Я быстро понял, что
у меня нет идей как писать тестовый план, и я боялся писать один. Но я начал
читать планы от тестеров, которых
уважаю, и я начал читать книги по тестированию. Я медленно произвел
трансформацию из разработчика к тестеру. Сейчас я люблю написание тестовых планов,
потому что я знаю, что это сделает мое тестирование лучше.
Пожалуй, есть много
интересных причин, почему тестеры не любят тестовые планы объясняется это тем,
что они не думают о полезности планов. Они указывают на тот факт, что
большинство планов тестирования, никогда не обновляются. Как только продукт
эволюционирует, тестовые планы разсинхронизируются с текущей функциональностью.
Я нахожу, что это правда. Из всех тестовых планов написанных мною за мою
карьеру, я знаю точно, как много я их обновлял после изменения продукта: НОЛЬ.
Это проблема по двум
причинам. Первая, это было бы одно дело, если планы тестирования писались бы
быстро и легко; но это не так. В зависимости от функциональности, это может
потребовать до недели, чтобы написать солидный подробный тестовый план. Некоторые
утверждают, что это время лучше потратить на автоматизацию тестов или выполнять
исследовательское тестирование.
Даже хуже, планы
тестирования, которые не
синхронизированы с функциональностью продукта, дают не точную информацию
читателю. Недавно, я работал над продуктом, который был в состоянии обновления
до следующего релиза, меня назначили тестировать функциональность, я был
полностью незнаком с ним. Первое что я сделал, был просмотр первоначальных
тестовых планов, чтобы узнать, как функции работают, и как это тестировалось
впервые. Я предположил, неправильно, что документация была актуальной. В
результате, я сообщил о багах хотя
функции работали правильно.
James Whittaker, Директор тестирования в Google, недавно обсуждал значение создания тестовых
планах в блоге Google потестированию:
«Что касается того, стоит ли это делать, вообще хорошо, что
это другая история. Каждый раз, когда я смотрю на десятки тестовых планов
написанных моей командой, я вижу мертвые планы тестирования. Планы написанные,
рассмотренные, упомянутые пару раз, а затем заброшенные, так как проект
движется в направлении, не задокументированном в плане. Возникает вопрос: если
план не нужно беспокоиться обновлять, стоит ли его создавать в первую очередь?
Иногда план отбрасывается потому что он пошел во множество
деталей или их слишком мало; третьи, потому что предоставляет значение только
для начала тестового усилия, а не в продолжающейся работе. Опять же, если это
так, этот план стоит своей стоимости создания, дал ли он ограничение и
уменьшение стоимости?
Некоторые тестовые
планы содержат простые истины что вероятно в действительности не нужно
документировать или предоставляют детализированную информацию, которая не соответствует ежедневной работе
тестера. Во всех этих случаях мы это будет напрасный труд.»
Я согласен, что тут
может быть напрасный труд в написании тестового плана. Например, я виновен в
том, что трачу очень много времени на корректировку формулировки моих
документов. Это тест план, не роман. Маркировка пунктов и приведение в порядок
фрагментов предложения – вы не должны тратить время на использование словаря в
поиске синонима для слова «характеристика».
Но это не значит что
все это напрасный труд. На самом деле, я верю в пользу превышения усилий. Это правильно
даже если тестовый план быстро становится устаревшим.
Рассмотрим
функциональную документацию: очень похожи на тестовые планы, функциональные
спецификации часто устаревают с
развитием продукта. Это не означает, что мы не должны писать функциональные
спецификации. Возможно документ «устаревший» и это не обоснованный довод против
написания спец документов – или тест планов. Только не делайте ошибку, рассчитывая,
что старая спецификация по-прежнему точна.
Одна из наиболее важных
причин создания тестового плана это получение ваших мыслей о тестировании
функциональности на бумагу из вашей головы. Это разгружает ваш ум и помогает
вам думать яснее. А кроме того документируя идею, которую вы получаете во время
тестирования особенности, так ни одну не забудете.
Процесс написания часто
приводит вас к продумыванию наиболее лучших путей тестирования особенности. Ваш
первый проход в письменной форме тестового плана может включить главным образом
позитивные функциональные тестовые случаи, а также горстка негативных
функциональных тестов. Но в процессе улучшения вашего документа это приведет
вас к рассмотрению более негативных случаев, более граничных случаев, больше
проблем вокруг масштабируемости и безопасности. Больше времени потратите на
планирование вашего тестирования, более полное тестирование будет.
Детализированные
тестовые планы могут также помочь вам найти баги в функционале, прежде чем код
даже будет реализован, когда они гораздо менее дорогостоящие. Два метода
которые прекрасно подходят для поиска дыр проектирования в течении планирования
теста это «Таблица решений» и «Диаграммы переходных состояний». Я помню
создавая большую Таблицу Решений как часть тестового плана для функций безопасности,
которая обнаружила, что почти 10% возможностей включая комбинации, не имеют
ожидаемого результата в проектном документе спецификации.
Тестовая документация
также полезна для проведения обзора тестового плана. После создания вашего тестового плана, важно,
чтобы его просмотрели другие тестировщики – ни один тестер не сможет продумать
все возможные тестовые случаи. Так же полезно, чтобы ваш тестовый план был
просмотрен со стороны разработчиков и руководителей проекта. В моем наиболее
свежем тестовом плановом обзоре, менеджер программ сказал мне, что одну из
особенностей, которую я запланировал проверить, должна быть исключена. В этом
же обзоре, разработчик проинформировал меня об существующих проверочных крюках,
которые сэкономят мне часы от времени разработки.
Когда тестеры говорят,
что не хотят писать тест-планы, я могу посочувствовать. Большинство из нас
пришел в этот бизнес, либо потому, что нам нравится программирование или потому
что нам нравится ломать вещи, не потому что нам нравится писать документы. Но когда
тестеры говорят, что не хотят писать тест-план, потому что это не полезно, я
вынужден не согласиться. Хороший тест-план сделает продукт лучше. Что из того
что они устаревают? Поскольку Dwight
D.
Eisenhower
и
Wile
E.
Coyote
однажды
сказал, «планы бесполезны, но планирование просто необходимо.»
