Імпонує думка Сергія про те, що тестувальники не мають заходити в межі компетентності розробників і перевіряти, як працює код. Якщо ми знаємо і рухаємось в одному потоці розробки з командою, то важче знайти баг, який буде на проді. Бо в нас думки вже збігаються. Можливо з досвідом - цього вже не трапляється, але як джуну - коли мені дають готовий продукт без залучення до команди розробки - після тестування всередині команди - дуже легко та швидко знаходяться нетривіальні баги, лише тому, що ти починаєш з дослідження і йдеш від користувача. Цікаво подивитись статистику такої метрики - коли в команду приходить новий QA, то який відсоток знайдених ним помилок, непоміченних QА, залученими з початку розробки проєкту? згадала, що нам на курсах розповідали про ступені незалежності тестування. Зараз в таку гонитву за hard skills загрались компанії, що з повним залученням вони не помітять, як зітруть ту грань, яка найцінніша для manual)) але це моя суб'єктивна думка, з маленьким досвідом (6 різних команд)
Багато новачків можуть сприйняти слова Сергія неправильно, бо багато з них дуже погано знають комп'ютер, як такий, і погано знають програми та відповідно погнано розуміють реальні дії користувача, видаючи за них свою власну поведінку. Варто звернути увагу, що водночас Сергій каже, що клієнт-сервер треба розуміти нормально, а це вже зовсім не про "звичайного користувача". Виходить так, що Сергію важлива поведінка тестувальника "а-ля користувач", але при цьому тестувальник має непогано розуміти певні технічні особливості продукту. Також хочеться зауважити, що коли мова про фронтенд, то не так часто потрібно копати до root cause, часто достатньо просто вказати кроки для відтворення. Але коли мова про логіку на бекенді, інтеграції, то це вже не спрацює. Тобто, зауважте, що Сергій фронтенд розробник, не бекенд, а ми зазвичай тестуємо все. І щоб гарно зробити свою роботу, нам потрібен той root cause хоча б тому, щоб ми зробили правильний ретест. Якщо ж казати про фронтенд, то тут технічні знання дозволять нам зрозуміти можливі affected areas, що можуть виникати при реалізації фічі чи фіксі, що також дозволить нам професійно виконувати свою роботу. Тому такий акцент на "нетехнічному" тестувальнику є небезпечним.
![Биология поведения человека. Лекция #1. Введение [Роберт Сапольски, 2010. Стэнфорд]](/img/n.gif)
Дякую за чудовий контент! 👏👏👏
Дякую !
Дякую за зустріч. Прям захотілось на співбесіду)
Імпонує думка Сергія про те, що тестувальники не мають заходити в межі компетентності розробників і перевіряти, як працює код. Якщо ми знаємо і рухаємось в одному потоці розробки з командою, то важче знайти баг, який буде на проді. Бо в нас думки вже збігаються. Можливо з досвідом - цього вже не трапляється, але як джуну - коли мені дають готовий продукт без залучення до команди розробки - після тестування всередині команди - дуже легко та швидко знаходяться нетривіальні баги, лише тому, що ти починаєш з дослідження і йдеш від користувача. Цікаво подивитись статистику такої метрики - коли в команду приходить новий QA, то який відсоток знайдених ним помилок, непоміченних QА, залученими з початку розробки проєкту? згадала, що нам на курсах розповідали про ступені незалежності тестування. Зараз в таку гонитву за hard skills загрались компанії, що з повним залученням вони не помітять, як зітруть ту грань, яка найцінніша для manual)) але це моя суб'єктивна думка, з маленьким досвідом (6 різних команд)
Багато новачків можуть сприйняти слова Сергія неправильно, бо багато з них дуже погано знають комп'ютер, як такий, і погано знають програми та відповідно погнано розуміють реальні дії користувача, видаючи за них свою власну поведінку. Варто звернути увагу, що водночас Сергій каже, що клієнт-сервер треба розуміти нормально, а це вже зовсім не про "звичайного користувача". Виходить так, що Сергію важлива поведінка тестувальника "а-ля користувач", але при цьому тестувальник має непогано розуміти певні технічні особливості продукту.
Також хочеться зауважити, що коли мова про фронтенд, то не так часто потрібно копати до root cause, часто достатньо просто вказати кроки для відтворення. Але коли мова про логіку на бекенді, інтеграції, то це вже не спрацює. Тобто, зауважте, що Сергій фронтенд розробник, не бекенд, а ми зазвичай тестуємо все. І щоб гарно зробити свою роботу, нам потрібен той root cause хоча б тому, щоб ми зробили правильний ретест. Якщо ж казати про фронтенд, то тут технічні знання дозволять нам зрозуміти можливі affected areas, що можуть виникати при реалізації фічі чи фіксі, що також дозволить нам професійно виконувати свою роботу.
Тому такий акцент на "нетехнічному" тестувальнику є небезпечним.