И снова о тестировании. И снова теория в виде перевода.
На этот раз "Thoughts on Testing - Breaking Down the Test Plan".
Вопрос 1: Кто и когда им пользуется
Вопрос 2: Для чего план тестирования используется. Не всегда ясно для чего используется план тестирования, после того как он написан. Часто это просто список задач и сроков, список тестов, которые должны быть автоматизированы или проведены, возможно, какие-то метрики по производительности или еще что-то. И обычно это больше не пересматривается до тех пор, пока что-то не случится.
На этот раз "Thoughts on Testing - Breaking Down the Test Plan".
Вопрос 1: Кто и когда им пользуется
| Этапы проекта | Кто использует | Для чего |
| Этап дизайна | Разработчики Менеджеры продукта Тестировщики Менеджеры тестировщиков | Тестируемость функционала Прототип функционала Соотношение и объем ручного и автоматического тестирования Влияние на другие функции Сколько времени займет тестирование Стратегия тестирование (зачем нужно) |
| Этап реализации | Разработчики Менеджеры продукта Менеджеры тестировщиков Внешние тестировщики Эксперты безопасности | Объем покрытия тестами Список одобренного функционала Сценарии безопасности Стратегия тестирование (зачем нужно) |
| Этап стабилизации | Менеджеры тестировщиков Менеджеры продукта Тестировщики Внешние тестировщики Служба поддержки | Объем покрытия тестами Список одобренного функционала Стратегия тестирование (зачем нужно) |
| Пострелизная активность | Служба поддержки Эксперты безопасности Тестировщики | Объем покрытия тестами Стратегия тестирование (зачем нужно) Сценарии безопасности Список одобренного функционала |
План тестирования – это то, что нужно постоянно пересматривать, то на что нужно постоянно ссылаться. Это должно быть целью любой команды тестирования. Иначе упражнение по написанию плана тестирования сводится просто к описанию действий по проверке функционала, а также к уточнению особенностей реализации.
| Кто использует | Для чего |
| Тестировщик | Этап дизайна Тестируемость функционала Объем ручного и автоматического тестирования Стратегия тестирования (зачем нужно) Этап реализации Объем покрытия тестами Объекты для проверки Тестовые сценарии Сценарии проверки безопасности Этап стабилизации Объем покрытия тестами Тестовые сценарии Список одобренного функционала |
| Менеджер тестировщиков | Этап дизайна Сколько времени это займет Стратегия тестирования (зачем нужно) Объем покрытия тестами Этап реализации Объем покрытия тестами Объекты тестирования Тестовые сценарии Этап стабилизации Объем покрытия тестами Список одобренного функционала |
| Служба поддержки Эксперты безопасности | Этап стабилизации Стратегия тестирования Тестовые сценарии Объем покрытия тестами Список одобренного функционала |
Вопрос 3: Поддерживаем актуальность плана тестирования
При любых изменениях в требованиях или реализации план тестирования должен быть скорректирован. Иначе на этапе стабилизации или пострелизной активности, устаревший план не сможет вам помочь.
Итак, как же должен выглядеть план тестирования:
- Тесты
- Тестовые сценарии
- Ручные
- Автоматические
- Специфические (например на безопасности)
- Объем покрытия тестами
- Кода
- Сценариев использования
- Список реализуемого функционала
- Все что обсуждалось с менеджером продукта
- Общие вопросы стратегии тестирования
- Спецификации
- Функционал
- Приоритизированные сценарии
- Должен быть легко изменяем
- Соответствовать текущему состоянию продукта
PS Бюрократизировано выглядит, но выкинуть действительно ничего не получается. Все по делу.
Когда я вижу подобные документы, у меня закрадывается подозрение что их пишут вовсе не для того, чтобы они помогали, а лишь для того, чтобы когда все облажаются можно было достать эту бумажку и тыкать всех носом. Мое мнение, что за качество продукта должна отвечать команда и никто кроме нее. Если у команды не хватает ума и сил чтобы писать тесты и они содержат людей-роботов (aka тестеров), которые не в силах проверить продукт за разумный срок, то это не что иное как проблема команды.
ОтветитьУдалитьА что толку тыкать, если уже облажались. Вообще действительно выглядит старомодно, но еще много где используется. И фиг знает, хорошо это или плохо. Пока нет представления нужно это и работает ли, когда у команды все типа и так круто, есть тесты на все юзер-истории и тд и тп. На моей практике такие планы чаще составлялись для того, чтобы оценить срок тестирования. И выглядели не как планы, а прост набор шагов со сроками. То есть процентов 30% от того, что написано выше.
ОтветитьУдалить