Начало работы: как тестировщику строить коммуникацию на проекте?

23 декабря 2016

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

3 признака эффективной коммуникации:

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

Это идеальный вариант. Но в реальной жизни тестировщики могут сталкиваться с ситуацией, когда:

  • Не всегда ясно, где найти тестовые данные;
  • Один и тот же вопрос повторно задается разными людьми;
  • Многократно создается описание одного и того же дефекта.

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

Общение с разработчиками

Поддерживайте личное общение

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

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

Пишите понятно

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

  • Пример плохого заголовка: «Невозможно заполнить поле кода мобильного оператора».
  • Пример хорошего заголовка: «Приложение аварийно завершает работу при выборе некоторых стран в поле выбора кода мобильного оператора».

При описании дефекта можно пользоваться принципом «Что? Где? Когда?». Например:

  • Что: аварийное завершение работы приложения.
  • Где: на странице с полем выбора кода мобильного оператора.
  • Когда: при выборе следующих стран: Молдова, Перу, Австралия.

Указывайте фактический и ожидаемый результат.

  • Фактический результат: Приложение аварийно завершает работу.
  • Ожидаемый результат: Страна выбрана.

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

Критикуйте конструктивно или совсем не критикуйте

Есть мнение, что разработчики «недолюбливают» тестировщиков, мстят им за каждый обнаруженный баг или, наоборот, жалуются на злорадствующих QA-инженеров, которые считают своим личным достижением лишний раз указать разработчику на ошибку в коде.

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

Коммуникация внутри команды

Узнайте лучше своих коллег

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

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

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

Делитесь тестовыми данными

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

Последняя по счету, но не по важности рекомендация:

Говорите на одном языке

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

Обучение на курсах — ваш первый опыт работы с командой!

Тому, кто проходит обучение на курсах по тестированию ПО стоит помнить, что ваша учебная группа – это уже команда. Пускай сейчас вы тестируете учебный, несуществующий продукт, но правила эффективной коммуникации никто не отменял. Пишете e-mail преподавателю? Убедитесь в том, что тема письма подскажет, о чем пойдет речь и сэкономит время на «погружение».

Кстати, статистика QA Academy говорит, что те группы, которые продолжают общаться после окончания курсов, делятся в skype-чате опытом прохождения собеседований, находят работу быстрее тех, кто такое общение прекращает.

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