Чистий код і тестування: де починається зона відповідальності QA

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

robot_dreams опитав п’ять досвідчених QA-інженерів про те, як виглядає чистий код очима тестувальника, як тестувати код не найкращої якості та чи треба самому тестувальнику вчити патерни проєктування і принципи SOLID.

Що таке чистий код з точки зору тестувальника

Чистий код легко розуміти, зберігати й підтримувати. А отже, як вважає Юрій Вороненко, Senior Software Development Engineer in Test у Very Good Security inc та лектор курсу QA Automation, такий код мусить: 

1. бути оформлений за стандартом (convention);

2. гарно читатися;

3. не містити дублікатів;

4. відповідати принципам SOLID;

5. міститиюніт-тести на кожен клас.

«Якщо ми кажемо про чистий код у контексті тестування, то це коли QA-інженер сам займається написанням тестів і дотримується певних правил для підтримки чистоти коду. Для мене це код без зайвого ускладнення, тобто використання “магічних змінних” або “магічних чисел”, коли ніхто не розуміє, що означає твоя змінна»

Юрій Сердюк, Software QA Automation Engineer

Сергій Сахненко, QA Lead / Community building manager та лектор курсу QA Manual, також каже, що чистий код легко зрозуміти, тому в ідеалі у ньому не має бути складних конструкцій:а

«‎Зрозумілий та читабельний код легше аналізувати на наявність багів. Він також дозволяє зосередитися на тестуванні функціональності та логіки, а не витрачати зайвий час на розгадування неявних або заплутаних розділів».

Як неякісний код впливає на тестування

«"Поганий" код не тільки збільшує кількість багів, але й провокує їхнє виникнення в неочікуваний час та в неочікуваних місцях». 

Олекса Мащиць, QA Team Lead

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

Юрій Вороненко, Senior Software Development Engineer in Test у Very Good Security inc, каже, що саме тому дуже важливо слідувати стандартам написання коду — щоб уникати тривіальних помилок, які обов’язково випливуть на наступних етапах тестування.

«Нічого нового тут немає: потрібне гарне покриття юніт-тестами, наявність код-рев'ю, продумана архітектура та дотримання мінімальних “правил” кодингу на проєкті, щоб усі розробники працювали як команда, а не кожен додавав унікальних підходів, що збільшує безлад і ризик виникнення купи багів — наприклад, інтеграційних».

Олекса Мащиць, QA Team Lead

Цікаво! Коли код чистий, тестувальнику набагато легше зрозуміти, який функціонал виконується, без додаткової комунікації з девелоперами. Юрій Сердюк, Software QA Automation Engineer, ділиться, що мав досвід, коли перед початком тестування він продивлявся pull request — і на цій стадії вже можна було знайти якісь баги. «Але зауважу, що це потребує від тестувальника хоча б якихось базових знань коду», — додає Юрій.

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

Щодо нефункціональних вимог до коду, то код, який погано читається, призводить до складнощів на етапах код-рев'ю, виправлення помилок, адаптації для нових інженерів на проєкті. Також такий код часто призводить до помилок, оскільки інженер може просто пропустити умову. 

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

Юрій Вороненко,
Senior Software Development Engineer in Test у Very Good Security inc,
лектор курсу QA Automation

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

Чому знати патерни проєктування — не привілей розробників

Олекса Мащиць, QA Team Lead, каже, що будь-яка інформація про проєкт для тестувальника буде корисною, але важливе питання — чи вмітиме він її використати? «На практиці ми нечасто заходимо в цей бік через брак кваліфікації, на жаль», — ділиться досвідом Олекса.

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

«Якість фреймворку тестування напряму залежить від грамотного використання патернів, архітектури фреймворку в цілому. Від цього залежить те, як швидко можна додавати нові тести й підтримувати наявні. Загалом усе як у розробці, тільки ми пишемо продукт, який тестує інший продукт», — каже Юрій Вороненко, Senior Software Development Engineer in Test у Very Good Security inc.

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

Ростислав Біляєв,
Senior QA Automation в Adidas,
лектор курсу QA Automation

Що робити, якщо потрібно тестувати погано написаний код?

Ростислав Біляєв, Senior QA Automation в Adidas, пропонує декілька кроків:

1. Співпрацюйте з розробниками для рефакторингу 

2. Впроваджуйте шаблони проєктування

3. Використовуйте макети

4. Визначте пріоритети тестування та автоматизації

5. Пропагуйте якісні практики кодування та документуйте проблеми 

Загалом кажуть, що ситуації, коли розробники ні в яку не дотримуються чистоти коду, трапляються вкрай рідко. Але все ж таки, якщо таке станеться з вами, Сергій Сахненко, QA Lead / Community building manager, ділиться двома базовими порадами:

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

2. Налаштуйте автоматизоване тестування: воно допоможе виявляти баги, навіть якщо код має низьку якість.

«Інженер з якості має займатись не тільки тестуванням, але й брати участь у плануванні, формуванні процесів розробки, налаштуванні чек-листів, які, своєю чергою, зводять ризики, пов'язані з помилками ПЗ, на мінімум. Якщо з менеджментом було погоджено підходи та процеси контролю якості та ви все правильно налаштували, то розробник просто не зможе вилити поганий код у гілку, його не пропустять quality gates»

Юрій Вороненко, Senior Software Development Engineer in Test у Very Good Security inc

Олекса Мащиць, QA Team Lead, каже, що розробники будуть прагнути покращувати якість свого коду, якщо грамотно вказати на втрати за часом та ризики, які виникають внаслідок написання неякісного коду.

Окремою темою тут може йти автоматизація тестування, яка відбере частину «брудної» роботи у мануальних тестувальників та буде «муляти очі» розробникам, мовляв, «Усі тести впали! Знову!». Такий статус нікому не подобається.

Інструменти, які допомагають тестувати код

Ростислав Біляєв, Senior QA Automation в Adidas, зазначає, що вибір інструменту тестування часто залежить від системи, що тестується (SUT), та її конкретних вимог:

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

Юрій Вороненко, Senior Software Development Engineer in Test у Very Good Security inc, підкреслює, що з точки зору функціонального тестування, це, звичайно, юніт-тести. Якщо тестування нефункціональне, то допоможуть різного родулінти — з ними легко знаходити помилки на рівні оформлення коду, документації. Один із потужних інструментів — SonarQube.