На етапі зародження IT-індустрії в Україні тестувальників в компанії брали з єдиною умовою — знання англійської мови. Всьому іншому навчали в процесі роботи, розповідає Валентин Костромін, QA техлід компанії AMO з екосистеми Genesis. З роками ситуація у професії, як і в усій індустрії, змінилась кардинальним чином. Стереотип про те, що тестувальник — це найпростіша професія в IT і такий собі «трамплін» перед переходом у розробники, — більше не актуальний. Але є декілька аспектів професії, про які в спільноті й досі ведуться дискусії. Ми розпитали Валентина про найпоширеніші міфи, які існують серед тестувальників.
МІФ № 1
Тестова документація завжди важлива і допомагає в роботі.
Насправді темпи розробки у нинішньому світі настільки високі, що постійна підтримка актуальної документації просто неможлива. Багато QA наступають на ці «граблі» — витрачають багато часу на написання документації, яка практично відразу застаріває, і ніяк не стає в пригоді. Але бувають і винятки — залежить від сфери. Якщо говорити, наприклад, про сферу медицини, то там наявність документації регламентується на законодавчому рівні, і без неї нікуди. У інших же випадках документація тільки в мінус — віднімає час і сили, не додає користі.
МІФ № 2
Знання мов програмування для QA необов'язкове.
Ця думка поширена серед новачків в QA, які після курсів приходять на роботу і думають, що знати хоч би одну мову програмування не треба. Цей стереотип — продовження помилкового уявлення про те, що програмування, мовляв, складна річ, а тестування — нічого складного, тільки «кнопки натискати». Звичайно, це не так. Рано чи пізно будь-який QA все одно приходить до необхідності розібратися в програмуванні, тому що неможливо тестувати щось, якщо ти не розумієш, як воно влаштоване. Тестувальник постійно працює в контакті з програмістами, але йому буде складно просунутись далі позиції джуніор-спеціаліста, якщо він не знатиме хоч би базових принципів розробки.
Що саме треба знати — залежить від того, в яку сторону фахівець планує далі розвиватися. Якщо збирається залишатися мануальним тестувальником, то йому буде достатньо загального розуміння принципів програмування, а не конкретної мови. Якщо ж планує переходити на автоматизацію, тестування навантаження, ставати лідом, то тут потрібна як мінімум одна мова програмування, яку важливо вивчити добре і постійно писати нею код.
Чому лід повинен уміти програмувати? Існують компанії, в яких призначають лідами мануальних тестувальників без знання мов програмування. Але рано чи пізно будь-який продукт доходить до стадії, коли автоматизація потрібна, і тут в команду починають шукати автоматизатора. З'являються дві проблеми: по-перше, з автоматизатором немає кому проводити співбесіду, а по-друге, навіть якщо його знайшли й найняли, для нього лід-мануальник не може бути повноцінним керівником, тому що він не розуміє, чим саме займається автоматизатор.
МІФ № 3
Автоматизація витіснить ручне тестування. Або навпаки.
Це найбільш гаряча дискусія в QA-спільноті, в якій насправді заховані відразу два міфи. Перший — ручне тестування помирає, і скоро зникне зовсім. Другий, протилежний — автоматизацією не можна замінити мануальників. Обидва ці твердження не зовсім вірні, а істина знаходиться десь посередині. З одного боку, без автоматизації зараз складно, а в якийсь момент розвитку продукту просто неможливо. Проєкти ніколи не зменшуються, вони завжди розвиваються і ростуть, і чим більше функцій у продукті, тим більше часу треба на їх тестування. Настає момент, коли команда починає випускати по одній фічі на тиждень, і при цьому на одну нову фічу треба перевірити ще сотню таких фіч, щоб вони в процесі релізу не «зламалися». Кількість часу, необхідного на тестування, зростає величезними темпами.
Чому спочатку складалася думка що мануальники краще за автоматизаторів? Тому що час мануальників коштує дешевше. Там, де ти в команду візьмеш одного автоматизатора, можеш найняти від двох до чотирьох «ручних» тестувальників (залежно від грейда). І вони будуть просто більше перформитити — така думка існувала раніше. Але зараз це не працює. Час автоматизатора не так сильно росте при зростанні кількості функцій на проєкті. А от у випадку з мануальниками час росте пропорційно зростанню проєкта. Кожна нова фіча — це плюс умовна одиниця часу мануальника. Тому звичайно вигідніше взяти одного автоматизатора, аніж чотирьох мануальників.
Але у цього питання є й інша сторона. Мануальне тестування не може зникнути зовсім, тому що автоматизувати все неможливо, і, мало того, автоматизувати все не доцільно. Існують проєкти, які, наприклад, здебільшого будуються на Google Analytics. Вони роблять у себе в адмінці дашборди з аналітики Google, і додають до них внутрішню аналітику. Сервіси Google — це third party (зовнішні джерела інформації), й команда ніяк не може вплинути на їх набір функцій, але при цьому дуже сильно від них залежить. Ви можете автоматизувати тестування такого проєкту, але при будь-якій зміні функцій з боку Google вам треба буде постійно виправляти всі тести у себе. При цьому витрачається величезна кількість часу на підтримку, й доцільніше застосовувати тут ручне тестування.
МІФ № 4
«Автоматизатори» і «мануальники» — це різні команди, які повинні працювати окремо одна від одної.
Я часто зустрічаю таке бачення серед лідів і автоматизаторів з компаній, що займаються аутсорсингом. Як це виглядає? Раз на спринт мануальники приходять до команди автоматизаторів, приносять готову документацію, всі тест-кейси й перевірки, які вони хочуть зробити. Автоматизатори впродовж спринту роблять ці тести, при цьому не завжди самостійно перевіряючи їх на коректність, а потім віддають назад мануальникам для перевірки. У чому тут проблема? Автоматизатори в такій системі не знають, в чому суть проєкту і яку бізнес-цінність він несе. Вони тестують функціональність, не розуміючи, навіщо вона потрібна в контексті усього продукту. Але це гальмує як професійний розвиток тестувальників, так і проєкт в цілому.
Як це повинно бути влаштовано? Одна загальна команда, плюс фахівець на позиції General QA, який одночасно покриває й автоматизацію, і завдання мануального тестування. Як правило, це команда, в якій на два-три розробники на одного QA. У них є своя частина функцій, яку вони розробляють і покривають увесь цикл тестування. Такий підхід часто зустрічається в невеликих кросфункціональних командах в продуктовому IT, і він дуже ефективний. Будь-який член команди може приносити додаткову цінність не лише за допомогою виконання своїх обов'язків, але і новими ідеями та баченням, а цього без знання продукту не буде.
МІФ № 5
Технічна академічна освіта обов'язкова для QA.
Якщо ви подивитесь вакансії для QA в західних компаніях, то навряд чи знайдете хоч одну, де не буде вимоги про наявність академічної освіти в технічній сфері. Такі ж вимоги часто додають українські компанії, що створюють продукти та сервіси для західних замовників. У такого підходу дві причини. Перша — академічна освіта в закордонних університетах влаштована принципово іншим чином, аніж в Україні. Наявність американського або європейського диплома дійсно дає хоч би мінімальні гарантії, що фахівець обізнаний в теоретичних питаннях, і компанії звертають на це увагу.
Друга причина — те, що зараз багато фахівців QA приходять в індустрію після закінчення курсів, і їх експертність обмежена тільки сферою QA, а базове розуміння того, як працюють, приміром, мережі або HTTP, часто відсутнє. При цьому тестувальник повинен працювати на вебпроєкті, в якому йому буде складно без розуміння принципів роботи інтернету. Проте, в українських реаліях наявність диплома про вищу технічну освіту мало що гарантує, а компанія швидше дивиться на навички й готовність рости, розвиватися і займатися самоосвітою.
Я вважаю, що технічна академічна освіта не обов'язкова — і не лише для тестувальників, але і для розробників в цілому. Якщо програміст працює, приміром, на проєкті, пов'язаному з банкінгом, то академічна освіта у сфері фінансів буде йому корисніша, ніж технічна. А усі необхідні професійні навички й знання можна отримати на курсах, з численних книг з тестування, і головне — на практиці, навчаючись в процесі, і обмінюючись досвідом і знаннями з колегами.
