Сфера QA довгий час вважалася легким трампліном для того щоби «застрибнути» в ІТ. Але висока конкуренція та прискорення розвитку індустрії диктує нові вимоги до компетенцій кандидатів. Суть їхньої роботи вже давно не полягає у банальному пошуку багів. Тепер контроль якості має фокусуватися на швидкості, спрощенні та побудові ефективних процесів. Олексій Лакович, Head of Quality в Solidgate, партнерській компанії Genesis, поділився основними трендами розвитку цієї сфери.
Редакція корпоративного блогу разом із фахівцями Genesis підготувала великий ґайд трендів продуктового ІТ на 2023 рік. Підпишіться на розсилку Gen.Read та дізнайтеся ключові тенденції за іншими напрямами.
Тренд №1. Швидкість та автоматизація тестування
Для більшості компаній доля тестування все більше зміщується в бік автоматизації. Мало хто може дозволити собі робити великі регресії: тестувати продукт вручну, заповнювати великі репорти тощо. Зараз набагато цінніше швидше «викотити» реліз, ніж доводити до ідеалу функціонал.
Якщо частота релізів — декілька разів на тиждень, ускладнене тестування сповільнюватиме процес. Якщо релізи відбуваються рідше, потрібна чіткіша структура тестування та документації. Наприклад, мобільні застосунки валідуються додатково Google Play та AppStore, і у вас може не бути можливості швидко вносити зміни. Але навіть в такому разі тестування закриватиметься в першу чергу шляхом правильних процесів.
Тренд №2. Перенасичений ринок та зміна фокуса у наймі
Ринок кандидатів в manual QA — надзвичайно перенасичений. Багато людей, які втратили роботу, намагаються знайти себе в ІТ і заходять через тестування. Ринок переповнений людьми, які тільки-но закінчити курси. Станом на зараз (день публікації тексту — ред.), згідно з даними Djinni, конкуренція складає 27 людей на одну посаду (6614 активних кандидатів та 246 вакансій), — і це найвищий показник серед всіх професії в ІТ.
Надалі конкуренція тільки зростатиме, і це впливає насамперед на саму позицію QA. Раніше у вимогах до позиції QA були лише знання з мануального тестування: ведення документації, знання теорії та інших базових речей. Тепер очікують, що кандидат володітиме хоча б мінімальними інструментами автоматизації — наприклад, Postman, або вмітиме писати базові тести з використанням браузера. Надалі фокус роботи QA зміщуватиметься в бік процесів: контроль якості, процес постановки задач для розробників, що покривається тестами та на якому етапі.
Тренд №3. Спрощення документації на користь швидкості релізу
Продукти можна умовно розділити на два типи — ті, в яких вартість помилки дуже висока (починаючи від кардіостимуляторів, автотранспорту і закінчуючи бойовими дронами) і ті, в яких помилка не спричиняє фатальних наслідків (більшість повсякденних застосунків). Для другої групи, у якій пріоритетом є випуск швидких фічей, багато практик QA поступово «помирають», зокрема ведення складної документації. Величезні складні талмуди тест-кейсів трансформуються у візуалізації, діаграми та чеклісти. Коли важлива швидкість релізу, а у більшості компаній навіть немає часу вдало поставити ТЗ, такий формат документації може стати справжнім порятунком.
Тренд №4. Контроль якості з боку девелопменту
Компанії, що активно зростають, зацікавлені в тому, щоби QA були якомога менше залучені у процес доставки фічей. Тому все більше уваги приділяється контролю якості з боку девелопменту. Йдеться про використання аналізаторів коду та написання тестів на рівні розробника. QA в цьому процесі має розділяти зони відповідальності за тестування продукту між Dev / QA / AQA, щоби не виникали ситуації фокуса усіх відділів на одному рівні тестування, або на окремо взятому функціоналі.
Тренд №5. Тестування бекенду та мікросервісів
Зараз неможливо уявити застосунок, побудований не за допомогою клієнт-серверної архітектури. Також чимало продуктів представлені на різних платформах та мають навіть спільну валідацію даних на стороні сервера. Тренд розробки останнього десятиріччя — розділення продукту на невеликі сервіси, що взаємодіють між собою через мережу.
Тому важливим є вміння правильно тестувати логіку продукту саме на бекенді. Протокол взаємодії не є принциповим, важливо правильно розділяти тестування на рівні. Розуміти, які речі треба тестувати окремо на конкретному сервісі, які на рівні інтеграції між різними сервісами, а які за допомогою UI продукту. Розуміння цих речей допоможе оптимізувати час на тестування та обрати правильну стратегію покриття вашого продукту тестами.