Ми продовжуємо знайомити вас із нашою командою. І сьогодні ділимося роздумами нашого QA Lead Романа про напрямок тестування та розвиток у цій професії. Приємного читання!
Як ти прийшов у професію? Відразу хотів цього чи розуміння прийшло з часом?
Так вийшло, що я нічого не знав про тестування і починав працювати в першій IT-компанії як Technical Writer.
Згодом задач по розробці документації було не так багато, а у відділі тестування було багато задач та мені запропонували спробувати допомогти. Так я втягнувся і повністю став тестувальником.
Як зрозуміти, що тестування – це твоє? Які плюси та мінуси цієї професії?
Мені здається, що має подобатись розбиратись в технологіях та інструментах, вміти та любити аналізувати першопричини технічних кейсів.
Щодо плюсів і мінусів професії – все доволі суб’єктивно і від різних людей я чув протилежні думки з цього приводу.
Інколи задачі можуть повторюватись і потрібно робити одні й ті самі дії для їх вирішення. В цьому випадку може допомогти автоматизація, але не завжди є змога і сенс її налаштувати.
Також інколи мінусом вважається, що на відміну від дизайнерів та розробників, тестувальник не створює продукт сам, а лише допомагає його покращити.
Щодо плюсів – то це широкі можливості для розвитку. Різні продукти потребують різних підходів та знань.
Крім суто функціонального тестування можна розвивати навички програмування та автоматизації, вивчати нефункціональні напрямки або ж займатись більш менеджерськими задачами.
Назви топ-10 навичок для QA інженера, на твою думку
На мою думку це:
- Аналітичне мислення;
- Уважність до деталей;
- Знання власне методологій та підходів до тестування;
- Навички автоматизації;
- Знання програмування та розуміння того, як створюються програмні продукти;
- Знання інструментів, які застосовуються для вирішення тих чи інших задач;
- Навички комунікації;
- Цікавість та критичне мислення;
- Гнучкість та адаптація до змін;
- Організованість та вміння спланувати роботу.
Як зрозуміти, куди тестувальнику рухатися далі в розвитку?
Потрібно зрозуміти поточний рівень та мету. Інколи потреби компанії та проєкту вказують на потенційні напрямки розвитку. Це може бути автоматизація, вивчення домену, менеджмент команди тощо.
Також напрямок можуть підказати власні цілі та інтереси.
Які ресурси для розвитку ти можеш порадити?
Радий відмітити, що за останній час раз з’явилось багато нашого, українського контенту в напрямку тестування. Одночасно може бути складно порекомендувати щось конкретне, бо в усіх різні цілі.
Тому можу порадити доєднатись до спільнот на кшталт QA Club Lviv і далі обирати ресурси відштовхуючись від потреб. В ком’юніті точно допоможуть порадою.
Як ти підходиш до вирішення конфлікту між тестувальником та розробником?
Не скажу, що це часте явище в моїй практиці. Проте непорозуміння можливі і тоді нашою спільною метою буде знайти причину непорозуміння та усунути її.
Можливо, не були обговорені очікування під час вирішення спільної задачі чи існує обмеження в часі, в яке кожен з учасників команди намагається вкластись і це призводить до обмежень в спілкуванні, що, в свою чергу, може бути причиною непорозуміння.
Що саме складне для тебе в роботі QA Lead-ом?
Це впоратись з бажанням бути всюди одночасно і корисним всім). З досвідом розумієш, що знати все і все скрізь встигати неможливо. На допомогу приходять практики делегування та приорітезації задач.
Що тебе драйвить на позиції QA lead?
Це можливість впливати на процеси та приймати участь в розробці артефактів не тільки однієї команди, а цілого напрямку чи компанії загалом. Дуже мотивує бачити результати через призму прийнятих рішень.
Чи потрібні будуть тестувальники через 5-10 років, зважаючи на розвиток AI інструментів для тестування?
ШІ дійсно має великий вплив на вирішення типових і нетипових задач. Можна точно сказати, що за цей час тестування зміниться – ми будемо мати більше інструментів, які ще більше полегшують життя.
Якісь задачі зникнуть з наших повсякденних активностей взагалі, бо ми їх делегуємо ШІ, але можуть і з’явитись нові.
Тестування не зникне повністю, але точно трансформується.
Уявімо, що замовник вважає, що тестувальники не потрібні на проєкті. При цьому якість страждає, хоча покриття юніт та інтеграційними тестами є. Що робити?
Як обрати тестову стратегію для проєкту?
Я би проаналізував існуюче покриття та виявив причини, через які якість вважається незадовільною. В залежності від продукту, не всі ризики можна покрити автотестами.
Якщо з’ясується, що кількість критичних сценаріїв велика і що їх покриття недоцільне, можна запропонувати залучити тестувальника, роботою якого буде не тільки пошук існуючих дефектів, але й запобігання потенційних.
Які QA метрики варто запроваджувати на проекті? Що ти можеш порадити?
Метрики треба обирати в залежності від цілей. Тоді буде зрозуміліше, що ми хочемо вимірювати і навіщо. Класичною метрикою в тестуванні вважається кількість пропущених дефектів.
Це можна вимірювати як кількісно, так і якісно в сенсі причин.
Також такі типові метрики як покриття автотестами, стабільність автотестів, накопичення відкритих дефектів можуть бути відправною точкою, щоб почати аналізувати дані по проєкту.
Загалом добре, коли метрики швидко збирати та просто інтерпретувати.
Що б ти побажав QA інженерам, які хочуть “вирости” на позицію ліда?
Дивитись ширше на процеси команди чи проєкту і шукати місця покращення. Розвиватись не тільки технічно, а й організаційно. А ще бути гнучкими та проактивними.
Post A Reply