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

Усі статті, обговорення, новини про тестування — в одному місці. Підписуйтеся на DOU | 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 рішенню ми значно пришвидшили процес розробки ПЗ всередині компанії.

Висновок

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

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

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

👍ПодобаєтьсяСподобалось5
До обраногоВ обраному5
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Раз тут склалася думка, що ви продаєте певний інструмент для автоматизації тестування, то і я з цього боку зайду.
Як на мене, це легко продати нетехнічному менеджеру, але менеджер, який розбирається в тому, що то таке ті авто тести, то вже не так просто. Не буду брати на себе відповідальність говорити за всіх, але запропоную продати цю історію мені.
Отже пункти, які мене, м’яко кажучи, насторожують:
1. Беремо будь-який лоу код тест автомейшн інструмент і пишемо на ньому 3000 тестів. Потім цей інструмент якось дуже дорожчає, або взагалі перестає існувати. На скільки просто мігрувати всі тести на інший інструмент? Коли пишеш тести з розумом будь-якою мовою на будь-якому інструменті, то можна той інструмент максимально ізолювати і відносно безболісно переїхати за потреби.
2. Що робити з підтримкою? Коли тестів стає багато і змінюється якийсь зашарений компонент на фронті, то падає одразу багато тестів, які треба окремо ручками піти і оновити. Коли є пейдж обджекти/фрагменти, компоненти, екшини і тести написані в бдд стилі (не плутати з кукумбером), то ледь не будь-яка зміна на юаї, яка афектить багато тестів, має відповідну одну зміну в коді тестів і все продовжує працювати.
3. Що робити з пре/пост кондішинами для тестів? Якщо є потреба в створенні перед тестом і видаленні після тесту ряду сутностей через апішку. При чому коли для створення наступної сутночті, треба спочатку отримати респонс від попередньої. І тут теж постає питання підтримку, так як контракт апішки теж може мінятися.
4. Ще мене турбують питання гнучкою параметризації тест рану (найпростіший приклад енв) та налаштування і інтеграція з CI, щоб, наприклад, зробити quality gate. Робота з куками та local storage... Це простіші питання і, впевнений, є ряд інструментів, які то все підтримують, але питання гнучкості залишаються відкритими.

Виглядає, як порохова бочка. Почали робити, всі задоволені, а потім нема кому ті тести підтримувати.
Я в питанні low-code automation не експерт, тому залюбки вислухаю всі аргументи за.

Впринципе, тот факт что в статье есть реклама это не проблема, особенно если статья хорошая! Но к сожалению мне статья не зашла, вода одна.

Если кому лень читать до конца — то тут автор рекламирует продукт своей компании. Вопрос к автору: ваша компания уже полностью перешла на

No-code рішення для автоматизації процесу тестування

?

No-code рішення для автоматизації процесу тестування стають все популярнішими серед розробників та QA-інженерів.

Ага ага, а статистику можна побачити?

Згідно з дослідженням компанії Gartner,

Вибачте, але там за посиланням 0 iнформацiï про no-code для автоматизації тестування.

Якось дуже схоже на приховану рекламу Testlum))

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

Підписатись на коментарі