Почему важно начать тестирование как можно раньше

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

Эксперты выделяют несколько этапов развития продукта:
  • идея;
  • стратегия;
  • требования;
  • дизайн;
  • прототип и верстка;
  • разработка и тестирование;
  • поддержка.

Как правило, процесс тестирования начинается на предпоследнем этапе. Но правильно ли это? И в какой момент тестирование становится актуальной проблемой?

Тестирование требований

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

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

Кент Бек и Cindee Andres в книге Extreme Programming Explained: Embrace Change, 2nd Edition пишут о том, что «перехват ошибок на ранних стадиях проекта представляет собой наименее затратный способ обеспечения качества программного обеспечения… В разработке программного обеспечения существует дилемма: дефекты обходятся дорого, но устранение дефектов также обходится дорого. Однако, большинство дефектов в итоге превышают средства, которые были бы затрачены на их предотвращение».

При раннем тестировании требований мы всегда находили и отсекали совершенно немыслимые логические баги. В одной из ситуаций для работы с формой нужна была привилегия (набор определенных прав). Форма представляла собой двухуровневую систему, и у привилегии был доступ к обоим уровням. Аналитик ввел доработку: еще одна привилегия должна получить доступ ко второму уровню формы. Разработчики начали работу, но еще до реализации команда тестирования обнаружила баг в спецификации: новая привилегия не сможет пользоваться формой второго уровня, так как путь к ней идет через форму первого уровня, доступ к которой у привилегии отсутствует. Дефект исправили, для разработки это стоило некоторых «архитектурных» усилий. В результате мы сэкономили приличное количество времени.

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

Тестирование макетов

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

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

Тестирование верстки

После завершения работы на стадии дизайна и исправления всех ошибок наступает этап прототипа и верстки. Если ваш продукт будет наполняться контентщиками в самом конце, оставьте им вычитку текстов; команда тестирования в этом случае может проверить правильность работы продукта на «рыбных» текстах. Баги верстки не отличаются большим разнообразием («поползла» верстка, некорректно переносятся строки и символы, тексты «залазят» на элементы интерфейса и т.п.) и обычно затрагивают небольшие элементы интерфейса, но даже такие, казалось бы, незначительные неудобства и ошибки могут отпугнуть ваших пользователей. На этой стадии также можно проверить основные поля ввода: какие символы должны приниматься, какие принимаются, а какие – нет.

Для маркетинговой акции интернет-гипермаркета разрабатывался промо-popup, который должен был появляться в центре экрана пользователя (потенциального покупателя) в определенных товарных категориях. На popup была расположена несложная форма, заполнив которую, пользователь получал письмо с кодом скидки на email, указываемый в форме. Форму передали в тест на стадии дизайна, и не напрасно: в форме неоправданно использовались разные шрифты, заголовки «скакали» над полями ввода, кое-где не хватало знаков препинания. После исправления ошибок форму сверстали и повторно передали в тест. И вновь было выявлено и отработано несколько ошибок: поля ввода можно было растянуть так, что они выходили за пределы самого popup, а отображение popup в браузере Internet Explorer версии 8 очень отличалось от его макетного представления. Теперь тестировщикам оставалось проверить логику работы (появление popup в нужных товарных категориях и «непоявление» в ненужных), а также правильность отправки кода скидки на почту пользователей.

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

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

Что в итоге?

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

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

Удачи и легких вам релизов!

Об авторе

Занимается тестированием с 2012 года, прошла путь от стажера на 20 часов в неделю до руководителя отдела тестирования интернет-гипермаркета, работает в "Лаборатории качества" на позиции тест-менеджера.

Поиск
Облако меток
8 марта (1)api (5)kpi (1)kpi в тестировании (1)postman (1)rest api (2)scrum (1)scrumban (1)soap api (1)sqa days (1)TDD (1)UX-экспертиза (1)won't fix (1)А/Б тестирование (1)День дарения книг (1)День защитника Отечества (1)ПОИНТ (2)Приёмочное тестирование (1)Юмор (1)автоматизация тестирования (5)аудит (1)аудит тестирования (1)аутсорс (1)баги (4)банковские приложения (1)вакансии (5)варианты использования (1)веб-приложения (1)веб-тестирование (2)верстка (1)граничные значения (1)дедлайн (2)диаграмма Исикавы (1)дополнительные материалы (1)ежемесячный отчет (12)интернет-магазин (1)исследовательское тестирование (2)коммуникации (3)конфликты (1)кроссбраузерное тестирование (1)курсы для тестировщиков (2)лаборатория качества (19)лайф-хаки (3)локализация (1)международные проекты (1)метрики (2)модель ситуационного лидерства (1)мотивация (3)новый год (2)обеспечение качества (7)обучение (6)оптимизация тестирования (13)поздравление (1)поздравления (4)пользовательские истории (1)пример (1)проблемы (1)проектные риски (1)проекты (4)процесс тестирования (24)развитие команды (5)разработчики (1)распределенная команда (3)решения (1)собеседование (1)специализация (2)с чего начать (1)тест-анализ (2)тестирование (44)тестирование безопасности (3)тестирование мобильных приложений (2)тестирование серого ящика (1)тестирование требований (1)тестирование черного ящика (1)тестировщики (10)тестовая документация (1)тестовое покрытие (1)тесты (1)техники тест-дизайна (1)требования (1)удобство использования (2)управление проектами (2)управление рисками (1)успехи (1)целевая аудитория (3)юзабилити (3)
Получите совет