Хто ж такий QA та яка його роль в команді

Привіт, DOU спільното!
Нарешті я наважилась написати постик і сюди, тож давайте знайомитись!
Я Аделіна, QA Engineer та Analyst в компанії Code&Cakes. Вже більше 2 років я працюю як QA Engineer та у мене є що вам розповісти.
Одна з найчастіших тем для обговорень — це «Хто ж такий QA та яка його роль в команді?». Давайте з’ясуємо разом!

Хто такий QA Engineer?
QA Engineer, або спеціаліст із забезпечення якості — це людина, яка відповідає за те, щоб продукт, над яким працює команда, був максимально готовим до використання реальними користувачами. Ми виявляємо баги, заводимо їх у баг трекінгових системах та допомагаємо покращити загальний користувацький досвід.
Але QA — це більше, ніж просто пошук помилок. Це про довіру: довіру до продукту, довіру між членами команди та довіру кінцевих користувачів. Ми працюємо над тим, щоб після релізу продукт працював стабільно, був зрозумілим і відповідав потребам бізнесу. Командна робота — основа успіху.
Ми не працюємо ізольовано. QA тісно співпрацюють з розробниками, дизайнерами та проджект-менеджерами, щоб переконатись, що всі частини проєкту гармонійно поєднані та відповідають цільовій аудиторії. Якщо якийсь із етапів розробки недопрацьований, кінцевий результат може бути далеким від ідеального.

Основні обов’язки QA:
Наші щоденні завдання різноманітні, але хочу вам привести приклади того, що входить в мою повсякденну рутину:
— Регресійне тестування
— Створення баг-репортів
— Тестування документації та дизайну
— Взаємодія з командою розробки
— Участь у щоденних стендапах
— Оптимізація процесів тестування
— Окрім цього, ми також беремо участь у дослідницькому тестуванні, ставлячи себе на місце користувачів та оцінюючи продукт з різних сторін.

Наведу для вас реальний приклад:
Як QA я часто беру участь у тестуванні проєктів ще на етапі збору вимог. Це часто передбачає переконання замовника у зміні цих вимог, в зв’язку з розумінням того, що стане перешкодою для швидкої та якісної роботи, користуючись підходом Error Guessing, де я можу передбачити потенційні помилки та визначити ризики для проєкту.
Я також використовую Exploratory Testing під час тестування дизайну у Figma. Це дає змогу уникнути багатьох критичних багів та значно скорочує час на розробку.

Про роль QA в команді:
Один із поширених міфів — що тестування це «найлегша» роль в ІТ. Але насправді QA вимагає широких знань не лише в забезпеченні якості, але й у дизайні, розробці та бізнес-аналітиці.

Ще потрібно бути гнучким, вивчати нові інструменти й адаптуватися до змін.

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

Ми запобігаємо дорогим помилкам і захищаємо користувацький досвід.

Якості успішного QA:
Увага до деталей. Це не лише про пошук дрібних помилок, а й про здатність бачити загальну картину та помічати приховані ризики.
Навички комунікації. Пояснити складну проблему простою мовою — це важливо для співпраці з розробниками.
Вирішення проблем. Кожен баг унікальний, тому творчий підхід і логічне мислення дуже допомагають.
Здатність до навчання. IT розвивається швидко, і нові інструменти з’являються постійно. Важливо не відставати.

Давайте підведемо невеличкі підсумки:

Контроль якості — це не лише про пошук багів. Це про мислення на випередження і створення продукту, яким користувачі будуть задоволені. Важливо думати про кінцевого користувача ще на етапі розробки, і QA тут грає ключову роль.
Успішний QA не просто тестує, а й розвивається разом із продуктом. Ми вчимося швидко, розвиваємо гнучкість мислення та постійно шукаємо способи покращити кінцевий результат. У цьому і полягає справжня цінність QA для команди та бізнесу загалом

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

👍ПодобаєтьсяСподобалось2
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Из моего опыта, в сложных проектах (всякие сложные взаимодействия софта на компе и фирмвары на харде + соответствующие спецификации, с описанием этого взаимодействия) — тестеры просто неспособны понять, как и что тестить. Т.к. не хватает квалификации въехать в спецификацию.

Как итог, приходится всё что связано со спецификацией/этим взаимодействием — покрывать тестами в коде.

Для хороших тестеров — есть ниша в написании автоматизированных UI-тестов. Мануальное тестирование — это уже, разве что где-то в Китае за 5 баксов/день.

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

Я вже працюю деяку кількість рочків в ІТ й пройшов через різні етапи ставлення до QA. Від juniorського кепкування не лишилось й сліду. Нині я вважаю, що проект без окремого QA — це катастрофа і бомба уповільненої дії. Також мій досвід показав, що простіше клієнту продати бодай одного QA спеціаліста, ніж ідею покриття всіма видами тестів. Останнє збільшує вартість розробки мінімум вдвічі, бо жоден окремий тип тестів не покриє всі можливі випадки, а писати все тріо дуже часозатратна операція.

