Це переклад статті.
Ще в червні я з великим інтересом прочитав статтю Джона Стівенсона, в якій обговорюється кар'єрний ріст для тестувальників. У той час (і досі) стаття зачепила мене за живе, тому що аналогічні питання почали підніматися в моїй нинішній компанії.
Примітка перекладача: Невеликий відступ і пара слів про ту статтю. У статті наводяться різна статистика про тестувальників - стать (75% чоловіка, хоча, в моїй практиці я б сказав, що жіноча стать превалює), спосіб розвитку (збігається з цією статтею) і зарплата. Останнє мене дуже здивувало, тому що, якщо вірити їй, то тестувальники в середньому отримують стільки ж або більше програмістів і розробників, що явно розходиться з моїм досвідом (до того ж у статті робиться акцент на те, що менше, хоча цифри говорять протилежне).
Після деяких турбот про залученість співробітників, я (голова тестувальників) а так само інші начальники функціональної частини (розробка програмного забезпечення, управління проектом і технічна розробка), зайнялися розмовами з усіма своїми людьми в межах наших компетенцій. Ми розробили набір питань, спрямованих на отримання реальної картини: їх поточного погляду на свою кар'єру і свою роль в компанії.
По-перше, це було здорово, просто обійти і поговорити з усіма, а по-друге, розмова з усіма двадцятьма тестерами дала мені досить гарне уявлення про те, де лежать проблемні ділянки.
Джон Стівенсон у своїй статті пише: «Так, ХХХ, був таким відмінним тестером, але він був змушений перейти в розробники, щоб мати можливість розвиватися в компанії» і саме цю фразу я чув в тій чи іншій формі кілька разів. У нашому випадку це був перехід або в розробники, або в керуючих проектом. Обидва варіанти розглядалися як єдиний реальний прогрес для тестувальника .//Примітка перекладача: не зовсім зрозуміло, чому ігнорується шлях QA Engineer - > Senior QA Engineer - > Lead QA Engineer. Але залишаю це на совісті автора.
Це зробило мене сумним.
Потім, коли я вивчив дані краще, з'ясувалася тенденція, що більшість тестувальників, яких ми прийняли на роботу випускниками рік-два тому, зараз зацікавлені в переході в розробники, в той час як тестери зі стажем 3-5 років дивляться в бік управлінців.
Так чому ж наші тестери з менш дворічним досвідом хочуть перейти в розробники? Надалі стало очевидно, що компанія прагне до частих релізів продукту; помітно суттєве зростання автоматизації тестування. Ми завжди багато часу приділяли автоматизованому тестуванню, але тепер більше, ніж коли-небудь. Сукупність малого часу на підготовку та акценту на швидких випусках, призвела до того, що наші нові тестувальники робили в основному автоматизоване тестування і тупе ручне регресійне тестування.
Ручне тестування = = Дослідницьке тестування
Можливо, бажання змінити область діяльності є наслідком вузького зору на роль тестування. Коли тестувальників запитали про дослідницьке тестування, деякі з них стверджували, що вони робили його кожен випуск, але це було дуже нудно і вони просто робили те ж саме знову і знову.
Саме в цей момент я почав з'єднувати точки. Ймовірно, реальна проблема була в тому, що навіть якщо вони і знали про існування інших областей тестування, вони не розуміють, що ці області собою являють насправді. Наприклад, в їх очах дослідницьке тестування = = ручному тестуванню, так що якщо їх єдина можливість проявити себе як тестувальника було прогоном регресійного тестування за заздалегідь складеними списками, не дивно, що вони захотіли покинути корабель!
Тому, можливо, реальною проблемою є освіта. Як компанія, ми наполегливо працюємо над більш частими релізами за останні пару років, і заохочуємо команди адаптувати свої методи роботи під більш гнучкі умови, щоб бути більш ефективними. В результаті, велика частина нашої команди працює на повну потужність більшу частину часу, що не залишає часу на навчання і розвиток. Є звичайно деякі люди, які знаходять час, для того щоб дізнатися щось нове, але ми повинні дивитися в загальному - «час» є бар'єром в цьому рівнянні.
Це було підтверджено багатьма тестувальниками, коли їх запитали, чи був у них якийсь прогрес у процесі навчання. Їхня часта відповідь була: «Ні, у мене немає часу» або «Немає часу протягом дня, щоб зробити це».
Знаючи, що ви не знаєте
Як прямий результат цього дослідження ми дивимося на те, як ми можемо ввести час на підготовку в проекти. Є уроки, які можна винести з Google прибрав 20% часу і нашого власного досвіду, тому ми впевнені, що зможемо реалізувати щось у себе. Робота над цим триває.
Але саме по собі це не вирішить проблему. Як ви можете навчитися чогось, якщо ви навіть не знаєте, що це таке - те, що ви повинні дізнатися. Існує якась річ у знаннях, в рамках вашої ролі, але ви не знаєте що саме. Може, ви вважаєте себе досвідченим тестувальником, коли як ви, насправді, просто не в курсі деяких областей вашої ролі. Це може здатися абсурдним, але уявіть, що у вас було мало контактів з суспільством тестувальників, за межами вашої маленької командної бульбашки тестерів або навіть всієї компанії. Тоді ваше уявлення про свою роль буде значно менше, і обрізатися до тих навичок, які необхідні вам щодня. Якщо ми прийняли підхід майстрів програмного забезпечення, то у нас є багато учнів, дуже небагато підмайстрів, а майстрів і того менше. Це означає дуже мало можливостей для наставництва.
Це призводить мене до іншої істотної відмінності між розробниками і тестувальниками, про яку я підозрював протягом тривалого часу, і яке було підтверджено нашими даними. Розробник зазвичай грав у комп'ютер, будучи дитиною, впізнавав комп'ютер краще в школі, продовжував навчання в сфері інформаційних технологій і можливо навіть отримував ступінь в університеті і все це з метою стати розробником. Бажання розробляти щось це їх пристрасть і вони, як правило, займаються програмуванням весь свій час (принаймні до шлюбу, дітей тощо).
У тестувальників немає вищої освіти з тестування програмного забезпечення, немає занять з тестування в школі і я впевнений, що ні в кого не було пекучого бажання дитиною або підлітком стати тестувальником програмного забезпечення. Сумно усвідомлювати, що неабияка кількість тестувальників (і я теж) раніше отримали цю роботу, тому що їм не вистачило знань або завзятості для розробників. Навички, необхідні для тестування, такі як допитливість, увага до деталей, здатність дивитися на загальну картину (а так само багато інших) є тими рисами, що у мене завжди були, так що, на щастя, все стало благополучно.
Тим не менш, я думаю, що тестування програмного забезпечення в даний час розглядається як сумлінна кар'єра у своєму праві і багато компаній зараз не розглядають це як невдалий шлях розробника.
Але я хочу сказати, що без цього пекучого бажання бути тестувальником, новий тестувальник повинен вивчити практично з нуля всі ті навички, що включає в себе роль тестування.
І це те місце, в якому ми помилилися. У моїй компанії розробників і тестувальників розглядають на рівних, та й взагалі багато навичок є загальними. Однак новим тестувальникам можливо набагато більше уваги приділити для пояснення ролей і навичок необхідним їм.
Карта навичок
У спробі відкрити очі нашим тестувальникам і пролити світло на навички, які охоплює роль тестування, ми зібрали карту навичок. Центр карти являє собою набір тих основних навичок, в яких кожен тестувальник повинен мати хоча б базові знання. Після розходяться від центру чотири квадранти. Ці квадранти визначають напрямки, які людина могла б взяти. Він все ще залишався б тестувальником, але міг би вже визначити яку саме форму тестувальника він міг би прийняти.
Шляхом явного перегляду набору основних навичок, таких як дослідницьке тестування, методики випробувань, проблема звітності, парне тестування, автоматизація тестування, навмисна практика, надання зворотного зв'язку та ін., це стає набагато простіше для тестера для визначення того на чому він повинен зосередитися. Дуже важливо, щоб основні навички були вивчені, практиковані і відточені, перш ніж думати про спеціалізовані навички.
Ця схема використовується в особистих бесідах з розвитку між тестерами та їхнім керівником, щоб допомогти знайти їм сильні і слабкі сторони і сформувати мету для подальшого навчання.
Ми випробували це на кількох людях, і ми досі займаємося налаштуванням і оптимізацією. Але цей інструмент виглядає перспективним для допомоги в обговоренні кар'єри.
Є надія, що деякі з тестерів-новачків, подивляться на розділ основних навичок і визначать кілька областей, які вони повинні поліпшити.
Звичайно, це довгий шлях і ми не стверджуємо, що ця схема відповість на всі питання, але це тільки початок.