Давайте почнемо з розгляду завдань – хто за що відповідає?

Розробник відповідає за реалізацію "Технічного завдання": опрацювати код, додати новий функціонал, перевірити як він працюватиме на рівні Unit тестів або перевірити прямий кейс. Після цього код відправляється на ревью, а потім він передається у тестування. Тобто розробник творить "своє дітище", і при цьому може не помітити якихось неточностей. Тестувальник відповідає за відповідність прямим та непрямим вимогам. Наприклад, неявні на перший погляд кейси, які не враховані у постановці завдання чи втрачені. Для непрямих кейсів можна звернутися до Бізнес-аналітика, свого Тім Ліда, або до Замовника для уточнення. Потім тестувальник починає “промацувати” нове доопрацювання відповідно до вимог, і намагатися зламати те, що було створено програмістом, щоб знайти недоліки, які можуть вплинути на роботу системи. Таким чином, тестувальник перетворюється на "руйнівника", адже важливо передбачити, що саме користувач може "зламати" при використанні продукту.

Чому краще не виходити за межі своїх обов'язків?

Розробники можуть бути хорошими тестувальниками і навпаки лише у тому випадку, коли вони виконують свою роль як тестувальники (або, відповідно, розробники). Для виконання тієї чи іншої ролі, необхідно знати та вміти застосовувати конкретні Soft та Hard скіли. Наприклад: щоб розробник міг добре протестувати, йому необхідно розібратися з теорією тестування, методиками тестування, техніками тест дизайну та навчитися грамотно складати тестову документацію. Також потрібно вміти використовувати різні тули для тестування. І навпаки - щоб тестувальник міг добре програмувати, потрібно вивчити ООП (об'єктно-орієнтоване програмування), навчитися його застосовувати на практиці і заглибитися в мову, якою ведеться розробка. Загвоздка у підході до виконання завдання та пріоритетності напрямів. Уявіть - розробнику потрібно не тільки реалізувати поставлене завдання згідно з вимогами, але й передбачити, що і де може піти не так. Таким чином, час спочатку йде на розробку, а після цього - на тестування. Важливо пам'ятати, що розробляючи самому, набагато складніше помітити недоліки. До того ж, розробник дивиться на код з боку поставлених вимог, і для якісного тестування йому доведеться перемикатися на логіку і мислення тестувальника або користувача. Ще одна проблема такого флоу – довга реалізація проєкту. Частина функціоналу розроблена, тестується, а наступна частина чекає на свою чергу. Таким чином, розробник, що виконує роботу тестувальника, стає боттлнеком. Це веде до великої затримки поставки як усього проекту, так і окремих доопрацювань чи виправлень знайдених дефектів. Це все виливається у відставання від початкових термінів, збільшення бюджету та проблеми з реалізацією та постачанням продукту замовнику. Завдяки поділу завдань, розробка суттєво прискориться та підвищиться якість продукту. Так як кожен відповідає за свій шматок роботи, фахівцям не потрібно розриватися і змінювати тип роботи і погляд на той самий код.