Схожа ситуація відбувається і з програмістами, які по молодості б'ють себе в груди і обіцяють народити безліч стартапів, стати CEO або на худий кінець хоча б проджект-менеджером. Але і тут особливого прогресу не видно - навіть в тімліда звуть неохоче. А в цей же час рядовому QA-мануальника видають нові лампаси і стрижуть в product owner'и. Але при цьому забороняють йому ходити в бар для програмістів. Що відбувається?
інертні люди
З одного боку, справа може бути в традиційній інертності людини. Витративши пару років на те, щоб освоїти свою професію (тестування / програмування), він уже не рветься в суміжну спеціальність. Йому і тут тепло. Хоча, з іншого боку, може, не так вже й хотів?
Але вони не йдуть. Мало того, що за фактом лише деякі QA таки переходять в розробку (з різних причин), так і дорога в product owner'и для них виявляється коротше, ніж для програмістів. Логіка проста: тестувальник знає, як додаток не повинно поводитися, тоді як PM знає, як повинно. Трохи магії, і - вуаля! - тримайте свіжого начальника.
Але є в роботі програміста і тестувальника кардинальна відмінність. Один будує, другий ламає. Один оптиміст, інший песиміст. Один любить, інший ненавидить.
Програміст проектує і виготовляє автомобіль, а тестувальник намагається його вбити об стіну на швидкості 200 км на годину. Розробник радіє, що машина продовжує, хоч і з ушкодженнями, але котитися по шосе, а тестер в цей час радіє, що у неї ось-ось відвалиться глушник. Програміст каже: «дурниця, заживе», тестувальник відповідає: «терміново в лікарню». Дуалістіка!
Оптимізм і песимізм
Програміст за своєю природою - оптиміст. Якщо він не буде оптимістично дивитися в майбутнє, його з'їсть щоденна гіркоту помилок. Ніколи нічого не буває гладко, навіть чортові туторіали - і ті Компільо не з першого разу. Програміста рятує віра в те, що все буде добре: «це не баг, це фіча», коли QA впевнений в зворотному. Так вони влаштовані - кожен в своє болото тягне. Але це взаємовигідний союз. Вони - як двоє друзів, або як сімейна пара, де один витає в хмарах, а інший його весь час тягне на землю. Щоб не полетіли обидва.
Але тестувальники теж вміють радіти. Правда, причини для радості у них своєрідні - як для програміста. У мене до цих пір холоне кров у жилах, коли згадую радісний крик знайомого тестувальника: «Аааа! Знайшов! ». «Що ж ти радієш, скотина?» - думаю я. Знайшов проблему, дефект, чортів баг. А хочеться летіти, рухатися далі. Тому якщо в робочій обстановці у одного на обличчі радість і посмішка, то в іншого неодмінно буде pokerface. «Тут не працює!», - посміхається тестувальник, - «І в логах, глянь - одні epic fatal total kernel panic error'и. Все червоним », - не вгамовується його радість. «Зараз подивимося», відповідає йому з лопаткової виразом обличчя розробок. Проходить півгодини - і вони міняються ролями: програміст з усмішкою пояснює, що це насправді не баг, а неправильна конфігурація environment'а, або що таки баг, але не критичний, і погоди він не робить. Тестер чахне прямо на очах.
До чого я все це говорю - у тестувальників з програмістами різні системи цінностей. І чим довше кожен з них працює в своїй професії, тим складніше йому потім зробити розворот на 180. Один живе роки з філософією «баги - це погано», тоді як інший все життя вважає: «баги - це добре».
Як в анекдоті: «Програміст бачить склянка наполовину повним, проджект-менеджер бачить склянка наполовину порожнім, тоді як тестувальник бачить його наполовину тріснутим.»
Але і це не все. Програміст дивиться в майбутнє - він моделює, планує, намагається передбачити на кілька кроків вперед. Чи планує тестувальник? Звичайно. Але в режимі «Карфаген повинен бути зруйнований». Як холоднокровний мисливець він продумує замах на софтину - відсипає пороху, чистить рушницю, дивиться прогноз погоди, точить ніж. Він постарається вбити її будь-що-будь, будь-яким доступним способом, хоч голими руками. Ось чому програмістам неспокійно, коли в «сезон полювання» рідна софтіна надовго йде в савану. «Чи достатньо я її підготував? Чи зуміє вона уникнути смерті? Якщо вона буде поранена, то не смертельно чи? Чи встигну я надати їй першу допомогу? »- миготять думки в голові програміста, поки він сьорбає каву, скоса поглядаючи на тестувальника, який, здається, починає входити в раж.
Критикувати завжди легше. Як би не було складно грамотно протестувати софтину, створити її або пофиксить приховану багу все одно складніше. Це як в мистецтві: кінокритики, щоб вказати на недоліки сюжету і загальне враження від картини, потрібно витратити години, максимум дні. Режисерові і його команді, щоб зняти цей фільм - місяці, а іноді й роки. У цьому плюс і одночасно мінус риботи тестувальника: з одного боку, він менше стресу, йому не дзвонять в неділю вранці з питаннями «чому не працює». З іншого боку, саме тому він знаходиться нижче на ієрархічній сходинці, адже головну роботу робить програміст. Звідси виникає питання: яке заняття людина вибере - менш сите, зате більш спокійне, або ж вигідніше, але при цьому вимагає більше нервів?
перфекціонізм
Стерильний світ нулів і одиниць є відмінною середовищем для поділу бактерій перфекціонізму, які захоплюють мізки IT-фахівців. У програміста гостра фаза триває до пори до часу, поки не притиснуть терміни і поки не доведеться винаходити милиці для свого дітища - чого не зробиш заради замовника? Тоді як у тестувальника вона набуває хронічного характеру. Якщо програміст - це перфекціоніст-другокласник, то тестувальник - перфекціоніст-третьокурсник. Поки розробник закриває очі на дрібні огріхи в надії, що глядач не помітить нерівностей і подряпин, тестер тільки на них і дивиться. З лінзою в руці. Спочатку все тихо-мирно. Але коли девелопер відволікається на «дивись, літак!», У тестувальника в руках опиняються здоровенні розпечені клешні, бензопила, відбійний молоток і ванна з рідким бетоном. Зараз він буде відчувати софтину на ідеальність.
Тому питання в тому, чи захоче тестувальник переглянути свої перфекціоністські звички, чи навчиться він дивитися крізь пальці на деякі дрібниці.
Програмісти люблять свій код і свої програми разом з усіма милицями і велосипедами, які вони створюють, як кішка любить кошенят. Розробити конструкцію творець вважає за краще не помічати недоліків і бачити тільки хороше. Але тестувальник в цьому плані більше схожий на суворого батька, який проявляє свою любов через сувору дисципліну і ремінь. Як Шварц.
Чи захоче турботлива матуся помінятися ролями з суворим батьком? Ось у чому питання.
Подивимося правді в очі: програмісти не завжди ладнають з тестувальниками. Воно і зрозуміло - хочуть начебто одного, але методи у них різні. Одні будують, інші ламають. Одні джинси зшивають, інші намагаються їх порвати кіньми. До цього додається ще й ієрархічна і зарплатна складова, а також дискримінація за ознакою тестувальника. Тому питання в тому, чи захоче людина, взявши замість лупи викрутку і помінявши зірку на свастику, переходити в стан ворога.
Тобто якщо повиносити за дужки типові причини, за якими тестувальники та програмісти неохоче міняються місцями (немає знань, досвіду, вакансій і т.д.), то в грі залишаться не менш цікаві чинники: оптимізм / песимізм, перфекціонізм, система цінностей, і , звичайно ж, любов і ненависть. Тому, якщо технар на старті свого шляху впевнений, що піде «далі» - наприклад, в тестувальники, розробників, керівники, в PM'и і product owner'и, але з плином років цього не відбувається, то далеко не факт, що справа в чиїйсь ледачою дупі або нездатності навчатися. Ні (хоча, дуже може бути, паскуда - прим. Авт.). Просто палі вже вбиті і бетон залитий. Простіше будувати новий будинок, ніж добудовувати поверхи або підривати фундамент і починати з нуля. Тому на старті непогано б ще разок обмізкувати, куди поїде бетономішалка, але при цьому не поспішати заливати перший-ліпший фундамент. Хто знає, може, там далі за горизонтом є більш цікаві й варті заливки форми.
придатний вкидання від людини який не розуміє в тестуванні зовсім нічого.
«Поганий той тестувальник, який не хоче стати програмістом» Ніколи б не взяла на роботу кандидата в тестувальники з такою життєвою позицією. Тестування - це не трамплін в IT, це окрема область зі своєю немаленькою картою прокачування скілів. Якщо людина мріє бути програмістом - нехай вчить мову і йде на стажування, в тестуванні йому робити нічого.
Через таких ось недо-програмістів-тестувальників які пишуть криві стратегії по тестуванню (якщо взагалі пишуть), створюють криві баг-репорти, бігають колами з криками «ааа нічого не працює» і дратують цим своїх колег програмістів і створюється враження ніби тестування це кривої потворний син IT.
А я б узяв. Тестувальник знає програмування набагато цінніше звичайного мануальщика. Як для компанії, проекту, так і для команди. Тим більше, що він завжди зможе поділитися знаннями з іншими. А як максимум зможе принести бенефіт в компанію через програмування. І заміну завжди можна знайти. З програмістами думаю не так легко.
Коли я йшов в тестування, у мене були точно такі ж думки (а-ля «пару років потестить, набратися досвіду, і програмісти»). Все від поверхневого розуміння процесу і перспектив кар'єрного росту. Але, нічого, розуміння прийшло після першого ж співбесіди.
Хоча, по суті, якщо тестер перекваліфікується в діва з плином часу - в цьому страшного немає нічого, справа ж в розумінні своєї роботи і стосовно неї.
Такі «недо-програмісти-тестувальники» переважно в будь-якій сфері будуть Партач і халатно ставитися до своїх обов'язків.
Програміст створює, тестувальник ламає, Автоматор створює щоб ламати!
Так що це все три різні професії. І логіка у них всіх різна. Так, було б добре, якщо тестувальники розбирали більше технологій, а також програмували у вільний час, і мали більше зп. І перспективи все-таки непогані:
Manual QA => Automation QA => 1. Developer, або 2. Team Lead
Але в основному проблема в відволіканні уваги і не постановці цілей на розвиток. І вдовольниться тим рівнем, який мають зараз.
Я QA інженер на Сейчас и неіяк НЕ розумію чого мені радіти Багам? Це загальна проблема проекту и его якості, це Біль всех, Якій треба діагностуваті, виправити, перевіріті и рухатіся далі. Цікаво тестуваті Нові фічі, розбіратіся в них, а не без кінця топтатіся на місці, даже если «топтання» автоматизоване. Якісь міфи на міфах.
Ось вся сіль в отому 'на зразок' бо НЕ вродє, а так і є. Окрім того тестувальник легше найти суть баги (локалізуваті логіку винекнення) чем програмісту. Фактично один (-а) доповнює Іншого (-у).
Це така «особлива айтішной соціоніка». Всі вже читали цей примітивний «аналіз» сотні разів на десятках різних сайтів (деякі, як Хабра або доу, на них спеціалізуються) і всіх він вже давно задовбав. Дещо які спостереження плюс трохи домислів і можна ліпити нову теорію поділу людей на сорти та типи. Таак товариш Юрій, судячи з вашої аурі ви оптиміст-холерик-Робесп'єр-Інти зі схильністю до графоманії. Ваша доля у цьому житті це ходити по четвергах з зеленим прапорцем. «Наступний пацієнт - заходите.»
Вважаю, що все якраз навпаки. Саме тестувальник найбільше і не любить помилки. Він витрачає купу часу на те, щоб якомога менше помилятися самому і запобігати, знаходити і виправляти чужі помилки. І радіє, коли знайшов помилку він саме тому, що отримав можливість покласти край її існуванню.
писати аби писати.
що тестування - це свого роду трамплін в IT, перша сходинка на шляху до програмування серйозно? =) Тестування окрема кухня, де ти розвіваєшся и вішся, як шеф-кухар.
Зіставляті чоламі тестерів проти девелоперів це тупо та давно заїжджена тема. Є віз, Який всі дружно тягти - мета успішній проект. Если ти хороший професіонал то орієнтований самє на цею результат и не має значення твоя роль на проекті. Девелопер помагає тестеру розібратись в функціоналі и Вимогах, а тестер девелоперу локалізуваті дефект.
Звісно є конфлікти, бо всі ми люди и з різнімі емоціямі та характерами и не КОЖЕН мені может подобатісь, але то є робота.
та вдаватся в Такі банальні крайнощі - один будує Інший ламає. потішіло, як на ранок понеділка =)
гарного дня