Автоматизація процесу тестування: кому, навіщо і як

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

Привіт! Мене звати Олексій Гнідаш, і я вже 15 років працюю у сфері розробки, 7 з яких в ролі архітектора. Як CTO міжнародної компанії KnubiSoft, я добре розумію, що програмне забезпечення (ПЗ) — це лише інструмент, і потрібно знати, як користуватись ним правильно, щоб бути успішним у бізнесі.

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

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

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

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

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

Найпоширеніші проблеми тестування сьогодні

Існують різні підходи до тестування. Деякі компанії намагаються покрити все юніт-тестами, хтось обирає підхід TDD (test-driven development), дехто взагалі перестає тестувати, а є й ті, хто все досконально покриває тестами, використовуючи навантажувальне чи наскрізне тестування.

Відсутність часу на якісне тестування

Якість продукту — це головна ціль будь-якої розробки. Буває, що клієнти використовують таку метрику, як code coverage, для визначення якості продукту. Проте насправді ця метрика показує лише якість покриття тестами ПЗ, а не якість самого продукту.

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

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

Щоб уникнути проблеми відсутності часу та покращити якість тестування, розробники можуть спробувати підвищити ефективність свого процесу тестування шляхом автоматизації деяких етапів. Згідно зі статистикою RWS, 44% компаній вже автоматизувало половину процесів тестування у 2020 році, і їхня кількість зростає щорічно.

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

Погана якість тестів

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

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

Відсутність стандартизації процесу

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

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

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

Важливість правильних інструментів для тестування

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

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

Що ж таке хороший інструмент

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

• Він має бути простим, інтуїтивним та зрозумілим та не потребувати довгого онбординг-процесу.
• Він має повністю логувати всі дії, що відбуваються під час процесу тестування та створювати технічну документацію автоматично. Будь-яка людина має розуміти, як пройшов тест, завдяки детальним логам.
• Такий інструмент не має бути мануальним, тобто не має містити повторення одних і тих самих рутинних дій для тестувальника.
• Головна задача дієвого інструменту — оптимізація процесів. Він має сприяти єдиній стандартизованій та оптимізованій системі роботи, що працює за єдиним регламентом та дає однакові результати для будь-кого.
• Він має розв’язувати ваші проблеми та звільняти час для інших, критичніших задач для тестувальників (пошук більш критичних багів та специфічних кейсів, створення більш кастомних дата-сетів, робота з вимогами до ПЗ та ін.).
• Такий інструмент має сприяти командній роботі тестувальників і розробників, бо він є головною формою обміну інформації між ними.

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

Як досягти синергії розробника та тестувальника

Розробники роблять баги — і це нормально. Проте вони також мають виявляти й виправляти ці баги наприкінці своєї роботи. Так само для ефективної та злагодженої роботи команда тестувальників має доповнювати команду розробників.

В більшості компаній існує два типи команд:

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

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

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

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

No-code рішення для автоматизації процесу тестування стають все популярнішими серед розробників та QA-інженерів. Згідно з дослідженням компанії Gartner, використання low та no-code рішень збільшиться втричі вже до 2025 року. Це пов’язано з тим, що вони дозволяють створювати автоматизовані тести без жодних знань з програмування.

Ми в компанії розробляли різні види тестування, але врешті-решт дійшли висновку, що саме no-code рішення значно покращують швидкість і якість тестування. Таким інструментом є, наприклад, Testlum. Це рішення для автоматизованого тестування є центральним хабом для обміну інформацією між тестувальником та розробником. В ньому є: документація, інструкції для відтворення багів в автоматичному режимі та інтеграція з git. Це дозволяє спростити формат взаємодії між тестувальником та розробником, тому що інструмент зменшує навантаження на тестувальника і розробника.

Testlum — це не єдиний інструмент для автоматизації, він є аналогом таких відомих продуктів для тестування як Selenium та Postman (API-тестування). Можливо, цей продукт не є новітньою технологією, але завдяки цьому no-code рішенню ми значно пришвидшили процес розробки ПЗ всередині компанії.

Висновок

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

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

Зичу всім простих релізів та мати час на настолки в п’ятницю!