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

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

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

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


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


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

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

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

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

Комментарии

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

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

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

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

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

Mock vs Stub

Когда мы начали изучать модульное тестирование, то одними из первых терминов, с которыми пришлось познакомиться, стали Mock и Stub. Ниже попробуем порассуждать в чем их сходство и различие, как и для чего они применяются. Проверять работоспособность тестируемого объекта (system under test - SUT) можно двумя способами: оценивая состояние объекта или его поведение. В первом случае проверка правильности работы метода SUT заключается в оценке состояния самого SUT, а также взаимодействующих объектов, после вызова этого метода. Во-втором, мы проверяем набор и порядок действий (вызовов методов взаимодействующих объектов, других методов SUT), которое должен совершить метод SUT. Собственно, если коротко, то в одном случае используется Stub, а в другом Mock. Это объекты, которые создаются и используются взамен реальных объектов, с которым взаимодействует SUT в процессе своей работы. Теперь подробнее. Gerard Meszaros использует термин Test Double (дублер), как обозначение для объе

Заметки на коленке - 3. Что еще делать, если ваши тесты уже "зеленые"?

"Lately I find I'm working on automated tests that return non-binary results. Tests that neither pass nor fail" by  @noahsussman Отличная мысль, которую я ретвитил еще в 2016. Но давайте вместе подумаем, что за этим может скрываться? ( кстати, не знаю, что при этом думал Noah ) Ваши тесты прошли и прошли "успешно". Все хорошо или все же есть, куда еще посмотреть? Дальше то, что использовал я лично и то, что еще можно прикрутить дополнительно. Естественно все шаги ниже должны быть автоматизированны. 1. Контролируйте время выполнения тестов. Если набор проверок не меняется (а такое часто бывает, к сожалению), то рост времени выполнения может говорить о проблемах в продакшен коде (чаще всего) или проблемах с окружением. 2. Контроль за количеством выполняемых тестов. "Все зеленое" не значит, что сегодня выполняли те же Х тестов, что и вчера. Смешно(нет), но случается такое, что какие-то проверки "исчезают" из запуска из-за того, что у кого-то &qu

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

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