Як скоротити ручне тестування і чи можна без нього обійтися

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

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

Ми говоримо тільки про власному прикладі, але він є досить показовим, оскільки в портфоліо компанії присутні продукти і платформи різних розмірів і складнощів для різноманітних індустрій.

Розробка з ручним тестуванням

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

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

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

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

Трансформація підходів до тестування продуктів

У процесі переходу Railsware до моделі software consultancy, про яку ми писали раніше , нам необхідно було значно підвищити якість створюваних продуктів і, відповідно, кваліфікацію команди. Адже без цих складових вийти на новий виток розвитку компанії не представлялося можливим. Як частина процесу трансформації, був вдосконалений і наш підхід до тестування.

Ми вивчали успішні приклади на ринку і експериментальним шляхом виявили для себе декілька ключових підходів і технік, які використовуємо і сьогодні:

Юніт-тести і інтеграційні тести — невід'ємна частина коду. Абсолютно всі інженери на всіх проектах зобов'язані супроводжувати фічі автоматичними тестами.
Безперервна інтеграція (Continuous Integration) — система, при якій автоматичні тести проганяються при будь-якій зміні коду. На ринку існує безліч рішень для такого роду автоматизації, ось деякі з них: Jenkins , Circleci , Travis CI .
Обов'язкове використання валідаторів якості коду, таких як Rubocop , ESLint .
Pull Request Policy. Будь-код, який потрапляє в основну гілку проекту (master branch), повинен бути перевірений і затверджений одним або більше учасником, але не самим розробником.
Парне програмування — техніка розробки, яка передбачає одночасну спільну роботу двох інженерів над одним кодом.

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

Чи означає це, що ми повністю виключили мануальне тестування?

З впровадженням підходів, описаних вище, завантаження мануальних тестувальників на проектах суттєво скорочувалася. Для full-time завантаження тестувальників залучали part-time відразу на кілька проектів (якщо говорити про невеликих і середніх продуктах). Але ця модель виявилася неефективною: QA не повністю занурювався в контекст досліджуваного продукту, не був у курсі всіх прийнятих рішень. Така залученість приносила більше проблем, ніж користі. Тому ми покрили функцію мануального тестування за допомогою ще одного підходу, який запозичили у наших голландських колег по проекту Philips Directlife (у них на той момент вже не було власних QAs).

TestFest — це сесія мануального тестування, що проводиться перед великими релізами. У ній беруть участь інженери, продакт-менеджери, іноді UI/UX дизайнери, команда з боку клієнта. Про це підході ми напишемо окрему статтю, але якщо коротко, то на кілька годин вся команда стає мануальними тестерами.

Результат TestFest — список багів, кожен з яких отримує свій пріоритет і додається до загального скоуп.

Застосування даного підходу природним чином прибрало якусь потреба в окремому людину на позиції manual QA.

Висновки

Railsware поступово пішла від необхідності мати окремого manual QA в команді.

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

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

У такому форматі ми розробляємо продукти (як невеликі, так і досить великі платформи) ось вже 7 років. Очевидно, що в продуктах є баги. Але якщо порівняти якість продуктів Railsware до і після трансформації QA — останні виграють зі значним відривом.

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

Опубліковано: 25/04/18 @ 10:02
Розділ Різне

SEO Блог