Дійсно … яка між ними суттєва різниця? … а ким я зможу стати, коли навчуся тестувати, отримаю практичний досвід? … під яку лінійку мені мірятися зі своїми skill –ами? …що мені потрібно зробити аби стрибнути на позицію вище? …як мені розрізнити, відчути, що я професійно виріс, не тільки у своїх очах, але й очах колег, HR –ів, роботодавців?

     Ми знаємо, як багато запитань виникає у людини, яка щойно розпочала чи планує розпочати кар’єру тестувальника. І як багато різноманітних відповідей у мережі інтернет — теж знаємо. Як правильно й  по–суті розібратися людині, зовсім не дотичній до ІТ? Що ж — пробуємо прояснити 💡 

Популярна на сайтах роботи градація, на яку орієнтується більшість, виглядає так:

0,5 — 2 років комерційного досвіду = Junior QA
1 — 4 роки = протягом цього часу приліплюється звання мідла, тобто Middle QA engineer
3 — 6 років = маєте шанс називатися Senior QA engineer

      Проте по факту це просто гігантське спрощення. Реальність така, що ніхто на усі 100% не підходить до окреслених рамок.

     Спроба оцінити людей часовими інтервалами — це занадто спрощений спосіб для таких тонких матерій, як знання та професійний досвід. Бо є суттєва різниця між людиною з 4 –х річним досвідом «протирання штанців», і людиною, що за цей самий проміжок часу стала професійнішою і досвідченішою у 10 разів.

      Уявляєте? Бувають, тест–інженери з 4 –х річним досвідом «сидять» на рівні, не дотягуючи до Міддла!  На превеликий жаль, це далеко не завжди тільки їх провина… Постійно прості задачі, хаос і повний творчий безлад у тестовій документації, погана якість коду автоматизаторів — у деяких компаніях спокійно прищеплюються початківцям, як норма… І у разі, якщо у певний момент людина сама цього не усвідомить, й не намагатиметься перевчитися — все закінчиться сумно при зміні роботи або коли такого “Senior -а” поставлять на керівну посаду на відповідальному для компанії проекті. Зазначу, перевчатися «на правильно» — це означає витратити майже стільки ж часу, скільки на навчання.

      Тотожно, бувають і ті, хто, згідно градації у 2 роки досвіду обганяє за якістю знань хороших сеньйорів з 6 -ним досвідом у тестуванні програмного забезпечення. Отже, все вимірюється здебільшого не роками, а знаннями.

ПАМ’ЯТАЙТЕ: все індивідуально!

      В деяких компаніях ще виділяють позицію Trainee, коли у ін. одразу стартують з позиції Джуніорів. Також у деяких компаніях є позиції QA Lead, QA manager.

     Окей, питання досі залишається відкритим, так як все–таки оцінити, якщо все індивідуально та відносно? Давайте продовжувати розбиратися, Junior QA, Middle QA engineer, Senior QA engineer — яка між ними різниця? Чому існує такий поділ?

Джуніор QA — отримує конкретні завдання, має право перепитувати, просити допомоги у виконанні певних завдань в інших колег, працює над простішими завданнями, складні завдання Junior -у не під силу, хіба витратить цілий місяць, але таке нікому не треба. Виконану роботу Junior QA завжди перевіряють.

Мідл QA — має всі необхідні базові знання, працює самостійно і оперативно над складнішими завданнями, може займатися менторством, допомагати джуніорам у своїй команді. Але при виникненні сумнівів, при виконанні складніших завдань, розставлені пріоритетів може радитись з Лідом або іншими колегами.

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

Сіньйор QA — працює самостійно над складними завданнями, допомагає у роботі молодшим колегам, самостійно оцінює ситуацію, розставляє пріоритети виконання завдань, планує і делегує їхнє виконання. До сіньйора прислухаються. Він здатен свої позиції аргументовано відстоювати.

QA Lead & QA manager — це рівень дійсно «експертності». QA Lead, QA manager впевнено керує командою тестерів інколи й розробників, серед яких далеко не всім завжди потрібна допомога чи вказівки. Приймають участь у реально складних завданнях: участь в pre-sales, вибір стеку технологій, архітектури, підбір команди, довгострокове планування, оцінка ризиків. Час, думки, ідеї по оптимізації роботи таких спеціалістів на вагу золота — у них чітке стратегічне розуміння SDLC (Software Development Life Cycle).

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

      В ІТ прийнято цінувати розумних молодих людей після університету. Ця енергійна молодь дійсно цінна і інколи необхідна, але не більше, ніж їх колеги з 15–20 роками “польового” досвіду.

      Окрім того, слід звернути увагу, що деякі роботодавці у ІТ не наймають собі працівників стереотипно. Погляд більше спрямований на досягнення соціального балансу у команді шляхом поєднати сумісність талантів кожного учасника. Вважається якщо усі в команді будуть думати однаково — це не принесе користі проекту і компанії. Скіли можуть бути не тільки технічними, але і можуть взагалі ніяк не зачіпати QA / Dev 🙂