Етапи тестування ПЗ

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

Основні поняття

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

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

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

Життєвий цикл програмного забезпечення можна розділити на наступні етапи:

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

Етап перший. Аналіз вимог

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

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

Етап другий. Процес дизайну

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

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

Етап третій. Розробка

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

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

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

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

Етап четвертий. Процес тестування та дебаггінгу

Дебаггінг (налагодження) – це процес, під час якого знаходять і усувають помилки програми.

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

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

Етап п’ятий. Експлуатація та підтримка

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

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

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

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

Все, що потрібно знати про тестування

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

Сьогодні існує дві популярні методології тестування ПЗ:

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

• Agile – більш гнучкий метод тестування ПЗ, в якому розробка та тестування продукту виконуються паралельно. Переваги такого підходу в тому, що помилки не накопичуються та швидко виправляються. До його особливостей також варто віднести високий рівень залучення з боку замовників проекту.

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

Рівні тестування Quality assurance

Перед релізом програмний продукт повинен пройти чотири рівні тестування. Розглянемо кожен рівень докладніше.

Модульне тестування

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

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

Інтеграційне тестування

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

Інтеграційне тестування необхідно з кількох причин:

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

Існує чотири основні типи інтеграційного тестування:

• Інтеграція «згори донизу». Головний принцип такого типу тестування полягає в тому, щоб перевіряти працездатність спочатку блоків вищих, а потім нижчих рівнів. Тобто, простими словами, інженер QA виконує перевірку «зверху вниз».

• Інтеграція «знизу нагору». Зворотна модель тестування передбачає початок перевірки програмного продукту з низьких рівнів і поступовий перехід до вищих компонентів.
• Гібридна інтеграція. Комбінована стратегія, у якій використовуються перші два підходи. У цьому випадку модулі верхнього рівня інтегруються та тестуються з блоками нижнього рівня, і низькорівневі модулі навпаки – з верхньорівневими. У такому підході використовуються драйвери та заглушки.
• Стратегія “Великого вибуху”. І тут всі компоненти продукту збираються разом і тестуються як єдине ціле.

Системне тестування

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

Приймальне тестування

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

Цей рівень має дві класифікації тестування:

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

Для забезпечення коректної роботи програмного продукту важливо дотримуватися всіх рівнів та методів тестування програм.

Етапи тестування програмного забезпечення Quality assurance

Тестування – це не просто пошук помилок. Це складний та структурований процес, спрямований на підвищення якості програмного продукту. В основі тестування ПЗ лежить 7 основних етапів:

Аналіз вимог

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

• визначити специфіку та завдання майбутнього продукту;
• переконатися у відсутності протиріч у вимогах;
• переконатися у повноті та здійсненності всіх завдань;
• виявити потенційні дефекти та «вузькі місця» у функціоналі.

Планування та розробка стратегії

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

Розробка тест-кейсів

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

Тестування ПЗ

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

Повторне тестування

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

Завершення циклу тестування

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

Види тестування Quality assurance