Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

Із журналістики в QA Engineer. Як побудувати карʼєру в IT з гуманітарною освітою

Привіт! Мене звати Анастасія Кулішенко, QA Engineer в продуктовій IT-компанії Universe, яка працює у двох напрямах: розробка додатків утиліт на iOS та розвиває власний R&D-центр.

До процесів забезпечення якості на web-проєктах я причетна вже як 4 роки, а останні 6 місяців працюю над edtech-платформою в Universe — Wisey.

Cтартувала моя професійна історія зовсім інакше: 6 років я навчалася журналістики, а також встигла попрацювати в медіа. У цій публікації я поділюся своїми поглядами на те, як гуманітарна освіта та досвід роботи в нетехнічній сфері може допомогти у професії QA-фахівця.

На нашому напрямі навчалося 120 людей, з них лише 10% — хлопці. І, як мені відомо, щонайменше п’ять однокурсниць пішли в IT: двоє обрали розробку і троє стали QA-інженерами.

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

Гуру софт-скілів

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

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

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

Інтерв’ювати бізнес-вимоги

Коли нас навчали грамотно проводити інтерв’ю, практично першою порадою лунало не ставити закритих питань. Банальний приклад «Ваше дитинство було щасливим?» програє формулюванню «Розкажіть про найрадіснішу подію з дитинства, яка запам’яталася». На етапі QA review вимог важливо також стежити за підходом до питань, що виникають. Очевидно, що вчасно виявлена ​​помилка в документації буде коштувати компанії набагато менше, ніж неточність, що народжена в додатку через неясність і що в результаті призведе до багу, виявленому на етапі тестування вже реалізованої фічі (і добре, якщо непорозуміння виявиться ще в dev-оточенні, а не в проді).

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

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

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

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

Майстер баг-репортів та тестової документації

Розсудливий гуманітарій (тим більше — журналіст чи філолог), за моїми спостереженнями, зі словом дружить більше, ніж технар. Тому написати грамотний та повний баг-репорт, накидати деталізований чеклист або задокументувати тест-кейси такому QA-інженеру буде простіше.

Любов до роботи з текстом, вміння з перших слів чітко відповідати на запитання «Що, де, коли?» допоможе і в написанні саммарі багу, і в формулюванні фактичного та очікуваного результату, і в описі кроків для відтворення помилки/ кроків тест-кейсу. Ще на курсах основ тестування ПЗ тема та практичні завдання зі структури баг-репортів давали відчуття, що десь я це вже чула: хто має розуміння з чого повинен складатися класичний лід новини, той помітить — з описом багу є багато спільного.

Формула «що, де сталося, хто брав участь в цьому, чому це сталося і коли» дуже нагадує саммарі баг-репорту. І якщо вже торкатися опису багу, то хоч-не-хоч спливає ще одна паралель. Скріншот і скрінкаст зовсім не такі далекі від фото- та відеорепортажу в журналістиці. Зафіксувати подію, показати її з різних боків (читай: проілюструвати можливі кейси, в яких помилка відтворюється) — і ось знову все своєю суттю схоже.

Поставити себе на місце читача користувача

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

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

Сюди ж можна зарахувати рубрику «Читачі пишуть» або — у світі IT-проєктів — новини від саппорту. Журналіст ставить себе на місце читача зокрема завдяки зворотному зв’язку від своєї аудиторії: розуміючи, що її непокоїть, які теми бентежать, формується контент-план з врахуванням редакційних пріоритетів. QA-інженер, особливо в продуктовій команді, так само часто добре знає проблеми користувачів, які долинають з відділу підтримки. Унікальні баги або miss click, конструктивна критика або «а поговорити» — це багате джерело для розуміння того, з чим стикаються ті, для кого все й призначено.

Інженер-детектив та ще кілька паралелей

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

Журналіст-розслідувач vs інженер-детектив 🕵🏼‍♀️

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

Висока ціна помилки 💰

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

