Про роботу в Zoom, ринок праці для тестувальників та ставлення до українців у Канаді. Історія Дмитра Шпаковського

Дмитро Шпаковський — Senior QA Automation Engineer, який нині працює в компанії Zoom. Три роки тому ми спілкувалися про релокацію в Канаду, особливості проходження співбесід і майбутнє тестування. Цього разу Дмитро розповів про роботу в Zoom, нещодавні скорочення, тренди у тестуванні та ставлення до українських фахівців у Канаді.

Про ринок вакансій для тестувальників: «З позиціями рівня Senior і вище компанії зазвичай чітко знають, чого вони хочуть»

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

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

Можу сказати, що за ці три роки кількість звернень від компаній коливалась так, як і весь ринок. Якщо починалися скорочення, то звернень від рекрутерів за інерцією ставало менше, ніж у «гарячі часи», коли всі билися за таланти. Упевнений, що такі коливання були актуальні не тільки для тестувальників, а й для розробників і девопсів. Тобто картини «найм продовжується, а QA більше не потрібні» я не помітив. Думаю, що на якомусь етапі була навіть зворотна тенденція: почали добирати тестувальників. За ковідний період найняли багато розробників, особливо великі компанії, бо їм треба було зробити якнайбільше фіч, але коли вони почали їх випускати, то зрозуміли, що якість просідає, тож покликали додатково тестувальників.

Про вибір компанії: «Якщо знаєте платформу як користувач, завжди цікаво подивитись на неї очима інженера»

Улітку 2022 року я так само спілкувався з кількома компаніями. На той момент я пропрацював у SurveyMonkey понад три роки і відчував, що досягнув рівня, після якого важко рухатись далі, оскільки у мене була передостання з можливих для Test Automation-інженерів позицій — Senior Software Engineer in Test. Після неї в SurveyMonkey йде тільки Staff Software Engineer in Test. Коли я приєднувався до компанії, на такій посаді була одна людина, коли йшов — додалася ще одна. При тому, що загалом у них майже 2000 співробітників, з яких 400 — це інжиніринг. Тобто, я би сказав, що майже нереально отримати цю позицію без «політичних ігор».

«Для переходу у мене було два основних кандидати — Coursera та Zoom»

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

Coursera була теж привабливим викликом. Але з того, що я зрозумів, спілкуючись з інжиніринг-менеджером, вони перебували на етапі становлення нової QA-структури, там було відчутне легасі. Тобто прийшов новий менеджер, частина людей звільнилися, тому їм треба було підхопити і переробити те, що було. При цьому основні співробітники, які розробляли інфраструктуру, пішли на етапі, коли Coursera виходила на IPO та ставала публічною. Грубо кажучи, вони продали акції, гарно заробили на цьому і звільнилися. Перебудувати легасі звучало заманливо, але будувати нове, що дає змогу робити внесок у добру справу, мені хотілося більше, тож Zoom переміг.

Порівнюючи Zoom із SurveyMonkey, я розумів, що там у мене буде більше перспектив, можливостей для реалізації, оскільки компанія разів у п’ять масштабніша. Крім цього, це світовий бренд, який потрохи набуває рівня Google, коли майже всі знають, що це таке, як цим користуватись, застосовують продукт у повсякденні. Тож мені було цікаво стати частиною цієї історії.

Як наймає Zoom: «Ніхто не буде давати „люте“ завдання на пів дня, чекаючи, що ви миттєво все зробите»

Якщо говорити про співбесіди до Zoom, то жодних кардинальних відмінностей не було. Як зазвичай, спочатку дзвінок з рекрутером, на якому ви обговорюєте наступні кроки.

