Cемь мифов о независимости спецификаций и тестирования

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

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

Миф 1: Сначала требования, а затем тестирование

«Пока еще рано думать о тестировании. Давайте сосредоточимся на требованиях», — при таком отношении вы неминуемо столкнетесь с большими сложностями в конце проекта. Конечно, разработка корректных требований крайне важна, но один из самых лучших способов подготовить корректные требования — привлечь к анализу требований тестировщиков. Как показано на рис. 1, необходимо выполнять проектирование тестов сразу, как только появляются материалы, которые можно тестировать, что обычно происходит уже при анализе требований к системе и подготовке тестов, предлагаемых пользователями для приемки окончательного продукта.

Рис. 1. V-образная модель максимально раннего создания тестов

Общая проблема, особенно для тестировщиков, связана с влиянием изменений, внесенных в требования слишком поздно. Предположим, что до окончания тестирования системы осталось всего несколько недель, а через две недели уже планируется начать выполнение тестов, подготовленных пользователями. Внезапно, ваши пользователи заявляют: «Кстати, нам бы хотелось, чтобы система работала здесь несколько иначе». Эта ситуация весьма неприятна и возникает гораздо чаще, чем следовало бы. Но что же на самом деле совершают пользователи? Они разрабатывают свои тесты для принятия продукта. Их действия по проектированию тестов показывают, что в действительности они хотят от системы. Если бы они подготовили свои тесты раньше (левая часть рис. 1), можно было бы обнаружить проблемы до того, как они проявились.

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

Миф 2: Тестирование невозможно, пока нет системы

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

Рис. 2. Что такое «тестирование»?

Миф 3: Требования используются при тестировании, но не наоборот

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

Когда вы пытаетесь кому-то объяснить абстрактную концепцию, вы говорите: «например» и иллюстрируете свою идею конкретными и особыми случаями, проясняющими любые неясности. Тесты и есть такие «примеры» для требований. Представьте ситуации, в которых будет использоваться продукт или производственный процесс. Если вы поймете, как конкретный пользователь будет работать с системой, то системная функциональность, которая при первом изложении казалась абстрактной, обретет конкретный смысл. При наличии такой обратной связи выигрывают и тестирование, и анализ требований. Разработка продуманных требований позволяет создавать более качественные тесты; тщательный анализ тестов позволяет создавать более качественные требования.

Миф 4: Если подготовка тестов оказывается сложной, то это проблемы тестирования

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

Подготовить количественное описание нефункциональных требований, таких как полезность или производительность, крайне сложно [1]. Утверждения типа «удобный в использовании», «дружественный к пользователю», «очень надежный» или «обладающий приемлемой производительностью» — это не спецификации, а расплывчатые благие намерения. Я полностью согласна с законом, сформулированным Томом Гилбом: «Если в оценке используется превосходная степень, значит, на самом деле, такая оценка вообще ни о чем не говорит» [2]. Заметьте, что количественное описание формируется не самым адекватным образом, а самым полезным. «Критерии соответствия», предложенные Сьюзанн и Джеймсом Робертсонами, показывают, как конкретно сделать требования измеряемыми и, как следствие, тестируемыми [3].

Миф 5. Небольшие изменения в требованиях не повлияют на проект

«Просто немного увеличьте это поле ввода. На экране для этого достаточно места. Это небольшие изменения и, в силу их незначительности, вам не нужно будет его тестировать», — изменения, которые кажутся незначительными с точки зрения требований, могут иметь далеко идущие последствия. Предположим, что добавление двух символов к полю означает, что база данных, в которой это поле определено, придется перестраивать. Может быть, это поле соответствует аналогичной информации, размещенной где-то еще в системе? Может быть подпрограммы, которые проверяют состояние данного поля, проверяют при этом и другие поля, длину которых нельзя увеличить? Нужно ли вам теперь создавать две проверочные подпрограммы?

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

Миф 6: Тестировщикам, на самом деле, не нужны требования

«Я знаю, что продуманных требований к системе не существует, так что, самое лучшее, что мы можем сделать в плане тестирования — просто посмотреть, что делает система», — работа тестировщика заключается в сравнении того, что система должна делать, и того, что она делает в действительности. Система должна помочь компании добиться определенных целей, в силу чего, необходимо понять, насколько то, что делает система, отвечает этим целям.

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

Миф 7: Тестеры не могут выполнять тестирования при отсутствии требований

«Поскольку требования формируют основу тестов, совершенно очевидно, что мы не можем проводить никакого тестирования до тех пор, пока у нас нет подобающих требований», — весьма распространенное заблуждение среди тестировщиков. Иногда изменения вносятся в системы с неадекватными или несуществующими требованиями. Это усложняет тестирование, но не следует опускать руки и заявлять, что вы ничего не можете сделать.

При отсутствии требований тестировщикам по-прежнему нужен какой-то «оракул», возможно, пользователи, которые знакомы с тем, как работает система, старая система, руководства пользователя или собственное представление тестировщика. Что произойдет в том случае, если оракулом тестирования будет сам тестировщик? Вместо того чтобы просто сравнить работу системы с ее документальным описанием, тестировщики определяют, насколько данная система соответствует их личному представлению о том, что она должна делать. (По существу, тестировщики всегда должны действовать именно так).

Кое-кто считает, что без спецификации вы не тестируете, а просто изучаете систему. Эта методика формализуется в рамках подхода, называемого исследовательским тестированием, применяемым в ситуациях с неадекватными требованиями или с жесткими временными ограничениями [4].

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

Надеюсь, мне удалось убедить вас в том, что тестировщики способны оказать большую помощь в подготовке качественных требований к системе. Теперь о том, как этого добиться на практике:

• привлекайте тестеров к анализу и проверке требований;
• начинайте планировать тестирование параллельно с анализом требований;
• потребуйте привести примеры тестовых условий и тестовых случаев в спецификации с описанием требований;
• включите в документ с описанием требований все конкретные случаи, которые пришли в голову при анализе требований;
• используйте случаи из работы компании с тем, чтобы привести конкретные примеры того, как должна работать система;
• определите измеряемые критерии как для функциональных, так и нефункциональных требований.

Тестирование — это увлекательная интеллектуальная деятельность, но она всегда весьма трудоемка, вне зависимости от того, на чем основаны тесты. Поддерживайте взаимосвязь между требованиями и тестированием. Если вы примите и поддержите предложения тестеров по поводу ваших требований, вам удастся избежать перечисленных заблуждений и, в конечном итоге, вы получите более качественные требования и тесты.

Dorothy Graham, Requirements and Testing: Seven Missing-Link Myths. IEEE Software, September/October 2002. All rights reserved, 2002. IEEE Computer Society. Translated adn reprinted with permission.

Литература

Дороти Грэхем (dorothy@grove.co.uk) — основатель компании Grove Consultants, предлагающую консалтинг, обучение и иные услуги, связанные с различными аспектами тестирования программного обеспечения.