2. 2
1963-1999 – Вычислительный центр Московского
Государственного университета им. М.В. Ломоносова
(студент, сотрудник)
1999-2005 – Luxoft (руководитель группы тестирования,
тест-менеджер)
2006-2007 – Auriga (директор по качеству)
С 2008 – Luxoft (эксперт по управлению качеством ПО)
C 2011 – Luxoft (тест-менеджер, менеджер проектов)
Кандидат физико-математических наук, доцент, старший
научный сотрудник
Сертифицированный инструктор университета Carnegie
Mellon по тематике Quality Assurance
Член коллегии RSTQB
Немного о себе
3. 3
Более 40 лет работы в области тестирования и обеспечения
качества (МГУ, Luxoft, Auriga)
Более 10 лет работы в области управления качеством (Luxoft,
Auriga)
Опыт cертификации ISO 9001 (Luxoft), CMM, CMMI (Luxoft,
Auriga)
Опыт внедрения процессов в рамках модели CMMI (Luxoft,
Auriga)
Сертификат обучения Project Management от Project
Management Institute (2000)
Сертификат обучения Introduction to Capability Maturity
Model Integration v. 1.2 от ProceXpert (2007)
Опыт работы
4. 4
Зачем все это
Тест-дизайн
Как проверять тестируемость требований
Требования и тестирование без тест-кейсов и/или без
тестировщиков
Требования и изменения
Проще читать или проще писать
Как устроены тест-кейсы
Какие возникают трудности
Как их преодолевать
Содержание
5. 5
Возрастающий интерес к автоматизации тестирования
Необходимость «фундамента» для разработки
автоматизированных тестовых скриптов
Сложность создания, использования и сопровождения
скриптов при отсутствии такого «фундамента»
Важность всего перечисленного вне контекста
автоматизации тестирования
Упрощение и ускорение работы и повышение надежности
результатов работы:
Тестировщика
Разработчика автоматизированных тестовых скриптов
Тест-менеджера, анализирующего результаты
тестирования (ручного / автоматизированного)
Зачем все это
6. 6
Как проверять тестируемость
требований
Мантры требований:
Полнота
Непротиворечивость
Однозначность
Трассируемость
Осуществимость
Тестируемость
…
Как все это надежно проверить?
7. 7
Раннее проектирование тест-кейсов
Визуализация связи тест-кейсов и требований (где и как
проверяется эта фича)
Как проверять тестируемость
требований
8. 8
Тестирование и требования
Требования vs. тестирование
Требования: определить, что и как должно работать
Тестирование: определить, что не работает или
работает не так, как должно работать
Соответствие программного продукта предъявляемым
требованиям
Все ли требования реализованы
Все ли требования реализованы правильно
Нет ли лишнего
Адекватная ли диагностика
9. 9
Требования и тестирование без тест-
кейсов и/или без тестировщиков
Нет ни тест-кейсов, ни тестировщиков
Тестирование разработчиками – хорошо известны
проблемы
Тестирование аналитиками – не нужны тест-кейсы?
Качество и объем тестирования
Ошибки в требованиях не обнаруживаются
10. 10
Требования и изменения
Обязательность изменений
«Неожиданность» изменений
Способы фиксации изменений
Матрица связи требований и тест-кейсов (оценка
трудозатрат на реализацию и тестирование изменений)
Влияние изменений на приложение в целом
11. 11
Тестирование, управляемое данными
Выводятся ожидаемые результаты в ответ на правильно
вводимые данные
Адекватная реакция на некорректные данные, в том числе и
не зафиксированные в требованиях (соответствующие
сообщения об ошибках)
А также:
Классы эквивалентности
Граничные значения
12. 12
Гранулярность требований
Много деталей
Просто использовать
Сложно поддерживать
Мало деталей
Сложно использовать
Просто поддерживать
Разумный компромисс (всегда риски)
Чек-листы
Тестирование по требованиям
Риски такого компромисса хорошо известны
13. 13
Что пишут про структуру тест-кейса
Тест-кейс включает:
Формат
Контент
Формат везде одинаков:
Порядковый номер шага
Воздействие на систему
Ожидаемый результат
Помним - дьявол кроется в деталях
14. 14
Анализ и сравнение форматов
Содержательно одинаковые:
Luxoft
RUP
Macroscope
Можно еще поискать в книгах, Интернете…
Адекватен ли контент формату?
16. 16
Тестирование, управляемое данными
Отделение шагов от данных
Раздельное описание со ссылками
Связь данных и ожидаемых результатов
Шаги
Действия для выполнения тест-кейса
Правила навигации
Данные
То, что пользователь вводит и/или выбирает и/или
нажимает (поле, список, …)
Ожидаемые результаты
Расширение за счет данных делается несложно
17. 17
Структура тест-кейса (уточнение)
Меняем формат:
Порядковый номер шага
Воздействие на систему
Ссылка на данные (если необходимо)
Ожидаемый результат (возможно, ссылка на данные и/или
иллюстрация)
19. 19
Структура тест-кейса (еще уточнение)
Избавляемся от:
Циклов типа «Повторить шаги 5-73 для всех возможных
данных»
Конструкций типа «любой», «соответствующий».
«подходящий», «ожидаемый» без необходимых уточнений,
например:
А что же еще остается?
22. 22
Что предлагается
Формат:
Порядковый номер шага – это понятно
Воздействие на систему – только действия
Ссылка на данные – только данные и/или ссылки
Ожидаемый результат - здесь все, что надо проверить и
указание, как проверять. Могут быть данные и/или ссылки.
Важна однозначность!
Контент:
Нет явных циклов - вместо этого наборы данных
Нет общих слов типа «любой, ожидаемый,
соответствующий» - вместо этого данные и/или ссылки
23. 23
Что предлагается
Данные:
Роли, значения
Ссылки на хранилище данных (запросы)
Подготовка данных
Предусловия (состояние базы данных)
Выполнение SQL запросов
Действия в формате тест-кейсов
24. 24
Зачем предлагается
Разумный компромисс сложности шагов и наборов
данных
Иногда стоит написать два-три похожих тест-кейса, сократив
на порядок объем наборов данных (за счет повторов)
Зачем все это:
Тестировщику трудно не сбиться и пропустить что-то
Разработчику трудно строить отображение кода
скриптов на описание тест-кейса (необходимо при
анализе и сопровождении скриптов)