Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Тест-дизайн: проще читать или проще писать

7,468 views

Published on

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

Published in: Education
  • Be the first to comment

Тест-дизайн: проще читать или проще писать

  1. 1. Тест-дизайн Luxoft (www.luxoft.com) 21.04.14 Александр Александров Проще читать или проще писать
  2. 2. 2  1963-1999 – Вычислительный центр Московского Государственного университета им. М.В. Ломоносова (студент, сотрудник)  1999-2005 – Luxoft (руководитель группы тестирования, тест-менеджер)  2006-2007 – Auriga (директор по качеству)  С 2008 – Luxoft (эксперт по управлению качеством ПО)  C 2011 – Luxoft (тест-менеджер, менеджер проектов)  Кандидат физико-математических наук, доцент, старший научный сотрудник  Сертифицированный инструктор университета Carnegie Mellon по тематике Quality Assurance  Член коллегии RSTQB Немного о себе
  3. 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. 4  Зачем все это  Тест-дизайн  Как проверять тестируемость требований  Требования и тестирование без тест-кейсов и/или без тестировщиков  Требования и изменения  Проще читать или проще писать  Как устроены тест-кейсы  Какие возникают трудности  Как их преодолевать Содержание
  5. 5. 5  Возрастающий интерес к автоматизации тестирования  Необходимость «фундамента» для разработки автоматизированных тестовых скриптов  Сложность создания, использования и сопровождения скриптов при отсутствии такого «фундамента»  Важность всего перечисленного вне контекста автоматизации тестирования  Упрощение и ускорение работы и повышение надежности результатов работы:  Тестировщика  Разработчика автоматизированных тестовых скриптов  Тест-менеджера, анализирующего результаты тестирования (ручного / автоматизированного) Зачем все это
  6. 6. 6 Как проверять тестируемость требований  Мантры требований:  Полнота  Непротиворечивость  Однозначность  Трассируемость  Осуществимость  Тестируемость  …  Как все это надежно проверить?
  7. 7. 7  Раннее проектирование тест-кейсов  Визуализация связи тест-кейсов и требований (где и как проверяется эта фича) Как проверять тестируемость требований
  8. 8. 8 Тестирование и требования  Требования vs. тестирование  Требования: определить, что и как должно работать  Тестирование: определить, что не работает или работает не так, как должно работать  Соответствие программного продукта предъявляемым требованиям  Все ли требования реализованы  Все ли требования реализованы правильно  Нет ли лишнего  Адекватная ли диагностика
  9. 9. 9 Требования и тестирование без тест- кейсов и/или без тестировщиков  Нет ни тест-кейсов, ни тестировщиков  Тестирование разработчиками – хорошо известны проблемы  Тестирование аналитиками – не нужны тест-кейсы?  Качество и объем тестирования  Ошибки в требованиях не обнаруживаются
  10. 10. 10 Требования и изменения  Обязательность изменений  «Неожиданность» изменений  Способы фиксации изменений  Матрица связи требований и тест-кейсов (оценка трудозатрат на реализацию и тестирование изменений)  Влияние изменений на приложение в целом
  11. 11. 11 Тестирование, управляемое данными  Выводятся ожидаемые результаты в ответ на правильно вводимые данные  Адекватная реакция на некорректные данные, в том числе и не зафиксированные в требованиях (соответствующие сообщения об ошибках)  А также:  Классы эквивалентности  Граничные значения
  12. 12. 12 Гранулярность требований  Много деталей  Просто использовать  Сложно поддерживать  Мало деталей  Сложно использовать  Просто поддерживать  Разумный компромисс (всегда риски)  Чек-листы  Тестирование по требованиям  Риски такого компромисса хорошо известны
  13. 13. 13 Что пишут про структуру тест-кейса  Тест-кейс включает:  Формат  Контент  Формат везде одинаков:  Порядковый номер шага  Воздействие на систему  Ожидаемый результат  Помним - дьявол кроется в деталях 
  14. 14. 14 Анализ и сравнение форматов  Содержательно одинаковые:  Luxoft  RUP  Macroscope  Можно еще поискать в книгах, Интернете…  Адекватен ли контент формату?
  15. 15. 15 Где данные?
  16. 16. 16 Тестирование, управляемое данными  Отделение шагов от данных  Раздельное описание со ссылками  Связь данных и ожидаемых результатов  Шаги  Действия для выполнения тест-кейса  Правила навигации  Данные  То, что пользователь вводит и/или выбирает и/или нажимает (поле, список, …)  Ожидаемые результаты  Расширение за счет данных делается несложно
  17. 17. 17 Структура тест-кейса (уточнение)  Меняем формат:  Порядковый номер шага  Воздействие на систему  Ссылка на данные (если необходимо)  Ожидаемый результат (возможно, ссылка на данные и/или иллюстрация)
  18. 18. 18 А если данных много? И как описать результаты?
  19. 19. 19 Структура тест-кейса (еще уточнение)  Избавляемся от:  Циклов типа «Повторить шаги 5-73 для всех возможных данных»  Конструкций типа «любой», «соответствующий». «подходящий», «ожидаемый» без необходимых уточнений, например:  А что же еще остается?
  20. 20. 20 Проверки – шаг или результат?
  21. 21. 21 Зачем UI зависеть от данных?
  22. 22. 22 Что предлагается  Формат:  Порядковый номер шага – это понятно  Воздействие на систему – только действия  Ссылка на данные – только данные и/или ссылки  Ожидаемый результат - здесь все, что надо проверить и указание, как проверять. Могут быть данные и/или ссылки. Важна однозначность!  Контент:  Нет явных циклов - вместо этого наборы данных  Нет общих слов типа «любой, ожидаемый, соответствующий» - вместо этого данные и/или ссылки
  23. 23. 23 Что предлагается  Данные:  Роли, значения  Ссылки на хранилище данных (запросы)  Подготовка данных  Предусловия (состояние базы данных)  Выполнение SQL запросов  Действия в формате тест-кейсов
  24. 24. 24 Зачем предлагается  Разумный компромисс сложности шагов и наборов данных  Иногда стоит написать два-три похожих тест-кейса, сократив на порядок объем наборов данных (за счет повторов)  Зачем все это:  Тестировщику трудно не сбиться и пропустить что-то  Разработчику трудно строить отображение кода скриптов на описание тест-кейса (необходимо при анализе и сопровождении скриптов)
  25. 25. 25 Благодарности
  26. 26. Your QR Code Спасибо за внимание! Вопросы? Александр Александров 21.04.14 Luxoft (www.luxoft.com) AAlexandrov@luxoft.com

×