Комунікація між тестувальниками та іншими ролями

Коли говорять про м’які навички, тема комунікації випливає одна із перших.Чому це так важливо? Причому, однаково важливо для всіх ролей. Через комунікацію ми збираємо вимоги, домовляємось про покращення, повідомляємо про проблеми, забезпечуємо прозорість для менеджменту і зацікавлених осіб.

Можна написати окрему статтю про “шкідливі поради” у спілкуванні з колегами. (Якщо цікаво, дайте знати в коментарях).

Проте, завжди треба пам’ятати одну річ. Коли ви спілкуєтесь з будь-яким колегою, не важливо з якого відділу, ви маєте виходити з того, що ви одна команда. У вас одна ціль: випустити кращий продукт.

Перш ніж починати розмову, підготуйтеся, зробіть невеличку паузу, вгамуйте емоції, якщо вони є.

Як би ви хотіли, щоб з вами розмовляли? Доносили новини? Просили щось пофіксити?

Подумайте, яку ціль ви переслідуєте? Чого хочете досягти у процесі розмови? Які слова, інтонація, будуть помічні? Виглядає як додаткова робота, проте такий підхід працює на вас. Гарні людські відносини так само критичні для проєкту, як і добре написаний код.

Ми маємо бути ввічливими, вміти слухати, вміти у конструктивний діалог, (а не шукати  винуватого і тикати пальцем в оточення).

Якщо ви починаєте розмовляти з позиції обвинувачення або з почуттями гніву, образи — розмова може швидко (і не контрольовано) перерости у суперечку або пошук винних. Так ви тільки витратите час та сили.

Яка комунікація буде гарна та ефективна? 

Для мене це і про вміння розмовляти спокійно, поважати думку один одного (навіть якщо вона протилежна, у всіх різний досвід), шукати рішення разом, вміти переконувати. Вміти довіряти експертизі колеги.

Це також про славнозвісне “активне слухання”, про яке вже кілька років розповідають у соцмережах і на тренінгах. Найвищий пілотаж – почути та побачити за словами людини її справжні цілі/болі/невдоволення.

Гарна комунікація також допомагає переконатися, що всі знаходяться на одній сторінці, швидко та ефективно розв’язувати проблеми та задачі, яки виникають.

Для мене, одне з ключових завдань у якості QA/QC — упевнитися, що всі розуміють що та як ми робимо. Тож найчастіша мета комунікації: зрозуміти які прогалини ми маємо і як їх закрити.

Поміркуймо, що саме ми можемо дізнатися через налагоджену комунікацію від різних ролей на проєкті

Важливо: все написане у статті є суто досвідом та інтерпретацією авторки. У вас на проєкті можуть бути інші ролі, ролі з трохи іншими обов’язками чи одна людина може мати декілька ролей. Не на всіх проєктах ви будете мати доступ до переліченої інформації, і не завжди вона вам вся буде потрібна. Як завжди, все дуже сильно залежить від проєкту та процесів на ньому.

З Розробниками:

• Матимете розуміння стандартів кодування, найкращих практик, що використовуються на проєкті.
• Дізнатись про системи контролю версій та способи управління та інтеграції коду.
• Матимете можливість разом переглянути вимоги на ранній стадії та включити туди як технічні обмеження, так і найкращі практики. Це допоможе одразу будувати продукт правильно.
• Дізнатись про відомі ризики, потенційні проблеми та області, що викликають занепокоєння, пов’язані з функціональністю.
• Будете мати можливість швидко виробити стратегію при форс-мажорах. Наприклад, коли у вас блокер на продакшені.
• Або зробити справді круту брейншторм-сесію і знайти найкраще можливе рішення.

З Власником продукту/Product Owner:

• Зрозуміти бачення продукту.
• Дізнатись про пріоритетність фіч та юзер сторей у беклозі продукту.
• Отримати уявлення про обґрунтування рішень щодо фіч та їхній вплив на користувачів.
• Можливість співпрацювати над визначенням критеріїв прийнятності та очікувань користувачів щодо функцій.
• Обговорити процес доопрацювання беклогу та планування спринтів для узгодження зусиль з тестування.

З Scrum Master:

• Отримати розуміння Agile та Scrum, як вони використовуються на проєкті.
• Дізнатись про планування спринтів, огляд спринтів, ретроспективи та щоденні стендапи.
• Зрозуміти правила у команді та проєкті.
• Отримати уявлення про перешкоди та виклики, з якими стикається команда.
• Співпрацювати над тим, щоб процес QA/QC відповідав практикам та часовим рамкам Scrum.
• Обговорювати можливості постійного вдосконалення процесу QA/QC в рамках Scrum.

З Продакт-менеджерами:

• Розуміти загальні цілі та завдання продукту, довгострокову стратегію та позиціювання на ринку.
• Дізнатись про персони користувачів та актуальні пріоритети.
• Отримати уявлення про дорожню карту продукту та майбутні вдосконалення.
• Спробувати поглянути на  результати досліджень ринку та користувачів, які впливають на рішення щодо продукту.
• Спільно працювати над визначенням критеріїв прийнятності та метрик успішності функцій.

З Бізнес-аналітиками:

• Отримати глибоке розуміння бізнес-логіки та правил проєкту.
• Дізнатись про конкретні вимоги від зацікавлених сторін та як вони перетворюються на функції.
• Розуміти варіанти використання та сценаріїв, які визначають поведінку системи.
• Усувати неоднозначності та збирати додаткову інформацію про вимоги.
• Співпрацювати над процесами та критеріями користувацького тестування (UAT).

З Дизайнерами/UI/UX командою:

• Розібратися з принципами дизайну користувацького інтерфейсу (UI) та користувацького досвіду (UX).
• Дізнатися про шаблони дизайну, фреймворки та макети, створені для проєкту.
• Отримати уявлення про взаємодію з користувачем, навігаційні потоки та очікування користувачів.
• Співпрацювати над тим, щоб візуальні та інтерактивні аспекти продукту відповідали специфікаціям дизайну.
• Обговорювати питання доступності та юзабіліті.

З Архітекторами:

• Отримати розуміння високорівневої архітектури системи та взаємодії компонентів.
• Дізнатись про масштабованість, продуктивність та безпеку архітектури.
• Отримати уявлення про рішення щодо стека технологій та конфігурацій інфраструктури.
• Спільно міркувати щодо тестабіліті продукту.

З Менеджерами проєктів/Делівері менеджерами:

• Отримати уявлення про часові рамки проєкту, етапи та графіки релізів.
• Розуміти проєктні ризики та обмежень.
• Дізнатись про методології та процеси управління проєктами, що використовуються.
• Співпрацювати над визначенням пріоритетів тестування відповідно до цілей проєкту.
• Обговорити канали комунікації та звітності для QA/QC.

Бачите, скільки можливостей дізнатися щось нове про ваш проєкт? Це наче калейдоскоп, коли один маленький шматочок інформації може зрушити інші — і картинка зміниться, стане зрозуміліша і повніша.

Пам’ятайте, що нормальні людські відносини та ввічливість можуть найскладніший проєкт зробити трішечки приємнішим, тому не нехтуйте можливостями, які дає спілкування.

Що ще важливо розуміти

Є токсичні люди, токсичні проєкти. Тоді, як би ви не намагались вибудувати комунікацію, у вас може не вийти. Тут може допомогти наступне: цікавтеся психологію, вмійте розпізнати “червоні прапорці”, вчиться захищати власні кордони.