Інколи буває, що пропонують виконати ДЗ з технічним проєктом. Але публічні компанії, з якими я спілкувався останнім часом, здебільшого їх не дають. Це більш притаманно стартапам. Я дійшов висновку, що не хочу витрачати час на їх виконання. Кілька разів стикався з ситуацією, коли в умовах було написано, що завдання розраховано на дві години, а насправді потрібен день чи півтора, щоб зробити його нормально. Крім цього, треба ще все задокументувати, щоб рев’юверу було легко розібратися. Ви витрачаєте свої вихідні, а потім через тиждень отримуєте відповідь: «О, ми вирішили іти далі з іншим кандидатом». Найчастіше все зводиться до того, що хтось попросив менше грошей.

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

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

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

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

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

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

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

«Коли я проходжу інтерв’ю, теж ставлю свої запитання»

Зазвичай намагаюся з’ясувати, по-перше, наскільки людям комфортно працювати, чи часто бувають овертайми, чи є простір «подихати». Також прошу назвати дві-три речі в компанії, які дуже подобаються і які не дуже подобаються та хотілося б змінити. Речі, які хотілося б змінити — якраз про те, з якими проблемами ви можете потенційно стикнутися. Не можу сказати, що всі відповідають дуже відверто, хтось робить хитренький поворот у позитивний бік. Але є й ті, хто прямо каже: «Є такі проблеми, ось так ми плануємо з ними боротися». Більшість інженерів намагаються бути щирими. Хоча й жорстку критику ви навряд чи почуєте, радше це буде відповідь про щось не дуже комфортне.

Коли я поставив такі питання на інтерв’ю до Zoom, то мені розповіли про документацію, яку непогано було б зробити, підтримувати та розширювати. А також про 12-годинну часову різницю між Америкою і Китаєм, оскільки там перебуває частина команд. Тож спілкуватися з ними не дуже легко: комусь треба або дуже рано встати, або пізно лягти спати. Нічого з того, що я почув, мене не збентежило.

Про офер: «Цікавий бонус, що всім працівникам видали ліцензії на продукт на нескінченній основі»

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

Тепер про офер. Звісно, я не можу оприлюднити соковиті деталі, але є сайт levels.fyi, де збирається статистика за компаніями — розмір компенсації, акції, бонуси. Вони дають наближену до реалій інформацію. Можу сказати, що, звичайно, зарплата була відчутно більша, порівняно з моєю попередньою, інакше не було б великого сенсу йти з SurveyMonkey. Хоча, напевно, я б все одно перейшов, тому що мене приваблює healthcare-сектор. Структура платні приблизно однакова — базова зарплата, RSU (акції), річний бонус. Страховка стандартна. Єдине, що у SurveyMonkey річний бонус залежав від позиції: що вона вища, то більший відсоток від річної платні. У Zoom, наскільки я знаю, відсоток бонусу однаковий у всіх співробітників.

Для мене була важлива кількість вихідних, і тут вона така сама, як у SurveyMonkey — 20 днів на рік, а ось лікарняних тут менше. Деякі взагалі без потреби не беруть sick days, а хтось їх використовує як вихідні. Мені здається, якщо людина бере лікарняний, але у неї не болить нога, проте вона потребує відновлення mental health, то це абсолютно нормально. Вигоряння стало відчутною проблемою. Тож моя думка, що брати sick days для відновлення піде на користь як співробітникам, так і компанії.

У Zoom для мене був цікавий бонус, що компанія всім працівникам видала ліцензії на свій продукт на нескінченній основі, тобто якщо ви навіть звільнитеся, то зможете ним користуватися. Раніше я не бачив, щоб компанії так чинили.

Щодо овертаймів, то це суб’єктивна штука: ви ніколи не дізнаєтеся, чи вони будуть. Навіть в одній компанії в різних командах може бути неоднакове навантаження, бо хтось класно побудував команду, а хтось — ні, у когось є колеги з такою ж роллю, які можуть підхопити, якщо ви пішли у відпустку або захворіли, а у когось — ні, тож ваші завдання будуть просто висіти в повітрі. Для мене в цьому плані мало що змінилося: і у SurveyMonkey, і в Zoom пекельних овертаймів немає, навантаження рівне. Від вас за контрактом очікують 40 годин на тиждень, 160 — на місяць. Але якщо ваші задачі рухаються, то ніхто не буде бігати з годинником і засікати, коли ви пішли поїсти.

