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

Що робити в такій ситуації, щоб не сперечатися з колегами, а залишитися при своєму?

Прикрий спину

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

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

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

Проблеми з програмним забезпеченням - це не лише проблеми тестувальників

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

В ідеалі, хтось вищий за вас повинен впливати на розробників, щоб вони могли внести необхідні вам корективи. Це має бути завданням вашого прем’єр-міністра, а не вашим!

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

Усі зміни мають бути безпечними

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

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

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

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

Ця проблема не обов’язково має бути вашою

У більшості випадків у тестувальників виникає проблема, яка потребує негайного вирішення. І відділ розробки тут буде вкрай корисним. Але це неправильно!

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