| Mother of QA | | Всіх вітаю з пʼятничкою! Я вже по троху наздоганяю всі заплановані под...

Всіх вітаю з пʼятничкою! Я вже по троху наздоганяю всі заплановані події! І сьогодні мала змогу переглянути вівторковий вебінар з «Суворої QA комʼюніті» і слухали ми доповідь від iOS розробника з United Tech про колаборацію між Dev та QA! 👩🏼‍💻 Олександр Березовський: «Mission Possible: How to improve collaboration between Dev & QA»1.0. QA очима розробників. 💡 Розробники теж повинні розуміти різницю між QA -> QC -> Testing. ❌ Міф про тестувальників - «Тестувальник - це особистий помічник деяких ролей на проєкті». 💅🏼 Якщо DEV побачив можливість поліплшення якості продукту - він здатен самостійно завести задачу. Він не чекає QA! ⚠️ QA не має адмініструвати технічні рішення, інакше він перетворюється на операційного асистента. ❗️ Відкладене «потім заведу» = процесна втрата, адже ми не працюємо з превентивною якістю.🫶🏼 Коли розробник знайшов баг раніше тестувальника, то він заводить тікет і фіксить. Це має бути про кожного поважаючого себе розробника! 🪥 Dev відповідає за технічну гігієну: • Логування. • Рефакторинг. • Юніт тести. • Зменшення legacy. • Cleanup. • Стабільність білду. ❤️ Сильна команда працює так: • QA заводить тікети на функціональні дефекти, UX проблеми і тд. • Dev заводить тікети на технічний борг, архітектурні покращення, стабілізаційні задачі, інструментарії для тестування. ❗️ Обоє мають думати про якість, але на різних рівнях.QA на рівні якості продукту.Dev на рівні якості коду.2.0. Тестування в продукті / аутсорсі. ❗️Продукт - це не завжди хороші процеси та тестування. Продуктова модель не гарантує якість. Аутсорс не означає слабку якість. ⚠️ Вирішальне - це не модель компанії, а: • Чи залучений QA з самого початку? • Чи є спільна відповідальність?• Чи є DoD?• Чи проводяться ретроспективи?• Чи є культура «виправити причину, а не симптоми»?💡 Якість визначає те, як побудований процес і розповідна відповідальність QA & Dev. 3.0 Долучення QA до команди розробки. 🫶🏼 QA не просто тестує «після», а й впливає на структуру задачі. ❗️ Тестування перед релізом - повинне стати НЕ єдиною точкою контролю, бо якість фічі має готуватись з самого початку. 💡 Важливо після релізу не «хто пропустив», а «що потрібно покращити в процесі». 4.0. Що Dev винен QA. • CI/CD інтеграція. • Контроль зміни Feature Flags. • Логування (REST, Sockets, Internal errors, etc.). • Reset / Clear state. • Token injection. • Інтеграція сервісів за запитом QA. Хороший дебаг тулінг економить дуже багато часу тестерів та команди в цілому.5.0. Ідеальний тікет. 🫶🏼 Хороший баг - це вже половина фікса.💡 Dev повинен зрозуміти: • Що сталось? • Де сталось? • Як повторити?• Що очікувати?😍 Ідеальний тікет очима розробника: • Чіткий заголовок • Середовище • Кроки відтворення • Очікуваний результат з пруфами• Фактичний результат • Докази • Додатковий контекст (чи є workaround, чи впливає на інших користувачів, чи це регресія, чи стабільно відтворюється) • Бонус (креди, токени юзерів і тд.)❔А яка у Вас взаємодія з розробниками? 😍 - дуже класна та ефективна. ❤️ - нормальна, але хотілось би краще. 😭 - дуже важко з ними співпрацювати. 🤯 - гриземось як кішка з собакою.