Співробітництво розробника і тестувальника

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

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

• протиставлення розробниками тестування своїй роботі – частіше за все девелопери надто «опікають» створений ними продукт, вони болісно сприймать дефекти у ньому відносно себе;
• «тестування заради тестування» – велика частина тестувальників надо вузько дивляться на специфіку професії та вважають за свою головну мету «ламати» продукт;
• несприйняття важливості тестування – частина розробників не вважають, що тестування є загальноприйнятою, важливою та доцільною професією, тому дещо зневажливо ставляться до тестерів;
• проблеми менеджменту – посередництво проджект-менеджерів може, окрім очевидних позитивних результатів, при неналежному підході давати негативні наслідки у вигляді конфронтації.

Окрім того, часто проблемою взаємодії розробників та тестувальників є наявність упереджень. Особливо це стосується спеціалістів із досвідом. Суть подібних ситуацій у тому, що спеціаліст (чи то тестер, чи девелопер) упереджено ставиться до другої сторони співпраці через свою призму поглядів, досвіду і сприйняття. У науці це носить назву когнітивних упереджень.

Серед найбільш популярних айтішних когнітивних упереджень можна виділити: 

• фреймінг – часто повторюваний один і той же сценарій у роботі може замилювати око і не давати розгледіти інші аспекти. Як тестувальник може не бачити дефектів в роботі за звичним сценарієм тестів, так і девелопер може не розгледіти проблем у коді, в сотий раз перечитуючи рідні рядки;
• ретроспективне упередження – ситуація, в якій факти і події «підганяються» під вже існуючу думку чи погляд. Якщо розробник вважає, що тестер просто намагається «зламати» його код, то кожен баг чи дефект вважатиме не що іншим, як такою собі «спробою замаху на вбивство» ідеального з його точки зору продукту;
• ефект прилучення до більшості – це перевага думки більшості над власною. Якщо майже вся команда проєкту вважає, що на формі не має бути інлайн-валідації, а тестувальник розуміє, що вона обов’язкова, то часто думка більшості подавлює думку одного, навіть якщо ця єдина думка більш правильна;
• ефект негативу розкривається у критичному ставленні до усіх моментів роботи. Чи то тестувальник бачить на кожній сторінці сайту купу багів, чи розробник вважає, що усі намагаються доскіпуватися до його роботи – так чи інакше надто негативний погляд погано впливає на взаємини;
• утрачена вартість – спроби довести, що витрачені зусилля варті результату. Наприклад, якщо тестувальник цілий день тестував продукт і не знайшов жодного багу, то намагатиметься знайти хоч якийсь дефект, аби лише не було відчуття, що час витрачено дарма.

З розумінням можливих причин та нюансів виникнення конфронтації, виділимо поради щодо уникнення, зниження та передбачення конфліктності стосунків між розробниками і тестувальниками.

Для тестувальників:

• варто пам'ятати, що тестери шукають дефекти у продукті розробки, а не у розробнику. Слід об'єктивно і безкомпромісно оцінювати роботу девелопера без прив'язки до особистості чи якостей;
• діліться своєю стратегією з розробниками, не тримайте в голові ключові моменти тестування чи дефектні місця, з думкою, що пізніше ви позначите це як проблему – комунікуйте з розробкою;
• спробуйте побудувати дружні стосунки з розробниками, щоб кожному було комфортно ділитися думками чи порадами. Здорові робочі стосунки – запорука успіху співпраці;
• зберігайте позитивний стиль повідомлення про проблему, це не повинно зачепити чиїсь почуття чи виказувати явне невдоволення роботою девелопера;
• уникайте ситуацій, в яких ви створюєте баг-репорт лише через те, що ви не до кінця розібралися у функціоналі. Вивчайте специфікацію та іншу наявну документацію, запитуйте у менеджерів/розробників у разі сумнівів;
• в обговореннях дефекту спробуйте представляти проблему у вигляді неузгодженості робочого процесу як точку зору користувача, а не як дефект розробки. Замість того, щоб говорити, що це дефект, запитайте: якщо користувач зробить це, він отримає ось це, чи не суперечливим/некоректним результатом це є? Перенесення фокусу на кінцевого споживача є певною мірою пом’якшенням градусу обговорення суперечливих моментів.

Для розробників: 

• не варто сприймати дефекти у власному коді як сумнів у вашій професійності. Спроможність визнати і виправити помилку набагато важливіша від самої помилки;
• необхідно пам'ятати, що тестування – це не конфронт розробці, а допоміжний важіль на шляху досягнення ідеального продукту, щит від звинувачень у наявних дефектах. Слід розуміти, що тестери мають на меті не принизити розробку чи її продукти, а навпаки,  покращити кінцевий результат, від чого виграють усі;
• коли QA просить мітинг, варто за найменшої можливості все ж знайти час для короткого обговорення; тестер, який шукає відповіді, – це баг, вирішений до того, як він виник;
• тестувальники можуть поставити будь-які різні або нестандартні запитання. На ці питання слід відповідати без будь-якої агресії, щоб не викликати у нього відчуття провини за те, що він підняв питання;
• перед тим, як стверджувати, що «це не баг, а фіча», впевніться, що це дійсно так, а не ваша лінь/гординя/зверхність не бажає більш детально вивчити ситуацію чи виправити знайдений дефект.

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

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

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