[highlight dark=”no”]Досвід приходить разом із розумінням того, що слід чи не слід робити.[/highlight]

Це правило може бути застосоване до всіх типів трудових відносин.

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

Чого не варто говорити розробникам

Не турбуйте їх через дрібниці

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

Не соромно просити про допомогу

Ми не можемо знати всього.

Добре і навіть правильно запитувати про щось, щоб дізнатися більше інформації.

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

Головний девіз продуктової команди: “Ми всі в одному човні, і це чудово, якщо у кожного є весло”.

Такі слова допомагають йти в одному напрямку.

Перше правило для QA-інженерів: не варто довіряти словам розробника

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

Ніякого мікроменеджменту

Неправильно говорити розробнику, що він повинен тестувати баг, коли ви цього забажаєте.

Це лише змушує їх нервувати і навіть може значно збільшити час, необхідний для вирішення проблеми.

Такі коментарі не допоможуть.

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

Що ви можете обговорити з розробниками

Постійно обмінюйтеся даними з розробниками

Обговоріть з ними свої методи та основи тестування, а також знайдіть “ключ доступу” до кожного розробника, з яким ви взаємодієте або будете взаємодіяти.

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

Ця стратегія допоможе вам уникнути численних дефектів у програмному коді.

Але це також може бути складним завданням з наступних причин:

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

Будьте готові захистити помилки, про які ви повідомляєте

Іноді тестувальникам потрібно довести, що помилки, які потрібно виправити, є критичними.

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

Правильна підготовка фактів і вміння дивитися на кілька кроків вперед допомагають заощадити гроші, які витрачає ваша компанія.

Намагайтеся чітко описувати помилки

Намагайтеся використовувати слова розробників.

В іншому випадку, намагайтеся писати повідомлення про вади якомога зрозуміліше.

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

Логічно припустити, що група тестувальників миттєво почне тестувати ту частину програмного забезпечення, яка містить проблему.

І, нарешті, терпіння і тільки терпіння

Спробуйте знайти спільну мову з проблемними і трохи егоїстичними розробниками.

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