Здравствуйте,

Уважаемые коллеги!

Меня зовут Ксения.

Я работаю в компании уже пять с лишним лет. Мой путь в тестировании начался здесь
же в качестве тестировщика на проекте ДБО.
Затем я была лидом группы тестирования на проекте Retail, а также
непродолжительное время на проектах СН и Fraud-Анализ. Сейчас я работаю
тестировщиком на проекте Corporate в группе у Наталии.
Т.о. я участвовала в тестировании практически всех коробочных продуктов компании в
разных ролях.

За время своей работы я не раз сталкивалась с ситуациями, при которых качество

тест-дизайна требовало более тщательной проработки. Причинам подобных ситуаций
и посвящен мой доклад, который называется Тест-дизайн и анализ.

В своем докладе я хотела бы поговорить о следующих вещах:

1. Понятие тест- дизайна
2. Активности тест-дизайна
3. Роль тест-аналитика в проектной команде

Возможно, мои определения не будут в чем-то совпадать с общепринятыми. Теми, что

вы читали в литературе и слышали от гуру тестирования, но возьму на себя смелость
дать определения, которые близки мне.

Итак.
1. Тест-дизайн - это этап процесса тестирования разрабатываемой системы,
результатом которого являются тестовые случаи или тест-кейсы.

2. Под тест-дизайном также подразумевается последовательное выполнение

следующих видов работ:
Предварительный анализ, разработка тестовой модели и написание тест кейсов
1. Предварительный Анализ включает в себя анализ требований, достаточности и
полноты их описания, в том числе и ревью,формирование общего
представления о тестируемой функциональности.
Какие ошибки мы обычно допускаем и какие проблемы вне нашей компетенции могут
возникнуть на этом этапе? Например,
● Мы не задаем системным и бизнес-аналитикам часть возникших вопросов,
которые все равно всплывают позднее. Это может создать ситуацию, когда под
конец тестирования функциональности появляется вопрос-уточнение, по
которому нужно изменить всю логику и соответственно провести тестирование
всей функциональности заново.
● Для больших доработок некоторые вопросы могут быть не очевидны и в связи с
этим упущены, что так же влечет за собой риск срыва сроков.
Что может помочь избежать таких ситуаций?
● Как только возник вопрос - его нужно зафиксировать. Но чтобы не создавать
консультацию или не писать на каждое уточнение письмо, можно завести
текстовый файл, в котором будут зафиксированы все вопросы по функционалу
и прояснять эти вопросы, например, блоками. Всегда необходимо использовать
 оптимальное средство коммуникации, часто вместо длительной переписки
лучше создать встречу.
● Для объемного функционала можно прибегнуть к mind-картам
, которые дают наглядность, упрощают восприятие требований и помогают
увидеть узкие места.

2. По результатам анализа уже можно приступать к созданию тестовой модели.

Тестовая модель - это совокупность всех тестовых случаев, которые мы предполагаем
воспроизвести при тестировании функционала, но на этапе создания тестовой модели
пока без описания шагов воспроизведения.
Тестовая модель имеет такой критерий, как полнота покрытия. И это на мой взгляд
самый сложный аспект тестирования. У нас есть требования, и мы пишем на них
позитивные и негативные тесты. А как быть c тестовыми случаями, требования к
которым явно не описаны в ТЗ и мы не смогли их выявить на этапе предварительного
анализа?
Пробелы требований могут быть найдены и своевременно обработаны с применением
такого подхода, как согласование тестовой модели с другими участниками процесса.
Для эффективного тестирования работать в команде очень полезно.

3.Что такое написание тест-кейсов все мы знаем. Знаем, что тест-кейсы должны
быть написаны, зачастую, подробно и всегда понятно любому участнику процесса. На
основе проваленного ТК мы заводим дефекты и по нашему описанию ситуацию
должны понять и воспроизвести аналитики и разработчики. И об этом всегда нужно
помнить.

На следующем слайде я хочу показать насколько выгоднее проводить более

детальный и тщательный анализ на ранних этапах разработки функционала.
Расчеты приведены приближенные, но, думаю, что с масштабом многие согласятся.
Представим ситуацию, что в ТЗ не учтено некое требование.
На этапе предварительного анализа мы заметили этот пробел и с участием
аналитиков и, возможно, системного архитектора дописали требование и разработчик
получил ТЗ с описанным поведением. Потратили на это 4 часа в сумме.
Если не проводить глубокий анализ и писать кейсы основываясь только на текущей
версии требований с минимальными уточнениями, то на вышеозвученный баг уйдет
уже около 8 часов, а скорее всего значительно больше. Дальше, если данная ситуация
проявится на релизной сборке, то нам придется, как минимум провести смоук после
исправления, что в моем примере увеличит время до 23 часов. Для системы
находящейся в эксплуатации добавится еще время затраченное поддержкой и в
сумме будет уже 27 часов, что почти в 7 раз больше, чем при проведенном тест-
анализе.

Стоит подчеркнуть, что квалификация и опыт специалистов, задействованных при

анализе и разработке тестовой модели, должны быть выше, чем у специалистов,
которые прописывают шаги тест-кейсов и выполняют их, так как именно от качества
анализа и разработанной тестовой модели зависит полнота покрытия, а значит и
количество пропущенных дефектов, поэтому роль тест аналитика так важна для
проекта.
Функции тест-аналитика могут меняться в зависимости от того, что нужно на проекте,
например они могут быть такими:

•Анализ требований
•Разработка тестовой модели
•Согласование тестовой модели
•Оценка полноты покрытия
•Приоритезация тест-кейсов
•Актуализация и поддержка
•Ревью тест-кейсов
•Обучение тестировщиков
•Оценка, анализ и оптимизация трудозатрат на прохождение тест-кейсов

В зависимости от объемов доработок тест-аналитиков может быть несколько. Эта

роль может быть переходящей, чтобы не было отрыва от системы. Эта роль может
быть совмещена с любой другой.

Главное, что все мы должны понимать, что без качественного тест-дизайна со всеми
его составляющими - не может быть Качественного тестирования и комфортного всем
участникам процесса.

Спасибо!

Например, для функционала Fraud-анализа Зеленый коридор заведен справочник

масок счетов, а поведение системы, если платежное поручение не имеет счета - не
описано. И о том, что возможно создать платежное поручение без счета знают не все,
потому что это не тривиальный кейс.