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.
Upcoming SlideShare
Организация времени в тестировании
Next
Download to read offline and view in fullscreen.

Share

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

Download to read offline

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

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

  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
  • MopMex

    Oct. 31, 2017
  • IrkComp

    May. 10, 2015

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

Views

Total views

8,032

On Slideshare

0

From embeds

0

Number of embeds

4,855

Actions

Downloads

231

Shares

0

Comments

0

Likes

2

×