Тестування у житті програміста

1. Навіщо тестування потрібне програмістам

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

У розрізі ПЗ можна сказати, що завдання тестування – перевірити, що програма:

• робить те, що має робити
• не робить того, що робити не повинна

Другий пункт, до речі, не менш важливий, ніж перший, але про це трохи згодом.

Почнемо з першого пункту. Що означає “програма робить те, що вона має робити”?

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

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

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

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

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

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

Але повернемося до помилок, які всі визнають помилками: програма явно робить щось не те, впала, зламала щось, тощо. Такі помилки умовно можна поділити на 3 категорії: великі, середні та маленькі.

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

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

Тестування — це процес, спрямований на пошук помилок. Ці помилки потрібно знайти, описати та пріоритезувати. Лише після пріорітезації помилок можна говорити про ефективний процес покращення ПЗ.

Не забувай, перший крок до вирішення проблеми – це визнати наявність проблеми. Не можна виправити помилку, про яку не знаєш.

2. Автоматизація тестування

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

Ми автоматизуємо будь-які процеси, з якими стикаємось. А як автоматизувати пошук помилок? Коротка відповідь: ніяк. Але тут нам на допомогу знову приходить те, що ми є програмістами.

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

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

Тут весь софт можна розділити на дві частини:

• програма взаємодіє з людиною
• програма взаємодіє з іншою програмою

Перша частина автоматизується складніше: для нього потрібні спеціальні тестувальники-автоматизатори, яких називають QA Automation або Software Test Engineer.

А ось другу частину можна автоматизувати самостійно. Якщо у тебе є фрагмент програми, який:

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

Рекомендую виділити час та написати для нього тести, які зафіксують ключові аспекти його поточної функціональності. На це буде розумно виділити 5% твого робочого часу, або 1 день на місяць.

Не потрібно писати тести для тестів.

Ніхто не підтримуватиме твої тести. Ані інші програмісти, ані ти сам. Так ніхто не робить. 99% всіх написаних тестів закинуто та/або відключено. Якщо можеш не писати тести – не пиши. Пиши тільки якщо без них точно не обійтися.

3. Типи тестування

Кожен програміст, якщо він не проходив спеціальне навчання, зможе розповісти своїми словами, що таке тестування: перевірка, чи робить програма те, що повинна. Проте професіонали у цій галузі виділяють окремі напрями (типи) тестування.

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

Скажімо, ти тестуєш типовий інтернет-магазин. Тоді напрями тестування можна розділити на такі типи: тестування продуктивності, функціональне тестування, інтеграційне тестування та модульне тестування.

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

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

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

Твій інтернет-магазин швидше за все інтегрований зі сторонніми сервісами: розсилання листів та СМС, платіжні системи, онлайн-чати підтримки, збір зворотного зв'язку від користувачів, рекламні системи тощо. Щоб переконатися, що все це працює як задумано, тобі потрібно провести інтеграційне тестування.

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

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

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