Комунікації в житті QA: як розуміти людей і підтримувати добрі стосунки з усіма

12 жовтня
Оксана Шатабілова, Senior QA Engineer у DataArt
Комунікації в житті QA: як розуміти людей і підтримувати добрі стосунки з усіма
Мене звуть Оксана Шатабілова, я QA-спеціаліст у DataArt. Пропрацювавши понад 5 років як QA Engineer і QA Lead на різних проектах, навчивши кілька практикантів, я зробила висновок, що всі люди різні та в кожного, як то кажуть, свої таргани в голові, але порозумітися можна абсолютно з усіма. У цій статті я розповім про роль комунікацій у житті QA.

КОЛО СПІЛКУВАННЯ QA

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

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

ДИЗАЙНЕРИ

Це люди творчі, вони відповідають за зовнішній вигляд програмного забезпечення. Тестувальник під час своєї роботи уточнює питання, пов'язані з макетами програмного продукту. Мені завжди подобається спілкуватися з дизайнерами. Коли ти робиш зауваження щодо якогось питання, натомість тобі прилітає ще три різні варіанти того, як зробити по-іншому, чого часто від розробників не дочекаєшся. На підставі свого досвіду можу сказати, що дизайнери — легкі у спілкуванні люди. З ними дуже цікаво, адже вони креативні особистості, і це відчувається.

РОЗРОБНИКИ

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

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

Причини, з яких Dev і QA можуть не ужитись

Черствість і байдужість

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

Невміння приймати критику

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

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

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

Складні люди

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

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

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

Поради для щасливого спільного життя Dev і QA

Не судіть суворо за помилки

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

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

Обмінюйтесь ідеями

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

Будьте реалістами

Буває, сидиш і ловиш баг півдня, виписуєш кроки, а потім бац — і він вже зі статусом “won’t fix” або “it’s not a bug”, і на очах з'являються сльози, тому що витрачено стільки часу і сил. Будьте реалістами, постарайтеся зрозуміти причину, з якої баг було відхилено. Може, ви щось неправильно зрозуміли чи припустили. Постарайтеся переконати розробника або менеджера усунути баг, якщо ви вважаєте, що представлений вами сценарій був правильним, і рухайтеся далі.

Розставляйте пріоритети всюди

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

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

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

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

Якщо дотримуватись вищевикладених правил, можна отримати наступні переваги:

  • МОТИВАЦІЯ. Добре згуртована команда завжди мотивує на прояв ініціативи, кар'єрне зростання, бажання рухатися тільки вперед і не припиняти вдосконалюватись.
  • ГАРНИЙ НАСТРІЙ. Коли в команді чудова атмосфера, всі хочуть іти на роботу та вкладатися, спілкуватися.
  • НАВЧАННЯ НА МАЙБУТНЄ. Кожен отримує безцінний досвід, який стане у пригоді в майбутньому.
  • УСПІШНІ ПРОЕКТИ. Коли команда розробників і команда тестувальників не воюють, а, навпаки, допомагають один одному, проект гарантовано буде успішним. Я мала досвід, коли розробники писали локатори спеціально для автоматизаторів, щоб полегшити їм життя. Був випадок співпраці, коли автоматизовані тести писалися ще на машині розробника, щоб після поставки функціоналу відразу протестувати його автотестами.
  • ІНДИВІДУАЛЬНИЙ РОСТ. Всі ростуть, тому що є здорова конкуренція. Обмін ідеями та ухвалені пропозиції дають всім шанс для прогресу.
  • КОМАНДНИЙ РОСТ. У підсумку команда стає сильнішою та компетентнішою завдяки тому, що члени команди розуміють та поважають роботу один одного.

БІЗНЕС-АНАЛІТИКИ

