Хто насправді є Senior QA та як його виростити у своїй команді

💡 Усі статті, обговорення, новини про тестування — в одному місці. Приєднуйтесь до QA спільноти!

Привіт! Я Ольга Кучер, Consultant, Test Lead в компанії GlobalLogic. На позиції ліда я вже більш як п’ять років, загалом у компанії — 14. Моя команда спочатку складалася з трьох тестувальників, з лідами та менеджерами з боку замовника. Зараз вся технічна експертиза на нашому боці, а команда тестувальників зросла до 15 людей.

Тестування медичних проєктів, до яких ми долучені — це дуже відповідальна робота. Головною особливістю є налагоджені процеси та детальна документація. Ці процеси ми (test team разом із замовником) налаштовували протягом усього цього часу.

Багато людей приходили до нас як Trainee або Junior та доростали до Senior. Тому я вважаю, що можу поділитися досвідом розвитку людей на проєкті. Та своїми думками про те, хто такий Senior і як його виростити.

Щоб відповісти на це питання, спочатку треба зрозуміти, який результат ми хочемо отримати. І що ми очікуємо від людини, яку можемо назвати Senior QA.

Почнімо з технічних навичок. Ледь втрималась, щоб не написати «скілів».

Test Design

Test Design — це найважливіша навичка для QA. Senior QA повинен володіти нею досконало, розуміти, звідки взялися саме ці техніки тест-дизайну, як вони працюють, коли та яку краще застосувати. Без знання технік і вміння їх використовувати не обійдеться ні manual-тестувальник, ні automation.

Я часто зустрічала на співбесідах кандидатів, які знають декілька фреймворків, мають добрі знання Java та Python. Втім, на питання про те, як вони вирішували, що автоматизувати, яке покриття потрібне, хто писав сценарії, отримувала відповідь, що цим займалися ліди, замовники або команда manual-тестування, і що вони просто автоматизовували вже написані сценарії. Сорі, але це не тестувальник, а просто кодер.

Якраз такий варіант робітника може бути замінений на ШІ у майбутньому. Щоб такому фахівцю стати Senior Automation, треба ставити питання: чому саме ці сценарії автоматизуються, яку ціль переслідують і, з розумінням технік тест-дизайну, самостійно писати тест-кейси і складати тестові набори.

Щоб отримати швидкий результат і знайти баги якомога раніше, потрібно мати стратегію тестування. Розуміти, який його обсяг вже виконано та скільки залишилося. Без чіткого плану і розуміння, що ми робимо і, головне, навіщо, тестування буде більше схоже на сліпе клацання. Так, є і такі види тестування, як Exploratory testing, ad-hoc, але чи дають вони нам чітке розуміння про якість нашого продукту? Error Guessing як техніка тест-дизайну теж має право на існування. Але якщо розібратись, за кожним випадком застосування цієї практики стоїть якась більш ґрунтовна техніка, і інженер несвідомо застосовує її. Тест-дизайн допоможе вам і вашим тестам бути більш ефективними. І якраз від Senior QA ми очікуємо швидкого й елегантного результату.

Я б рекомендувала книгу A Practitioner’s Guide to Software Test Design lee Copeland.

CI/CD-практики

Continuous integration and Continue Delivered — це вже невід’ємна практика в процесі розробки програмного продукту. QA як один з учасників розробки повинен добре розуміти весь процес. Цю практику може бути застосовано так чи інакше, залучення QA теж може бути різним. На деяких проєктах QA самі можуть деплоїти потрібні їм фічі на тестові середовища. Необхідно зрозуміти, чи впали тести та які. Що саме було протестовано в рамках Continuous integration, а що треба подивитись мануально. Безперервне тестування часто реалізується у вигляді набору різних автоматизованих тестів (регресійних, продуктивності та інших), які виконуються в CI/CD-конвеєрі (pipeline, build chain тощо).

