Я Manual QA, який не хоче бути автоматизатором

Ця репліка дивує майже всіх рекрутерів, з якими я спілкувалася, поки шукала роботу: «Я Manual QA який не хоче бути автоматизатором».

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

Я бачила різні сетапи ручне тестування/автоматизація. Від великого відділу тестування (15-20 manual і 5-6 людей на automation) до менших команд, що спеціалізуються лише на автоматизації. Хоча я розумію, що кожна компанія тюнить процес тестування під потреби свої й клієнта, я хочу поговорити, чому ручне тестування важливе і чому такі тестувальники все ще не вимерли. І чому бути General QA видається мені не дуже гарною ідеєю.

Найбільша відмінність між ручним і автоматизованим тестуваннями, яку я побачила на першій роботі: ручне тестування відбувається у «реальному часі», зі збором вимог, комунікацією з PO/BA, Архітектором, Розробником і купою інших людей. Створення автоматизованих тестів ефективніше, коли більшість цієї підготовчої роботи вже виконана, щоб ви або ваш колега не витрачали час на переписування коду. Безперечно є ситуації, коли це можна робити паралельно, та насправді, їх не так вже і багато. (Наприклад, якщо ви робите майже копію наявного модуля, чи коли є контракт для API та можна швидко його замокати.)

Тож, чому я хочу залишатися саме ручним тестувальником?

Більше часу на вимоги

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

Як QA, я завжди прошу залучати мене, як тільки з’являється перша версія вимог чи збирають мітинг, де будуть обговорювати що ми імплементуємо. Чому? Бо тестування повинно розпочинатися як можна раніше. І саме QA, як носій знань про те, як працює продукт, може дати свій відгук чи поставити каверзне питання.

Можливість тестування UI/UX

Найбільш класно технічно зроблений продукт може провалитися через проблеми на UI. І я не про те, чи сповзла у вас кнопка на 1 піксель (і автотести зафейлились) чи про кількість символів у полі.

Чи логічно побудований юзер флоу? Які є ерор меседжі? Вони достатньо зрозумілі для користувача? Якщо сервер  відповідає status 500,  що побачить користувач? Як ми можемо покращити user experience?

Я стикалась з тим, що колег автоматизаторів більше хвилює розташування тексту помилки vs чи несе воно користь. Чи з’їхала кнопка на пару пікселів vs чи вона логічно розташована.

Хтось скаже, що для дизайну і вимог в нас є дизайнери, продакт менеджери, продакт оунери, то чому ми маємо приділяти цьому стільки часу? Та поняття «якість» ширше ніж «наш код працює». Якість також включає задоволення користувачів. І тестувальники мають на це впливати.

Час для  Exploratory Testing

Це найкраща частина, чесно кажучи. Можна знайти дивовижні речі, від невідповідності ерор меседжа діям користувача до того, що дані записуються в іншу табличку (чи не записуються нікуди взагалі). Причому, навіть якщо ви з розробником добре пройшлися по вимогах, це не гарантує, що реалізація вийшла як задумано (з величезної кількості причин). Можна знайти плаваючий баг і півдня витратити на аналіз(а проблема буде в іншому модулі програми).  На то воно і дослідницьке — ми досліджуємо безліч речей, обговорених та не обговорених, записаних, того, що малося на увазі або common sense.

Тут треба тримати у голові, що

1. протестувати вичерпно не можливо
2. перемикатися між підходами «як довести, що це працює як у вимогах» і «як довести, що це не працює як треба»

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

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

А що ж не так з General QA спитаєте ви?

Це ж можна об ‘єднати суперсили ручного та автоматизованого тестування! Ну, майже. Згадаймо про project management triangle.

Бо якщо ми зафіксуємо всі три, то якість у середині просідає дуже відчутно. Накладемо цей трикутник на обов’язки, з якими стикається General QA. 

Time

Лімітовано ітераціями та релізом, треба встигнути зробити заплановані тікети.

Scope

Частіше за все зафіксовано на плануванні — кожен тікет треба потестити руками, вірогідно, написати ручний тест і потім його автоматизувати. Це залежить від підходу компанії, цілком можливо, що автоматизувати одразу не потрібно. Такі тести підуть у наступні ітерації як «борг».

Cost

Чи будуть компенсувати понаднормові робочі години, щоб 100% покрити все тестами (ймовірно, ні, відповідно також зафіксовано). 

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

Колеги, у коментарях розкажіть, як це у вас влаштовано? Чи відчуваєте ви, що одна сторона тестування просідає при такому підході?