Про скорочення: «Я сидів і періодично дивився, чи не забрали у мене доступ до однієї з внутрішніх систем»

Коли я влаштовувався до Zoom у кінці серпня 2022 року, люди були в передчутті, що скоро буде щось погане, але компанії ще не почали різати бюджети та за інерцією продовжували добирати спеціалістів. За п’ять місяців скорочення докотились і до Zoom. Хоча компанія до останнього пручалася, нам казали: «Дивіться, Microsoft скорочує, Amazon скорочує, але це не наша політика. Шлях компанії — триматися наших людей».

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

Наскільки я пам’ятаю, тим, кого скоротили, дали ліцензію на користування Zoom довічно, severance package — зарплатні й акцій за 3–4 місяці та приблизно на стільки ж продовжили страховку. Керівництво підкреслювало, що намагається все зробити якнайделікатніше, що дадуть гарні рекомендації, продовжують вірити, що це сильні інженери, які, на жаль, покидають компанію. Така була політика.

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

Думаю, така ситуація є циклічною для великих публічних американських компаній. Скорочують не через перформанс, а просто тому, що у них є бюджет, який виконується або ні — і вони мають адаптуватись під це. Я не здивуюсь, якщо частина інженерів, яка пішла, потім повернеться до Zoom. Пам’ятаю, що в SurveyMonkey були такі працівники. Щоправда, вони просто переходили в інші місця, а потім повертались. Таких співробітників називають boomerang employee (тут можна почитати цікаву статистику щодо тренду повторного найму).

Про переведення до офісу: «Фізичного офісу в Канаді немає, лише віртуальний»

Оскільки Zoom переводить людей в офіси, виникає цілком логічна хвиля нерозуміння зовні. Адже платформа є одним з піонерів віддаленої роботи. Знаю, що позиція компанії була така: вони хочуть зробити гібридний режим, щоб люди, наприклад, працювали з офісу двічі на тиждень. Перша причина — щоб співробітники більше спілкувались. Маються на увазі water cooler talks, тобто розмови за кавою-чаєм — те, чого ви не робите, коли зідзвонюєтеся з кимось онлайн, якщо, звісно, ви цього спеціально не заплануєте. Також з’являється можливість познайомитися з людьми з інших команд.

Друга причина — щоб працівники користувались додатковими фішками Zoom. Так, у healthcare-команди є продукти, які розраховані на дзвінки між пацієнтами та лікарями, і є кімнати, обладнані спорядженням для цього. Це корисно як клієнтам, щоб вони могли зайти та зрозуміти, як це розгорнути у себе в госпіталі, так і інженерам, які пишуть доповнення, щось виправляють, щоб вони могли «погратись», подивитись, як це буде працювати в реальному житті.

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

Ще у той же Zoom Team Chat вбудований інструмент, щоб робити скриншоти і відразу туди додавати помітки: вказувати на щось стрілочкою, обводити рамкою, підкреслювати, додавати текст тощо. Для мене як для тестувальника це дуже комфортно. До того я звик, що коли приїжджає новий ноутбук, треба зразу поставити свій софт, і одним з інструментів завжди буде скриншот-тул, щоб показувати розробникам, що і де пофіксити.

Ніагарський водоспад

Я працюю дистанційно, як і всі співробітники у Канаді. Фізичного офісу тут немає, лише віртуальний, але він задовольняє всі потреби. Було питання у працівників з Канади, що буде з нами, якщо в Штатах переходять на гібридний формат. І надали офіційну відповідь з таким змістом: «Ми наймали вас на ремоут, ви залишаєтесь на ньому. Ніхто не буде змушувати йти в офіс або переїжджати до Штатів». Якщо я не помиляюся, для співробітників у США також лояльні правила: працювати офлайн лише двічі на тиждень, але тільки якщо живете в радіусі 50 миль від якогось з офісів Zoom. Якщо мешкаєте в іншій частині Сполучених Штатів, ніхто не буде вимагати перебратися ближче до офісу.

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

