Розробка
Розробник
П’ять рівнів від Junior до Principal і шість компетенцій — від розробки й випуску до розвитку команди.
- 5 рівнів
- 6 компетенцій
Шаблон кар’єрної драбини
Грейди QA-інженера: шаблон кар’єрної драбини
Чотири рівні від Junior QA до Lead QA і шість компетенцій — від тест-дизайну до практик якості в команді.
Безкоштовний тариф · Банківська картка не потрібна
Цю кар’єрну драбину написано для QA-інженерів у компаніях приблизно на 20–200 людей: тестувальники працюють усередині продуктових команд, на всю компанію їх може бути лише кілька, і та сама людина вранці проводить дослідницьке тестування, а після обіду пише автотести. Вона описує чотири рівні — від людини, яка вчиться добре тестувати одну фічу, до того, хто визначає підхід до якості в усій компанії. Найвищий рівень, Lead QA-інженер, — експертний, а не управлінський.
Кожен рівень описано через те, що людина робить і наскільки далеко сягає її робота, а не через стаж чи кількість заведених багів. Читайте рядок матриці компетенцій зліва направо, щоб побачити, як зростає одне очікування, або розділ рівня — щоб побачити все, що на ньому очікується. З її допомогою зручно пояснювати, що означає наступний крок, проводити самооцінку й чек-іни та порівнювати кандидатів на підвищення між командами.
Сприймайте її як чернетку. Якщо ваші QA-інженери не пишуть автотестів або більшу частину тестування беруть на себе розробники, змініть формулювання до публікації: очікування, яке у ваших умовах неможливо виконати, лише розчаровує.
Рівні коротко
Junior QA-інженер
Тестує чітко описані фічі за готовими тест-кейсами й вивчає продукт та його користувачів.
- Масштаб
- Окремі історії або виправлення багів в одній частині продукту; тест-плани перевіряє хтось досвідченіший.
Middle QA-інженер
Відповідає за тестування фіч однієї команди — від розбору вимог до рішення про реліз.
- Масштаб
- Фічі однієї продуктової команди разом із їхніми ручними й автоматичними тестами.
Senior QA-інженер
Визначає, як одна–дві команди вбудовують якість у роботу, і відповідає за стратегію тестування великих проєктів.
- Масштаб
- Стратегія тестування, набори автотестів і рішення про релізи однієї–двох команд, а також проєкти на стику команд.
Lead QA-інженер
Задає підхід компанії до якості й допомагає кожній команді випускати продукт із меншою кількістю пропущених дефектів.
- Масштаб
- Якість усього продукту: спільна тестова інфраструктура, стандарти релізів і те, як влаштована й працює функція QA.
Матриця компетенцій
Рядки — компетенції, стовпці — рівні. Читайте рядок зліва направо, щоб побачити, як зростають очікування.
Що означає кожна компетенція
- Тест-дизайн і аналіз
- Розуміти, що може піти не так, і обирати тести, які це знайдуть.
- Автоматизація тестування
- Будувати швидкі й стабільні автотести, яким команда довіряє.
- Пошук і опис дефектів
- Знаходити, відтворювати й пояснювати проблеми так, щоб їх швидко виправляли.
- Рішення про реліз і оцінка ризиків
- Вирішувати, чи готове щось до випуску, і чітко про це говорити.
- Практики якості
- Вбудовувати якість у те, як працює команда, а не перевіряти її лише наприкінці.
- Менторство та обмін знаннями
- Допомагати іншим тестувати краще й не давати знанням про продукт жити в одній голові.
| Компетенція | Junior QA-інженер | Middle QA-інженер | Senior QA-інженер | Lead QA-інженер |
|---|---|---|---|---|
| Тест-дизайн і аналіз | Уважно проходить готові тест-кейси, пише нові для невеликих історій з основним сценарієм і очевидними граничними випадками та ще до початку тестування уточнює незрозумілі вимоги. | Пише тест-план для кожної фічі команди з граничними випадками, правами доступу, станами даних та інтеграціями й ще до початку розробки шукає прогалини у вимогах. | Розробляє стратегію тестування проєктів, що зачіпають кілька фіч або команд, вирішує, що покривати на рівні unit-, API- та end-to-end-тестів, і зосереджує зусилля на тому, що найімовірніше зламається. | Визначає, як компанія вирішує, що й наскільки глибоко тестувати, спираючись на ризики й дані про використання, і стежить, щоб усі команди застосовували цей підхід однаково. |
| Автоматизація тестування | Додає автотести в наявний фреймворк за усталеними зразками, запускає набір локально й повідомляє про незрозумілі падіння, а не перезапускає тести, доки вони не позеленіють. | Автоматизує регресійні тести для фіч команди, підтримує їх стабільними й читабельними та виправляє або видаляє нестабільні тести, а не ігнорує їх. | Проєктує структуру набору автотестів, вбудовує його в CI/CD-пайплайн із розумним часом прогону й рецензує тести, які пишуть розробники та інші QA-інженери. | Обирає інструменти тестування й спільну інфраструктуру компанії, балансує рівні піраміди тестування в усіх продуктах і тримає весь набір достатньо швидким, щоб команди справді чекали на результат. |
| Пошук і опис дефектів | Заводить баг-репорти зі зрозумілими кроками, очікуваним і фактичним результатом та оточенням, щоб розробник міг відтворити проблему без уточнювальних запитань. | Локалізує баги за логами, мережевими запитами й даними в базі, оцінює їхню критичність за впливом на користувачів і перевіряє виправлення разом із суміжними сценаріями. | Розслідує плаваючі проблеми й ті, що відтворюються лише на продакшені, на стику сервісів, помічає закономірності в повторюваних дефектах і перетворює їх на пропозиції, які усувають цілий клас багів. | Відповідає за те, як компанія обліковує й пріоритизує дефекти, звітує керівництву розробки про динаміку пропущених багів і домагається, щоб на усунення головних джерел дефектів виділяли ресурси. |
| Рішення про реліз і оцінка ризиків | Виконує призначені перевірки перед релізом, повідомляє, що було протестовано, а що ні, і висловлює сумніви досвідченішому QA-інженерові. | Дає чітку рекомендацію «випускаємо» чи «не випускаємо» щодо релізів команди, пояснюючи відомі ризики й те, що залишилося неперевіреним, і бере участь у перевірках після релізу. | Разом із розробниками обирає спосіб випуску ризикованих змін — фіче-флаги, поетапне розгортання, додатковий моніторинг — і керує тестуванням під час інцидентів і хотфіксів. | Задає стандарти релізів для всіх команд, визначає, коли реліз можна зупинити, і саме до нього керівництво приходить із питанням, чи готовий продукт до великого запуску. |
| Практики якості | Дотримується прийнятого в команді визначення готовності й процесу тестування та повідомляє про кроки, які пропускають або які незрозумілі. | Долучається до грумінгу й обговорення рішень, щоб заздалегідь додати критерії приймання та питання тестованості, і разом із розробниками вирішує, що їм покрити власними тестами. | Покращує процес тестування однієї–двох команд — тестові оточення, тестові дані, чек-листи рев’ю — і вимірює, чи стало менше пропущених дефектів. | Формує практики якості в усій розробці, вирішує, де працюють QA-інженери і за що відповідають розробники, і робить якість спільною відповідальністю, а не завданням однієї команди. |
| Менторство та обмін знаннями | Записує те, що дізнається про продукт під час тестування, і ділиться з командою корисними знахідками та інструментами. | Підтримує тестову документацію команди в актуальному стані, вводить нових колег у свою частину продукту й пояснює техніки тестування розробникам, які про це просять. | Цілеспрямовано менторить junior QA-інженерів, проводить для розробників сесії про підходи до тестування й бере участь у співбесідах на позиції QA. | Розвиває навички й кар’єрні шляхи в QA-групі, визначає, як наймають і онбордять QA-інженерів, і вирощує наступних senior- та lead-інженерів. |
Прокрутіть таблицю вбік, щоб побачити всі рівні.
Завантажити CSV Відкривається в Excel, Google Таблицях і Numbers.
Junior QA-інженер: що очікується
Тестує чітко описані фічі за готовими тест-кейсами й вивчає продукт та його користувачів. Окремі історії або виправлення багів в одній частині продукту; тест-плани перевіряє хтось досвідченіший.
- Тест-дизайн і аналіз
- Уважно проходить готові тест-кейси, пише нові для невеликих історій з основним сценарієм і очевидними граничними випадками та ще до початку тестування уточнює незрозумілі вимоги.
- Автоматизація тестування
- Додає автотести в наявний фреймворк за усталеними зразками, запускає набір локально й повідомляє про незрозумілі падіння, а не перезапускає тести, доки вони не позеленіють.
- Пошук і опис дефектів
- Заводить баг-репорти зі зрозумілими кроками, очікуваним і фактичним результатом та оточенням, щоб розробник міг відтворити проблему без уточнювальних запитань.
- Рішення про реліз і оцінка ризиків
- Виконує призначені перевірки перед релізом, повідомляє, що було протестовано, а що ні, і висловлює сумніви досвідченішому QA-інженерові.
- Практики якості
- Дотримується прийнятого в команді визначення готовності й процесу тестування та повідомляє про кроки, які пропускають або які незрозумілі.
- Менторство та обмін знаннями
- Записує те, що дізнається про продукт під час тестування, і ділиться з командою корисними знахідками та інструментами.
Middle QA-інженер: що очікується
Відповідає за тестування фіч однієї команди — від розбору вимог до рішення про реліз. Фічі однієї продуктової команди разом із їхніми ручними й автоматичними тестами.
- Тест-дизайн і аналіз
- Пише тест-план для кожної фічі команди з граничними випадками, правами доступу, станами даних та інтеграціями й ще до початку розробки шукає прогалини у вимогах.
- Автоматизація тестування
- Автоматизує регресійні тести для фіч команди, підтримує їх стабільними й читабельними та виправляє або видаляє нестабільні тести, а не ігнорує їх.
- Пошук і опис дефектів
- Локалізує баги за логами, мережевими запитами й даними в базі, оцінює їхню критичність за впливом на користувачів і перевіряє виправлення разом із суміжними сценаріями.
- Рішення про реліз і оцінка ризиків
- Дає чітку рекомендацію «випускаємо» чи «не випускаємо» щодо релізів команди, пояснюючи відомі ризики й те, що залишилося неперевіреним, і бере участь у перевірках після релізу.
- Практики якості
- Долучається до грумінгу й обговорення рішень, щоб заздалегідь додати критерії приймання та питання тестованості, і разом із розробниками вирішує, що їм покрити власними тестами.
- Менторство та обмін знаннями
- Підтримує тестову документацію команди в актуальному стані, вводить нових колег у свою частину продукту й пояснює техніки тестування розробникам, які про це просять.
Senior QA-інженер: що очікується
Визначає, як одна–дві команди вбудовують якість у роботу, і відповідає за стратегію тестування великих проєктів. Стратегія тестування, набори автотестів і рішення про релізи однієї–двох команд, а також проєкти на стику команд.
- Тест-дизайн і аналіз
- Розробляє стратегію тестування проєктів, що зачіпають кілька фіч або команд, вирішує, що покривати на рівні unit-, API- та end-to-end-тестів, і зосереджує зусилля на тому, що найімовірніше зламається.
- Автоматизація тестування
- Проєктує структуру набору автотестів, вбудовує його в CI/CD-пайплайн із розумним часом прогону й рецензує тести, які пишуть розробники та інші QA-інженери.
- Пошук і опис дефектів
- Розслідує плаваючі проблеми й ті, що відтворюються лише на продакшені, на стику сервісів, помічає закономірності в повторюваних дефектах і перетворює їх на пропозиції, які усувають цілий клас багів.
- Рішення про реліз і оцінка ризиків
- Разом із розробниками обирає спосіб випуску ризикованих змін — фіче-флаги, поетапне розгортання, додатковий моніторинг — і керує тестуванням під час інцидентів і хотфіксів.
- Практики якості
- Покращує процес тестування однієї–двох команд — тестові оточення, тестові дані, чек-листи рев’ю — і вимірює, чи стало менше пропущених дефектів.
- Менторство та обмін знаннями
- Цілеспрямовано менторить junior QA-інженерів, проводить для розробників сесії про підходи до тестування й бере участь у співбесідах на позиції QA.
Lead QA-інженер: що очікується
Задає підхід компанії до якості й допомагає кожній команді випускати продукт із меншою кількістю пропущених дефектів. Якість усього продукту: спільна тестова інфраструктура, стандарти релізів і те, як влаштована й працює функція QA.
- Тест-дизайн і аналіз
- Визначає, як компанія вирішує, що й наскільки глибоко тестувати, спираючись на ризики й дані про використання, і стежить, щоб усі команди застосовували цей підхід однаково.
- Автоматизація тестування
- Обирає інструменти тестування й спільну інфраструктуру компанії, балансує рівні піраміди тестування в усіх продуктах і тримає весь набір достатньо швидким, щоб команди справді чекали на результат.
- Пошук і опис дефектів
- Відповідає за те, як компанія обліковує й пріоритизує дефекти, звітує керівництву розробки про динаміку пропущених багів і домагається, щоб на усунення головних джерел дефектів виділяли ресурси.
- Рішення про реліз і оцінка ризиків
- Задає стандарти релізів для всіх команд, визначає, коли реліз можна зупинити, і саме до нього керівництво приходить із питанням, чи готовий продукт до великого запуску.
- Практики якості
- Формує практики якості в усій розробці, вирішує, де працюють QA-інженери і за що відповідають розробники, і робить якість спільною відповідальністю, а не завданням однієї команди.
- Менторство та обмін знаннями
- Розвиває навички й кар’єрні шляхи в QA-групі, визначає, як наймають і онбордять QA-інженерів, і вирощує наступних senior- та lead-інженерів.
Як адаптувати цю драбину
Зафіксуйте співвідношення ручного й автоматизованого тестування
Якщо ваші QA-інженери переважно проводять дослідницьке тестування, скоротіть рядок «Автоматизація тестування» й розширте «Тест-дизайн і аналіз». Якщо вони переважно пишуть автотести, підніміть очікування щодо якості коду. У будь-якому разі зробіть вибір явним, щоб нікого не оцінювали за роботою, заради якої його не наймали.
Запроваджуйте рівень Lead, лише коли це реальна робота
Коли в компанії два–три QA-інженери, зазвичай вистачає рівнів junior, middle і senior. Додавайте Lead, коли хтось справді задає стандарти якості для всіх команд, а не як нагороду тому, хто найдовше тестує. У цій драбині Lead — експертний рівень; якщо ваш QA-лід ще й керує тестувальниками, додайте очікування щодо роботи з людьми з драбини керівника розробки.
Зіставте рівні з драбиною розробника
Прив’яжіть кожен рівень QA до рівня розробника зі схожими масштабом і зарплатою. Коли Senior QA-інженер стоїть поруч із Senior-розробником, перехід між треками стає кроком убік, а не пониженням чи стрибком.
Збирайте приклади, а не кількість багів
Для чек-інів і рішень про підвищення збирайте приклади: тест-план, що виявив дорогий дефект, нестабільний набір автотестів, який став надійним, рішення про реліз, яке виявилося слушним. Підрахунок заведених багів заохочує шум і карає тестувальників у стабільних командах.
Питання та відповіді
Питання про цю драбину
Скільки грейдів потрібно QA-інженеру?
Для компанії на 20–200 людей зазвичай вистачає трьох–чотирьох: QA-групи там невеликі. У цьому шаблоні їх чотири: Junior, Middle, Senior і Lead QA-інженер. П’ятий рівень варто додавати, лише якщо масштаб роботи справді вийшов за межі стандартів якості для всього продукту.
Чи потрібна мануальним тестувальникам і автоматизаторам спільна кар’єрна драбина?
У більшості невеликих компаній — так. Суть роботи — розуміти ризики, проєктувати тести й ухвалювати рішення про реліз — однакова, різняться лише інструменти. Залиште одну драбину й домовтеся для кожної людини чи команди, якою мірою до них стосується рядок «Автоматизація тестування».
Чи може QA-інженер перейти в розробку?
Так, і найкраще, коли такий перехід сплановано. Порівняйте людину з драбиною розробника, домовтеся про кілька завдань з розвитку — наприклад, невеликі фічі чи виправлення багів — і переводьте її, коли вона стабільно відповідає потрібному рівню. Досвід тестування зазвичай робить її сильнішим розробником, а не слабшим.
Як оцінювати роботу QA-інженера без підрахунку багів?
Дивіться на результати й поведінку: скільки дефектів у його зоні потрапило в продакшен, наскільки надійні та швидкі автотести, як рано він сигналізує про ризики і чи справдилися його рішення про релізи. Обговорюйте конкретні приклади за драбиною на регулярних чек-інах, а не покладайтеся лише на дашборди.
Скільки QA-інженерів потрібно на команду розробників?
Фіксованої пропорції немає. Багато компаній такого розміру працюють з одним QA-інженером на чотирьох–вісьмох розробників, але правильна кількість залежить від того, скільки розробники тестують самі і наскільки дорогий дефект для ваших користувачів. Стежте за пропущеними дефектами й затримками релізів і наймайте, коли якийсь із цих показників стабільно зростає.
Створіть цю кар’єрну драбину в LadderKit — безкоштовно
Налаштуйте її рівні й навички для своєї команди, оцінюйте людей за ними на чек-інах і ухвалюйте рішення про підвищення за єдиними правилами.
Безкоштовний тариф · Банківська картка не потрібна
Схожі шаблони
Розробка
DevOps-інженер
Чотири рівні від Junior до Staff DevOps-інженера і шість компетенцій — від інфраструктури до допомоги розробникам.
- 4 рівні
- 6 компетенцій
Розробка
Керівник розробки
Чотири рівні від Engineering Manager до VP of Engineering і шість управлінських компетенцій.
- 4 рівні
- 6 компетенцій