Про автоматизацію тестування та чи завжди вона потрібна. QA voice chat

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

Ми провели перший войсчат QA-спільноти DOU і присвятили його автоматизації тестування. Обговорили, коли вона потрібна, а коли ні, чи не буває її забагато, як її починати, про інструменти, стек і багато іншого.

Ви можете послухати войсчат у записі або прочитати текстові тези у цьому матеріалі. Таймкоди по темах розставлені у заголовках матеріалу.

Спікери:

🎙 Роман Марінський, Test Engineering Lead в Intellias, QA Club Lviv лідер, QA Consultant

🎙 Олег Заревич, DevOps \ Site Reliability Engineering, QA лектор

🎙 Рамелла Басенко, Lead QA Engineer в AgileEngine

🎙 Cергій Могилевський, QA Lead в NIX

🎙 Михайло Салівонов, Test Lead в Luxoft

Трошки контексту (01:05)

У грудні 2021 року DOU зібрали 2160 анкет QA-фахівців усіх спеціалізацій і рівнів з усіх регіонів України і зробили зарплатну аналітику.

Вона показала, що у другій половині 2021 року зарплати активно зростали у спеціалістів Automation QA. Таких спеціалістів наразі 28% на українському ринку на противагу 52% мануальних тестувальників. Варто зазначити, що частка Automation QA зросла на 1 відсотковий пункт від початку 2021 року, а частка Manual QA знизилася на 2 відсоткових пункти.

Найвищі зарплати QA-спеціалістів, які сягають $4-5 тисяч — у верхньому квартилі зарплат фахівців Automation QA, а також рівня Lead та Manager.

На форумі учасниця DOU-спільноти та розробниця Оксана Лобко опублікувала топ-120 скілів та категорій, які вважає популярними на українському IT-ринку. На основі зустрічань у різних статистичних звітах та по розділах Джинні вона зазначає, що Категорія QA Automation дефіцитна вже останні багато років.

Що таке автоматизація QA (2:33)

Роман: Є термін автоматизації архітектори, ним називають unit та інтеграційні тести, і ще можна притягнути статичні аналізатори коду. Для QA автоматизація — це по суті автоматизація тестів перевірок на оточення.

Давайте ваші пропозиції, як ви розумієте, що таке автоматизація, щоб потім в нас не було сперечань, на основі якого контексту ми будемо розмовляти?

Олег: Обмежимося E2E-тестом, які є UI тести, APi тести, коли ми маємо повну систему в зборі, і проводимо E2E сценарій кінцевого користувача тощо.

Роман: Це класна тема, насправді перформанс можна назвати швидше перформанс аналізом, а не тестуванням. По термінології ISTQB це нефункціональне тестування, а перформанс — скорше окрема роль, яку аналітик може виконувати.

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

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

Ми хочемо перевірити, що щось у нас працює так, як треба, або не так.

Рамелла: Ми відштовхуємось від того, що йде після unit-тестів, бо за класичною пірамідою ми автоматизуємо юніти API і далі все, що є. Я так розумію, що ми будемо говорити про те, що йде після unit.

Які тести потрібно автоматизувати, а які краще не автоматизувати? Як визначати, чи потрібна автоматизація чи краще використовувати ручне тестування? (9:08)

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

Роман: Від простіших і найпріоритетніших.

Рамелла: Бізнес не завжди розуміє на що можна витратити гроші, і вони запитують менеджерів про стратегію автоматизації.

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

Складні тести зі складними тестовими даними і умовами я б не робив. У мене був один проєкт — десктопний застосунок. У ньому написали автоматизацію, а один з тестів перевіряв чи експайриться ліцензія через рік. І оскільки це була десктопна автоматизація, тести були на комп’ютері, вони переводили час на рік вперед, і це було зроблено Ranorex через клікання по UI. Мега не стабільно і складно, а відповідно, це буде мати малу цінність. Такі речі я б не автоматизовував.

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

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

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

