Я свічнулась з Web у macOS QA: кілька моїх порад

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

Привіт, мене звати Валерія і я QA-інженерка у продукті Setapp by MacPaw. Раніше я перекладала технічні інструкції, але зараз у ролі QA-інженерки я допомагаю людям подружитися з технологіями.

Спочатку я перейшла з перекладачки у QA-інженерку. Я тестувала iOS та вебзастосунки та до цього ніколи не мала справи з macOS. Десь приблизно після трьох років почався мій перехід у desktop QA.

Наскільки це складно

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

Проте інколи вдається досягти успіху!

Сьогодні я хочу розказати вам три історії про свій перехід в desktop QA і, можливо, допомогти комусь зробити омріяний світч. Нічого такого, просто три моменти з мого життя, як говорив Стів Джобс.

Знання архітектури платформи — це база

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

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

То для чого нам знання архітектури

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

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

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

Гайдлайни: ключ до розуміння UX у вашому застосунку

Друга історія — про важливість UI та UX вашого застосунку.

Кожен, звісно, приходить до цього розуміння по-своєму. Я усвідомила це на співбесіді: мене запитали, чи знайома я з Human Interface Guidelines (HIG) і чому це важливо для тестувальника. На друге питання не було сенсу відповідати, адже я не знала, що таке HIG.

І тоді PM, який брав участь у співбесіді, поділився зі мною посиланням на Apple Guidelines і порадив ознайомитись, якщо я хочу далі розвиватись у цьому напрямі.

Про важливість гайдлайнів

Гайдлайни — це набір рекомендацій, правил та принципів від авторів платформи або операційної системи, завдяки яким застосунки від різних розробників будуть виглядати уніфіковано.

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

Як нам допоможуть ці знання під час тестування

У користувача вже є певний досвід використання операційної системи, а також набуті звички: потягнути вниз, щоб оновити дані списку; свайпнути ліворуч/праворуч для навігації між сторінками тощо.

Зі сторони QA важливо звертати увагу на ці аспекти під час розробки тестових сценаріїв і пропрацюванні вимог.

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

Загалом гайдлайни спрощують життя під час тестування. Усі правила вже написані. Бери й використовуй.

Самостійність як основний крок до професійного росту

Третя історія про самостійність.

Якщо ви працюєте в компанії зі стандартною ієрархічною структурою, вам 100% відоме таке поняття, як Team Lead. Якщо коротко, саме ця людина направляє вас на проєкті. Але уявімо, що у вас більше немає Team Lead? Які ваші дії?

(Не) вміння брати на себе відповідальність

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

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

Від страху до самостійності

У моїй компанії сама структура передбачає самостійність інженерів будь-якого грейду, а не тільки Senior-ів.

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

Як ці історії допоможуть свічнутися

Ви можете подумати: «О’кей, перехід у macOS — доволі специфічна і вузькоспрямована штука. Що конкретно я можу дізнатися з цього?» Усе просто. Замініть слово macOS на iOS, Android або ж Windows, і ви побачите, що принципи залишаються незмінними.

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

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

По-третє, самостійність і відповідальність. Для нас це можливість ставати кращими й більш експертними спеціалістами/ками, відкриваючи для себе ширші перспективи розвитку. Відповідальність не має платформи, вона не на iOS-і, вона не на macOS-і, вона не на Android-і; відповідальність всюди однакова. Брати відповідальність страшно, але саме це і є шлях до розвитку.