Вручну або автоматично: Пара слів про тестування додатків

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

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

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



/ фото verkeorg CC

Автоматизоване тестування
думку Сари Фитжи (Sarah Fittje), інженера контролю якості в компанії Project A Ventures, якщо тест передбачає виконання великого числа повторюваних завдань, то його має сенс автоматизувати. Класичний приклад — регрессионное тестування, що дозволяє виявити серйозні баги, тому його важливо регулярно проводити у повному обсязі до запуску кінцевого продукту (до речі, якщо вам цікаво, можете почитати посібник для QA-фахівців від Сари, його ви можете знайти на посилання).

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

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

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

Тестування графічного інтерфейсу

Цей тип тестування націлений на перевірку front-end-частини програми. Без допомоги автоматизації дуже важко врахувати всі можливі комбінації взаємодії користувача з інтерфейсом в веб-браузерах, мобільних пристроях та інших системах (важливо розуміти, що такий тест не зможе оцінити UX, як було зазначено вище).

Регрессионное тестування

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

Функціональне тестування

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

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

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



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

Пара юзкейсов ручного тестування:

Юзабіліті-тестування

Це тестування служить для перевірки зручності використання програми з точки зору користувача. Таку розпливчасту по своїм цілям завдання комп'ютер не може вирішити — машині потрібні чіткі формулювання.

Ad hoc тестування

Разове тестування, спрямоване на перевірку одного аспекту програми. Для такого типу тестування ні формально визначених правил, воно проводиться імпровізаційно — тестувальник може використовувати будь-які доступні засоби для пошуку багів. Фактично ad hoc тести – це спроба «вгадати» можливу помилку.

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

Як приклад такого підходу Сара Фитжи призводить процес тестування онлайн-магазину natue, коли після успішного впровадження нових функцій в тестовому проекті, QA-команда запускала автоматизоване регрессионное тестування.

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



Ще один приклад наводить Стівен Аллен (Steven Allen), інженер компанії TestGrid.io. Він говорит, що в iOS повноцінне автоматизоване тестування довгий час було недоступним. Кілька років тому Apple почали випускати інструменти для автоматизації, але вони поки що не досконалі. Тому використовувати тільки засоби автоматизації не виходить – доводиться вдаватися до ручного тестування.

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

«Дуже складно написати ідеальний код для автоматичних тестів, – говорить Джозеф Міллар (Joseph Millar), спеціаліст відділу контролю якості компанії Lucid Software. – Якщо розробник припуститься помилки в скриптах, він ризикує пропустити великий пласт помилок, тоді як при ручному тестуванні ці недоліки, швидше за все, будуть виявлені. Тому так важливо використовувати обидва методи при розробці додатків. Один для економії часу, другий для «шліфування».

P. S. Наші інші матеріали: Дайджест про хмарах, мережевих технологіях і розробці сервісів.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.