«У світчерів майже завжди є перевага». Поради тестувальникам-початківцям від Senior QA Engineers
Нині за одне місце в компанії на позицію QA Manual у середньому змагаються 44 кандидати, і 5 — якщо йдеться про QA Automation. Ці показники є найвищими серед технічних спеціалістів в IT, що свідчить про неабияку конкуренцію. Певну роль у збільшенні кількості кандидатів відіграють і світчери, яких з початком повномасштабної війни побільшало.
DOU поспілкувався із Senior QA Engineers про те, як вони починали свій шлях у професії та що сьогодні можуть порадити тим, хто вирішив стати тестувальником.
«Для нормального старту і розвитку потрібно знати хоча б одну мову програмування й ООП»
Михайло Чуга, Senior QA Engineer у SQUAD
Те, що я став QA Engineer, можна назвати закономірним збігом обставин. Усе «довколоайтішне» цікавило мене ще зі школи. Я охоче навідувався до місцевого радіогуртка, збирав різної складності прилади і в 10 років вивчив частину програми
Пізніше, коли зʼявився перший компʼютер, з ним виник і більший інтерес, ніж просто «грати в ігри й друкувати реферати». Приблизно у 15 років я дізнався, що таке Linux і програмування на Basic. Одного разу навіть вийшло зібрати й оновити ядро, що в ті часи було на диску журналу «Хакер» :) Тобто ще з дитинства я був зацікавлений в ІТ і вбачав у ньому перспективу. Ну і, звісно, це привело до вибору відповідного навчального закладу — Київського національного університету технологій та дизайну, кафедра «Інформатизації і компʼютерно-інтегрованих систем».
Під час навчання мені хотілося працювати за спеціальністю (хоча обʼєктивно я ще не бачив, що саме хочу робити). Після третього курсу я опинився на практиці в компанії мого товариша, що займалася роумінговим звʼязком. І хоч там вдалося трошки покодити, здебільшого це було схоже на сучасний DevOps: налагодження інфраструктури, процесів деплою тощо. Вже після четвертого курсу я потрапив у маленьку продуктову компанію адміном, де згодом почав тестувати продукт, який вони розробляли (тоді це був онлайн-покер). Це важлива частина історії, бо там, вважай, не було налагоджених процесів, тести були в Excel, і все плавно змінювали в бік якості; починали використовувати нові інструменти, запроваджували щось на кшталт Scrum. У підсумку жодна навичка, здобута на цьому шляху, не була даремна.
Мені пощастило потрапити на практику, де старші колеги просвітили, що є такі речі, як Perl, Bash, що можна гнучко все використовувати й комбінувати. Я робив задачки «за дякую», втім досвід здобув. Та вже тоді відчував, що мені все ж бракує знань для карʼєрного розвитку.
За рекомендацією колег я почав вчити C#. Мені ця мова здалася дуже дружньою як для новачка. Памʼятаю, як зачитував куплену на стипендію товстенну книжку... Також базово я вивчив усі парадигми ООП і повʼязані технології. Після року роботи в онлайн-покері я вже опанував віртуалізацію, мережі та Linux. І це допомогло мені, коли я почав працювати в аутсорсі на проєкті, повʼязаному з Mobile Security. Пізніше, у наступній компанії, я використовував той самий C#, коли покривав мануальні тести автотестами (використовували Selenium і .NET).
До чого я веду? Для нормального старту і розвитку потрібно знати хоча б одну мову програмування й ООП. Просто для банального розуміння того, що коїться «під капотом», та якісного покриття функціональності тестами, а не клацання формочок. Звісно ж, напрям Automation неможливий без цих знань. Хоча легко знайдете задачі, де буквально треба написати з нуля, наприклад, вебсервер, що імітує потрібну поведінку бекенду (привіт, Python).
Також важливим є знання мереж, моделі OSI, TCP/IP та інших протоколів. Думаю, вже немає проєктів, що не містять передачу даних.
Ще одна важлива вертикаль — SQL, починаючи від вебпроєктів і завершуючи банальним збором логів. Розуміння баз даних і вміння витягнути інформацію з них потрібне і важливе.
Якщо ж говорити про профільні знання для QA, то однозначно потрібно зазубрити ISTQB Syllabus. Філософія, підхід і процеси розробки — все там.
Тестувальник — це інженер, «технар». Відповідний багаж знань і навичок робить його кращим за конкурентів, коли на ринку пропозиція перевищує попит.
У мене є знайомі, які повелися на пропаганду «Увійти в IT легко та весело!». Вони спробували, але не вдалося... Одна з основних причин відмов — банальне незнання англійської. Як не крути, але ми здебільшого працюємо на експорт, і вміння комунікувати із замовником надважливе. Багатьох знайомих, які і досвід мали, і бажання, завертали просто через це. Вчіть мову, дивіться навчальний контент англійською, пробуйте спілкуватися. Інвестуйте в це.
Якщо говорити про більш специфічне, то коли ви умовно 10 років займаєтеся випічкою чи шиттям, маєте досвід і вміння, є професіоналом своєї справи, а потім раптом змінюєте вектор життя, це вимагатиме дуже багато часу.
Треба розуміти, що зміна сфери діяльності завжди повʼязана з ризиком, не всі мають змогу просто піти з роботи, сказавши: «Я звільняюсь і стаю тестувальником». Не у всіх є можливість рік сидіти вдома і вчити базу, особливо тепер, коли чимало українців втрачають роботу.
Відповідно не кожен може прийняти те, що буде важко, що доведеться віддавати весь вільний час самоосвіті. Ніхто не стає хірургом за 21 день і не починає робити видатні операції на серці. Тож я б це назвав персональною відповідальністю за себе і свій вибір. Ви будете факапити, будете чогось не знати. Це нормально. І на це піде час.
Нормально й отримувати відмови. Перед першим офером в IT я розіслав сотні резюме, завалив не одну співбесіду. Але так має бути, бо це досвід. Я згадую свою співбесіду у велику компанію, де були важкі (як на той момент) питання. І там, де не знав відповіді, я так і казав: «Не знаю, що це, але якщо знадобиться в роботі, я загуглю і вивчу». Будьте щирі й визнавайте, коли чогось не знаєте. Я не раз бачив, як люди вдають, що щось «знали», але забули. Зрештою я отримав роботу, хоча певен, що були кандидати, які знали більше за мене.
З того часу я не готувався до співбесід, сидячи й повторюючи усе вечорами, а просто йшов з тим набором знань, які збирався «продавати» роботодавцю. Не більше, не менше. І кожна співбесіда була успішною.
Щодо світчерів сьогодні і їхніх шансів отримати роботу. Оскільки IT — це бізнес, і фактором тих чи інших рішень є потенційна вигода, компанія охоче інвестує у власних нетехнічних працівників, які мають бажання змінити фах, коли бачить, що в людини є мотивація і базові знання. Наприклад, співробітник працює у підтримці, приблизно розуміє продукт, вміє розв’язувати конфлікти й має бажання зростати. Такий перехід з нетехнічної спеціальності в бік інженерної є досить реалістичним і навіть перспективним. Бо компанії вигідно мати справу з тим, хто вже в контексті. Особливо коли продукт специфічний і знайти спеціалістів з досвідом нереально (це, до речі, про Embedded).
Щодо людей з інших галузей, то тут, обʼєктивно, все складніше. Я маю наразі лише один успішний приклад — подруга змінювала сферу діяльності, і їй це вдалося. Приємно усвідомити, що я доклав до цього руку (давав базові знання з вищеперелічених напрямів). Щоправда, вона стала PM, але отримані знання знадобилися, щоб зрозуміти продукт і налагодити роботу команди. Вона — чудовий приклад того, коли людина пристає на ризики, бере відповідальність і сумлінно працює та досягає успіху.
Підсумовуючи, скажу, що, на жаль, у світчерів буде менше шансів, ніж у людей з профільною освітою і досвідом, за будь-яких умов. Але все тільки в їхніх руках. Працюєте — отримуєте результат.
Тож потрібно змиритися з тим, що легко не буде. На ринку багато охочих, і всі у плюс-мінус схожих умовах. Відповідно треба викластися на максимум.
Не ведіться на гарну рекламу і гасла курсів. Якось я ледь не почав викладати на таких, проте після пробного вебінару, де розповів факти про ринок, зі мною не дуже захотіли співпрацювати... навіть не дали фідбеку :) На таких курсах, можливо, і дадуть знання, але вони будуть дуже «гуманітарні». Вам доведеться вивчити технічну частину, якщо плануєте займатися цим довго і якісно. Зацитую подругу-PM: «Наявність знань з курсів допомогла зрозуміти, куди рухатися, побачити загальний напрямок».
Наостанок пораджу спілкуватися з людьми, які мають досвід у сфері IT. Свого часу це допомогло мені, бо ви бачите живий приклад і можете перебрати ті чи інші знання. Та й навіть на DOU у профільних темах можна подивитися авторів, вивчити навички й досвід, і в такий спосіб підтягнути свої знання про технології, оскільки ці люди вже QA, а ви тільки робите перші кроки.
«Я не погоджуюся з думкою, ніби увійти в IT через тестування найпростіше»
Євген Толчинський, Senior QA Engineer у WIX
Я багато років працював у банках — будував кар’єру (одна з моїх вищих освіт — фінансова). Та одного дня мені все набридло і я зрозумів, що в банку більше працювати не хочу. Певний час після цього рішення я продавав софт і «залізо» великому корпоративному бізнесу, аж поки один з клієнтів не запропонував мені співпрацю, в межах якої я мав створювати IT-інфраструктуру банків. Тож на деякий час я знову повернувся у цей сектор.
Однак після Революції гідності, окупації Криму й початку бойових дій усе змінилося. Власник бізнесу сказав, що ситуація нестабільна й він розпускає команду. Після цього я став волонтерити: перекладав з англійської інструкції до користування турнікетами й іншими медичними приладами, бо людині на полі бою точно не до цього. Аж поки до мене не звернувся друг із проханням «поклікати» сайт. Я погодився, бо за це він пообіцяв мені пляшку хорошого віскі [усміхається]. Я «поклікав» і склав в Excel щось на кшталт баг-репорту: кнопка не натискається, не надсилається форма зворотного зв’язку тощо.
За тиждень-два я зустрівся зі знайомою й із запалом розповідав їй, як мені сподобалося працювати над сайтом. А вона каже: «Так це те, чим я займаюся на позиції QA». Тож я став розпитувати її більше про професію. Вона надіслала мені кілька лінків, зокрема й на DOU, і мені сподобалося те, що я дізнався.
Друг, для якого я тестував сайт, постійно запускає стартапи, тож я повернувся до нього з питанням, чи не знайдеться для мене роботи. І він найняв мене, щоправда, не лише тестувальником, а й PM та BA паралельно. У нас була невелика команда, зокрема фрилансери, тож потрібен був той, хто зможе налагодити процеси.
Далі я перечитав чи не всі статті, які тільки міг нагуглити, про QA. А потім та ж знайома тестувальниця розповіла мені про курси від EPAM. З другої спроби мені вдалося на них потрапити. Паралельно, оскільки у мене була парт-тайм робота, я також влаштувався адміністративним директором однієї IT-школи в Києві. Закінчив курси не лише з QA, а й PM, оскільки мене цікавили й менеджерські обов’язки. Забігаючи наперед скажу, що після побаченого у роботі PM ця сфера мене не цікавить :)
Чи всім тестувальникам-початківцям потрібні курси? Однозначно не скажу. З одного боку, коли шукаєте інформацію самостійно, вона краще вкладається в голові (принаймні мені). З іншого боку, я знаходив стільки нісенітниць! Коли немає ментора, який скаже, що читати, а що ні, в голові все буде невпорядковано. Тож у цьому аспекті курси допомагають — вони фільтрують інформацію і дають її у потрібній послідовності. Можна спочатку вивчати, як побудовані мережі, API тощо, а тільки потім розбиратися з документацією. Але, на мою думку, це трохи неправильно, бо ви все одно сприйматимете цю інформацію як тонну непотрібної теорії. Курс — не панацея, як не є панацеєю і самостійне вивчення. Тож кожен обирає для себе найзручніший спосіб.
Якщо ви світчер, раджу зважати на вже наявний досвід. Наприклад, людина має досвід у банківській справі й розуміється на фінансах. Якщо в команду потрібен спеціаліст, якому доведеться тестувати СRМ-систему, а ви в очі її ніколи не бачили, краще шукати іншу вакансію.
Якось я наймав людину, яка досить посередньо знала теорію тестування, на «четвірочку» розумілася на мережах і технічній частині. Але вона сім років працювала з 1С. Відповідно мені не потрібно розповідати їй, що таке інвентаризація, баланс підприємства абощо. Значно простіше допомогти новачку в ІТ вивчити тест-кейси, ніж переповідати економічну теорію з першого курсу університету.
Коли знань у тій чи іншій доменній сфері немає, потрібно добре вивчити теорію, технічні аспекти, як-от відповіді сервери, якщо ми кажемо про API, запити, що надсилаються тощо.
Крім того, коли я шукаю фахівця в команду, мені завжди цікаво чути від людини запитання. Для мене співбесіда — це діалог. Це не має виглядати так, ніби кандидат стоїть на воротах, а я б’ю пенальті.
Читайте також
