Чим займається QA Engineer
Як тестувати баги.
Будь-яке програмне забезпечення, сайт або програма вимагає перевірки якості перед запуском у реліз. Це пов’язано з тим, що програмісти не завжди розуміють, як користувач взаємодіятиме з продуктом. Також вони не можуть передбачити всі нестандартні ситуації в його роботі. Тоді на допомогу приходить Quality Assurance Engineer (QA).
Разом з Іриною Петренко, QA Lead у Billie та лекторкою курсу QA Manual, і Тарасом Карпенком, Software Developer у NewStore Inс і лектором курсу QA Automation, розуміємо, на що звертати увагу, щоби стати QA.
Тестуємо як користувач
Ірина: «Завдання QA — бути амбасадором якості в щоденній роботі команди. Роль QA не обмежується фазою тестування, він має дуже добре знати продукт та підтримувати команду критичним поглядом на систему, з якою працює.
QA має допомогти команді доставити якісний продукт кінцевому користувачеві».
Ключовий скіл QA — вміння писати документацію. Види документації:
- специфікація — технічний опис продукту;
- test plan — загальний план із тестування продукту;
- checklist — список функціонала, який потрібно перевірити;
- test case — опис дій для перевірки окремих функцій продукту;
- use case — сценарії взаємодії з продуктом;
- баг-репорт — опис багу та кроків, що його спричиняли.
QA готує та передає звіти розробникам, а ті ― вносять правки. Після цього — ще раз перевіряє сценарії, які спричинили помилку. І так доти, доки продукт не відповідатиме вимогам. Щоби розуміти готовність продукту, потрібно мати чіткі аceptance criteria — критерії, яким повинен відповідати кінцевий продукт. Acceptance criteria не можуть бути подвійними, вони описують лише успішний чи провальний результат. Наприклад, функція відновлення пароля користувача або скидає його, або ні.
Ірина: «У роботі QA найважливіше — гнучкість і критичність мислення, вміння знаходити нестандартні кейси. Не забуваємо про увагу до деталей, скрупульозність і стресостійкість. Також важливо вміти дебатувати та працювати з базами даних. Якщо ви талановитий QA, але не можете зрозуміти, чому відбувається помилка, і донести це до розробника, працювати буде складніше».
Види QA
Тестувати продукт можна як вручну — manual, так і за допомогою коду — automation. У першому випадку QA повинен повторювати дії, які може зробити користувач. У випадку з automation QA пишеться код (тести), який покриває певний функціонал продукту і працює без участі людини.
Плюси QA automation:
- швидкість — код працює швидше, ніж ручне повторення дій користувача;
- масштабованість — легко перевірити, як продукт буде поводитися зі збільшенням кількості користувачів;
- повторюваність результатів — код виконується завжди однаково й не може помилитися в сценарії.
Тарас: «Автоматизація краще справляється із будь-яким видом тестування, де можна чітко описати вимоги:
- тестування окремих модулів;
- функціональне UI End-to-End тестування всієї програми;
- тестування продуктивності;
- тестування поведінки на різних платформах».
Ірина: «Масштабованість та тестування продуктивності — те, що не перевіряється вручну. Ручне тестування програє автоматичному за часом і надійністю при повторюваності. Тестування технічно складних сценаріїв краще автоматизувати».
Якщо ми говоримо про технічні навички, QA automation повинен знати мову програмування (наприклад, Java або Python), розбиратися в тестових фреймворках (Selenium), вміти працювати з базами даних та системами контролю версій (Git).
Тарас: «Для QA automation найважливіше:
- вміти складати тестові сценарії. Трапляються тести, які виконують безліч дій, але не приносять користі.
- вміти знаходити спільну мову з технічними та нетехнічними фахівцями.
- вивчати нові інструменти. Наприклад, компанії можуть використовувати різні інструменти збору (Maven або Gradle).
- вміти будувати ефективні алгоритми. Чим більше в компанії тестів, тим довше вони виконуються. Тому час кожного тесту критичний.»
Розробка без manual QA
Автоматизоване тестування не може повністю замінити ручне. QA automation підвищує вартість розробки та спеціаліста, оскільки автоматизатор повинен знати більше, ніж мануальник. Проблема ще в тому, що автотести не можуть покрити всі потреби продукту. Не можна стати QA automation без досвіду QA manual.
Ірина: «Незамінність ручного тестування — у його «людяності». Exploratory testing, UX testing це те, що не можна автоматизувати. Продукти з інтерфейсом користувача неможливо повністю покрити автотестами».
Тарас: «Трапляються компанії, у яких QA manual виконують усю роботу над aceptance criteria, пишуть тестові сценарії, погоджують їх. QA automation лише переводять тестові сценарії в програмний код. Але таких компаній дедалі менше. З приходом Agile у розробку все частіше потрібні Agile QA. Найчастіше це 1–2 QA на команду з 5–8 розробників. QA займається всім, аж до аналізу результатів автоматизованих тестів. Досвід QA manual — must have».