Тестировщик и его роль в разработке. Когда нужно сломать сайт и чем это полезно?
Сегодня поговорим о тестировании в digital-агентстве Alente, а конкретно — о том, как трансформировалась роль тестировщика в проектах.
Пару лет назад мы работали как большинство студий: привлекали тестировщика только на этапе тестирования. Но сейчас он принимает деятельное участие в работе уже на этапе сбора требований к сайту. Почему так получилось и как это помогает улучшить продукт? Читайте — и вы всё узнаете.
Как было раньше?
Проекты приходили на тестировку перед запуском. И мы получали набор стандартных проблем данного этапа: непроработанные изначальные требования приводили к переделкам на этапе тестирования. При этом отметим, что непроработанные требования — это не только недостаточное описание работы функций, но и возникающие противоречия в их трактовке. Мы все люди, и бывают ситуации, когда команда разработки, начиная от
Причиной чаще всего были ошибки коммуникации, потому что не все требования фиксировались текстом или выражались в виде прототипов и макетов.
Другой проблемой становились изменения требований по ходу разработки. Отсутствие чёткого механизма фиксации изменений приводило к ситуациям, когда
Получалось, что часть требований выяснялась только на этапе тестирования, когда тестировщик сталкивался с противоречиями и начинал задавать вопросы. То есть этап тестирования готового продукта, по сути, становился этапом выяснения исходных требований и попыткой доработать проект с их учётом.
К каким последствиям это приводило?
Отсюда вытекает
Минусы данной схемы:
- Неверная трактовка требований в самом начале.
- Возникновение новых требований по ходу проекта.
- Всплывающие проблемы на этапе тестирования, отладки или запуска. Чинить такие проблемы может быть дорого, а иногда и невозможно. Это приводит к срывам сроков, бюджетов, и потере лояльности клиента.
- Потеря рабочего времени разработчиков и тестировщиков.
- Попытки вписать пропущенные требования в проект, часто приводящие к проблемам в его работе.
- Излишняя нагрузка на тестировщиков и, как следствие, снижение качества их работы.
Как мы работаем сейчас?
Чтобы избежать вышеупомянутых проблем, мы стали подключать тестировщика и всю команду разработки с самого начала.
Сейчас команда разработки подключается начиная с этапа сбора требований. Каждый член проектной команды отвечает за то, чтобы требования не были противоречивыми, чтобы уточнения поступали вовремя и весь процесс был под контролем. Теперь клиент видит прототипы, макеты и ТЗ только после внутреннего согласования с командой разработки.
Раннее включение важно и в том смысле, что позволяет лучше погрузиться в среду, понять
Что делает тестировщик на каждом этапе разработки?
Тестировщик подключается на каждом этапе для того, чтобы:
- дать свою оценку, протестировать требования;
- зафиксировать важные моменты по проекту (
чек-листы ,тест-кейсы ); - выявить особые сценарии использования или
user-stories , затрагивающие доступность, тестируемость, граничные случаи.
Предпроектный этап. Этап дизайна
Здесь тестировщик определяет приоритеты и сценарии. важные для бизнеса. Он расставляет приоритеты на рисках (вещах, важных для клиента и его бизнеса), определяет, какие из заложенных функций своей некорректной работой могут повысить риски и в какой мере. Например: возможность оплаты заказа, оформление заказа, заявки, использование функций «личного кабинета».
Тестировщик составляет дневник проекта — его структуру с разделением на разделы и отдельные блоки с перечислением основных функций. По мере тестирования он заполняет этот документ информацией.
Этап ТЗ
Здесь тестировщик определяет структуру проекта по блокам, перечень функций, пишет
Стандартные проверки представляют собой
Стандарты зафиксированы для разработчиков в их типовых задачах и покрывают такие факторы, как:
- выполнение требований, необходимых для успешного продвижения сайта в поисковых системах;
- выполнение требований для сайтов определённых тематик, например медицинских учреждений или автосайтов;
- выполнение требований к доступности (более подробно о доступности можно прочитать здесь).
Также на этапе ТЗ тестировщику необходимо выяснить вопросы о работе функций, которые потенциально могут возникнуть на этапе тестирования. Свою оценку по данному вопросу дают и разработчики.
Кроме того, важно протестировать требования:
- Требования должны трактоваться всеми одинаково.
- Автор требований должен оперативно отвечать на вопросы и фиксировать изменения.
- Требования нужно поддерживать в актуальном состоянии на момент работы над продуктом.
- Все коммуникации и дополнительные договорённости по требованиям должны фиксироваться письменно.
- Согласование требований должно проходить со всей командой разработки.
- Не должно быть отсылок к неопределённой информации или незафиксированных требований.
Этап тестирования и отладки
На этом этапе происходит непосредственно тестирование проекта. Тестировщик выполняет свою задачу на всех требуемых конфигурациях, заложенных на этапе ТЗ, с помощью
Этап ретроспективы
Цель данного этапа — анализ внутренних процессов с целью их улучшения. Ретроспектива призвана совершенствовать взаимодействие внутри команды разработки, постановку задач, планирование релизов. Она помогает выявить узкие места в процессах и подумать, что можно улучшить, изменить или внедрить.
В компании существует два вида ретроспективы: одна из них — внутри рабочей группы, другая — только для тестировщика. На данном этапе тестировщик работает над выявлением пропущенных дефектов, причин их пропуска и возможностей улучшения процесса. Например: если дефект был пропущен
Ретроспектива помогает и самому специалисту — он может лучше понять свои качества тестировщика: что было легко, а что далось сложно и почему так вышло. Ему становится понятно, в каком направлении следует развиваться и улучшать навыки.
Что даёт такой подход?
Менеджеру проектов:
- Увеличивается скорость разработки. Снимаются одинаковые вопросы и снижается количество доработок.
- Менеджер раньше получает информацию, важную для принятия решений.
- Растёт качество конечного продукта.
- Появляется дополнительная информация о рисках, возникающих в процессе разработки.
Разработчику:
- Качественные и понятные требования с однозначной трактовкой.
- Отсутствие изменений в требованиях, возникающих в процессе работы или после завершения разработки.
Тестировщику:
- Возможность влиять на проект в самом начале.
- Меньше багов на этапе тестирования продукта.
- Понятный конечный результат и алгоритм проверки. Лёгкое погружение в процесс, стандартизированный план тестирования и тестовая документация.
- Контроль над любыми изменениями в требованиях.
Результат проекта зависит не только от этапа тестирования, но и от всего процесса разработки. Качество закладывается в самом начале — чем лучше отрегулированы внутренние процессы в целом, тем легче тестировать готовый продукт и тем меньше в нём проблем. Мало того, большинства сложностей с поддержкой, внесением изменений и общением с клиентом можно избежать, правильно выстроив работу с самого начала.