qa s roles vs goals how balance both achieve your goals
Ця стаття присвячена моєму пристрасному братству QA !!!
Минули ті часи, коли системи контролю якості мали достатньо часу, чекаючи на збірки, і пізніше вони починали тестування, відповідно виховували помилки, а потім знову чекали, поки розробники їх виправлять.
Вони витратили б значну частину свого часу на практикуванні англійської мови, LOL !!. Я маю на увазі написання тестових справ, їх перегляд та доопрацювання для використання у тестуванні.
Час сильно змінився, і ролі теж. Можливо, вам пощастить, якщо ви виживете, лише проводячи ручне тестування, яке також проводиться з такими великими ІТ-гігантами, як Infosys, Wipro, TCS, Accenture тощо.
Перебуваючи в середній або невеликій фірмі, ви повинні знати деякі спеціальні навички, крім базового ручного тестування. Це може бути щось на зразок тестування API, листоноша, МИЛО , Тестування бази даних , перевірка на стороні клієнта до більш складних, таких як автоматизація та тестування продуктивності.
У цій сучасній тенденції ви могли б помітити, що вакансії навіть для тестувальників із досвідом 2-4 роки містять багато речей.
Нижче наведено зразок посадової інструкції на роль випробувача з досвідом роботи 2-4 роки:
- Хороші знання Java.
- Селен - Обов’язково.
- Має бути хорошим у тестуванні продуктивності - Jmeter / LoadRunner з глибоким розумінням ОС та концепцій налаштування продуктивності
Я перерахував лише основні навички, але до набору можна додати ще багато іншого. Python, Perl, groovy тощо знаходять своє місце в більшості отворів.
Тому, що ми тут робимо висновок? Чи переходить галузь до ролі SDET?
Однак я б погодився з певними моментами, наприклад - тестувальник повинен мати базові знання мови програмування і бути готовим займатися автоматизацією коли потрібно . Вам, мабуть, цікаво чому термін “ коли потрібно ”Зберігали сміливість? Це пов’язано з практикою, якої дотримуються в наш час.
Багато компаній наймають для тестування автоматизації, але ви повинні почуватись щасливчиком лише в тому випадку, якщо зможете знайти проект автоматизації в цій новій організації. Багато разів ви б просто опинилися в іншому ручному проекті, де через кілька місяців ви не знайдете можливості для навчання.
Основною причиною зміни вашої поточної компанії може бути 'Я не отримую досвід автоматизації' . Можливо, вам доведеться докласти всіх зусиль, щоб навчитися автоматизації, а потім змінити компанію, тому що ви хочете перейти від ручного тестування. Отож ви тут !!
Вас знову закрутили !!
Ще одна найгірша частина, яку я помітив, що трапляється у багатьох організаціях, полягає в тому, що навіть керівник з контролю якості або менеджер з контролю якості майже виконують ту ж роботу, що і молодший тестер. Це може бути не скрізь, але просування на посаду провідника з контролю якості не гарантує, що ви отримаєте ті ролі, на які шукаєте.
Ієрархія у вашому проекті може змусити вас виконати ту саму роботу, яку виконують ваші молодші однолітки. Ролі менеджера з контролю якості майже закінчуються.
То де провідний КЯ повинен бачити себе в майбутньому?
Нарешті, але найцікавіше, що кожен із усіх цих ІТ-братств мріє побувати на місці. Якщо порівняти шанси на місці, які отримують спеціалісти з вищої освіти або розробники, з отриманням контролю якості, то вам буде сумно опинятися на стороні, яка програє. Я працював із різними організаціями, і є деякі загальні слова, які часто чули мої вуха від HR та вищого керівництва.
Це слова, які мене засмучують - 'Немає місця для контролю якості' . Але знову ж таки, це не однаковий випадок скрізь, однак, я просто цитую загальні тенденції в галузі.
найкраще розширення спливаючих вікон хром - -
Отже, переглянемо заголовок цієї статті' QA Roles v / s Goals '.
Ключовим моментом, який я намагаюся тут виділити, є “Чи фокусуються наші ролі на наших цілях” . Я впевнений, що більшість із них сказали б НІ !! Із плином днів, із збільшенням вашого досвіду з кожним роком, часом ми відчуваємо, що нового ми робимо? Відповідь буде в тому, що ми виконуємо ту саму роботу, яку ми робили 3-4 роки тому ».
Я зіткнувся з профілями певних тестувальників, які навіть маючи 10-річний досвід роботи, вони все ще працюють як „Тест-аналітик” або „Старший аналітик тестів”, тоді як розробники з таким самим досвідом стають „менеджерами проектів” або „менеджерами продуктів”. '.
Якщо ви переглянете ролі, які ви виконували протягом усієї вашої кар’єри, то таблиця нижче буде звучати цікаво, а також гнітюче. Ви помітите, що нічого не дізнаєтесь навіть після 7-8 років досвіду роботи.
Позначення | Роки на одній ролі (Середнє значення | Загальна кількість років досвіду | Навчання / Проблеми / Проблеми |
---|---|---|---|
Керівник QA | 3 | 14 | Майже не змінюється в ролях, все ще думаючи, чи продовжувати контроль якості, чи переходити до BA |
Молодший юрист QA | 1 | 1 | Написання тестових кейсів, виявлення дефектів, базове ручне тестування |
Асоційований QA | 1.5 | 2.5 | Огляди тестових кейсів, автоматизація (якщо пощастить) |
Старший юрист QA | 1.5 | 4 | Звітування про стан, автоматизація, продуктивність (ви починаєте вчитися, навіть якщо не в проекті) |
Асоційований керівник з питань якості | два | 6 | Створення тестових планів, оцінок та обробки команд (якщо пощастить), призначення завдань, звітування про стан клієнта, більше дзвінків клієнта |
Провідний контроль якості | два | 8 | Тестова стратегія, додаткова робота в Excel, управління табелями робочого часу, створення облікових записів, платіжні дані |
Помічник менеджера з якості | 3 | одинадцять | Тим більше, що ти виконував би все в ролі Lead QA. |
Директор з контролю якості | 3 | 17 | Ролі майже не змінюються. Детальніше про управління загальною якістю в організаціях. |
Отже, я б сказав, що 5-7-річний період дуже важливий у кар'єрі QA. Вам потрібно попрацювати над своєю силою і слабкістю і відповідно йти шляхом.
- Якщо у вас немає інтересу до кодування і ви також не розумієтесь з автоматизацією, але ви відчуваєте, що володієте хорошими аналітичними навичками та хорошими навичками спілкування, то краще перейти до ролі бакалавра через 5 років.
- Якщо ви божевільні, тоді обов’язково дотримуйтесь шляху автоматизації. Немає сенсу залишатися в Керівництві. Продовжуйте змінювати компанії, поки не отримаєте свою ідеальну роль.
- Якщо ви не божевільні коди, але добре розумієте логіку, тоді зрозумійте технології на ринку і краще перейдіть до менеджера доставки, а не менеджера якості. І ви дізнаєтесь багато нового у вертикальній доставці.
Як правило, люди кажуть, що нам не слід часто міняти компанії, але що робити, якщо ми не задоволені своєю роллю? Чи слід іти на компроміси щодо того, що відбувається? Продовжуйте виконувати ту саму роботу, якщо вам не подобається? Зрештою, продовжуй думати, що я роблю?
Хлопці !! Переконайтеся, що ваші ролі змушують вас досягти своїх цілей. Якщо ні, ви просто компрометуєте своє життя та кар'єру. Якщо ви не задоволені професійно, то ви в кінцевому підсумку також зіпсуєте своє особисте життя.
Про автора : Ця стаття написана членом команди STH Hasneet . Він працює керівником з тестування програмного забезпечення в MNC.
Ви переживали таку ж ситуацію? Будь ласка, не соромтеся поділитися своїм досвідом.
Рекомендована література
- 5 способів переповнити ваше тестування продуктивності та досягти цілей
- Найкращі засоби тестування програмного забезпечення 2021 р. (Інструменти автоматизації тестування якості)
- Завантажити тестувальник електронної книги
- Як досягти рівня зрілості 5 для забезпечення якості та процесу тестування
- Основні 7 основних цілей тестувальника програмного забезпечення - Ви “зроблений” тестер чи “Обраний”?
- MongoDB Створення користувача та призначення прикладів ролей
- Тестування навантаження за допомогою підручників HP LoadRunner
- Різниця між робочим столом, тестуванням клієнтського сервера та веб-тестуванням