Доклад Александра Александрова на SQA Days-15. 18-19 апреля, 2014, Москва. www.sqadays.com

1. Тест-дизайн
Luxoft (www.luxoft.com)
21.04.14
Александр Александров
Проще читать или проще писать

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
 Можно еще поискать в книгах, Интернете…
 Адекватен ли контент формату?

15. 15
Где данные?

16. 16
Тестирование, управляемое данными
 Отделение шагов от данных
 Раздельное описание со ссылками
 Связь данных и ожидаемых результатов
 Шаги
 Действия для выполнения тест-кейса
 Правила навигации
 Данные
 То, что пользователь вводит и/или выбирает и/или
нажимает (поле, список, …)
 Ожидаемые результаты
 Расширение за счет данных делается несложно

17. 17
Структура тест-кейса (уточнение)
 Меняем формат:
 Порядковый номер шага
 Воздействие на систему
 Ссылка на данные (если необходимо)
 Ожидаемый результат (возможно, ссылка на данные и/или
иллюстрация)

18. 18
А если данных много?
И как описать результаты?

19. 19
Структура тест-кейса (еще уточнение)
 Избавляемся от:
 Циклов типа «Повторить шаги 5-73 для всех возможных
данных»
 Конструкций типа «любой», «соответствующий».
«подходящий», «ожидаемый» без необходимых уточнений,
например:
 А что же еще остается?

20. 20
Проверки – шаг или результат?

21. 21
Зачем UI зависеть от данных?

22. 22
Что предлагается
 Формат:
 Порядковый номер шага – это понятно
 Воздействие на систему – только действия
 Ссылка на данные – только данные и/или ссылки
 Ожидаемый результат - здесь все, что надо проверить и
указание, как проверять. Могут быть данные и/или ссылки.
Важна однозначность!
 Контент:
 Нет явных циклов - вместо этого наборы данных
 Нет общих слов типа «любой, ожидаемый,
соответствующий» - вместо этого данные и/или ссылки

23. 23
Что предлагается
 Данные:
 Роли, значения
 Ссылки на хранилище данных (запросы)
 Подготовка данных
 Предусловия (состояние базы данных)
 Выполнение SQL запросов
 Действия в формате тест-кейсов

24. 24
Зачем предлагается
 Разумный компромисс сложности шагов и наборов
данных
 Иногда стоит написать два-три похожих тест-кейса, сократив
на порядок объем наборов данных (за счет повторов)
 Зачем все это:
 Тестировщику трудно не сбиться и пропустить что-то
 Разработчику трудно строить отображение кода
скриптов на описание тест-кейса (необходимо при
анализе и сопровождении скриптов)

25. 25
Благодарности

26. Your
QR Code
Спасибо за внимание!
Вопросы?
Александр Александров
21.04.14
Luxoft (www.luxoft.com)
AAlexandrov@luxoft.com