Окрім автоматичного запуску тестів та оцінки метрик якості коду, CI/CD допомагає тестувальникам оптимізувати релізний процес. Важливо зрозуміти, як інтегрувати автоматизоване тестування в CI/CD так, щоб воно було фінансово виправданим та ефективнішим за мануальне тестування.

Автоматизоване тестування

Навіть якщо ви manual-тестувальник, на рівні Senior повинно бути розуміння, що доцільно та доречно автоматизовувати, а що ні. Можна спробувати автоматизувати все, але чи принесе це дохід замовнику? Треба розуміти, як часто ми будемо використовувати ці скрипти, через який час запуск та розробка автоскриптів буде коштувати менше за мануал-тестінг цієї фічі. Менеджер чи лід не повинен пояснювати Senior-спеціалісту ці моменти.

За довгий час роботи тестувальником я зустрічала ситуації, коли за рік праці automation-команда знайшла тільки один чи два баги, скрипти постійно переписувались, бо змінювався інтерфейс. Автомейшини нервували, пили каву, клієнт оплачував. Чи доречно це? Як швидко пішов клієнт? Або закінчились гроші інвестора? Так, можна сперечатися і казати, що вони довели своєю працею якість продукту. Це так, якщо не брати до уваги, скільки багів за цей час знайшли мануал-тестувальники, і хто забезпечив цю якість продукту.

API-тестування

Application Programming Interface тестування перегукується з двома попередніми пунктами: автоматизацією і CI/CD. Вміння поєднувати ці три пункти є дуже важливим для надання кращих результатів в короткі терміни. І це якраз те, що чекають від Senior QA.

API-тестування надає можливість почати тестування раніше, без застосування UI. Зазвичай так воно проходить швидше, ніж через GUI. Дуже легко автоматизується, дає змогу заощадити ресурси та забезпечити швидкі й ефективні релізи.

Відразу скажу, що security і performance-тестінг я відношу до окремої спеціалізації QA, бо вважаю, що це окрема магія. Проте загальне розуміння про них не завадить.

Tools

Скажу пару слів про Test Management and Bug Management tool. Рівень володіння тулами повинен бути достатньо високим. Такі речі, як зробити фільтр чи Dashboard в Джирі — не повинні викликати питання. Як мінімум свої процеси Senior повинен намагатися автоматизувати якомога більше (не плутаємо автоматизацію тестування з автоматизуванням процесів).

Борди, якими користується вся команда, налаштовують Менеджери чи Leads. Однак для розуміння скоупа своєї роботи просто вкладинки My open issues замало для Senior. Треба вміти налаштувати Dashboard так, щоб одразу бачити не тільки роботу на сьогодні, але й план на декілька днів-тижнів вперед, ризикові таски й навантаження. «Не розібрався з фільтром», «не подивився пріоритет», «зробив не той таск», «навіть не уявляв такого навантаження завтра, не вигребу» — таке звучить непрофесійно навіть від Middle, вже не кажучи Senior. У команді, де Lead назначає таски на учасників, ніколи не виросте гарний спеціаліст. Процеси розподілу навантаження повинні бути зрозумілі всім і налагоджені так, щоб члени команди не чекали, поки на них прилетить таск.

Test Management Tools. Тут не важливо, що ви використовували — Zephyr, TestRail чи Jama. Загальний функціонал дуже схожий у всіх цих тулах. Такі інструменти можуть допомогти в управлінні тестами, покращуючи продуктивність та якість тестування, дозволяють управляти вимогами та життєвим циклом продукту. Також вони дають командам можливість ефективно співпрацювати, відстежувати зміни та забезпечувати відповідну якість. Як створити Test Case, набір тестових сценаріїв, залінкувати з Requirements, багами, зробити Traceability-матрицю — все це дуже необхідно знати Senior QA. І, звісно, розуміти, навіщо воно потрібно.

Requirements