Тому порада junior — цінуйте своїх QA, вони як ніхто прикривають ваші дупки від звільнення та є дуже важливою складовою дійсно успішної команди.

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

Смешно про дупки))) иногда наоборот взгреваем эти дупки чтоб шевелились

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

Всё так. Только мало кто это понимает, большинство сводит до понятия тестеров, причём в основном мануальных тестеров. Увы.
Я бы ещё добавил, что в задачи QA должен входить, хотя бы частично, анализ ТЗ на явные ляпы (не всё найдут, но хотя бы в сценариях использования — точно).

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

А «Просто Антон» виглядає як токсичний і ображений на життя хейтер тестувальників:)

Знаю, що в Chrome DevTools тіми немає QA. Тільки деви, що код пишуть та автотести.

так і я ж про це — просто узагальнено)

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

У нас замовник проти QA, каже покривайте все тестами і все (що ми і робим). І це не перший замовник/проект такий.

Мені подобається коли є QA (тобто і дуже високе покриття тестами і QA вдобавок) але у замовників якісь свої ідеї на цей рахунок

Скільки часу у вас займає покрити тестами 90% вимог?
Та як ви і замовник дізнаєтесь ефективність такого підходу?
Та чи усі розробники у вас сіньйори? Чи все ж є джуни і мідли?
Просто цікаво)

Нас 4 людини — 3 сеньора і мідл. По строкам замовник не пушить, тобто якщо кажем що треба час на тести — є час на тести.

В мене 50/50 — половину часу займає код половину написання тестів, може навіть 40/60 (40 код 60 тести)

як ви і замовник дізнаєтесь ефективність такого підходу

Я так розумію, замовника влаштовує ефективність цього всього: продакшен не падає (шось критичне ламалося 1-2 рази раз за пять років) і користувачі не жаліються (якщо репортяться баги то фіксим)

Особисто у мене було менше стресу і зайвої роботи коли QA на проекті був

Тут погоджуюсь, підхід доцільний)

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

це 10000%, але не всі це розуміють. тут також грає роль, як замовнику пояснить це все компанія і який саме буде замовник. може замовник був розробником і мав негативний досвід роботи з QA, або ж брат свата кума дідової мами сказав що «А от в Google тестують розробники», і замовник подумав, а чим же його «стартап» гірше ніж Google... та й таке)

Бути тестувальником — це величезна відповідальність.
Важливо думати про кінцевого користувача ще на етапі розробки, і QA тут грає ключову роль.

Тестерів звільняють першими якщо якісь фінансові проблеми на проекті.
Є багато успішних проектів де тестери відсутні в командах.

Тому qa мають найменшу цінність для клієнта порівняно з будь якою іншою роллю (ну ок, може ще тех райтери). Тому краще йти в інженери, хоча б авто тести писати.
Манкі клікерам роботи стає все менше і менше.

Це лише з вашого досвіду такі висновки? Я працюю в компанії, де проектів досить багато, і на 1 тестувальника може бути 2-3-4 проекти, як коли, і компанія розсудливо підходить до найму персоналу, тому і тестувальників у компанії переважно 2.
Це вже друга компанія з таким підходом де я працюю, і повірте, розробників у нас звільняють частіше, ніж будь кого іншого)
Тому бажано писати на початку «З мого досвіду», бо у кожного цей досвід різний 🙂

і на 1 тестувальника може бути 2-3-4 проекти

Ого, Code&Cakes серйозна контора=)
Клієнти хоч в курсі?

переважно таку думку, як ваша мають розробники на нижчих рівнях,

Я техлідом вже 5+ років працюю, і працював на багатьох проектах

то тестувальників можуть гарно продати клієнту

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

Ви часом не в генезісі працюєте? Бо якраз звідти виходять такі ж токсіки🙂

Ви часом не в генезісі працюєте? Бо якраз звідти виходять такі ж
токсіки

Ні, але з радістю почитаю вашу історію чого вас туди не взяли)

Я звісно знаю про енергетичних вампірів, але що ви вже заполонили і ДОУ...
Що ви намагаєтесь доказати? Мені останній раз в років 6 так хлопчик на площадці доказував що моя лопатка не того кольору, якого має бути)

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

Розробники розуміють цінність QA, бізнес — не завжди. З мого досвіду, компанія нещодавно скоротила 80% QA-офісу (він був децентралізованим), тому що вирішила піти більш прогресивним шляхом: розробники будуть самостійно відповідати за якість продукту.

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

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

