Проблемы QA при офшорной разработке могут быть значительно уменьшены при правильном построении коммуникаций с клиентом. Обсуждение мер по обеспечению качества начинается уже на стадии продаж, в дальнейшем коммуникации строятся на доверии и должны быть регулярными. Команда QA является независимым звеном между заказчиком и командой разработчиков, главной целью которой является качество конечного продукта и организация управления рисками. Особенностью общения с бизнес и конечными пользователями продукта является умение разговаривать с ними на одном языке, используя доменные термины.
Коммуникативная роль QA
Стиль общения на этом этапе значительно зависит от клиента. В отличие от идеального заказчика в вакууме, который знает и понимает, что такое QA, соглашается с предварительными сроками и оценкой времени, соглашается с с предложенной суммой расходов, реальность выглядит по-другому.
Например, существуют клиенты, которые имеют слабое представление о том, что такое QA. На самом деле это не самый плохой вариант. Задача Sales-менеджера – рассказать что такое QA, показать на реальных и успешных примерах, как обеспечение качества позволило получить в итоге качественный продукт. При правильно построенном общении такие клиенты проявляют больший интерес к процессу разработки охотнее дают обратную связь при возникающих вопросах.
Другие заказчики считают, что QA это только тестирование. Тоже не плохой вариант. Возможно, это вызвано недостатком знания о процессах обеспечения качества. В этом случае так же задача sales менеджера состоит в том, что бы показать и рассказать зачем нужно QA и что можно делать в рамках процесса для предполагаемого.
Сложности чаще бывают с клиентами, которые думают, что знают, что такое QA, но считают- оно им совершенно не нужно или же понимают необходимость, но не желают платить за него. В таком случае Sales-менеджер в своем рассказе делает упор на риски, возникающие при отсутствии управления качеством, приводит в пример неудачные истории. Так же можно устроить встречу клиента с гуру в QA из компании , который сможет проанализировать потенциальные риски будущего проекта и стоимость их исправления.
Грамотно оставленный предварительный план проекта, в котором QA активности являются неотъемлемой частью процесса разработки на протяжении всего времени, так же может изменить мнение клиента в лучшую сторону.
Но в любом случае, каждый клиент они ожидают получить в итоге качественный продукт. При этом, конечно, понятие качества у каждого свое. Важно выяснить мировоззрение заказчика и на этом основывать рассказ о QA.
Особенности коммуникаций
Во-первых коммуникации должны быть независимы, т.е. представлять собой третье звено между заказчиком и командой разработчиков. Команда QA помогает клиенту сформулировать параметры качества для продукта, а так же измерить или определить текущее состояние продукта согласно тому, что делает команда разработчиков.
Таким образом, QA и тестировщики обладают полной информацией о проекте – бизнес требования и приоритеты (от заказчика), текущее состояние разработки проекта (от девелоперов). Это помогает определить текущие риски и выявить потенциальные проблемы. Чем раньше это будет сделано, тем легче минимизировать риски.
Используя полученную информацию, QA команда может сообщить, готов ли продукт к релизу или промежуточному деплою или нет. В идеальной ситуации у команды есть право вето на выпуск версии. То есть, QA команда как независимое звено должна иметь право высказать свое мнение, о том, является ли на данном этапе продукт настолько качественным, что быть допущенным до релиза и если нет — обосновать почему (привести метрики, список открытых критичных багов или незавершенных и не проверенных тасков). Очевидно, для этого обладать хорошими коммуникативными навыками. Не даром многих вакансиях для QA лидов и менеджеров обязательным требованием является коммуникабельность. Важно умение сообщать неприятные новости и не переходить при этом на личности. Именно за то, то тестировщикам часто приходится сообщать неприятные для заказчика новости о несовершенстве мира и продукта в частности, тестировщики вызывают негативные эмоции.
В то же время QA должен быть тонким психологом, что бы найти общий язык с командной разработчиков и стать ее неотъемлемой часть. Важно, что бы разработчики были благодарны за то, что вы находите потенциальные проблемы, которые влияют на качество, чем считали, что вы к ним придираетесь. А заказчик благодарен за то, что вы выявляете проблемы до того, как это увидят конечные пользователи и тем самым вы экономите заказчику деньги.
Таким образом, главной задачей QA является не нахождение максимального числа проблем и ошибок, а улучшении качества продукта. Особенно при изменении плана разработки, сокращении сроков и нехватке времени, появлении дополнительных требовании или же изменения существующих. Впрочем, в современном мире редко встречаются проекты со статическим планом и неизменными требованиями. Поэтому контроль за качеством, изменение приоритетов, пересмотр критичности рисков и т.д. – процесс постоянный во времени. К тому же со временем одни риски компенсируются действиями qa и тестированием, возникают новые или выявляются скрытые.
Стиль коммуникаций
Доверие это основной стиль общения с заказчиком, в этом случае клиент чувствует, что он контролирует ситуацию. Но прежде чем сообщать о неприятных новостях нужно подумать как минимум дважды. Возьмите за правило не отправлять письмо клиенту, не перечитав его. Как уже и говорилось в сообщении важно опираться на факты, метрики, статистику багов и т.д.
Коммуникации обязательно должны быть регулярными. Удобнее всего превратить отчетность в рабочую рутину, которая не отнимает много времени. Но не превращайте это в рутину у заказчика. Иначе это чревато уменьшением внимания к письмам, клиент будет пропускать письма, не считая их важными. Сделайте так, что бы каждое письмо, звонок или сообщение обладали ценной информацией для клиента. Особенно если письма содержат первые сообщения о появляющихся проблемах. В таких случаях недостаточно просто отправить письмо, важно получить обратную связь. Например, если в течение 1-2 дней не было получено ответа на описание проблемы, необходимо еще раз написать письмо с указанием рисков и возможных и почему ответ так важен (например, блокирует дальнейшую разработку продукта).
Если планы, вопросы или важные аспекты процесса обсуждались на телефонной конференции, то сразу после созвона необходимо отправить клиенту по электронной почте краткое содержание беседы: о чем говорили, какие решения приняли, какие вопросы остались. Если возникло недопонимание с какой-либо из сторон, то на этом раннем этапе можно это выяснить, не после реализации некорректной функциональности В дальнейшем в отчетах можно указывать какие из вопросов были закрыты, а какие до сих в процессе.
Отчетность
QA отчет должен не просто содержать информацию о закрытых/открытых багах и текущих тасках. Он должен отвечать на основные вопросы заказчика, такие как:
— как все продвигается?
— общее состояние?
— Какие риски и как мы можем их уменьшить?
— Мы ничего не пропустили?
— и иногда: кто виноват?
Ответом на эти вопросы могут служить данные из системы баг трекинга: соотношение количества найденных багов к количеству закрытых; количество найденных за конкретный промежуток времени; тип багов – функциональные или технические; текущее значение используемых на проекте метрик и значение метрик в динамике. Иногда заказчика интересует кто нашел тот или иной баг и кто работает над его исправлением. Это позволяет оценить так же качестсво нашей QA команды.
Правильно составленный отчет помогает составить общее представление на какой стадии проект и насколько он соответствует необходимому уровню качества.
Формы отчетности
Основной формой отчетности как правило является email.
Отчеты могут генерироваться автоматически, при этом зачастую можно настроить расписание, когда эти отчеты будут создаваться и отправляться клиенту. Они будут объективны, т.к. в них не будут замачиваться и скрываться критичные баги или понижаться их значимость.
Email отчеты должны наглядно отображать информацию, например значение метрик из системы багтрекинга и их динамику лучше показывать на графиках или диаграммах. К счастью, большинство систем управления задачами позволяют получить графическое представление QA метрик, основанных на ошибках.
Хорошее правило для отчета – написать о самом важном, рискованном в самом начале, затем общий статус проекта.
Если же отчет производится во время интерактивных конференций (созвоны по телефону, скайпу), важно четко формулировать свои мысли. (все та же необходимая коммунтикативность для QA менеджеров и лидов). Для успешного проведения можно составить письменный план, учитывая основные рекомендации для письменного отчета: выделить самое важное и рискованное вначале.
Если во время конференции возникают вопросы или наоборот, то после так же необходимо подготовить их краткий конспект беседы и отправить.
Управление рисками
Управление рисками является одной из основных задач QA менеджера или лида. Даже если на проекте не используются методики, такие как FMEA или Hazard Analysis, риски приходится анализировать, ну хотя бы для приоретизации функциональности для тестирования и разработки. Конечно, QA лид занимается оценкой не в одиночку и основная оценка исходит от клиента. Тем не менее он занимает активную позицию и, как уже упоминалось, может помогать клиенту с выявлением потенциальных проблем в ПО исходя из опыта, на основании похожих проектов или используя чекисты; типизировать риски и оценивать вероятность сбоя и насколько те могут влиять на качество продукта.
Серьезность некоторых рисков может быть значительно уменьшена за счет тестирования, выбора библиотек(например, системы шифрования для проведения электронных платежей) и т.д.
Первые риски выявляются на этапе продаж, а затем закладываются в QA плане и в критерий приемки. Например, для системы, которая должна поддерживать одновременную работу большого количества пользователей on-line необходимо на ранней стадии выбрать технологию, позволяющую реализовать требование, возможно создать прототип приложения, а так же обязательно провести нагрузочное тестирование и в приемочном наборе добавить тест, показывающий, что система справляется с заданным количеством пользователей.
На ранний стадии проекта важно выделить как можно больше технологических рисков. Иначе можно получить приложение, которые будет не соответствовать желанию заказчика. Например, риск, поддержки большого количества пользователей был уменьшен с помощью выбора правильной технологии, время отклика сократили до приемлемого значений, UI содежит красивый флеш и работает правльно, но на обычном браузере, а изначально планировалось, что пользователи будут обращаться к приложению через мобильные браузеры. Это забыли учесть в разработке. В итоге получится хороший проект с быстрой производительностью, но не соответствующий требованиям заказчика.
Отчеты являются важной частью управления рисками. Они могут быть включены в регулярные отчеты по проекту, а могут быть отдельными. Формат отчета зависит от проекта, но в самом простом случае это может быть простой Exel документ, содержащий риски в виде тасков или проблем, приоритет и критичность.
Одним из основных рисков, который присутствует всегда, является риск изменения требований или добавления новых. В моем опыте не было ни одного проекта,где бы не менялись и не добавлялись требования. Конечно, время на покрытие риска частично закладывается при планировании, но план не всегда может покрыть время необходимое на изменение и доработку. К тому же, новое требование не оговаривалось в контракте и надо либо заключать новый контракт или приоретизировать требования таким образом, что бы уложиться в заданные рамки. Но это скорее относится к задаче проджект менеджера. Задача QA лида в оценке того, насколько новое или измененное требование может повлиять на качество проекта, переприоритезации рисков в сотрудничестве с заказчиком, аргументированно, с указанием фактов необходимо объяснять почему теперь прийдется сократить время некоторые запланированные действия, например, тестирование для других областей проекта, и как это повлияет на качество. Общение с бизнес пользователями- это одна из самых сложных задач QA.
Бизнес пользователи и качество
В чем же сложность взаимодействия с бизнес пользователями? Во-первых, как привило, это очень занятые люди. И часто от их решения зависит дальнейший процесс разработки. Наилучшим вариантом будет выделить конкретного человека, который будет отвечать за качество на стороне заказчика и имеет возможность принимать решение в спорных ситуациях, или может быть делегировать это тому человеку, который сможет ответить на вопрос. Конечно же этот человек должен понимать, насколько важны его быстрые ответы. При общении старайтесь задавать как можно более конкретные и важные вопросы (никто не любит, если его отвлекают по пустякам), проведите небольшое исследование и напишите возможные последствия по возможным ответам, четко сформулируйте как это повлияет на смежные области в проекте. Если вопрос блокирующий дальнейшую разработку, обязательно укажите и объясните почему вы не можете продолжать дальше. Хорошо, если такой человек у клиента будет посредником между вами и конечными пользователями.
Но если приходится общаться с пользователями напрямую нужно определить по какому вопросу к какому пользователю стоит обращаться. При составлении письма такому человеку важно четко формулировать запрос. Помните, что пользователи не любят читать (и не читают) детальных технологических текстов. Что бы получить ответ быстро, формулируйте вопрос на их языке. Поэтому важно разбираться в бизнес домене и терминологии заказчика. Например, если проект – это некая брокерская система, которая следит за котировками акций на бирже, важно выучить финансовую терминологию заказчика, то есть как минимум различать понятие security как ценная бумага и security как безопасность.
Сообщайте и спрашивайте о проблемах как можно раньше, если проблема все-таки случится, будет письменное свидетельство о том, что вы об этом уже писали и приводили возможные риски. Стоит помнить, что решение клиента высокоприоритеный и важный риск. Не всегда стоит сразу сообщать клиенту, что он не прав, возможно, его решение продиктовано как раз знанием предметной области, где данное решение будет наиболее верным. Если вы все еще сомневаетесь, в правильности решения, попробуйте предложить сделать прототип или дизайн новой функциональности. Это хороший способ быстро получить обратную связь о том, насколько эта реализация подходит клиентам.
Все это похоже на бизнес анализ? Да, так и есть. Зачастую роль бизнес аналитика в жизненном цикле проекта исполняет QA лид, даже если на начальном этапе присутствовал отдельный человек в роли бизнес аналитика, так же бывает, что QA менеджер и бизнес аналитик это один человек. В любом случае роли очень близки. В любом случае лид исполняет роль бизнес аналитика как только меняются требования и необходимо пересматривать подход к тестированию и главной составляющей успеха роли будут правильно поставленные и вовлеченные в процесс коммуникации.