Вимоги є не на всіх проєктах. Проте, якщо вони присутні, важливо переконатися, що вони повні, чіткі та несуперечливі. Виявлення можливих невідповідностей і помилок, а також перевірка того, що вимоги технічно можливі — забезпечує аналіз вимог, яким QA має володіти. Особливо, якщо це Senior. Це дає змогу уникнути дефектів і помилок ще на початку розробки, полегшує роботу менш досвідченим членам команди. Правильно складена Requirements Traceability Matrix дозволяє розробляти точні та ефективні тестові сценарії, що забезпечує краще покриття тестування й моніторинг змін у вимогах.

Test Documentation

Вміння розробляти тестову документацію не повинно закінчуватися на створенні баг-репорта чи тест-кейса. Senior QA повинен розуміти:

• Коли та яку документацію потрібно створювати, навіщо вона потрібна.
• Коли доречно розробляти Test Cases, а коли достатньо тільки чек-ліста.
• Навіщо потрібен Test Plan: чи буде він окремо від Test Strategy, чи буде містити її.
• Як створити Test Summary, кому і навіщо це потрібно.
• Не забуваємо про Traceability-матрицю.

Якщо ви знаєте відповіді на ці питання, можете починати думати про промоушен.

Methodologies

Знання різних методологій дозволяє Senior QA краще співпрацювати з іншими командами (розробники, BA, продуктові менеджери), розуміючи їхні підходи та методи роботи. А також встановлювати реалістичні очікування і забезпечувати кращу комунікацію з усіма зацікавленими сторонами проєкту.

Покращення процесів тестування, оптимізація підходів: знання різних методологій дозволяє Senior QA вибрати найефективніший підхід для конкретного випадку. Це містить вибір методів тестування, які найбільше підходять для специфічних вимог і цілей проєкту.

English

Англійську мову треба постійно покращувати. Це як у спорті — якщо зупинитися, то можна відкотитися назад. Гарна англійська робить людину більш професійною в очах замовника чи інвестора, дає змогу краще розуміти клієнта, пояснювати свою думку чи розв’язувати питання. Я не відкрию таємницю, якщо скажу, що всі інновації приходять до нас з США — тож і слідкувати за цим краще з першоджерел.

Ось ми й дійшли до найцікавішого та найскладнішого питання — це не технічні навички та Soft Skills. Можливо знати та вміти все, що було сказано вище, але не бути Senior QA.

Бо Senior QA це майже Lead: може лідити невелику групу QA, очолити тестування окремої фічі чи фікса, в деяких випадках реліза починає з нуля і до деплоя (або Test Summary репорта). Він має не боятися брати на себе відповідальність за досягнення та фейли, приймати рішення, делегувати. Є багато спільного у Senior QA, розробника і BA: досягнувши цих загальних навичок, прокачавши й ввібравши їх, ви будете виглядати більш професійно на будь-якій позиції.

Моя подруга досягла позиції Lead QA в одній відомій аутстаффінговій компанії, пішла в декрет, а коли прийшов час виходити на роботу — вирішила змінити фах на ВА. І знов досягла позиціі Lead ВА десь за три роки. Бо навички, які я опишу нижче, в неї вже були.

Estimation

Існує багато технік естімування — від T-shirt до PERT. Треба вміти застосовувати хоча б декілька, розуміти, що Schedule не дорівнює Estimate. Грати в пленінг-покер і естімувати в Story points — це, звісно, добре. Але для більш комплексних задач потрібна декомпозиція.

Можу порадити наступні книжки:

1. Steve McConnell Software Estimation: Demystifying the Black Art
2. Tom DeMarco The Deadline: A Novel About Project Management

Вміння делегувати

Дуже добре, коли Senior QA може розподіляти та делегувати роботу, нести відповідальність за себе і команду. Делегувати — це важко. Звісно, ніхто не може зробити краще за вас. Але треба довіряти людям і розуміти, хто що може зробити.

Бажання глибоко розібратися з проблемами

Senior QA має копати вглиб, розширювати кругозір. Ставити питання: «Навіщо я це роблю?». Памʼятаєте міф про мавп, банан і холодну воду? Так от Senior якраз і запитує — а чому не можна брати банан?

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

