Home

Автор: Иван Бондарь, ведущий инженер по тестированию компании "Лаборатория качества"

Оригинальная публикация: http://quality-lab.ru/how-to-understand-cutomers-needs/

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

К сожалению, наладить единство понимания бывает не очень просто, так как:

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

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

Общие ожидания от тестирования

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

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

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

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

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

Ожидания от тестируемого продукта

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

Очень важно правильно оценить целевую аудиторию продукта. Только анализ пользовательских потребностей позволит учесть пожелания и потребности аудитории продукта, используя их при разработке и проведение тестов. Подробнее о важности работы с целевой аудиторией можно узнать из статьи Виктории Юркевич «Целевая аудитория тестируемого продукта – важно ли знать и обязательно ли учитывать?».

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

В предыдущем примере я рассказывал о том, насколько важна для правильного построения процесса тестирования вовремя полученная обратная связь от клиента. Увы, на практике эту связь не всегда удается наладить.

Пример из практики. Мы работали над тестированием крупного федерального портала, где планировалось внедрение нового функционала по загрузке пользователями таблиц с данными. У нас имелось подробно составленное ТЗ, в котором, кроме всего прочего, было оговорено, что размер таблиц ограничивается 100 записями. В ходе тестов мы для большей уверенности проверяли их на 300 записей: все работало. И вдруг после выхода релиза началась паника: основной клиент загрузил таблицу на 5000 значений, и «все сломалось». Ни нами, ни аналитиками не был учтен тот факт, что целевой аудитории этого продукта будут важны таблицы с большим объемом данных. Просчет привел к провалу релиза, сорванным срокам и дальнейшей переработке. Всего этого можно было избежать, если бы на этапе проектирования был поставлен вопрос о требованиях целевой аудитории.

Выбор окружений для тестирования

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

Так как же выбрать окружения, с которыми действительно целесообразно работать? Для этого существуют различные методы. Например, для сайта, который уже запущен, можно воспользоваться сервисами веб-аналитики, такими как Google Analytics или Яндекс.Метрика. С их помощью можно посмотреть, какими устройствами и ОС обладают ваши пользователи и сосредоточиться на них. Это поможет максимально точно определиться с ключевыми окружениями. Также существует готовая статистика и исследования по распространенности браузеров и мобильных устройств в нужном вам регионе и на требуемой целевой аудитории.

Вот некоторые сервисы по просмотру статистики:

- http://gs.statcounter.com – здесь собрана статистика по отдельным странам или сторонам света (Азия, Европа, Океания);
- http://netmarketshare.com – на этом сервисе можно самому составить список из интересующих Вас браузеров и их версий.

Подробнее с выбором окружений для тестирования можно ознакомиться в статье Татьяны Бирюковой «Тестируем кроссбраузерную совместимость – на что важно обратить внимание».

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

Согласование стратегии тестирования

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

Стратегия тестирования реального проекта может выглядеть так:

Кликните на картинку, чтобы увеличить изображение

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

Отчетность по проекту

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

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

Отчёты должны создаваться не для красоты и не для галочки, а для решения конкретных задач. Начните с вопроса: «Какие задачи мы решаем?». После ответа в отчет можно включить такую информацию:

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

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

Прозрачность работ

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

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

Введенная система отчетности выглядела так:

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

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

Вывод

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

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

Обсудить в форуме