І код буде без багів?
Ану давайте експеримент зробимо — ви лінку на проект, який ви розробляли — я вам критичні баги, які там знайду🙂

я вам критичні баги, які там знайду

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

Ви певно працювали лише з псевдо тестувальниками, і тут ще питання чи точно ви техлід? Бо таке враження що переписуюсь з обіженою дитиною. Може вам мало платять і тестувальники мають більші зп ніж ви?
Просто смішно таке читати, якщо чесно)
Ваша думка ніяк не впливає на мою роботу, компанію, проекти чи зп, тому писати можна що завгодно👻

Ви певно працювали лише з псевдо тестувальниками

Лол, це хто такі?)

Може вам мало платять і тестувальники мають більші зп ніж ви?

Саме так, ви мене розкусили)

Та воно, звісно, ок, згоден. Але коли критичні баги (наприклад, з останнього: thread pool saturation), то вже складно це все самому розгрібати. І я пишу з позиції SDET. Я зараз залишився один на цьому проекті з команди тестування (в нас не було манкі тестерів), є допомога девів у цьому плані, але поки що цього недостатньо для якісної роботи

Але коли критичні баги (наприклад, з останнього: thread pool saturation),

Тоді ручний тестер не допоможе бо він/вона тих слів не знає)
І буде бага з описом «не працює кнопка», яка перше піде до ФЕ дева, він потратить день щоб розпитати що то взагалі за бага, тоді скаже що це бекенд, бекенд без степів ще з кілька днів буде репродюсати.

Я звичайно утрирую, але смисл зрозумілий. І клієнтам це вже теж зрозуміло.

Є QA, є QC, є «тицяльники» або «манкі тестери»
Перші і другі розуміють більшість технічних аспектів, і заводять баги таким чином, щоб вони потрапляли до тих розробників, до яких і мають потрапляти, і щоб розробник не ламав голову що ж там сталось. Ми можемо дослідити баг і пояснити технічно що пішло не так (часто з досвідом розуміння цього стає все кращим)
А якщо в вашій команді люди які лише називають себе тестувальниками, але пишуть так, як ви описали, то я вас розчарую, ви ніколи не працювали ні з QA ні з QC

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

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

Є QA, є QC, є «тицяльники» або «манкі тестери»

Різниці 0, попрацюєте ще кілька років і зрозумієте це.
І клієнти теж вже це розуміють.
Оце «ми ж не тестерів продаєм а quality assurance» ще працювало років 10 рому, але не зараз.

Якість залежить від інженерних процесів, від рівня людей (тобто від найму і розвитку існуючих), від чітко визначених вимог, від співпраці з замовником.
Це все обов’язки людей рівня лід, делівері менеджер, РО і вище. А замовнику приводять джуна і кажуть «ось це ваш quality assurance спеціаліст, і не переплутайте з QC, це зовсім інший рівень»

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

Побачила,що вам просто нема чим зайнятись, от ви і виписуєте різним людям під їх постами.

Я не у вас на сторінці у фейсбуці пишу)
Це форум, тут люди пишуть пости щоб під ними коментали=)

З мого досвіду — НЕ всі програмісти уважні. З пяти людей десь один буде неуважний. Хтось тестує свій власний код і там дійсно нема багів, а хтось «каже я все потестував» відкриваєш і за три хвилини знаходиш 2 бага. І це лягає на тімліда — перепровіряти за неуважними елементами. Бо якщо воно поїде недотестоване (або пагано протестоване) на продакшен буде винуватий лід. За QA я не перепровіряла бо знала що в нього/неї глаз алмаз.

З часом, будь-яку людину можна навчити якісно тестувати («перевіряй крайні значення, перевіряй негативні значення, не забувай про не-unicode символи, etc») але це теж нагрузка на ліда.

Тоді, як кажуть в теорії систем «Міцність системи визначається її найслабшою ланкою» — якщо є 5 уважних людей і 1 неуважна — у вас дира в якості. З тією людиною має хтось працювати і навчати, а хто це буде робити якщо нема ліда чи не назначено ментора.

Згодом і стане зрозуміло, чи є такий підхід ефективним, чи все ж вам повернуть QAшок

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

Трошки про скіли «не інженерів» (qa) з власного досвіду, тобто то що треба мені для роботи.
— глибоке розуміння роботи мереж з першого по четвертий osi.
— значення баш та пайтон на рівні написання скриптів
— лінукс, rtos
— розуміння роботи мікроконтролера і переферійних пристрої
— знання мови С хоча би на рівні читання коду.
— базові знання схемотехніки.
Взагалі не інженерні скіли.

значення баш та пайтон на рівні написання скриптів

Уважність до дрібних деталей забули дописати 🤔

Зі своїм стеком знань можу собі дозволити.

Підписатись на коментарі