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