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)?