«Немає поганих тестувальників, є погані системи»
«Поганих тестувальників, як і Житомира — не існує»
Натрапив на цікаву статтю, де авторка пише, що ділити тестувальників на «хороших» і «поганих» — безглуздо. Адже якість продукту залежить не лише від конкретної людини, а від усієї системи: процесів, взаємодії в команді, часу, бюджету та підходів до тестування.
Іноді тестувальник просто працює в умовах, які не дозволяють йому робити роботу якісно. Наприклад, коли компанія цінує швидкість релізів більше, ніж стабільність продукту.
Авторка закликає не шукати винних, а шукати способи покращити систему: створювати середовище, де якість стає спільною відповідальністю, підтримувати колег, інвестувати в навчання та відкрито говорити про проблеми.
А ви погоджуєтеся з думкою авторки? Як, на вашу думку, можна побудувати систему, яка справді підтримує якість, а не звалює відповідальність на окремих людей?
6 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарівА пам’ятаєте як усі були у захваті від Agile?
Колись навіть казали що команда професіоналів не потребує менеджера з батогом — бо вони ж спеціалісти і самі знають як краще організувати роботу!
Але система — це не якийсь Скайнет, а організація створена людьми і складається з людей.
І якщо система працює погано — то винні саме конкретні люди. Перше за все — менеджери, бо «риба гниє з голови». Але це не знімає відповідальності з кожного члена команди.
І тому він проста мовчки виконує свою роботу неякісно? Тоді він справді поганий тестувальник — бо приховує проблеми замість їх знаходити.
Колись ще казали «кадри вирішують все». І це так і є: і серед тестувальників, і серед девелоперів, і серед менеджерів є «хороші» професіонали, які піклуються і про організацію роботи і про результат. І є «погані» співробітники які «відбувають робочий час» заради зарплатні і шукають тільки як би менше викладатися на роботі.
А як тоді назвати тестувальника, який в лінкедині має 10+ років досвіду, а на практиці не може нормально оформити тікет?
Це 100% правда. Особливо відгукнулася фраза про те, що «компанія цінує швидкість релізів більше, ніж стабільність». Мені здається, це корінь 90% проблем і вигорання в QA.
Ти намагаєшся зробити свою роботу добре, знаходиш ризики, а тобі кажуть: «це не блокер, релізимо, потім пофіксимо». А коли воно «вибухає» на проді — всі біжать до QA з питанням «як ти це пропустив?».
Здається, єдиний вихід — це намагатися вбудувати якість у процес якомога раніше. Якраз зараз багато експериментую з тим, як AI-помічники можуть у цьому допомогти — наприклад, аналізувати вимоги чи код ще до того, як фіча потрапить на тестування. Складую такі практичні кейси у свій невеликий проєкт, телеграм-канал QA Co-pilot.
Ну все більш фігово насправді, всьо тлєн, буквально
Захочеш ініціювати зміни, люди будуть сперичатись не захочуть змінюватись
Захочеш підвищення завдяки покращенням що можеш зробити — ти зробиш, а тобі лиш дякую скажуть а бабла не дадуть
Оточення не стабільні, нема часу на вирішення техборгу, бо треба деліверити
Сі левел та менеджмент — хоче щоб всі краще працювали завдяки ШІ в сраці — але часу на досілдження не дають бо ДЕЛІВЕРІ НЕ МОЖНА ЗУПИНЯТИ
А девелопери з ШІ ще більше почанають прутні всякої деліверити, а тестувальники як і отримували в кінці спірнта всі зміни, так і отримують а теперр ще більше..
Розслабьтесь! Всьо тлєн — як і було так і буде!
Плак-плак😢🥹
Йой, ну зміни в кінці спрінта і навіть в кінці регресу — тупо маст хев. Ай філ ю.. Все ж, здебільшого відгукується ваш перелік проблем)
Проте не всюди старання настільки не оцінені, бачила й приклад зміни процесів з подальшим підвищенням ініціаторки, і вона справді чудова.
Делівері не можна зупиняти, бо бізнес ніколи не стоїть на місці. Так і прогоріти можна, тож доводиться поспішати. Якби ж ще не кастомер-скнара, то це б компенсувалось кадрами принаймні. Короче, не все прям такий тлєн, просто часом в колективі потрібен герой — хтось, хто «розворушить кодло», хоче воно того чи ні, і любить ту роботу))