Тестування — це гарантія того, що з кожним оновленням продукту користувачі будуть максимально захищені від багів. Інакше вони без краплі жалю почнуть використовувати рішення ваших конкурентів. То чи варто ризикувати? Сьогодні я розповім про те, як боротися з багами на великих проектах.
Джерело: Some Bugs, Amazon
Unit-тести
Перша категорія — баги, які з’являються у процесі написання функціоналу. Вони виникають, коли розробник не розібрався в функціоналі і не зрозумів замовника, або припустився помилки — всі ми живі люди, не помиляється лише той, хто нічого не робить.
Для цих багів ідеально підходять unit-тести, у яких враховуються можливі сценарії для даного юніту і його поведінку. У випадку фронтенда може бути простий юніт у вигляді кнопки і поп-апа: натиснули на кнопку, з’явився поп-ап.
Девелопер лише раз пише тест, а потім під час розробки за секунду або й менше може запустити його і перевірити, як працює відповідний функціонал. Якщо не написати цей автоматичний тест, frontend-розробнику доведеться вручну оновити сторінку, витратити додатковий час на проклікування елементів і перевірку стану через консоль.
Є більш цікаві баги, які напряму пов’язані з відсутністю тестів. Вони виникають в процесі оновлення функціоналу або написання нового. Щось із старого функціоналу не врахується або змінилася поведінка певних компонентів, і через це інші компоненти не можуть з ними взаємодіяти. Найстрашніше в багах без тестів те, що можна написати нові фічі, думати, що все добре і не знати про свіжу міну, на якій може підірватися репутація компанії, або баг, який може спричинити суттєві фінансові втрати.
Наприклад, у 2014 році через баг ціна на увесь асортимент товарів на сайті Screwfix стала однаковою — 34,99 фунтів, завдяки чому покупці змогли купувати інструменти з суттєвою «знижкою», а у 2011 році контракт з оператором T-Mobile можна було підписати безкоштовно, чим і скористалося 2 тисячі користувачів.
Звичайно, такі баги може виявити тестер чи сам розробник в процесі написання і перевірки, але, якщо вдуматись, скільки часу потрібно для багаторазової монотонної ітерації, то з цього можна зробити висновок: написання тестів заощадить в майбутньому набагато більше часу, ніж сам час, витрачений на написання тестів.
Також розробника може підвести впевненість у тому, що він все врахував. Для таких багів також дуже корисні unit-тести. Раз написав тести, після кожної зміни запустив їх, і, якщо нічого не впало, то молодець. А якщо є помилки, то швиденько виправив — і все чудово.
Інтеграційні тести
При відсутності тестів інтеграція сумісних компонентів також може вилитись у баги. Обидва компоненти можуть бути гарно написані, але їх взаємне використання призводить до пекельних страждань. Не слід також забувати про те, що під час розробки частина компонентів буде редагуватись і вдосконалюватись, і у нас залишається невизначеною їх взаємодія між собою.
Коли один компонент отримує від іншого не те, що очікувалось до цього, ми можемо з легкістю отримати баг і навіть не помітити його. Для того, щоб уникнути подібної ситуації, використовуються інтеграційні тести, які перевіряють стабільність взаємодії окремих частин.
e2e
Окрім того, для тестування взаємодії всіх компонентів в цілому використовуються end to end tests, котрі більш розлого тестують роботу всієї системи.
Приклад для фронтенда: є форма для заповнення певних даних. Наші e2e-тести завантажать сторінку і понатискають різні кнопки, введуть дані і перевірять, чи все загалом відбудеться по спланованому сценарію.
А давайте все покриємо e2e-тестами!
Здавалося б, e2e-тести ідеальні, якщо подивитись на них з точки зору теорії. З їх допомогою можна протестувати всі варіанти взаємодії користувача й інтерфейсу і виявити баги ще на ранніх етапах. Навіть і думка промайне, що більше тестів ніяких не потрібно, тільки e2e-тести, бо з ними і так можна виявити всі дефекти, явні для користувача.
Це частково вірно, але на практиці великі компанії (навіть Google) зіткнулися з тим, що e2e для розробки дуже не зручні, тому що одна із задач — це виявити баг, а інша — його виправити. Для фіксів необхідно знати, де саме виник баг, в якій частині коду, та оскільки e2e — узагальнюючі тести, вони не спроможні надати детальну інформацію. Саме через це Google у своїй статті Just Say No to More End-to-End Tests пропонує наступну пропорцію використання різних видів тестів:
70/20/10. 70% unit-тестів, 20% integration і 10% e2e. З цього можна зробити висновок, що чим легше розробнику виявити баг, тим менше часу на нього витратиться, і сам фікс буде більш коректним. Ми ж матимемо достатньо інформації про баг, а це пришвидшить реліз і зекономить кошти, які витрачаються на розробку програмного продукту.
Якщо взяти невеликий проект, який пише один девелопер, то спочатку можна обійтись без тестів. Фінанси обмежені, потрібно якнайшвидше випустити реліз і оцінити реакцію ринку на нього. Але коли проект масштабний і на ньому працює далеко не одна людина, без тестів дуже важко підтримувати продукт в робочому стані. Процес розробки без тестів виглядатиме приблизно так:
Здавалося б, зменшуючи час на тести, ми збільшуємо швидкість виходу релізу. Але насправді набагато більше часу ми витратимо на пошук і фікс багів, які не були усунені одразу завдяки написаним тестам. Один розробник щось написав, а інший з благими намірами додав щось своє, чим зламав функціонал свого попередника.
Великим проектам — великі тести
На моє глибоке переконання, іноді все ж можна (хоча й не бажано) відмовитись від тестів, але за умови, що проект дійсно дуже малий. Для великих проектів, які в майбутньому планують розвиватись і вдосконалюватись, іншого виходу, як писати тести, не існує. Інакше ми матимемо зриви релізів, і від релізу в реліз наш проект буде перетворюватись в колос на глиняних ногах, який все тяжче буде підтримувати і розвивати. Для бізнесу це виллється у невиправдані витрати і втрату часу та зниження актуальності запропонованого користувачам рішення.
Потрібен MVP, розробка під iOS, Android або прототип додатка? Ознайомтеся з нашим портфоліо і зробіть замовлення вже сьогодні!
