Іноді на спеціалізованих ІТ-форумах можна зустріти таке питання: яке співвідношення між тестувальниками та розробниками є найкращим?

Відповідь на це питання залежить від контексту.

Хороше співвідношення між QA-інженерами та командами розробників визначається бальними коефіцієнтами.

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

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

Далі ми детально проаналізуємо деякі з них.

Варіант 1: співвідношення 1:1

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

Тандем розробник-тестувальник може легко працювати разом над випуском нової функції, а оскільки вони націлені на спільну роботу, то мають високі шанси знайти і виправити всі можливі дефекти.

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

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

Варіант 2: 2 розробники та 1 тестувальник

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

Тестувальник відповідає за тестування інтеграції фронт-офісу та бек-офісу.

Ця трійця буде експертами у цій сфері - так само, як і у варіанті 1:1. Але іноді така стратегія може призвести до дисоціації, коли новому члену команди буде важко допомогти.

Варіант 3: 2 тестувальники та група розробників

Це дуже популярна справа.

Команда із забезпечення якості розподілила роботу відповідно до своїх навичок та навантаження.

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

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

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

Варіант 4: 1 тестувальник і група розробників

У цьому випадку тестувальник стає певним чином інструктором із забезпечення якості.

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

Він/вона керує розумінням розробниками того, що має бути просто протестовано, а що має бути автоматизовано.

У цьому випадку за якість продукції відповідає ціла команда.

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

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

Висновок

Кожне співвідношення має певні переваги, але вони також мають багато спільного.

По-перше, один з членів команди є досить хорошим тестувальником.

Такі навички допоможуть їм шукати дефекти, які важко знайти, та фіксувати їх.

По-друге, вам не обійтися без професійних комунікативних навичок.

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