Session-Based Testing Теория и практика

Сначала тестирование было таким…

Потом стало таким…

Но ничего не менялось

Проблемы хаотического тестирования Проблемы скриптового тестирования Непонятен статус продукта, невозможно оценить и измерить качество Невозможно планирование тестирования В зависимости от квалификации – непредсказуемые результаты работы Нет передачи знаний будущим поколениям Куча времени уходит на документирование тестов Тесты проходить скучно, развития нет, бюрократия демотивирует Внимание рассеивается при однотипной работе, очевидные вещи пропускаются «Эффект пестицида» – тесты перестают находить баги Что делать?

В ноябре 2000 Дж. Бах и Дж. Бах предложили решение

Это должно работать во-о-о-от так! Charter (цель тестирования) Session (период времени на тестирование) Session Report (заметки, баги, проблемы, вопросы, статистика по затраченному времени и т.д.) Debrief (обсуждение результатов сессии)

Гибкость Отчётность Статистику Передачу знаний Обучение, коучинг Фокус на результате Бюрократию Итого, мы получили:

Гибкость Отчётность Статистику Передачу знаний Обучение, коучинг Фокус на результате -Бюрократию + Планируемость + Творчество А что хочется:

Мой алгоритм 1.Составляем список сессий 2.Определяем длительность и процесс 3.Перемножаем + 30% 4.Идём от большего к меньшему

Список сессий 1.Таблица 2.Майнд-карта – На сетевом ресурсе – На листе ватмана 3.Блокнот 4.… Детализация определяется планами

Формат сессии 1.Длительность 2.Когда заводить баги? 3.Где хранить результаты? 4.Как определять задачи? Мой вариант – 2 часа.

Тестирование От большего к меньшему!

Специи SBTM Регулярность планирования Наглядные результаты Творческая обстановка Приоритезация на лету