Роман: Головне тут, щоб автоматизатор не вніс хибних розрахунків чи багів в автотест.

Рамелла: Але ми матимемо тренди, якщо будемо вносити в репорт і дивитись, що цей тест завжди працює, то, мабуть, все добре. Якщо колись зламається, то треба дивитись, що не так.

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

Рамелла: Ще є bag seeding programs, але мені його не доводилося використовувати. Це коли ви навмисно насаджуєте баги, щоб зелені тести стали не зеленими, щоб побачити, що ці тести взагалі щось відловлюють. Можна автотести перевіряти на їх продуктивність.

Скільки ресурсів (людей, часу, грошей) допустимо витрачати на автоматизацію? (16:08)

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

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

Якщо ви лише паралельно працюєте над автоматизацією — залежить від бюджету.

На початку я б інвестував власний час в автоматизацію, навіть в овертайми, щоб навчитись її робити. Не потрібно забувати про пріоритети проєкту.

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

Стосовно бекенд-тестів. Якщо рівень автоматизатора високий і він розуміється на плануванні, дизайні й автоматизації, то вийде так, що на проєкті буде виділено близько 60-80% ресурсів на автоматизацію, а інший час — на те, щоб розібратись, чому тест впав, та чи буде достатньо перевірити його вручну.

Якщо експертизи немає, то все залежить від співвідношення інженерів розробників на тестувальників. В ідеалі вона має бути 1 до 2/3/4. Головне, щоб не забагато.

Важливо, щоб автоматизували старий функціонал або одразу новий. Від цього варто відштовхуватись.

Михайло: Я прихильник системи, коли є автоматизатори, які 100% автоматизатори і вони не займаються мануальною роботою.

Ресурс людини — 8 годин. Ми не можемо сьогодні звільнити, а завтра набрати нового автоматизатора. Якщо в нас є проєкт, на якому 6-8 автоматизаторів, вони будуть автоматизовувати на 100%.

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

Ресурс для мене — статичний параметр, а не динамічна система.

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

Тож автоматизацію слід розглядати, як один з інструментів, який QA використовує за необхідності. І тут не стоїть питання про виділення ресурсів. Клієнт платить за роботу quility insurance інженера, який забезпечує якість. Якими методами він це зробить — неважливо, бо клієнт на виході отримує якість. А парадигма, де одні роблять одне, а інші — інше обмежує наші можливості та гнучкість.

Михайло: Можливо це і обмежує. Але я неодноразово стикався з тим, що є супер класні автоматизатори, але вони середні мануальщики, або навпаки, класні мануальщики, які посередні автоматизатори.

Найбільший ККД від працівника отримуємо, якщо він робить те, що вміє найкраще. Тоді ресурс використовується на 100%.

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

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

Автоматизатори ж, які тільки пишуть кодяру, — не тестувальники. Це просто ресурс, а не людина, яка може завалідувати якість продукту.

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

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

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

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

Коли ці двоє людей не розуміють одне одного, виникає певна складність.

Михайло: Для цього є код-рев’ю, яке показує, що тест відповідає коду. Це поганий процес, а не проблема підходу.

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

Дуже часто всі не на одній хвилі. Щоб це залагодити, було б добре розуміти, що робить ваш колега. Багато підводних каменів.

Рамелла: Кожному оркестру треба свій диригент. Якщо хтось вміє класно автоматизувати, а хтось класний мануальщик — треба їх поєднати. Добре визначити, хто краще чим володіє і скласти композицію. Від неї залежить результат.

Мала негативний досвід з тим, коли хотіли, щоб мануальщики теж автоматизували. Було погано всім. Автоматизаторам доводилось допомагати і вчити,а у мануальщиків було недостатньо скілів, щоб зануритись і почати продукувати щось суттєве. Ми не отримали в цьому випадку бенефіту.

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

Роман: Все залежить від режисера — від засновника, лідів, які дають волю.

