Катерина Несмелова — QA з понад десятирічним досвідом, одна з небагатьох в Україні, хто отримав сертифікацію Full Advanced Level ISTQB. Вона працює Test Lead у внутрішньому ІТ-відділі компанії PricewaterhouseCoopers (PwC) в Digital Transformation Team у Новій Зеландії. Маючи за плечима багаторічний досвід тренера з підготовки до ISTQB, Катерина Несмелова розповіла про те, як успішно здати цей екзамен і чому досвідченим QA це вдається важче, ніж початківцям, підготовку до релокації, розвиток ІТ-сектора у Новій Зеландії й хто такий «справжній тестувальник».
— Раніше ви займалися здебільшого Quality Control. Зараз ви — Test Lead у PricewaterhouseCoopers (PwC) в Digital Transformation Team, а це інший бік тестування. Розкажіть про це.
Я була тестувальницею у найпоширенішому сенсі. Працювала разом з девелоперами, займалася більш технічними аспектами тестування. Зараз в мене немає доступу ані до девелоперів, ані навіть до багтрекера. Тому напрямок моєї роботи справді сильно змінився. Здебільшого займаюсь приймальним тестуванням кінцевого користувача — user acceptance testing з елементами керування проектами. А це дає зовсім інший погляд на продукт. В тестуванні дуже важливо розуміти потреби кінцевого користувача, і це додає драйву в роботі, бо кожний день я працюю паралельно над трьома-п’ятьма різними проектами. А це вимагає зовсім інших професійних навичок.
Я керую тестувальниками, але не професійними: це представники бізнесу, справжні кінцеві юзери. Коли ми апгрейдимо продукт, я тестую його сама. Але передусім мені необхідно, щоб продукт протестували люди, які будуть виконувати свою роботу за допомогою цього продукту. Востаннє я керувала командою з тринадцяти осіб по всій Новій Зеландії, охоплюючи обидва острови. Мені було потрібно скорегувати роботу всієї команди, пояснити кожному суть його роботи, розробити приблизні сценарії того, що треба перевірити. Хоча це не моя робота, бо самі користувачі мають знати, як повинен використовуватися цей продукт.
— В чому специфіка вашого відділу?
В нас майже немає автоматизації. Ми дуже мало розробляємо внутрішнього софту в рамках нашого локального новозеландського відділу. За дуже короткий час мені потрібно зрозуміти, як працює той чи інший продукт, протестувати його не тільки з точки зору базового функціоналу, але й найважливіших слабких сторін, наприклад, інтеграції з вже існуючим програмним забезпеченням, а потім прослідкувати за тим, аби кінцеві користувачі теж щільно протестували програму. Тому на передній план виходить дослідницьке тестування — exploratory testing.
Зараз усі ми потрохи просуваємося в бік continuous deployment — програміст пише код, тисне кнопку й за дві години цей код вже в Production. Частіше за все, це якась дуже маленька зміна. До прикладу, частка нового функціоналу або частика виправлення дефекту. У тестувальників вже немає ані можливості, ані часу використовувати старі підходи. Код вже не деплоїться в Production великими шматками кілька разів на рік. Крихітні шматочки вистрілюють чи не кожну годину. У червні робитиму про це доповідь на конференції The Australia and New Zealand Testing Board 2018 (ANZTB2018).
Сьогодні реактивний підхід до тестування, який був актуальним ще п’ять років тому, відмирає. Ти не можеш реагувати лише на те, що тобі дають, а повинен бути в центрі команди, рухаючись й щільно співпрацюючи з її іншими членами. Ми не можемо займатися реактивним тестуванням: виключно тестуванням вже готового продукту, написаного розробниками чи виданого бізнес-аналітиками. Ми самі повинні бути бізнес-аналітиками, передбачати можливі проблеми як з технічного аспекту, так і з бізнес-аспекту.
Тестувальник перестає бути просто тестувальником, він стає більш T-shaped професіоналом, який має багато знань із сумісних областей. Коли програміст натисне кнопку задеплоїти код, ми вже не можемо нічого змінити чи протестувати, адже продукт вже пішов в Production. Ми повинні тестувати набагато раніше, починаючи зі стадії ідеї, та щільно співпрацювати з командою. Звичайно, є певні засоби, завдяки яким можна тестувати й в Production — feature switch, коли новий код є доступним лише для команди розробників, але не для юзерів. Але якщо щось хибне, навіть якщо воно не доступне для користувача, це може зруйнувати живу Production базу даних.
— Як ви потрапили в ІТ?
Це був смішний випадок. З 1998 по 2004 рік я працювала викладачем комп’ютерних дисциплін для нетехнічних фахівців, на кшталт фінансистів, економістів, менеджерів, у Харківському національному аерокосмічному університеті (ХАІ за тих часів). Якось в обідню перерву мій колега, що працював паралельно в одній ІТ-фірмі, сказав, що їм потрібні програмісти з добрими знаннями англійської мови, мова навіть важливіша за навички в програмуванні. В нас студенти не знали ні мови, ні програмування. На той час я англійську знала досить добре, програмування — в рамках своїх курсів — Pascal, Delphi, трішки С++, бази даних. Я вирішила спробувати й опинилась на посаді тестувальниці. Працюю вже п’ятнадцять років, й ніяк не відпускає. Випробовую різні галузі, напрямки, підходи, різні країни. Коли нудно, пробую себе в іншій ролі.
— Як виглядали ваші перші дні в новій професії?
Складно, але й цікаво. Перший місяць на будь-якому новому проекті так і виглядає: я нічого не знаю, нічого не розумію, як я сюди потрапила, що мені робити, заберіть мене звідси. Це цілком нормально. Адже за дуже короткий проміжок часу необхідно в’їхати в контекст справи, зрозуміти, як воно працює. Більшість членів команди вже в курсі, а ти одна — ні. Але тут є дуже важливий момент, який я зрозуміла лише через багато років. Всі ми в дечому не компетентні, а робити помилку в новому для тебе контексті цілком природно. На мою думку, очікувати від нової людини моментальної ефективності — безглуздо. Треба робити помилки і не соромитися їх. Чим більше ви зіштовхуєтесь проектною новизною, тим менше у вас стресу. Професіоналізм полягає саме в тому, аби вчитись швидко опановувати контекст і виділяти пріоритетні речі. А ще — співпрацювати з колегами, навчаючись від них та разом з ними.
— Як далі склалась ваша кар’єра в ІТ?
У першій компанії я пропрацювала близько чотирьох місяців. Там вважалось, що вершина кар’єри тестувальника — це стати програмістом. Мені це не подобалось, тому я вирішила шукати своє місце. Далі була Validio, яку згодом придбав GlobalLogic. Там було багато цікавих та різноманітних проектів, пов’язаних, здебільшого з медициною. Проте за два роки я зрозуміла: так, як там робиться тестування, — не моє. А коли воно зміниться, було невідомо. Тому знайшла маленьку компанію, де займалась тоді ще дуже новою темою data mining. Там я налагодила процес розробки та тестування, але не було перспектив росту. Наступною була EPAM, де я провела три роки, зробивши кар’єру від Senior Software Tester до Test Manager. Напевно, саме там були мої найкращі часи як менеджера. В мене була найкраща команда й дуже цікавий проект, який ми змогли зробити ефективним та розширили нашу команду більш ніж вдвічі.
Згодом я стала мамою. З декретної відпустки вийшла у Murano Software на дуже цікавий стартап-проект, пов’язаний з data centre management, який згодом придбала компанія Ericsson. Це був дуже цікавий досвід з неодноразовими відрядженнями до Сполучених Штатів. Коли ти випадаєш з родинного кола на
Коли ми вирішили спробувати переїхати до Нової Зеландії, я не знала, чи зможу знайти роботу на позиції менеджера. А для роботи на позиції senior software tester мені був потрібен свіжий hands-on experience, якого на той час я вже довго не мала. Тому я вирішила в деякому сенсі зробити даунгрейд і зайнятись більш технічною роботою, що б допомогло мені знайти роботу саме технічного спеціаліста. Тому я повернулася до Murano Software на інший проект, де займалась більш практичним аспектом тестування. Коли ми переїжджали до Нової Зеландії, в мене вже був підписаний контракт на позицію senior software tester від команії Orion Health. Але знову кар’єрні перспективи були не дуже. Так я й потрапила до PwC на позицію Test Lead. Гадаю, що саме такий різнобічний досвід відкрив мені нові можливості.
— Над чим обов’язково потрібно задуматись перед релокацією?
Як на мене, у Новій Зеландії дуже гарний, м’який клімат й немає снігу та дощів тижнями. Принаймні в Окленді, де ми мешкаємо, клімат набагато кращий, ніж у Харкові. Стресові епізоди, звісно, були: чи зможемо ми тут працювати, як донька житиме, не знаючи англійської, та інше. Але з роботою проблем не було. Англійська була на доброму рівні.
Ключовий момент при переїзді: дослідження потенційних проблем та їх вирішення. Я дуже раджу вивчати всі доступні ресурси — від офіційних до форумів, де мігранти розповідають про деякі моменти, яких ти не побачиш в офіційних джерелах. Там вони діляться власним досвідом. Треба розуміти, чи зможеш ти прийняти всі відмінності й жити з ними. І чи зможеш ти собі це дозволити фінансово. Наприклад, найбільша проблема тут — все дуже дорого. По-перше, оренда житла, потім — їжа. А ще — дуже холодно взимку. Незважаючи на те, що температура дуже рідко буває нижче +5, вдома запросто може бути +7. Потрібно мати план Б у разі, як щось піде не так.
— Який план Б був у вас?
Повернутися в Україну. Ми створили резерв грошей на квитки та перші місяці життя в Україні, доки не знайдемо роботу.
— Наскільки швидко розвивається ІТ-сектор в Новій Зеландії, порівнюючи з Україною?
Як на мене, український ІТ-сектор на аутсорсі відверто випереджує Нову Зеландію на
— Що ви маєте на увазі?
Зараз тут дуже популярний скрам, всі намагаються його розповсюдити, а в нас він вже відмирає потроху. Півтора роки тому на конференції з програмування один зі спікерів розповідав, як вони налагодили continuous integration за допомогою Jenkins — аудиторія була у захваті. А ми з командою втілювали подібний процес років за п’ять до моєї релокації до Нової Зеландії. Хоча мені здається, що Україна і Нова Зеландія йдуть в одному напрямку — намагаються бути просунутими. На жаль, часто це відбувається у вигляді карго-культу, коли люди починають буквально копіювати все одразу з думкою, що на виході вони отримають такий самий результат. Але при цьому зовсім не беруть до уваги локальний контекст, поточні умови проекту, навички та настрої команди. Це відноситься до скраму, continuous deployment, big data тощо.
Знаю випадок, коли одна компанія вирішила завести собі відділ big data просто тому, що у всіх просунутих компаніях є такий відділ. Нащо він потрібен, як ці дані потрібно використовувати в роботі, який прибуток воно принесе клієнтам — вони не розуміли. Ще один приклад розповіла колега. В її компанію прийшов новий менеджер. Він одразу змінив процес на скрам. Протягом одного тижня. Вперше за всю історію існування компанії випуск продукту був затриманий на три місяці.
— Як ви оцінюєте розвиток спеціальності QA-інженера в Україні та у світі загалом?
Професія тестувальника не така вже й молода. Вона завжди була, але чомусь, на мій погляд, вважалася другосортною, не такою важливою, як професія програміста. Але все змінюється. Зараз нова ідея фікс — тотальна автоматизація. Це не зовсім правильно, бо якщо автоматизувати хаос, то на виході ти отримаєш тільки автоматизований хаос. До того ж, ефективно автоматизувати можна далеко не все, а дещо цілком неможливо.
— Чому?
Як можна автоматизувати, наприклад, user experience? Чи зручно юзерам використовувати нашу програму для вирішення їхніх проблем? Чи ефективно з точки зору кінцевого користувача це виходить? До того ж, перш ніж щось автоматизувати, треба розуміти, що ж саме необхідно зробити, і як це зробити найефективніше. Для мене автоматизація — це спільна робота тестувальника та девелопера. Хтось краще пише код, хтось краще розуміє, що саме потрібно перевірити і як. Дуже часто я бачила «автоматизаторів», які були, як морська свинка — ані код писати не вміли, ані в тестуванні не розбиралися. Справжніх профі я бачила дуже мало.
Нещодавно я почула дуже цікаву дефініцію — «тестувальник-автоматизатор». Це людина, яка краще за програмістів розбирається в різних тулах для автоматизації та може їм підказати, що краще використати в тому чи іншому випадку. Звісно, є речі, які неможливо зробити вручну — те ж перфоманс-тестування. Якщо ми ведемо розмову про continuous deployment, там автоматизація взагалі передусім. Але в цьому випадку якість автотестів повинна бути кращою за якість самого коду. І це — командна задача, яку кожна команда повинна розв’язувати самостійно.
— Чому ви не хотіли перейти в інший розряд, наприклад, програмування? Чому сьогодні не спостерігається особливої тенденції в ІТ, коли тестувальники без вагань стають програмістами?
Програмування — не моє. Я можу писати код, але мені це не дуже подобається. Є те, що в мені вдається значно краще за написання коду. Наприклад, проводити тренінги. Щодо тенденції, не думаю, що взагалі є тенденція мігрування з тестувальників у програмісти чи навпаки. Все залежить від конкретної людини, її схильностей та обставин. Я знаю людей, чий кар’єрний шлях змінювався як в одному, так і в іншому напрямку. Але для тестувальника, як на мене, більш природно просуватися в сторону бізнес-аналізу, керування проектами чи, наприклад, стати product owner чи scrum master. На мою думку, в тестуванні багато спільного з цими напрямками.
— Чи не вичерпали ви для себе QA?
Поки ні. Напевно, я ще не досягла того, на що здатна. В мене наразі немає проекту чи компанії, про які я можу сказати, що це мій magnum opus.
— Ви написали статтю для журналу «Testing Trapeze», де зазначили, що успішний тестувальник — це не лише той, хто вміє створювати SQL-запити, автоматичні чи мануальні тести, знає бізнес-домен, словом, «tech pro». Хто такий справжній тестувальник?
Технічні знання важливі. Але дуже часто проблеми в роботі тестувальника пов’язані не з браком технічних знань. Вони пов’язані з неефективним спілкуванням з іншими людьми — командою, менеджерами, замовниками. І це стосується не тільки тестувальників. Основна проблема полягає в тому, що хтось щось не до кінця зрозумів, не зміг довести чи відстояти свою точку зору тощо. Дуже часто можна почути: «Проект було зіпсовано, тому що ми зрозуміли одну й ту ж саму проблему по-різному, але не обговорили її». А «проект було зіпсовано тому, що я не зміг вивчити SQL» — цього ніколи не було. Навіть якщо ти абсолютно не розумієшся в SQL, його можна навчитися. Чи знайти того, хто тобі допоможе.
Є багато людей, які в певних сферах працюють швидше й більш професійно за мене. Той же SQL я розумію на базовому рівні, і моїх знань достатньо для роботи. Але якщо потрібно зробити складне і технічне, я йду до DВA, і це цілком нормально. Я буду ефективнішою в іншій сфері, там, де не будуть такими ефективними вони. Це і є командна робота.
— У тексті ви говорите про ваш девіз «People matter». Як він виник?
People Matter — це гра слів: з англійської це перекладається водночас як «люди важливі» і «те, що стосується людей». Для чого програміст пише код? Щоб результатами роботи цього коду так чи інакше користувалися інші люди. Космонавт летить до космосу за новими знаннями, щоб згодом їх передати іншим людям. Еколог рятує рідких тварин для того, щоб їх побачили наступні покоління людей. На жаль, це не всі розуміють. Деякі програмісти вважають, що пишуть код виключно заради написання коду, і взагалі не думають про кінцевих користувачів. А кожен проект — це люди, які створюють продукт та підтримують його, й ті, хто ним потім користуватимуться. Чим більше я читала книжок з психології, бізнесу та управління, тим більше я переконувалася: все, що ми робимо — робимо для людей.
Щоб допомогти кінцевим користувачам, я повинна зрозуміти їхню логіку й те, що для них найважливіше. Зараз ми з командою працюємо над трансформацією бізнесу за допомогою сучасних технологій, нового програмного забезпечення, нових пристроїв. Ми технологічно змінюємо бізнес. Щоб допомогти юзерам у будь-якій сфері, її треба зрозуміти. Якщо завдяки вам виросте ефективність кінцевого користувача, тоді разом з цим і виросте ваша особиста ефективність.
— Ще в одній зі статей на LinkedIn ви писали про своє розчарування тим, що у Новій Зеландії випускників комп’ютерних наук не навчають належним чином тестуванню, й вони мають лише туманне уявлення про це. Чому так?
На мій погляд, майже всі вищі навчальні заклади, зокрема власне професори поки не зрозуміли можливостей тестування. За часів моєї роботи в ХАІ ми, відверто, були десь на десять років позаду від затребуваності на ринку. По закінченні університету людина відстає вже на п’ятнадцять років. Після навчання студенти повинні бути в змозі використовувати здобуті знання, а не «забудьте все, чому вас вчили в інституті».
Коли через декілька років в IT я звернулася до рідного вишу з пропозицією викладати тестування студентам-програмістам, мені відмовили: все це дуже добре, але нам потрібно своїх аспірантів просувати. Спеціальності «Тестувальник програмного забезпечення» тоді не було взагалі. Я не знаю, чи є вона хоча б в одному українському виші. Єдина надія на ХНУРЕ. В Новій Зеландії також ніхто не готує професійних тестувальників, і не викладають тестування окремою дисципліною для студентів-програмістів. Ситуація майже така ж сама, як була в Україні.
— Розкажіть, як ви здобули сертифікацію Full Advanced Level ISTQB та з чого усе почалось? Чому вирішили сертифікуватись?
На той час проект, яким я займалася, закінчився, а нового мені ще не знайшли. Я діставала своїх директорів, мовляв, дайте мені якийсь проект, мені треба чимось зайнятись. Дали: отримай сертифікат. Тоді я почала міркувати, яку саме сертифікацію краще отримати та найголовніше — навіщо? Мені хотілося щось таке, що я потім зможу використовувати в своїй роботі. Microsoft, відверто, нічого саме для тестувальників не давав, тому він відпав одразу. Єдиний доступний в Україні був ISTQB. На ньому я й зупинилася. А ще мені дуже кортіло дізнатися, чи відповідаю я міжнародному рівню в своїй роботі. Наскільки ми, тестувальники з усього світу, спілкуємось однією мовою?
Я зібрала всіх тестувальників, що тоді працювали в харківському офісі ЕРАМ. Ми почали дискутувати щодо глосарія. Виявилося, під одним і тим ж терміном ми розуміємо зовсім різні речі. І саме це дає ISTQB — базовий рівень спільного глосарію й спільного контексту, таку собі точку опори. Звісно, ISTQB не панацея. До всього треба ставитися критично. Але саме в Foundation Level є багато здорового глузду.
— Наприклад?
Дуже яскравим прикладом був термін Smoke test. Я розуміла його в буквальному сенсі — дуже поверхневий тест додатка — взагалі, чи можна відрити програму та зробити якусь найпростішу операцію. Саме тому цей тест називається «димовим» — увімкнули прилад і дивимося, чи не пішов дим. Якщо пішов — прилад вимикаємо і розбираємося, де проблема. Якщо диму нема — можна працювати далі. А ось деякі з моїх колег під Smoke test розуміли повний end-to-end тест продукту. Така різниця у розумінні одного терміну може мати погані наслідки.
— Як проходила ваша підготовка до іспиту та яка її роль?
Підготовка — запорука успіху. Найбільш ефективний спосіб — деякий час розв’язувати завдання, максимально наближені до тестових. Дуже важливо не зубрити, це контрефективно. Треба розуміти, як воно працює й чому воно працює саме так. На жаль, я не є взірцем підготовки, бо готувалась лише два тижні у вільний від роботи час.
Foundation Level дуже простий та логічний. У ньому досить розуміти принципи та засвоїти деякі постулати. Далі можна нагуглити доволі багато прикладів. Важливо згодом проаналізувати свої відповіді й чітко зрозуміти, чому вони правильні або чому ні. Це питання самостійної роботи. Знаю людей, яким було достатньо тренінгу, а є ті, що здавали тричі. Буває різне. З мого досвіду найгірше здавали саме ті люди, які пропрацювали десять і більше років.
— Чому? Важко перевчитись?
Здати екзамен — це одне, працювати — зовсім інше. До всього треба ставитись критично й аналізувати з точки зору контексту твого проекту, ситуації на проекті. На екзамені такого контексту немає. Є лише той, який заклав автор екзамену. У цьому полягає дуже важлива різниця, яку розуміють далеко не всі. Реальне життя дуже відрізняється від книжки. Збігається дуже рідко. Коли ти розумієш, в якому контексті поставлені запитання на іспиті, відповіді на них знайти легко. Вони дуже логічні. Але коли ти намагаєшся відповісти на ті ж самі запитання з точки зору власного досвіду, відповіді можуть бути зовсім інші. Можливо, правильні в контексті особистого досвіду, але хибні для відповіді на екзамені. Для деяких людей це дуже складно. Я б радила здавати екзамен англійською, бо російська термінологія, як на мене, не зовсім точна, а української поки що не існує.
— Що варто прочитати під час підготовки до екзамену?
Раджу починати з курсу «Learning how to learn»на Coursera та книжки «Make it stick»Пітера С. Брауна. Ці ресурси вчать ефективно вчитися. Тоді до якого б іспиту ти не готувався, його буде складено успішно. Також нещодавно прочитала дуже цікаву книжку Насіма Талеба «Чорний лебідь». Основне, що я з неї винесла — це розуміння того, що все наше життя керується випадком. Ще один важливий здобуток, особливо важливий для критичного мислення в тестуванні, — це silent evidence, мовчазні докази. Стів Джобс став тим, ким він був, адже йому постійно таланило, обставини складалися вдало. А скільки було людей, так само талановитих, як Джобс, але які народилися не в тій країні, не тої статі, для яких обставини склалися не на їхню користь? Книжка також допомогла мені зрозуміти, як підвищити можливість того, що щасливий випадок трапиться, та мінімізувати наслідки нещасного.
Загалом класикою підготовки до іспиту ISTQB як Foundation, так і Advanced, є книжки Рекса Блека «Foundations of Software Testing ISTQB Certification»та всі три томи «Advanced Software Testing». Не принципово, яку саме книжку читати. Важливо те, як ти це робиш. В книжках потрібно знаходити відповіді на питання.
Ще одним важливим елементом підготовки є постійна практика. Коли ми проходимо певний розділ на тренінгу, обов’язково вирішуємо завдання. Спершу намагаємося розв’язати
— Що підштовхнуло вас до проведення тренінгів?
Усе почалося у 2008 році, коли я складала ISTQB Foundation Level. Ми вирішили розглянути, як команда знає глосарій ISTQB. Що означає той чи інший термін? З цього мій тренінг і народився. Мені дуже закортіло спілкуватися однією мовою зі всіма тестувальниками та вчитися досвіду інших людей. Потім на тренінгу з тест-менеджменту мені пощастило познайомитися з чудовою дівчиною Вікторією Мусіяченко, організаторкою цього тренінгу. Ми говорили про те, що тренінгів для тестувальників не так і багато. Люди хочуть готуватися до іспиту ISTQB, а можливості немає, то чому б не зробити тренінг. Так і почалася наша дуже плідна співпраця, яка триває вже 8 років.
— Маєте бажання повернутися в Україну?
Бажання, звісно, є, й це потенційно реально. Правда, мені поки ще не набридла Нова Зеландія. Якщо буде шанс повернутися, я його з радістю розгляну. Наразі для мене важливо, щоб донька закінчила початкову школу. Далі з’явиться більше можливостей. В Україні дуже цікаві перспективи. До того ж, на мене чекають друзі — і це, мабуть, найважливіше для мене.