Дуже гарно працює техніка «5 Whys» (П’ять «чому»). Вона допомагає виявити корінні причини проблеми шляхом послідовного порушення цього питання. Після кожної відповіді задається наступне «чому», поки не буде досягнуто першопричини проблеми. Або RCA (Root Cause Analysis). Аналіз корінних причин — це систематичний підхід до виявлення основних причин проблеми або дефекту з метою їх усунення, а не лише вирішення симптомів. RCA допомагає забезпечити тривале покращення процесів і уникнути повторення проблеми в майбутньому.

Zoom in zoom out view

Розуміння пріоритетів і оцінка ризиків. Іншими словами — на що можна забити, з чим змиритися, а що ескалювати. Вміння розставити акценти, привернути увагу до важливих речей і знайти слова, щоб довести, що це дійсно варто уваги. Як додаток до цього — не слід забувати про інженерну креативність.

Мається на увазі вміння шукати нові ідеї та створювати нові технічні рішення. Це Junior може робити все за зразком. Від Senior очікується пошук відповідей, гарних рішень і написання цих зразків. Треба вміти дивитися на проблему під іншим кутом, знаходити інші рішення.

Проактивність

Багато вже сказано про це, а скільки мемів! :) Втім, це все одно дуже важлива звичка. Давайте відразу надам приклади. Людина не чекає спонукання, чи коли на неї заасайнять таск, сама знаходить роботу. Якщо бачить якісь проблеми чи гепи в процессах — порушує це питання і надає своє рішення. Високий рівень проактивності — це бачити, як можна покращити процесс, продукт, комунікації тощо, і надавати своє рішення раніше, ніж це помітив менеджмент чи ліди.

Навички тайм-менеджменту

Або як не вмерти на роботі. Повторюсь — нікому не потрібний мертвий Senior на проекті.

Як допомогти людям досягти всього, що було описано вище

В GlobalLogic дуже поширена практика IDP (Individual Development Plan). Його можна використовувати, коли запит про зростання йде від кандидата, але він не розуміє, куди і як рухатися. Що робимо:

1. Окреслюємо зони розвитку. Хто, як не Lead, може бачити, чого не вистачає майбутньому Senior?
2. Думаємо разом з кандидатом, що можна зробити по кожному пункту:
   • які курси, тренінги обрати;
   • що кандидат може зробити сам;
   • що можна використати з цього на практиці;
   • кандидат сам повинен поставити дедлайни до кожного пункту.
3. Проводимо періодичне рев’ю і коригування за потреби.

Сам по собі IDP не буде працювати добре, якщо не створити наступні умови в команді:

1. Підтримувати бажання самостійно розібратися з проблемами. Ставте задачі і чіткі терміни її виконання. Вони повинні бути не тривіальні, а, скажімо так, із зірочкою, що спонукатимуть до розширення кругозору.
2. Делегування. Делегуванню теж треба вчити! На власному прикладі показувати, що і як можна делегувати, як і коли контролювати виконання.
3. Підтримувати бажання драйвити зміни, дослуховуватись до критики, намагатися зрозуміти, звідки виникає те чи інше питання.
4. Надавати можливість втілювати у життя ідеї, з якими приходять до ліда члени його команди.
5. Поступово збільшувати зони відповідальності.
6. Надавати можливості менторингу.
7. Забезпечувати ґрунтовний зворотний зв’язок від ліда — що виходить добре, що ні, і чому. Дуже важливо не забувати давати позитивний зворотний зв’язок.
8. Давати розуміння повної картини й того, який внесок в нього робить кожен член команди.

Щоб стати Senior QA, звичайно, треба бажання самої людини. Але якщо лід або менеджер допоможе, дасть поради та замотивує на зміни, від цього виграє вся команда. Висококваліфікований фахівець, що досконально знає проєкт, на якому виріс, та замотивований підтримкою — це win-win для усіх.