Комусь може не зайти автоматизація. Через людей, які хочуть тільки писати кодяру, я проти автоматизації. Я б скоріше дав на проєктах команду девелоперам написати тести для оточення для кожного n-point, фронтендщикам — написати тести для сторінок, а мануальникам перевірити це вручну і експлорювати тестування. Цього буде достатньо.

Про проєкти, на яких впроваджували автоматичне тестування і це було помилкою та мало негативні наслідки (35:34)

Олег: Я не бачив негативних сценаріїв. Для вас, як для найманого працівника, навіть за завал проєкту особливо нічого не буде. Максимум — роботу втратите чи вас насварять.

Але я бачив ситуації, коли автоматизація стартувала, а на неї ніхто не звертав уваги. У нас був чувак, який писав автотести. Кожного демо він приходив і казав: «ми написали 10 нових тестів», чим робив менеджера і product owner дуже задоволеними. Але за тестами не дивився ніхто, крім нього, і в тому випадку тести приносили мінімальну цінність. Потім людину перевели на мануальне тестування, ця автоматизація вмерла, бо її ніхто не підтримував. Постраждав лише замовник — він втратив свої гроші. І це частий кейс.

Треба, щоб всі члени команди розуміли, для чого ця автоматизація і що вона робить.

Роман: Знаю два кейси, коли автоматизація зафейлилась — занадто дорого коштувала, а користі приносила мало.

Перший кейс — це коли сліпо приводили Gherkin-описи тестів у вигляді Gherkin сценаріїв. Через Кукумбери тощо. Коли це не було як процес, behavior driven development. Комунікація з інженірінгом не виконувалась у вигляді Gherkin.

Коли тест-кейси писали тільки у вигляді Gherkin, автоматизацією були не задоволені самі автоматизатори і це приносило мало користі для продукту. Особливо коли кількість тестів збільшувалась.

Другий — коли привносили графічні інструменти для автоматизації — ranorex, testcomplete, TOSKA, UIpass. Суто для того, щоб автоматизувати тестування.

Рамелла: В мене один дурний кейс. Клієнту продали олінклюзів пакет тестування. Йому пропонували зробити аналіз коду, зробити автоматизацію (не зрозуміло, для чого), а проєкт був на 3 місяці. Прийшов клієнт з працюючим застосунком і хотів отримати інформацію про якість. Йому продали пакет автоматизації + тест-кейсів. Усе це робили за 3 місяці великою кількістю людей. Автоматизація була написана на selenium, все було добре, фреймворк зробили, тест-кейс описали. Але навіщо і кому це реально було треба?

Сергій: Зі всіма можу погодитись. Єдине, що може статися, — це те, що ми витратимо гроші клієнта на те, що не треба.

А чи був у когось з присутніх BDD-підхід?

Михайло: Це працює зазвичай на маленьких проєктах. З маленькими сценаріями і нескладними user stоry. Я повний противник BDD.

Олег: В мене був хороший досвід роботи з BDD-підходом. У нас була невелика команда з 3-4 Test Automation Engineers. Ми писали на C# і SparkFlow.

Я прийшов на проєкт, і чувак, який був до мене, вже використовував SparkFlow. Пізніше ми писали під новий продукт. Писали доволі класний код, там було дуже багато абстракції, ми використовували dependency injection. І технічно складний був код, який не часто побачиш в automation solution, і дуже багато хороших речей підтримувалось з SparkFlow.

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

Хотіли подолати бар’єр, де мануальщики тільки мануалять, а автоматизатори тільки автоматизують. І в нас це вийшло. Ми вчили мануальщиків автоматизувати, а вони нас — тест-кейси писати. У нас був один словник термінів, а всі тести були синхронізовані. Непоганий був підхід. Часто люди перебільшують свій біль з BDD, або дійсно погана кодова база.

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

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

