К основному контенту

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

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

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


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


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

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

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

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

Комментарии

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

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

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

Отправка комментария

Популярные сообщения из этого блога

Mock vs Stub

Когда мы начали изучать модульное тестирование, то одними из первых терминов, с которыми пришлось познакомиться, стали Mock и Stub.

Ниже попробуем порассуждать в чем их сходство и различие, как и для чего они применяются.

Проверять работоспособность тестируемого объекта (system uder test - SUT) можно двумя способами: оценивая состояние объекта или его поведение.

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

Во-втором, мы проверяем набор и порядок действий (вызовов методов взаимодействующих объектов, других методов SUT), которое должен совершить метод SUT.

Собственно, если коротко, то в одном случае используется Stub, а в другом Mock. Это объекты, которые создаются и используются взамен реальных объектов, с которым взаимодействует SUT в процессе своей работы.

Теперь подробнее.

Gerard Meszaros использует термин Test Double (дублер), как обозначение для объекта, который зам…

План "Б" или как прикольно провести субботний день

Всем привет.
Вчера состоялась конференция "План Б". Организаторами выступили ребята из Яндекса, за что им большое спасибо. Судя по приблизительным подсчетам в мероприятии участвовало около 200 человек.

Основной темой конференции было планирование, планирование всего: проектов, разработки, тестирования, дизайнеров и даже организации музыкального фестиваля.
Сначала думал написать отчет в обычном своем стиле: кто и что говорил, но почитав твиттер по #pbconf понял, что просто потеряю время :) Поэтому кому оооочень интересно узнать подробности следуйте за птичкой и вы все узнаете (тэг #pbconf попал в top-30 твиттера)
Здесь приведу лишь те вещи, которые мне запали в мозг
Роман Чернин о продуктовой разработке: "нет заказчика, нет требований, нет сроков -> как принимать решения? ответ: заводим себе Product Manager-а"
Оля Павлова (@op): "бойтесь иллюзии точной формулировки" "заказчик - ребенок, выдаем ему игрушку как можно чаще" "не забываем, …

Полезные ресурсы для молодых (и не только) тестировщиков

Уже 3 месяца провожу собеседования тестировщиков.
Поначалу они просто  веселили - после 15-летнего опыта собеседования С++-разработчиков, общение с тестировщиками (чаще были "-цы") было чем то экзотическим и забавным.

Потом становилось все грустнее и грустнее, мимими закончилось. Началась печаль.