Тестировщик и его роль в разработке. Когда нужно сломать сайт и чем это полезно?

Пару лет назад мы работали как большинство студий: привлекали тестировщика только на этапе тестирования. Но сейчас он принимает деятельное участие в работе уже на этапе сбора требований к сайту. Почему так получилось и как это помогает улучшить продукт? Читайте — и вы всё узнаете.

Как было раньше?

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

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

Другой проблемой становились изменения требований по ходу разработки. Отсутствие чёткого механизма фиксации изменений приводило к ситуациям, когда что-то делалось по договорённости, а потом не было никакой возможности выяснить, кто, с кем и о чём конкретно договаривался. В случае кадровых ротаций в команде это приводило к очень серьёзным проблемам.

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

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

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

Минусы данной схемы:

1. Неверная трактовка требований в самом начале.
2. Возникновение новых требований по ходу проекта.
3. Всплывающие проблемы на этапе тестирования, отладки или запуска. Чинить такие проблемы может быть дорого, а иногда и невозможно. Это приводит к срывам сроков, бюджетов, и потере лояльности клиента.
4. Потеря рабочего времени разработчиков и тестировщиков.
5. Попытки вписать пропущенные требования в проект, часто приводящие к проблемам в его работе.
6. Излишняя нагрузка на тестировщиков и, как следствие, снижение качества их работы.

Как мы работаем сейчас?

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

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

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

Что делает тестировщик на каждом этапе разработки?

Тестировщик подключается на каждом этапе для того, чтобы:

• дать свою оценку, протестировать требования;
• зафиксировать важные моменты по проекту (чек-листы, тест-кейсы);
• выявить особые сценарии использования или user-stories, затрагивающие доступность, тестируемость, граничные случаи.

Предпроектный этап. Этап дизайна

Здесь тестировщик определяет приоритеты и сценарии. важные для бизнеса. Он расставляет приоритеты на рисках (вещах, важных для клиента и его бизнеса), определяет, какие из заложенных функций своей некорректной работой могут повысить риски и в какой мере. Например: возможность оплаты заказа, оформление заказа, заявки, использование функций «личного кабинета».

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

Этап ТЗ

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

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

Стандарты зафиксированы для разработчиков в их типовых задачах и покрывают такие факторы, как:

• выполнение требований, необходимых для успешного продвижения сайта в поисковых системах;
• выполнение требований для сайтов определённых тематик, например медицинских учреждений или автосайтов;
• выполнение требований к доступности (более подробно о доступности можно прочитать здесь).

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

Кроме того, важно протестировать требования:

• Требования должны трактоваться всеми одинаково.
• Автор требований должен оперативно отвечать на вопросы и фиксировать изменения.
• Требования нужно поддерживать в актуальном состоянии на момент работы над продуктом.
• Все коммуникации и дополнительные договорённости по требованиям должны фиксироваться письменно.
• Согласование требований должно проходить со всей командой разработки.
• Не должно быть отсылок к неопределённой информации или незафиксированных требований.

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

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

Этап ретроспективы

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

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

Ретроспектива помогает и самому специалисту — он может лучше понять свои качества тестировщика: что было легко, а что далось сложно и почему так вышло. Ему становится понятно, в каком направлении следует развиваться и улучшать навыки.

Что даёт такой подход?

Менеджеру проектов:

1. Увеличивается скорость разработки. Снимаются одинаковые вопросы и снижается количество доработок.
2. Менеджер раньше получает информацию, важную для принятия решений.
3. Растёт качество конечного продукта.
4. Появляется дополнительная информация о рисках, возникающих в процессе разработки.

Разработчику:

1. Качественные и понятные требования с однозначной трактовкой.
2. Отсутствие изменений в требованиях, возникающих в процессе работы или после завершения разработки.

Тестировщику:

1. Возможность влиять на проект в самом начале.
2. Меньше багов на этапе тестирования продукта.
3. Понятный конечный результат и алгоритм проверки. Лёгкое погружение в процесс, стандартизированный план тестирования и тестовая документация.
4. Контроль над любыми изменениями в требованиях.

Результат проекта зависит не только от этапа тестирования, но и от всего процесса разработки. Качество закладывается в самом начале — чем лучше отрегулированы внутренние процессы в целом, тем легче тестировать готовый продукт и тем меньше в нём проблем. Мало того, большинства сложностей с поддержкой, внесением изменений и общением с клиентом можно избежать, правильно выстроив работу с самого начала.