5 трендів QA 2023 року: фокус на швидкості та побудові процесів

Сфера QA довгий час вважалася легким трампліном для того щоби «застрибнути» в ІТ. Але висока конкуренція та прискорення розвитку індустрії диктує нові вимоги до компетенцій кандидатів. Суть їхньої роботи вже давно не полягає у банальному пошуку багів. Тепер контроль якості має фокусуватися на швидкості, спрощенні та побудові ефективних процесів. Олексій Лакович, Head of Quality в Solidgate, партнерській компанії Genesis, поділився основними трендами розвитку цієї сфери.

> Швидкість та автоматизація тестування

> Перенасичений ринок та зміна фокуса у наймі

> Спрощення документації

> Контроль якості з боку девелопменту

> Тестування бекенду та мікросервісів

Тренд №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 продукту. Розуміння цих речей допоможе оптимізувати час на тестування та обрати правильну стратегію покриття вашого продукту тестами.