Про команду й інструменти: «Як і Google, Zoom любить все своє»

Моя команда називається Healthcare Integrations, їй більше як три роки. Вона займається інтеграцією Zoom з великими медичними платформами, продуктами, CRM. Команда розкидана по всіх Штатах, я єдиний у Канаді. Взагалі, наскільки я можу судити, команди в Zoom сформовані не за географічною ознакою, а з огляду на експертизу, м’які навички і часові пояси.

Нас до десяти людей: розробники, інжиніринг-менеджер, Product Owner і я, який повністю займається тестуванням, щоб перекривати в ньому потреби команди. У Zoom саме за тестування нової функціональності зазвичай відповідають розробники. Тобто я виступаю як фінальний погоджувач: до мене приходять з тест-кейсами, я перевіряю, раджу, що краще розширити, як оптимізувати тощо. Потім я все одно передивляюсь їх, коригую. І коли вони вже відкатані, перевірені, затверджені мною, я структурую тест-кейси в більші набори тестів. Плюс відповідаю за всю стратегію тестування: як і що тестувати, що автоматизувати, що ніколи не автоматизувати, які інструменти краще застосовувати, які фреймворки та сервіси обирати.

У Штатах команди, у яких є тестувальники, працюють приблизно так само, як і ми. А ось на боці Китаю — інша, більш традиційна структура: у них виділені команди тестувальників і розробників. Також там відрізняються підходи до написання коду та документації, співвідношення планування архітектури та швидкості виконання.

Працюючи вже понад рік, можу сказати, що в Zoom зручні інструменти. Як і Google, вони люблять все своє, писати внутрішні інфраструктурні речі. Можливо, це пов’язано з безпекою, бо, окрім звичайних компаній, уряди багатьох країн використовують Zoom. Наскільки я знаю, раз на рік вони проходять аудит, щоб усе було сек’юрно і держава дозволяла своїм представникам використовувати цей продукт. Оскільки ми самі відповідаємо за побудову інструмента, його використання та безпеку, то не зав’язані на вразливості деяких інших компаній. Кожна нова фіча проходить аудит окремої безпекової команди.

Про кар’єрне зростання: «Якщо починаєте впливати на інші команди, це дає підстави для підвищення»

Кар’єрне зростання в Zoom цікаво організовано. Наскільки я бачив, тут немає публічних розсилок про те, як пройшов раунд підвищень. Навіть у корпоративній структурі немає чіткого розподілу на рівні. Наприклад, є Software Engineer і Senior Software Engineer, але це можуть бути люди на одному і тому самому рівні внутрішньозумівської компенсації. Ви бачите офіційний рівень позиції колег, але не знаєте, який у кого ранг всередині внутрішньої системи.

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

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

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

Zoom досить нейтральний у плані корпоративної культури, немає якоїсь сильно вираженої фішки, як це, наприклад, є у SurveyMonkey, які позиціонують себе як найбільш справедлива і різноманітна (diverse) компанія. Основний стрижень Zoom — покращення комунікації між людьми, є фокус на клієнта та вирішення його питань просто, швидко і зручно.

Тренди в тестуванні: «Штучний інтелект додає користі, але це не вбивця робочих місць в IT»

Щодо трендів у тестуванні, то мені здається, усе залежить від розміру компаній, їхньої орієнтації. У публічних корпорацій стає менше Manual Test Engineers, більше QA Automation. Навіть так: зменшується кількість Test Automation Engineers, і їхнім завданням стає не написання тестів, а інфраструктури, щоб потім навчати на ній розробників писати та рев’ювити тести. Тобто тестувальники перетворюються на консультантів з покращення тестування, розробників інфраструктури для тестування, популяризаторів використання її та інших інструментів для тестування. У стартапах і непублічних компаніях знову все залежить від їхнього напряму, продукту. Є ті, кому цілком комфортно працювати без автоматизаторів, з десятьма мануальниками. І якщо для них це підходить, то чому ні? Як то кажуть, працює — не чіпай.

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

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

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