Не на всіх проектах є бізнес-аналітик. Дуже часто його роль виконують інші учасники життєвого циклу розробки ПЗ. Мені довелося порівняти життя на проекті з бізнес-аналітиком і без нього. На одному з них роль бізнес-аналітика виконував Team Lead з боку замовника. Зізнаюся, це було нелегко, адже крім основних задач, він мав приділяти час роботі з вимогами, а часу катастрофічно не вистачало. Тому якість вимог була низькою, про зручність роботи з боку тестувальника я взагалі мовчу.

На наступному проекті мені пощастило попрацювати з Senior BA, і, скажу чесно, спочатку я не розуміла, наскільки мені пощастило. Тільки за кілька місяців я усвідомила, як зручно працювати з бізнес-аналітиком, і виділила наступні плюси:

  • ХОРОШІ ВИМОГИ. User Stories орієнтовані на бізнес, немає залежності з боку розробки — є задача, яку потрібно виконати. А ось як — це вже головний біль розробників.
  • Є НА КОГО СПИХНУТИ. Якщо замовнику щось не сподобалось у функціональності, ви завжди можете сказати, що вона реалізована відповідно до заявлених вимог, і тоді вже бізнес-аналітик пояснює, звідки він взяв такі вимоги.
  • КРАЩЕ РОЗУМІННЯ, можливість обговорити, зважити всі за і проти та ухвалити необхідне рішення на ранній стадії розробки.

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

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

ЗАМОВНИКИ

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

Терпіння. Замовники бувають різними: агресивними, діловими. Цей список можна продовжувати довго, але найважливіше для нас — це терпіти їхні забаганки та не виходити за рамки дозволеного.

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

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

Інформативність. Замовник має бачити, що робота виконується, тому намагайтеся максимально візуалізувати процес. Одного разу я прийшла на проект, на якому не було звітів про тестування. Коли я запропонувала надсилати їх замовнику, моя команда тестувальників сказала, що це марна трата часу, а замовник нам і так довіряє. Я не послухала хлопців, зробила звіт і надіслала його. На мій подив, замовник не просто був у захваті, він роздрукував звіт і на загальному зідзвоні сказав, що це круто і йому дуже подобається.

Активне слухання. Я маю таке правило: завжди більше слухати, ніж говорити. Нехай навіть ви говорите про погоду, але інтерес маєте проявляти ви, а не замовник.

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

Не викладайте компромат на себе в соціальних мережах. Зі мною трапився кумедний випадок. Я погано почувалась і взяла лікарняний на день, але ввечері мала виступ на конференції. Думаю, підлікуюсь до вечора, щоб виступити добре. Але організатори виклали в соцмережі історію про мій виступ, і наступного дня я отримала догану від PM, що так робити не можна. Замовник подумав, що я всіх обманула і насправді не хворіла. Тож соцмережі — це компромат на вас. Якщо ви не викладаєте компрометуючі фото, то переконайтесь, що цього також не роблять ваші друзі та колеги.

Все вищесказане може принести вам і вашій команді такі плюси:

  • довіру і повагу замовника;
  • премії та зростання заробітної плати;
  • відповідальність і незалежність.

ВИСНОВОК

Сучасний світ, по суті, сформулював одне з ключових правил: щоб бути успішним фахівцем, недостатньо лише глибоких знань і трудового досвіду, потрібно ще щось, чого толком не вчать у школах. Це soft skills.

Треба відзначити, що soft skills можна й потрібно розвивати, причому починаючи зі шкільної лави. Мій син недавно закінчив перший клас, і однією з основних цілей його навчання було не вивчення математики або читання, а навчитися спілкуватися з іншими дітьми, бути командою. Адже математика — наука точна, її можна вивчити, а ось адаптувати дитину до соціуму, розвинути лідерські якості — це задача складна, вона вимагає особливих зусиль.

Розвивайте soft skills, рухайтеся кар'єрними сходами вгору, цінуйте свій час і час інших.

  • Україна, Дніпро; Україна, Київ; Україна, Львів; Україна, Одеса; Україна, Харків; Україна, Херсон
    3 грудня