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

• мнение, что тестирование должно начинаться после разработки
• низкая вовлеченность
• нехватка времени и людей.

Расскажу, какие подходы мы применяем, какую теорию изучаем и какими инструментами пользуемся, чтобы не допускать их возникновения.

Почему перевернули все с ног на голову: ранний подход тестирования

Традиционный подход подразумевает, что тестирование начинается после того, как программа уже готова и развернута на тестовый стенд. Конечно, проще открыть приложение, наткнуться на проблему и передать ее на исправление. Тем не менее этот метод устарел. Со временем мы пришли к подходу раннего тестирования, когда тестировщики работают только с требованиями заказчика ПО еще до того, как программа написана.

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

Команде тестирования выгоднее работать именно с требованиями, а не с готовым продуктом, поэтому мы исключили разработчиков из цикла тестирования (см. рисунок выше). Однако, чтобы такая модель работала успешно, тестировщику необходимо активно взаимодействовать со всеми членами команды и в особенности с бизнес-аналитиками. В следующем пункте расскажу, как удалось реализовать это условие в Softline Development.

Тестирование – это люди. Что с ними делать, чтобы хорошо работали

Проблема мотивации

Самый опасный тип невовлеченных сотрудников в среде тестирования – это те, которым всегда «все понятно». Маркеры, по которым их можно опознать:

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

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

Вовлечение можно реализовать в несколько этапов:

1. Мотивацию нужно начинать в первую очередь с анализа желаний, стремлений и ориентиров сотрудников.
2. Затем каждому необходимо дать представление о возможностях, с помощью которых они могут реализовать свои цели. Если это повышение зарплаты, то предложить дорожную карту, по которой сотрудник будет видеть, какие конкретные шаги предпринимать. Если это, например, отпуск в пиковый период нагрузки, отпустить сотрудника при условии выполнения определенных показателей.
3. Далее обязательным этапом вовлечения служит общение с командой. Мы доносим до сотрудника, что необходимо участвовать в обсуждениях, задавать вопросы, формулировать все, что не понятно. На протяжении проекта у разработчика, аналитика и тестировщика могут быть вопросы друг к другу, поэтому необходимо взаимодействовать, чтобы лучше понимать работу системы и в будущем предупреждать дефекты еще на этапе планирования.
4. Если сотрудник, который раньше был сам по себе, достигает результатов на любом этапе мотивации, мы обязательно хвалим и благодарим его. Как правило, после всех этих этапов он видит, что становится продуктивным и ощущает, что его усилия ценятся среди коллег.

Проблема нехватки времени и персонала

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

1. Планирование активности

Задача:

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

Нельзя за 5 минут решить, кто будет работать с требованиями. Команда тестирования или тест-лид должны заранее обсудить весь скоп задач по разработке и равномерно распределить их между исполнителями, исходя из загруженности. Мы просчитываем нагрузку так, чтобы к моменту, когда сотрудник приступит к новой сложной задаче, на нем не висела еще одна такая же, а оставалась только текучка или что-то не очень сложное. Это необходимо, чтобы специалист мог сразу включиться в важную работу и полностью погрузиться в нее, вместо того чтобы утопать в нерешенных задачах и нарушать сроки из-за неадекватного распределения нагрузки.

Что получаем:

• работа с требованием заранее спланирована
• нет высокой нагрузки на исполнителе к моменту начала тестирования.

2. Знакомство с функциональностью

Задача:

• привлечь всю команду тестирования
• договориться с бизнес-аналитиком о проведении ликбеза по новой функциональности.

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

Что получаем:

• все знают о новой функциональности и об основных сценариях
• есть понимание в общих чертах о сложности фичи, объемах тестирования, возможных проблемах.

3. Самостоятельное изучение

Задача:

• подробно изучить требования
• сформулировать вопросы и обсудить с бизнес-аналитиком
• передать выявленные дефекты в аналитику
• проконтролировать исправления.

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

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

Что получаем:

• понимание достаточное для формирования тестовой модели
• способность объяснить другим, как и что должно работать
• снижение рисков дефектов в требованиях.

4. Разработка и отладка тестовой модели

Задача:

• разработать тестовую модель
• приоритизировать тесты
• выполнить ревью
• исправить замечания.

Что получаем:

• готовую тестовую модель
• оценку трудозатрат на тестирование готового функционала и понимание приоритетов.

Применяя данный алгоритм, мы снизили количество дефектов в требованиях, а каждая найденная ошибка экономила нам целый цикл работы над всем проектом.

Чек-листы по эвристическим методам тестирования

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

Эвристика исследовательского тестирования

Этот подход нам особенно импонирует, мы внедряем его и применяем, потому что он сразу же приносит результат. Его автор Джеймс Бах, американский разработчик, тестировщик, консультант. В данном случае применяется контекстно-ориентированный подход, при котором приложение необходимо анализировать со всех возможных точек зрения, чтобы выявлять неявные кейсы, не учтенные при первоначальном формировании тестовой модели. Предлагаем пример чек-листа эвристики SFDPOT в виде карточек для проверки программных продуктов:

Чек-лист особенно полезен, когда приложение работает на большом объеме данных и сложно охватить все узкие места, предугадать поведение пользователей. Такая работа приносит иногда неожиданные результаты, из-за которых приходится в корне менять идеи разработки.

Эвристика регресс-тестирования

Автор этого метода Карен Н. Джонсон – американский тестировщик, консультант, тренер. Эвристика регресс-тестирования направлена на обнаружение ошибок в уже протестированных участках исходного кода. Готовый чек-лист, который мы сейчас пробуем применять на практике:

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

Полезные инструменты

MindMap

Ментальная карта или карта сознания сейчас повсеместно популярный инструмент, и сфера тестирования не стала исключением. Все потому, что этот способ действительно помогает «разрезать слона на стейки» и увидеть путь к конечному результату. С MindMap члены команды понимают, что им нужно делать, чтобы развиваться. Она помогает группировать планы и упорядочивать их. Прикладываю пример карты, которая должна составляться с каждым специалистом индивидуально:

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

Выводы

Тестирование не гарантирует полного отсутствия дефектов. Оно выявляет проблемные зоны и оценивает текущее состояние качества продукта. Чтобы делать это максимально эффективно, нужно изучать теорию, пробовать разные подходы и регулярно осваивать новые инструменты. Наш опыт развития показал, что опаснее всего в тестировании «театр одного актера», когда тестировщик не взаимодействует с командой и формально подходит к решению задач. «Спящих» специалистов нужно будить и направлять их на четкий путь развития.