«У світчерів майже завжди є перевага». Поради тестувальникам-початківцям від Senior QA Engineers

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

Нині за одне місце в компанії на позицію QA Manual у середньому змагаються 44 кандидати, і 5 — якщо йдеться про QA Automation. Ці показники є найвищими серед технічних спеціалістів в IT, що свідчить про неабияку конкуренцію. Певну роль у збільшенні кількості кандидатів відіграють і світчери, яких з початком повномасштабної війни побільшало.

DOU поспілкувався із Senior QA Engineers про те, як вони починали свій шлях у професії та що сьогодні можуть порадити тим, хто вирішив стати тестувальником.

«Для нормального старту і розвитку потрібно знати хоча б одну мову програмування й ООП»

Михайло Чуга, Senior QA Engineer у SQUAD

Те, що я став QA Engineer, можна назвати закономірним збігом обставин. Усе «довколоайтішне» цікавило мене ще зі школи. Я охоче навідувався до місцевого радіогуртка, збирав різної складності прилади і в 10 років вивчив частину програми 8–9 класу з фізики.

Пізніше, коли зʼявився перший компʼютер, з ним виник і більший інтерес, ніж просто «грати в ігри й друкувати реферати». Приблизно у 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, запити, що надсилаються тощо.

Крім того, коли я шукаю фахівця в команду, мені завжди цікаво чути від людини запитання. Для мене співбесіда — це діалог. Це не має виглядати так, ніби кандидат стоїть на воротах, а я б’ю пенальті.

Читайте також 👇Мені, наприклад, цікаво, чи дізналася людина щось про компанію напередодні. Я розумію, що коли йдеться про велику аутсорс-компанію, невідомо заздалегідь, на який проєкт потрапите, але якщо це маленька компанія на 50 людей, можна зайти в Google і почитати про неї. Я завжди готуюся до співбесід, хоч і провів їх понад 100. Відповідно, коли людина приходить непідготовлена й не знає, чим займається WIX, де я працюю нині, це справляє не надто гарне враження.

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

Я не погоджуюся з думкою, ніби увійти в IT через тестування найпростіше. Потрібно знати, нехай і не все, втім досить багато інформації щодо Front-end, Back-end, роботи DevOps. Ми з колегами часом жартуємо, що я знаю про Back-end нашого сервісу більше, ніж Lead Front-end. А враховуючи те, скільки сьогодні кандидатів подаються на одну вакансію (особливо якщо це перша робота), QA — точно не найлегший шлях увійти в IT.

Те, що в індустрію приходять нові люди зі свіжим поглядом, — чудово. Чому чимало айтівців проти цього? Просто не всі розуміють, хто такі світчери і «як їх готувати». Якщо в людини невеликий досвід, а з неї у компанії питатимуть як з Senior QA з 10 роками досвіду, це безглуздо. Потрібно давати легкі завдання і розуміти, що, можливо, доведеться розповісти частину курсу IT-факультету КПІ; що новачок може не розуміти мережеві протоколи абощо. Це ж круто, коли людина вчиться нового.

І мене дивують, зокрема, спеціалісти рівня Senior, які через конкуренцію проти того, щоб в IT приходило більше людей. Поки джун стане сеньйором, мине зо п’ять років. Якщо ви за цей час не наберетеся додаткових знань і конкуруватимете з тим, хто сьогодні джун, то який з вас спеціаліст?

Я дуже люблю одну приказку: «Мудрий вчиться на чужих помилках, розумний — на своїх, а дурний — не вчиться зовсім». Тому раджу новачкам завжди просити фідбек. Не у всіх компаніях він передбачений, і подекуди, якщо це не обов’язок, ті, хто проводив співбесіду, забувають давати зворотний зв’язок. Але якщо, наприклад, мені написати й попросити дати фідбек, я це зроблю. Тож будьте як не мудрими, то розумними, і вчіться на власних помилках.

«Моїм неймовірним і постійним козирем була англійська»

Марина Кубічка, Senior QA Engineer в Astound Commerce

