lesson 148 Часть первая

Как считаете, из примерно 25 человек сколько откликнутся на призыв:

Кто хочет потратить уйму свободного времени и энтузиазма на самообучение, слишком похожее на неоплачиваемый рабочий день?


Слово Канеру

Чтоб проанализировать требования к документации тестирования, задайте вопросы из этого списка.

Мы рекомендуем Gause и Weinberg (1989) для введения в анализ требований и в качестве великолепного списка свободных от контекста вопросов, являющихся полезными для анализа любых требований. Michalko (1991, 138) предоставил дополнительный набор независимых от контекста вопросов (вопросы CIA Phoenix). В добавление к этому мы собрали ряд вопросов, выявляющих более конкретные требования к документации тестирования.

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

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

Качество продукта регулируется юридически или рынком? Если ваше ПО предмет проверок и аудитов, то вы, вероятно, следуете формальным стандартам наподобие IEEE 829. Аналогично, если ваш продукт может нанести вред людям или уничтожить имущество и документация может играть роль доказательства в суде. Стандарт 829 и оформление документов в стиле 829 стандарта в таком случае является хорошим выбором. Отличная документация тестирования может помочь или не помочь улучшить качество программного обеспечения, но она наверняка поможет компании защитить себя позже. С другой стороны, если следствием низкого качества стало падение продаж, а не судебные иски, ваши клиенты никогда не потребуют документацию тестирования.

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

Насколько быстра меняется спецификация после изменения в архитектуре? You cannot do specification-driven testing if the specification is chronically incomplete and out of date, nor would you want to tie your test documentation to the contents of such a specification. Примечание: не пытайтесь вилять собакой. Если проект был запущен без актуальных спецификаций, проект может в них и не нуждаться. Неудобство группы тестирования не является весомым аргументом для изменения политики ведения спецификаций. Если у вас их нет, запланируйте адаптацию стратегии тестирования, а не изменение политики проекта. Если вы планируете бороться за качественные спецификации, делайте это на основе расходов и рисков других заинтересованных сторон, особенно тех, кто имеет более заметное влияние на прибыли и убытки компании.

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

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

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

Should the documentation ever control the testing project? Do you want testers to look in the documentation for operations information (such as scheduling info that lays out what to do next)?

lesson 148 Часть 2

Слово Канеру



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

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

Какие документы (требования или сппецификации) вы отслеживаете и кто это контролирует?


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

Насколько хорошо должна документация поддерживать передачу работы новым тестировщикам? Чтоб эффективно делегировать работу, вы должны достаточно подробно объяснить, что нужно делать. Эффективное делегирование не обязательно подразумевает пошаговые инструкции. Мы предпочитаем обучать новых тестировщиков ряду навыков, дать им несколько вступительных задач, ознакомить с документацией (например с руководством пользователя), а затем давать им инструкции, предполагающие, что они уже имеют нужные навыки и справочные материалы. Вместо того, чтоб замедлиться (и усложнить документацию) ради тестировщиков, которые не могут развить свои навыки, мы заменяем их на тех, кто может. Если вы считаете, что детальные инструкции необходимы, то мы предупреждаем вас, что их создание требует много времени и навыков, для того чтоб сделать их эффективными. По этим вопросам читайте Wurman (1991). Другим аспектом делегирования является ваша способность определить что именно должно быть сделано и насколько качественно оно сделано. Если у вас есть кто-то для работы над коротким документом (например одна из матриц из приложения к главе 3, методы тестирования), то вы оцените результат верно с большей вероятностью, чем если бы у вас были несколько десятков или сотен страниц сценариев тестирования.

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


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

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

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

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

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