Олег: Я трошки працював з мутантами. Класно працює з unit-тестами: трошки міняємо код і можна перевірити якість тестів. Якщо вони попадали, значить працюють. Але на E2E тести, з конкретними фреймворками, з якими я працюю — це Striker. Він є для багатьох платформ. Для E2E це буде складніше, у вашому випадку треба перевіряти, чи тести знайдуть якісь функціональні дефекти. Такою технологією ви не перевірите.

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

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

Михайло: Адекватність тесту краще перевіряти на моменті створення. Ви створюєте тест, якимось чином симулюєте неправильну поведінку системи, якщо це можливо, хоча б у debag mode, і дивитесь, чи він впав з тим меседжем, який ви очікували в тому місці. Після цього немає варіанту, коли він може стати неактуальним. Хіба що фукнціонал повністю зміниться. І навіть тоді він впаде на тому ж місці, де ви перевірили.

Про мінуси Gherkin підходу (51:57)

Олег: Коли кажеш, що пишеш на BDD, тебе навіть ніхто не слухає.

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

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

З preconditions та postconditions було важко розібратись нормально. І з потокобезпечним триманням даних, якщо тести запускаються у велику кількість потоків. Через специфіку побудови всяких кукумберів.

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

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

Олег: Погоджуюсь з Сергієм. Всі технічні речі далі можуть бути як з BDD, так і без. Залежить від імплементації. Це проблема комунікації. Треба комунікувати, щоб якісно все підтримувати — і з людьми, які пишуть тест-сценарій, і з тими, хто пише User story. Це біль, але воно так і задумувалось.

Де брати досвід QA-початківцям та чому всюди вимагають високий рівень англійської (59:54)

Роман: Англійська це 0 критерій для будь-якої людини в ІТ-тестуванні, бо 90% проєктів пов’язані із закордонними замовниками. Це стандарт. І більшість інформації, стандартні специфікації — все англійською.

Щодо досвіду. Джуни — це люди, які вже щось трошки спробували, їх можна відправляти в бій, але все одно треба дивитись, як він чи вона виконує свою роботу і чи коректно це робить. Спочатку треба дивитись на trainee вакансії.

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

Для входу в ІТ тестувальником також треба розуміння хоча б базових технік тест-дизайну: state transition, equivalent partition та інше + гарно виконане ТЗ. Тільки в такому випадку є більші шанси отримати роботу.

Михайло: Англійська точно необхідна штука. Середнього рівню — intermediate, pre-intermediate — буде достатньо в більшості випадків. Головне, щоб можна було хоча б якось порозумітись із замовником.

Стосовно досвіду, то я зустрічав людей з 15-річним досвідом автоматизації, які не знали нічого ні про ООП, ні про супер елементарні штуки. Вони не могли нічого відповісти. Зараз я більше люблю співбесідувати студентів технічних ВНЗ, які на 4 курсі можуть розказати мені дуже багато цікавого. Тому я частково не погоджуюсь з тим, що людей без досвіду не розглядають. Особисто я не люблю розглядати сеньйорів, вони розчаровують.

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

Бачите, що там потрібно до 1 року досвіду? Сміливо подавайтеся. У моїй практиці не раз було так, що ми шукали людину з роком досвіду, а вона прийшла без досвіду, проте дуже підкована. Ми її взяли і вона класно розвивалась.

Технічні речі легко вивчити за потреби. І швидше, ніж англійську.

Роман: Коли я працював у перших двох компаніях, завалив десь 100 співбесід через англійську. Я довго її вчив і не міг знайти роботу тільки через англійську.

Про in sprint automation. Чи це про те, як продати більше людей чи про автоматизацію, її доповнення чи покращення як процесу (1:12:36)

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

Якщо дивитись у розрізі кроссфункціональних команд, все залежить від інженерної культури та рівня розробників. Бо частково in sprint автоматизацію можуть робити і автоматизатори, якщо є культура Green build. Blue green employment.

