QA — це «перевір, чи працює» чи «переконайся, що зроблено правильно»?
На просторах Reddit побачив обговорення, де QA-інженер розповідає, що у їхній команді роль QA тепер більше нагадує «перевір, чи працює», а не «переконайся, що зроблено правильно».
За словами автора, більшість роботи зводиться до запуску скриптів після девелопера, відтворення багів і пересилання тікетів далі. Ніякого глибокого аналізу вимог чи раннього залучення в процес немає.
Він хоче, аби QA були партнерами з самого початку: ставили незручні питання до вимог, ламали фічі ще на етапі задуму й допомагали уникати проблем ще до того, як код потрапить у прод. А поки що це більше схоже на «постфактум-фіксацію», ніж на справжню якість.
А ви погоджуєтесь із таким баченням? Як у вас загалом відбувається взаємодія між девами і тестувальниками?
10 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарівНажаль обидва ваші варіанти невірні. QA це про процеси і попередження проблем, QC — про виявлення проблем у вже створених артефактах (коді, спеках, etc.)
«Перевір чи працює» — більш атомарно, а тому більш правильно.
Переважна більшість тестерів (яких тепер називають QA, але людина ж та сама) це ніколи не зможе.
Який QA зможе сказати що технічно можливо а що ні? Що якщо зробити фічу без вимоги X то буде в 2 рази швидше?
Це може хіба тімлід/техлід/аріхект/ EM, от з ними про нові фічі і розмовляють.
QA (дешевші) в тімці для щоб програмісти (дорожчі) не тратили час на регресії, звіти, написання е2е тестів.
Трохи не про QA,але по темі — багато років тому працював в дуже відомій компанії- запускали на ринок дуже специфічний низькоякісний по всім параметрам продукт. маржа висока -собівартість смішна. Так от, всі косяки розробки сипалися на команди сапорта — ui /ux був настільки незручний, в обробка помилок настільки мало інформативна, що клієнти постійно навалювали гору запитів. Формально ПЗ працювало , фактично на ’відчепись’. Фідбеки , про покращення та оптимізації до розробки майже не доходили.зі сторони керівництва дешевше було роздувати штат енд юзер саппорта.весь фокус був не усунення недоліків, пз а на написання інструкцій та гайдів для користувачів
Зараз роль QA настільки розмита. В одній команді можна перевіряти щось зовсім простеньке, а в іншій — підіймати інфру для автотестів, писати пайплайни і колупатись у докерах, — і це формально теж буде QA (SDET, SET, whatever).
Щоб бути корисним при формуванні вимог, потрібно знати продукт краще, ніж середній розробник і на рівні з архітекторами, бізнес-аналітиками і менеджментом. Якщо у QA цього немає (а так буває дуже часто, з мого досвіду), то і логічно, що приймати участь на ранніх етапах розробки такому спеціалісту немає жодного сенсу.
Є різні проекти, десь необхідна залученість QA ще на етапі вимог, десь ні. Десь навіть самі QA пишуть вимоги) А десь їх не кличуть навіть ставити естімейти ( мудрий менеджер вже все зробив) Тобто все дуже варіативно, і залежить від команди, проекту, продукту, а також досвіду QA і його ставлення до роботи. В багатьох компаніях навпаки, дуже вітають самостійність і бажання щось покращувати ще на етапі вимог. Дуже вітають і deep thinking, і questioning requirements, і catching flaws early.
Чуваку з реддіта вочевидь трапився проект, де його думка просто нікого не цікавить на етапі збору і оформлення вимог, а він в душі цього дуже хотів. Можливо його залученість не потрібна, бо є хороший БА, купа інших менеджерів. Він страждає) Ніхто ж не заважає тоді перейти в БА чи ПО, якщо так сильно хочеться questioning requirements.
1. Якщо тебе не залучають, але ти бачиш проблеми які виникають від твоєї відсутності на ранніх етапах, підсвіти це, запропонуй допомогу щоб покращити процеси (ось вже твоя залученість як QA окрім тасок)
2. Якщо там така класна команда (що цілком має місце бути), що класно вирішують питання вимог без залучення тестувальника — значить вони успішно покривають цей етап QA без залучення безпосередньо тестувальника
QA- це процес, і його дійсно можуть виконувати усі люди, що залучені в проект , це зрілість команди
Якщо безпосередньо автору не відгукується такий сценарій, або читачам які бачать себе в цьому, шукайте для себе нових можливостей, де ви можете повністю реалізувати свій потенціал.
Варіантів насправді дуже багато
Є тестувальники, є QC, є QA інженери. Так само, є кодери, програмні інженери, системні архітектори. І проєкти, де різні спеціалісти потрібні в різних пропорціях. Узагальнювати до того, що все зводиться до чогось одного — доволі поверхово, як на мене.
На співбесідах шукають другий варіант, а у робочому процесі по факту до такого не готові, «заводь в беклог, колись подивимося».
Одразу прилетить — ’хто тут у нас самий вумний?’