В реальной жизни тестировщики часто сталкиваются с ситуацией, когда требования к системе меняются постоянно, сроки разработки сжаты, а 100% покрытие недостижимо – не потому, что заказчик не знает, чего хочет, а потому что постоянно меняется среда, в которой работает система, и потому что опоздать – хуже, чем ошибиться. Здесь приходится говорить о достаточном уровне надежности, приоритетах и принятии определенной доли риска. Классическая литература такие ситуации часто обходит: считается, что четко определенный процесс тестирования в подобных условиях не существует. На самом деле процесс есть, он просто другой. Целью становится не полное покрытие и документальное подтверждение следования технологии, а постоянная оценка и пересмотр критических мест системы, поддержание целостной информации о ее состоянии, ее функциональности и дефектах. В докладе пойдет речь о возможной организации такого процесса при помощи GTD, управления конфигурациями и быстрой визуальной оценки состояния системы.

1.  Тестирование как средство противодействия  внешнему хаосу Никита Налютин

2. Как мы хотели бы тестировать ?

3. Как оно бывает на самом деле ? Менеджер проекта Аналитик Разработчик Дизайнер Тестировщик

5. Уровни критичности

9.  Зона внутреннего хаоса Сроки Релизы Требования Стандарты ??? Тесты Дефекты Код

13. Время

14.  Планирование времени

17. Информация о системе

18.  Управление конфигурациями Конфигурация документов Архитектура Руководство пользователя План проекта Система

19.  Управление конфигурациями

22.  Workflow все-таки есть

23. Отчеты о состоянии

24.  Вычисление состояния Объект конфигураци Объекты конфигурации Состояния объектов Состояние конфигурации Принятие решения Технологическое воздействие Изменение состояний Анализ состояния Вычисление статуса конфигурации

26. Календарь приоритетов   Задача 1 Задача 2 Задача 3 Задача 4 Задача 1 Задача 2 Задача 3 Задача !!! Задача ??? Пн Вт Ср Чт Пт Пн Вт Ср Чт Пт Приоритет Лесенка сверху вниз

27. Где критические места ? Пузыри должны всплывать, уменьшаясь в размерах по мере исправления дефектов

28. Сколько осталось Разработка Тестирование Задача 1 Задача 3 (исправление) Задача 5 Задача 2 Задача 3 Задача 4 (исправление) Задача 4 Задача 6 Считаем каждого или через одного

29. Трудозатраты Перекос на регрессию – надо автоматизировать

31.  Вопросы ? Никита Налютин [email_address] http://pine.moikrug.ru