Якщо є така постійна ціль, то коли виникає щось червоне, ми все кидаємо і фіксимо. Інженери-розробники можуть писати власноруч тести для мобілки і скріна. Back-end — unit інтеграційні тести. Ми ж лише підтримуємо тести для оточення, розвиваємо їх та іноді дивимось на те, що роблять front-end. У мене було таких 3 проєкти. Все залежить від того, чи є людина, яка може це підтримати, і чи команда готова до такого процесу, бо вона може його не зацінити.

Сергій: У мене теж був подібний досвід на in sprint автоматизації. Це точно можна реалізувати, але це потребує високого технічного скіла. З командою потрібно одразу домовитись про те, що і як ми робимо. Треба максимально співпрацювати розробникам. Пушити свої тести в одній гілці разом з функціоналом. Тестувати новий функціонал локально в себе або локально в розробника, поки це не потрапило в загальну кодову базу. Важливо, щоб команда була готова до такого темпу постійно. Бо якщо тут зашпортатись, весь підхід буде сипатись. Чим більше накопичується непокритого, тим гірше це починає працювати.

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

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

Які інструменти для автоматизації краще використовувати — перевірені чи нові та модні? І на якому проєкті краще зводити всі тести до одного стеку чи мови, чи відштовхуватись лише від потреб кожної задачі та не обмежуватись інструментами? (1:22:18)

Рамелла: Використовувати все підряд не корисно, як і використовувати лише новеньке і свіже. Думаю, є багато стандартних підходів, які працюють скрізь. Тут вже треба дивитись залежно від стеку проєкту, що вам більше підійде. Можливо, треба буде поекспериментувати.

Роман: Якщо хапати все підряд, то може не вистачити кваліфікації. Краще брати те, що по кваліфікації підходить всій команді.

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

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

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

Чому мануальщики отримують менше грошей, ніж автоматизатори? Хоча мануальщики можуть більше користі принести.

Михайло: Автоматизатори теж можуть більше користі принести. Тут питання в кількості знань. Кількість знань, яку потрібно накопичити, щоб стати висококласним спеціалістом. Якщо ми беремо мануальне тестування, то там є теорія, яка вміщується в одну книжку, і основна її частина вміщується в один розділ про техніки тест-дизайну. Це все. Далі ти розвиваєшся в цьому, але кількість знань, яка потрібна, щоб класно виконувати свою роботу, менша, ніж кількість знань автоматизаторів, яка потрібна їм, щоб класно виконувати свою роботу. У цьому різниця.

Олег: Я думаю відмінність в бюджетуванні. У мене є знайома, яка має до 5 років досвіду і в неї не великі технічні знання, а ЗП в районі 3000 доларів. Вона працює мануальщиком.

Тут особистий фактор ще грає роль: впевненість в собі, наглість і конкретна проблема проєкту.

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

Роман: Швидше дефіцитом знань. Статистика на ДОУ показує, що 28% автоматизатори, а всі інші мануальщики. А ще менше Performance-аналітиків, а ще менше Penetration-тестерів. Зарплата залежить від попиту.

Михайло: Наш ринок QA скаламучений тим, що в певний момент виникла ідея, що тестувальники потрібні на всіх проєктах. Вона виникла 15 років тому або трошки більше, їх почали набирати майже із кого завгодно, і в нас купа людей із величезним досвідом і з мінімальними знаннями, бо їх беруть більше за досвід, ніж за знання по факту. Це велика проблема нашого ринку. У нас багато кандидатів, а класних спеціалістів не так багато.

Олег: Я хочу сказати, що так багато де в світі працюють. Є ж оці тули, які продають той самий record&play, testcomplite. І це ж хтось купує, є люди, які цим користуються. І, напевно, вони їм якусь користь приносять.

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

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

Чи у майбутньому залишиться місце для фахівців, які спеціалізуються на мануальному тестуванні, чи всім невдовзі доведеться перекваліфікуватись? (1:46:53)

