вторник, 28 февраля 2012 г.

План тестирования - когда, кто и зачем?

И снова о тестировании. И снова теория в виде перевода.
На этот раз "Thoughts on Testing - Breaking Down the Test Plan".

Вопрос 1: Кто и когда им пользуется


Этапы проекта
Кто использует
Для чего
Этап дизайна
Разработчики
Менеджеры продукта
Тестировщики
Менеджеры тестировщиков
Тестируемость функционала
Прототип функционала
Соотношение  и объем ручного и автоматического тестирования
Влияние на другие функции
Сколько времени займет тестирование
Стратегия тестирование (зачем нужно)
Этап реализации
Разработчики
Менеджеры продукта
Менеджеры тестировщиков
Внешние тестировщики
Эксперты безопасности
Объем покрытия тестами
Список одобренного функционала
Сценарии безопасности
Стратегия тестирование (зачем нужно)
Этап стабилизации
Менеджеры тестировщиков Менеджеры продукта
Тестировщики
Внешние тестировщики
Служба поддержки
Объем покрытия тестами
Список одобренного функционала
Стратегия тестирование (зачем нужно) 
Пострелизная активность
Служба поддержки
Эксперты безопасности
Тестировщики
Объем покрытия тестами
Стратегия тестирование (зачем нужно)
Сценарии безопасности
Список одобренного функционала


Вопрос 2: Для чего план тестирования используется.
Не всегда ясно для чего используется план тестирования, после того как он написан. Часто это просто список задач и сроков, список тестов, которые должны быть автоматизированы  или проведены, возможно, какие-то метрики по производительности или еще что-то. И обычно это больше не пересматривается до тех пор, пока что-то не случится.
План тестирования – это то, что нужно постоянно пересматривать, то на что нужно постоянно ссылаться. Это должно быть целью любой команды тестирования.  Иначе упражнение по написанию плана тестирования сводится просто к описанию действий по проверке функционала, а также к уточнению особенностей реализации.

Кто использует
Для чего
Тестировщик
Этап дизайна
Тестируемость функционала
Объем ручного и автоматического тестирования
Стратегия тестирования (зачем нужно)
Этап реализации
Объем покрытия тестами
Объекты для проверки
Тестовые сценарии
Сценарии проверки безопасности
Этап стабилизации
Объем покрытия тестами
Тестовые сценарии
Список одобренного функционала
Менеджер тестировщиков

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

Итак, как же должен выглядеть план тестирования:
  • Тесты
    • Тестовые сценарии
      • Ручные
      • Автоматические
      • Специфические (например на безопасности)
    • Объем покрытия тестами
      • Кода
      • Сценариев использования
    • Список реализуемого функционала
      • Все что обсуждалось с менеджером продукта
    • Общие вопросы стратегии тестирования
  • Спецификации
    • Функционал
    • Приоритизированные сценарии
  • Должен быть легко изменяем
  • Соответствовать текущему состоянию продукта
PS Бюрократизировано выглядит, но выкинуть действительно ничего не получается. Все по делу. 

2 комментария:

  1. Когда я вижу подобные документы, у меня закрадывается подозрение что их пишут вовсе не для того, чтобы они помогали, а лишь для того, чтобы когда все облажаются можно было достать эту бумажку и тыкать всех носом. Мое мнение, что за качество продукта должна отвечать команда и никто кроме нее. Если у команды не хватает ума и сил чтобы писать тесты и они содержат людей-роботов (aka тестеров), которые не в силах проверить продукт за разумный срок, то это не что иное как проблема команды.

    ОтветитьУдалить
  2. А что толку тыкать, если уже облажались. Вообще действительно выглядит старомодно, но еще много где используется. И фиг знает, хорошо это или плохо. Пока нет представления нужно это и работает ли, когда у команды все типа и так круто, есть тесты на все юзер-истории и тд и тп. На моей практике такие планы чаще составлялись для того, чтобы оценить срок тестирования. И выглядели не как планы, а прост набор шагов со сроками. То есть процентов 30% от того, что написано выше.

    ОтветитьУдалить