Тестер-розробник спілкування

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

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

Якісь поради чи дослідження щодо того, як тестер повинен спілкуватися з розробниками?

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

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

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

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

Навпаки цього, багато організацій люблять займатися розробкою, розміщуючи всіх тестерів (і DBA, і дизайнерів, і програмістів) в окремих підрозділах. Це протидіє комунікації і слугує лише закріпленню ідеї поетапного розвитку. Спробуйте покращити спілкування в такій ситуації можливо, але незначні покращення, які ви можете очікувати, не вартують зусиль. Принаймні, не порівняно з тим, як насправді розміщувати людей у ​​одній кімнаті та створювати крос-функціональні команди.

Я твердо вірую у будь-який вид спілкування між розробником та тестом.

Занадто багато разів я бачив битву між двома командами, дрібну туди-сюди ("закрита дизайном", а потім "знову відкрита" тощо).

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

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

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

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

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

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

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

Скористайтеся своїми щоденними зустрічами з stand-up. Будьте максимально залучені до участі; не тільки з тестуванням, але з продуктом у повному обсязі. Зрештою, розробник та тестер працюють над однією метою і завжди повинні тримати це у фокусі.

Я вважаю за краще бачити тестерів частиною однієї команди. У зв'язку з цим немає питання комунікації.

Щоразу, коли тестувальник повинен поговорити з розробником або навпаки, просто приходьте і давайте поспілкуватися. Просто рутина щоденних.

Однак обидві сторони повинні поважати один одного і виконувати свою роботу належним чином.

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

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

Професійне ставлення - це все, що потрібно.

Інструмент № 1, за яким я виявив, що я, як тестер (SDET), можу використати для поліпшення взаємозв'язків тестування розробників, - це чесне лестощі, особливо у формі пошуку наставництва від розробників.

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

Надання позитивних відгуків про якість, а також негативних відгуків та прохання про допомогу змінює стосунки від суперечливих до роботи в команді та взаємного навчання та знижує захисність. Розробники знають, що вони можуть мені довіряти завжди говорити більше добрих, ніж поганих, тому їм комфортно слухати мене. Крім того, задаючи глибокі запитання щодо розвитку, викликає їх думку про мене і пробиває стереотип "СДЕТ - це невдалі дияволи" (де він все ще існує).

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

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