Прагнення до об’єктивності ⚖️

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

Всеприсутній фактчекінг 📝

Хороший журналіст та QA-інженер мають ще один загальний скіл — критичне мислення, а також здорове прагнення до повторної перевірки. Сумнівні джерела інформації, таємні доброзичливці кореспондента вимагають особливої ​​пильності щодо того, чи відповідає заявлене істині. Тест-інженер на регулярній основі може чути нескінченну кількість доводів, що так і працювало або «ми усно домовилися», баг виправлений, але ніщо з цього не варто приймати на віру. Тут добре допоможуть правила:

  1. За можливості, прикріплювати до завдань пруфи того, як поводила себе система на момент закриття таски. Це можуть бути скріншоти або скрінкасти — у будь-якій наочній формі короткий результат того, що функціональність працювала правильно. Це хоч і займає час, але все ж таки передусім потрібно не скільки для звітності менеджерам, скільки самим собі, щоб мати можливість перевірити ще раз себе і аргументи будь-кого на правдивість.
  2. Перепитувати. Якщо розробник каже, що затвердили такий варіант, не зайвим буде поцікавитись у менеджера про причину цього рішення. Нерідко запитання породжує переосмислення запропонованої швидкої реалізації в бік якіснішої та надійнішої, а то й зовсім виявляється, що у розробника з менеджером стався місском’юнікейшн. QA в такому випадку виступає перекладачем, відкриваючи очі на очевидне. І зворотна картина: якщо інформація підтвердилася, а ви дізналися про неї останнім, на майбутнє попросіть менеджера коментарем до задачі або специфікації обов’язково фіксувати зміни та тегати всіх, хто має бути поінформованим.
  3. Не покладатись на хороші новини від девелоперів. Буквально в день, коли я писала цей матеріал, після багфіксингу одного із завдань я отримала радісну звістку від розробки — «пофіксив, хепі флоу пройшов, ніби ок». Оскільки в повітрі літав шлейф очікуваного релізу можна було б довіритися цим словам, перемикнутися на завдання, що залишилися, і виявити недофікс тільки на етапі регресії, що дуже б недоречно затягнуло очікуваний деплой на прод. Але хеппі флоу виглядало хеппі лише на перший погляд, адже стара функціональність встигла потрапити під гарячу руку, що здебільшого помітить саме той, хто знає проєкт/продукт як свої п’ять пальців — людина, відповідальна за якість.

Довіряй, але перевіряй ☝🏻

Очікування: «Це завдання просте, можна навіть не тестувати», — чую я на черговому плануванні спринту.
Реальність: без тестування такого мінорного завдання у продакшн могли потрапити чотири баги.

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

За можливості прибути першим 🧯

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

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

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

👍ПодобаєтьсяСподобалось18
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Чудова стаття. Сам з викладача укр мови і л-ри перекваліфікувався в QA

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

Я обожнювала писати, але конкретно журналістика виявилась не моїм. Напевно, я занадто сильно прагнула до справедливості та об’єктивності, аби працювати в сфері, де ці ідеали важкодосяжні (:
Окрім цього, робота журналістом вимагала завжди якогось натхнення, все залежало від настрою: то писалось легко, то не було завзяття. Тож, хотілося осягнути професію більш практичну і з більшим різноманіттям повсякденних завдань.
Коротко не пояснити, та й це не рідкість, бо одразу обрати в 17 років професію на все життя — звучить дуже романтично, а в сучаному світі тим паче)

Перепис журналістів в каментах :) Майже 10 років моя графоманія комусь подобалась настільки що за це аж платили.

Оу, я також перейшов в ІТшечку з дипломом журналіста і чотирма роками досвіду на ТВ і сайті. Погоджуюсь майже з кожною тезою автора. Скіли отримані на журфахі чудово матчаться на потреби QA

Свічнувся з журналіста в Front-end розробника))
Одним словом було б бажання

Стаття супер, успіхів в роботі QA! :)

Підписатись на коментарі