«Немає поганих тестувальників, є погані системи»

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

«Поганих тестувальників, як і Житомира — не існує»

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

Іноді тестувальник просто працює в умовах, які не дозволяють йому робити роботу якісно. Наприклад, коли компанія цінує швидкість релізів більше, ніж стабільність продукту.

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

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

👍ПодобаєтьсяСподобалось2
До обраногоВ обраному1
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

Це 100% правда. Особливо відгукнулася фраза про те, що «компанія цінує швидкість релізів більше, ніж стабільність». Мені здається, це корінь 90% проблем і вигорання в QA.
Ти намагаєшся зробити свою роботу добре, знаходиш ризики, а тобі кажуть: «це не блокер, релізимо, потім пофіксимо». А коли воно «вибухає» на проді — всі біжать до QA з питанням «як ти це пропустив?».
Здається, єдиний вихід — це намагатися вбудувати якість у процес якомога раніше. Якраз зараз багато експериментую з тим, як AI-помічники можуть у цьому допомогти — наприклад, аналізувати вимоги чи код ще до того, як фіча потрапить на тестування. Складую такі практичні кейси у свій невеликий проєкт, телеграм-канал QA Co-pilot.

Ну все більш фігово насправді, всьо тлєн, буквально
Захочеш ініціювати зміни, люди будуть сперичатись не захочуть змінюватись
Захочеш підвищення завдяки покращенням що можеш зробити — ти зробиш, а тобі лиш дякую скажуть а бабла не дадуть
Оточення не стабільні, нема часу на вирішення техборгу, бо треба деліверити
Сі левел та менеджмент — хоче щоб всі краще працювали завдяки ШІ в сраці — але часу на досілдження не дають бо ДЕЛІВЕРІ НЕ МОЖНА ЗУПИНЯТИ

А девелопери з ШІ ще більше почанають прутні всякої деліверити, а тестувальники як і отримували в кінці спірнта всі зміни, так і отримують а теперр ще більше..

Розслабьтесь! Всьо тлєн — як і було так і буде!

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

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

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