Я починала кар’єру в ІТ як викладачка англійської для програмістів і, готуючись до занять, сиділа в кабінеті з QA-інженерами. Мене зацікавило те, чим вони займаються, як саме працюють з різними застосунками, як ці застосунки взагалі можна протестувати... Хоча раніше я не замислювалася над такими речами, тут мене раптом захопило. Тому я почала розпитувати, що треба вчити, в якому напрямку рухатись, а згодом — записалася на курси QA.

Чи легко світчерам потрапити в IT? Напевно, це залежить від сфери, з якої вони прийдуть. Але що за мого світчерства, що нині я з упевненістю кажу: ця сфера однозначно не всім дається з легкістю.

Моїм неймовірним і постійним козирем була англійська. І ті, хто стверджує, ніби цю навичку можна опустити, ніби вона не є такою ж важливою, як технічні знання, дуже помиляються. Тому я точно раджу новачкам для початку підтягнути англійську. Я свого часу фокусувалася на вивченні саме бізнес-англійської.

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

У чому полягають поширені помилки новачків? Дехто начитується теорії, завчає терміни й уже пробується на інтерв’ю. Але оскільки людям бракує практики і розуміння цієї теорії, співбесіди даються важко. Тому я рекомендую на початку все ж шукати курси, онлайн чи офлайн, де буде ментор. Можливо, хтось з друзів чи колег може вас підучити й пояснити незрозумілі моменти.

Чи є переваги у світчерів перед тими, хто має профільну освіту й від початку був націлений на кар’єру QA? Напевно, це залежить від самої людини. Часом ті, хто має профільну освіту, просідають у soft skills. До прикладу, у вмінні комунікувати й ладнати з людьми. А ті ж світчери, які, скажімо, мають педагогічну освіту, легко з цим справляються. Зі мною, наприклад, працюють колишні юристи, слідчі, економісти, бухгалтери, і, на відміну від «технарів», у них може бути кардинально інший тип мислення, інші підходи й методи розв’язання завдань.

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

Кожна нова співбесіда — це додатковий досвід. На інтерв’ю вам підказуватимуть, куди рухатися і які саме теми підучити. Навіть якщо вам не дали офер, не розчаровуйтеся, адже наступний може бути вашим.

«Будь-який досвід в інших сферах може стати в пригоді як під час тестування, так і просто під час роботи з людьми»

Євген Тихоліз, Senior QA Engineer у Ciklum

QA Engineer я став років дев’ять тому. Закінчував магістратуру у Київському національному університеті імені Шевченка за спеціальністю «Прикладна фізика», і треба було обирати, куди рухатися далі. Я мав технічні знання, дипломну з моделювання фізичного процесу, але до програмування не тягнуло взагалі. Я став дивитися, які ще є суміжні професії, і відкрив для себе тестування. Це саме те, що підходило мені ментально та професійно. Про свій вибір не пожалкував.

Спочатку здебільшого я вчив, які є процеси в IT та QA зокрема, теорію з тестування. Намагався заглибитися в професію, з’ясувати, який тип мислення для цього потрібен. Зараз насправді опановувати професію простіше, оскільки в інтернеті є більше якісного та структурованого матеріалу для навчання.

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

Тобто у світчерів майже завжди є перевага. Будь-який досвід в інших сферах може стати в пригоді як під час тестування, так і просто під час роботи з людьми. Мені відомо багато випадків, коли завдяки попередньому досвіду людину швидко забирали на проєкт. Фізика, охорона здоров’я, автомобільна промисловість тощо — такий досвід і знання здобути набагато складніше, ніж підготувати QA.

Нині можна знайти багато інформації. Почніть з будь-якого безоплатного курсу, а краще — з кількох, для закріплення знань. Це може не тільки зекономити вам гроші, а й пришвидшити навчання.

Створіть гарне резюме. Не треба, щоб воно майоріло фарбами. Сконцентруйтеся на структурі й наповненні. У вас вже є досвід роботи. І, найімовірніше, ви так чи інакше щось колись перевіряли раніше. Зробіть акцент на цьому, а решту відкиньте або опишіть стисло.

Вчіть лексику, що використовують в IT, це допоможе в перші тижні роботи і на співбесідах. На цьому етапі кожна ваша співбесіда — це вже гарний досвід. Намагайтеся запам’ятати кожну та потрапити на якомога більшу їх кількість.

👉🏼 Долучайтесь до QA-спільноти DOU в Telegram!