Від тестувальника до інженера: як зростати у QA. Поради експерта з NIX

Тестування – чи не найпопулярніший напрям серед новачків в IT. Багато хто вибирає цю професію, навіть не підозрюючи, що це лише початковий етап для QA-фахівця.

У партнерському матеріалі Сергій Могилевський, QA Tech Lead у команді NIX, розповідає, які перспективи чекають на тих, хто долучився до сфери QA.

Що потрібно для переходу від тестувальника до інженера

Для успішного старту кар’єри в QA вам зазвичай вистачить лише декількох базових навичок:

• уважність;
• посидючість;
• розуміння софту, який ви перевіряєте.

Ці якості треба доповнити знанням спеціальних інструментів: від багтрекінгових систем до фахових месенджерів.

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

Аби вийти на новий рівень, потрібно розібратися в теорії та основах предметної галузі, мати практику використання різних застосунків і бути знайомими з усіма поширеними підходами до тестування. І на все треба витратити певну кількість часу та зусиль. Головне – не боятися повсякденної практики, складнощів і викликів.

Яка різниця між тестувальником і QA-інженером

Завдання тестувальника дуже сильно відрізняються від завдань QA-інженера.

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

Потрібні навички приходять лише з досвідом. Тестувальник бере участь у командних активностях, бачить роботу QA-колег, розробників, девопсів, отримує нові завдання та поглиблює експертизу. Це і є початок шляху до інженера.

Які складності чекають на цьому шляху

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

Основні серед них:

• Відсутність системного мислення. Таке вміння життєво необхідне для QA-інженерів. І його, як м’язи, можна тренувати. Саме завдяки системному мисленню інженери бачать проєкт у цілому, генерують оптимальні способи тестування і створюють тест-кейси. Початківці через відсутність системности дивляться лише на окремі фічі, над якими працюють. Але потрібно осягнути всю цілісну систему і внутрішні залежності. Якщо навчитися цього, можна планувати тестування навіть для масштабних проєктів. Тож треба завжди шукати оптимальні підходи до тестування, розширювати професійний світогляд, знаходити корисні тест-кейси та в цілому підвищувати ефективність роботи.
• Невідповідність між реальністю та очікуваннями. На початку своєї кар’єри я потрапив до повністю нового проєкту, де мені було необхідно написати тест-кейси для кількох модулів. Я це зробив, як мені здавалося тоді, якісно, але через певні обставини залишив проєкт. Утім, за кілька років я повернувся до нього в ролі тимчасового підсилення команди. І зустрів ті самі тест-кейси на прогоні мануальної регресії: у них було чимало недоліків, які я не побачив новачком. Те, що мені колись здавалося ідеальним, виявилося досить поверховим і погано продуманим.
• Неефективна командна комунікація. QA-інженер не просто тестує продукт, але й активно взаємодіє з командою, збирає інформацію та готує документацію. Тож необхідно розвивати вміння швидко отримувати й передавати дані, ділитися ними з різними людьми: від інших тестувальників до замовників. Також ви маєте грамотно розподіляти завдання між учасниками команди. Але новачок може й не знати, які запитання ставити, кому та коли, як ділитися результатами своєї роботи, як обробляти зворотний зв’язок тощо. Пам’ятайте: проєкти завжди рухаються вперед, і багато в чому це залежить від ефективного спілкування команд. Саме воно допомагає підвищувати поінформованість.
• Використання обмежених інструментів. Для QA-інженерів вкрай важливо оновлювати й розширювати власний інструментарій. Звичайно, у вас можуть бути улюблені, перевірені інструменти. Але жоден з них не є універсальним. Тому ви маєте знаходити відповідні до завдання інструменти, аби виконувати роботу швидко та якісно. Наприклад, для автоматизованого тестування web UI на Angular краще обрати Protractor, а для інших завдань – уже Selenium. Тож не бійтеся вивчати нові, необхідні для роботи інструменти. Це може бути складним, але й захопливим процесом.

Чому тестувальник має мислити як інженер

Тестувальник-початківець, зіткнувшись з незнайомим інструментом, може сказати: я цього не вмію, шукайте обізнаного фахівця. А от інженер за покликанням, навіть якщо за статусом він поки що тестувальник, скаже: я готовий розібратися.

Навіть якщо все знайоме, справжній інженер знайде нові підходи до вже перевірених тестів. Завдяки цьому він буде оптимізувати все нові й нові області.

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

У результаті цим фахівцям доступні все нові й нові активності. Наприклад, до простого мануального тестування додалися цікаві завдання з таких сфер:

• автоматизація функціональних перевірок;
• перфоманс;
• сек’юрність;
• аксессібіліті.

Також QA-інженери, які виросли з тестувальників, можуть:

• аналізувати код софту, щоб відшукати нові способи тестування та виключити дублювання перевірок;
• застосовувати нові техніки тест-дизайну до вже наявних перевірок;
• створювати нові тестові пайплайни.

Список можна продовжувати. Кожен інженер знайде щось цікаве з огляду на свої навички.

Звичайно, інколи обмежує ситуація проєкту. Інколи немає різноманіття через особливості продукту, технологій, інструментів, команди тощо. Але, якщо прагнути розвитку, нові підходи з’являться в будь-якому проєкті. Адже QA – це більше ніж тестування. Ця галузь дає дуже широкий горизонт для зростання. Головне – уже на старті змінити погляд і почати думати як інженер.

Це партнерський матеріал. Інформацію для цього матеріалу надав партнер.
Редакція відповідає за відповідність стилістики редакційним стандартам.
Замовити матеріал про вас у форматі PR-статті ви можете тут.