Роман: Це питання не нашої ери, це промислова революція. Робота для мануальщиків у будь-якому випадку знадобиться, навіть штучний інтелект треба тестувати руками.

Рамелла: Не бачу можливості позбутись мануальщиків зовсім.

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

Роман: Я погоджуся з цим певною мірою, але оці інструменти кодогенерації породять новий ринок, і розробка і тестування переродиться. Бо колись вважали, що UML-діаграмами можна буде замінити департамент розробки, і просто намалювавши діаграми таблички для баз даних і продукт, візьме і запрацює. На жаль, нічого не вийшло. Те саме з no code solution — вони створюють новий ринок для розробки, бо вони породжують новий ринок для нових знань спеціалістів. Все буде перероджуватись.

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

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

Олег: А пам’ятаєте Delfi, visual basic. В 90-х був модним підхід Rapid development aplication — це ідея Delfi, visual basic, де вони зараз? Але є люди, які досі підтримують код на цих мовах. І їм зараз напевно привозять відро грошей.

А є ще чуваки, які пишуть на Cobol, я читав, що в США був дід, який зібрав таких самих дідів, які пишуть код на Cobol. Велика частина оборонних систем США написана на Cobol, Fortrun тощо. І це досі працює.

Рамелла: Мене запрошували тестувати Cobol в Німеччину з релокейтом. Це банківський проєкт.

Олег: А людей, які знають це, нема, в Україні знайшли двох. Дві людини, які можуть щось зробити на цьому проєкті. Такі технології живуть. І наші будуть жити.

Напишуть потужних роботів, а хто буде підтримувати код написання роботів. Код в основі хтось буде робити.

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

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

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

Нейронні мережі були в 14-15 році були блекбоксом, зараз є достатня кількість тулів, які дозволяють візуалізовувати на hidden layer якісь проміжні результати і розуміти ті патерни, які впливають в тому чи іншому кейсі на те чи інше прийняття рішення зі сторони нейронної мережі.

🎁 Бонус-треки:

Які є етапи запровадження автоматизації на проєкті? З чого потрібно починати?

Рамелла: На мою думку і виходячи з власного повторюваного успішного досвіду, слід розпочинати з аналізу інструментів та фреймворків, які найбільше підходять до даного проєкту. Скоріш за все буде потенційно підходити декілька і саме тому потрібна подальша оцінка (tool evaluation).

Для цього варто скласти табличку, де прописати pros vs. cons , враховучи також вартість інструментарію (якщо це не опен сорс). Також, якщо підрахувати приблизний ROI (тобто коли застосований інструментарій зможе окупити себе), продавати автоматизацію клієнту буде простіше.

Для більш точного прорахунку ROI варто зробити POC (proof fo concept) за допомогою одного, або двох інструментів і використати невеличкий набір тест кейсів, потім підрахувати час на виконання такого самого набору вручну та автоматично (можна подивитися багато статей на тему ROI of automation, або один з моїх виступів на QADay, де я якраз розповідаю про досвід моєї команді і надаю підрахунки:

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

Сергій: У запровадження автоматизації є конкретні явні пререквізити. Є моменти, про які варто подумати завчасно. По-перше, це тестова документація, умовні тест-кейси. Якщо вони не можуть бути перенесеними на автотест, це може викликати проблеми в подальшому. Буде складно метчити написаний тест-кейс і тест, вони будут не повністю співпадати. З цим буде складно працювати або взагалі переписувати тест-кейси.

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

Якщо два ці аспекти враховані, то впроваджувати автоматизацію вже буде нескладно.

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

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

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

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

Спочатку — прості тести, які відповідають business flow. Ваша мета — написати тести, довести їх до стабільності і вчасно їх запускати. Навіть якщо це буде невелика кількість тестів, вони можуть вже давати результати.

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

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

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

Ми вирощуємо спеціалістів самі, процес окупається, приносимо користь одне одному — людина отримала знання, а ми отримали на якийсь час спеціаліста, який вирішив конкретну задачу.

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