Щодо релокації тестувальників, то, думаю, глобально нічого не змінилося. Що вищий ваш рівень, що автономніше можете працювати, вирішувати проблеми, то ціннішим ви є для компанії і то більше вони прагнутимуть вас взяти на роботу. Знаю, що в контексті повномасштабної війни українцям стало навіть легше влаштуватися, тому що деякі канадські роботодавці намагаються якось допомогти наймом. Якщо є кандидат українець/українка і неукраїнець/неукраїнка, то віддадуть перевагу українцям. Часто це буває так, що хтось з українців, який уже працює в компанії, каже: «Ой, у нас є гарний інженер, який приїхав з України. Проведімо співбесіду». І після цього наймають навіть на Junior-позиції, що досить нетипово.

Мітинг на підтримку України в Оттаві

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

Щодо майбутнього в галузі тестування — минулого разу я говорив про відсоткове співвідношення 60% автоматизація і 40% manual. Думаю, що прогноз плюс-мінус справдився. Але я б підкоригував його щонайменше для корпорацій — на 80% та 20% відповідно. Зазвичай роботодавці хочуть, щоб це була одна і та сама людина, яка поєднує два види тестування та максимально автоматизує, в ідеалі — 100%. Але ми всі розуміємо, що це неможливо. Тому 80% автоматизує, а 20% — тестує руками. Тому що, по-перше, треба спочатку потестувати руками, щоб зрозуміти, як це автоматизувати. А по-друге, є корнер-кейси, складні сценарії дій чи багів, які немає сенсу автоматизувати.

За інерцією тренди в Штатах будуть поступово розтікатись на Канаду, далі на Європу, Україну. Напевно, це сприятиме тому, що будуть Software Development Engineer in Test, які охоплюватимуть і мануальне тестування, і автоматизацію, але компанії віддаватимуть перевагу автоматизації і стимулюватимуть максимальну кількість сценаріїв покривати нею.

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

Книги, блог і open source

Я продовжую відстежувати аналітику свого блогу: як люди на нього потрапляють, за якими запитами, що вони читають тощо. Але останній рік я не писав до нього, більше уваги сконцентрував на open source. Продовжую контриб’ютити та не збираюся від цього відмовлятися, бо це активність, яка дає відчуття повернення користі спільноті. Так ви допомагаєте людям використовувати певні інструменти, покращувати їхнє тестування, інженерні практики.

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

У мене є ідея ще однієї книжки, але поки що складно виділити час на її написання. Хотілося б, щоб у неї увійшли висновки, які я зробив зі свого досвіду, корисні поради, практичні підходи до тестування, а також трохи філософських роздумів про співбесіди та ринок IT для інженерів з тестування. Я не готовий оприлюднити фінальний каркас, але кодова назва «Notes from a decade in testing». Тож, як то кажуть, stay tuned — найімовірніше вона з’явиться на Amazon.

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

Про плани: «Канада продовжує виглядати для мене як гарний варіант»

Я хочу все глибше поринати в healthcare-індустрію, мене б зацікавив проєкт, спрямований на медицину або біотехнології.

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

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

В особистому плані я не планую жодних змін. Не хочу релокуватися до Штатів: Канада мені подобається більше, не бачу потреби змінювати місце проживання. Хто знає, може, у майбутньому з’явиться щось цікаве в Європі. Повернення в Україну також можливе. Взагалі хотілося швидше перемоги. З початком повномасштабної війни стало набагато важче робити прогнози.

Похожие статьи:
Советы сеньоров — новая рубрика,...
[Об авторе: Виталий Лаптенок — развивает свои продукты уже порядка 8 лет — начинал с проекта TUT.BY...
«МегаФон» первым из мобильных операторов начал сотрудничество с российской платежной...
У каждого наступает момент в жизни, когда он/она перестает жить на родительские деньги...
Чому така назва? Тому що практична практична філософія — то важлива штука: •...
Яндекс.Метрика