Управління якістю програмного проекту

Размещено на http://www.allbest.ru/

1. Система управління якістю

1.1 Якість продукту в системі управління якістю програмного проекту

якість вимога проект

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

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

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

З огляду на специфіку проектної діяльності, слід так само керуватися профільними стандартами: ISO, СММ (Capability Maturity Model), CMMI (Capability Maturity Model Integration), PMBoK і ін.

Відповідно до ДСТУ ISO 9000-2001, якість - це "ступінь відповідності сукупності притаманних характеристикам продукції вимогам"[1], які для області розробки програмного забезпечення можуть бути не трактовані повністю.

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

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

Іншими словами, щоб забезпечити якість, необхідно задовольнити потреби зацікавлених сторін. Однак, задоволення або перевищення вимог не є частиною управління якістю проектів. Відповідно до Посібника до Органу управління проектами (Керівництво PMBOK®), якість - це "ступінь, до якого набір властивих характеристик відповідає вимогам". Керівник проекту та команда з управління проектами несуть особливу відповідальність за збалансування якості та класу (категорія чи ранг, присвоєний продуктам або послугам, що мають однакове функціональне використання, але різні технічні характеристики).

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

Управління якістю в проектах має такі дві сторони як:

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

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

Взаємозв'язок між якістю проекту та якістю продукції може бути проілюстрована такими загальними прикладами:

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

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

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

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

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

Функціональність (наскільки програмний продукт буде актуальний для користувача);

Якість призначеного для користувача інтерфейсу (зручність та легкість у використанні);

Надійність (відсутність дефектів в програмному продукті, стійкість до збоїв);

Продуктивність, споживання ресурсів, вимоги до зовнішнього середовища;

Якість інформаційної підтримки (документація);

Якість дизайну і коду, внутрішня якість.

Інші варіанти переліку критеріїв якості можна знайти, наприклад, в [2, с. 456-457; 3, с. 244]. Кожна компанія повинна визначати свої стандарти якості для кожного критерію для кожного програмного проекту. При оцінюванні якості необхідно мати можливість кількісно оцінити кожен із критеріїв.

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

Таблиця 1. Вплив видів діяльності життєвого циклу на якість програмного проекту

Види діяльності	Функціональність	Якість інтерфейса користувача	Надійність	Якість архітектури і коду	Продуктивність	Якість документації
Розробка вимог	Ч	Ч
Архітектурний аналіз і дизайн		Ч	Ч		Ч
Кодування			Ч	Ч	Ч
Розробка документації						Ч
Тестування	Ч	Ч	Ч	Ч	Ч

*Джерело: побудовано автором на основі даних [2,с.243]

Важливо, що на якість кінцевого продукту впливають всі фази і види діяльності проекту без винятку - від найбільш ранніх до самих пізніх. Таким чином, то, наскільки добре і якісно працювати на кожній фазі проекту, залежить, наскільки якісним вийде продукт. Або іншими словами, якість процесу розробки визначає якість продукту, що розробляється [2, стр. 470], тобто якість продукту невіддільне від якості процесу, і для того, щоб поліпшити якість програмного проекту, потрібно покращувати якість процесу розробки цього продукту [4, стр. 271].

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

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

Дефекти можна класифікувати, наприклад, за такими параметрами:

Тип дефекту (визначається фазою розробки або активністю, на якій він був внесений);

Критичність дефекту (наскільки критично його наявність в програмному продукті);

Пріоритет дефекту (наскільки важливо його виправити);

Складність дефекту (наскільки трудомістким його виправити).

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

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

Рис. 1. Зміна кількості дефектів в проекті з плином часу при традиційному підході до управління якістю.

*Джерело: побудовано автором на основі даних [2, c.291].

Представлений рисунок 1 вказує, що Req - фаза збору вимог, design - фаза проектування, Code - фаза кодування, IT - фаза інтеграційного тестування, ST - фаза системного тестування. Верхня червона лінія - кількість внесених дефектів на поточний момент часу (слід пояснити, що ця лінія є уявної, тому що не можна точно підрахувати загальну кількість дефектів до тих пір, поки не знайдуть їх). Нижня зелена лінія зображує кількість знайдених та виправлення дефектів на поточний момент часу (тут припускається, що дефекти виправляються практично відразу ж після того, як були знайдені). Різниця між червоною і зеленою лінією в кожен момент часу відображає кількість наявних на даний момент дефектів. Чим вона менша, тим якісніше вийшов продукт. З точки зору якості життєвий цикл як це показано на рис. 1 представляється як змагання між процесами внесення дефектів та їх виправлення [2, с. 292-293].

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

Отже, для управління якістю недостатньо простого використання різних методів її підвищення. Необхідно їх усвідомлене систематичне застосування, яке стало б невід'ємною частиною процесу розробки програмного забезпечення, орієнтованого на якість [6, с. 231-233].

Необхідний постійний контроль якості розробленого програмного забезпечення через метрики якості [7, с. 304-337], а також контроль якості окремих підпроцесів, що становлять цілісний процес розробки.

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

1.2 Особливості тестування програмних продуктів

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

Організація тестування програмного забезпечення забезпечує регулювання наступних параметрів:

IEEE 829-1998 Стандарт для тестової документації на програмне забезпечення. Описує види документів, слухає для підготовки тестів;

IEEE 1008-1987 (R1993, R2002) Стандарт для тестування програмного блоку. Описує організацію модульного тестування;

ISO / IEC 12119: 1994 (AS / NZS 4366: 1996 та ГОСТ Р-2000, також представлений IEEE під номером IEEE 1465-1998) Інформаційні технології. Програмні пакети - Вимоги до якості та тестування. Описує вимоги до процедури тестування програмних систем [8].

Відповідно стандарту ANSI / IEEE 1059, тестування можна визначити як «Процес аналізу програмного продукту для виявлення відмінностей між існуючими та необхідними умовами (тобто дефекти / помилки / помилки) та оцінки особливостей цього програмного забезпечення».

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

Хто проводить тестування?

Це залежить від процесу та пов'язаних із ним зацікавлених сторін проекту. У ІТ-індустрії великі компанії мають команду, відповідальну за оцінку розробленого програмного забезпечення в контексті заданих вимог. Більше того, розробники також проводять тестування, яке називається Одиничне тестування (Unit Testing). У більшості випадків до тестування системи у відповідних можливостях беруть участь наступні фахівці:

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

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

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

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

Як відбувається процес тестування?

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

Життєвий цикл тестування програмного забезпечення (STLC) - це процес тестування, який виконується систематично і плановим чином. У процесі STLC проводяться різні заходи для покращення якості продукту. Сьогодні програмний продукт проходить кілька етапів STLC (Рис. 2), перш ніж його розгортати та використовувати. Проводяться різні типи тестів для виявлення не лише помилок, а й будь-яких незначних збоїв, щоб клієнти були повністю задоволені ефективністю та якістю вашої продукції. Усі етапи тестування програмного забезпечення є важливими, оскільки вони гарантують, що тестування проводиться систематично і документується, щоб уникнути прогалин. Всі етапи STLC в основному містять перелік заходів, які потрібно виконати, і мають встановлені критерії входу (передумови, які необхідно виконати до початка фази життєвого циклу тестування) та виходу (вимоги, яким потрібно виконати до завершення фази циклу тестування).

Рис. 2. Життєвий цикл тестування програмного проекту.

*Джерело: розроблено автором.



Модель STLC, як правило, складаються з 6 фаз тестування, починаючи від необхідності аналізу до закінчення випробувального циклу. Аналізуючи рис. 2, доцільно буде детально розглянути кожний з пунктів.

Аналіз вимог

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

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

Щоб розпочати аналіз вимог, вам потрібно мати такі документи:

Документ щодо функціональних специфікацій;

Документ із специфікацією вимоги;

Документ-дизайн проекту.

На цьому етапі проводяться такі дії:

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

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

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

Визначення вимоги тестового середовища;

Визначення, чи потрібно тестування автоматизації, та інші типи тестів, які потрібно виконати.

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

Планування тесту

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

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

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

Документ щодо вимог;

Звіт з технічного обґрунтування (якщо застосовується у проекті);

Список перевірених вимог.

На цій фазі будуть проведені наступні дії:

Команда з контролю якості визначає об'єктиви та висвітлення тестового проекту;

Підготувка переліку видів тестування, які будуть проводитися;

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

Інструмент звітування про помилки;

Інструмент управління тестом;

Інструмент автоматизації тестування.

Розбиття процесів тестування на етапи та опис кожного кроку;

Вибір необхідного середовище для тестування;

Підготовка тестового графік із зазначенням часової шкали для всього процесу тестування та кожного кроку;

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

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

Розробка тестового випадку

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

Налаштування тестового середовища

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

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

Виконання тесту

Цей крок є основною суттю всього процесу життєвого циклу. Це етап, на якому виконуються всі розроблені тестові справи. Існує два способи виконання: ручне та автоматичне. Під час ручного тестування інженер управління якістю вручну виконує тестові випадки та записує результати. Хоча для автоматизованого тестування розробляються тестові сценарії, які автоматично запускаються в автоматизованому тестувальному інструменті для перевірки результатів кожного тестового випадку. Є три можливі результати виконання тестового випадку: пройдено, не вдалося або заблоковано.

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

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

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

Закриття тестового циклу

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

1.3 Роль та місце автоматизованого тестування інтерфейсу користувача в забезпеченні якості програмного продукту

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

У автоматизованого тестування є як свої переваги, так і недоліки. До сильних сторін автоматизованого тестування відносять:

Стрімка швидкість виконання, набагато перевершує можливості людини;

Відсутність вплив «людського фактору» (неуважність, втома);

Можливість багаторазового виконання тестів і зниження витрат через це;

Виконання тест-кейсів особливою складністю, недоступних людині;

Здатність зберігати, аналізувати в зручній формі колосальні обсяги даних;

Здатність виконувати низькорівневі дії з додатком, з операційною системою.

До недоліків автоматизованого тестування відносяться:

Необхідність залучення висококваліфікованого персоналу для автоматизації замість можливості використовувати низькокваліфікований працю тестувальників;

Витрати на засоби автоматизації, на розробку і супровід тестів;

Фінансові витрати і ризики, пов'язані з наявністю великої кількості коштів автоматизації і складністю вибору;

Старіння тестів у випадках змін вимог, переробки інтерфейсів тестових продуктів.

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

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

У своїй книзі «A Practitioner's Guide to Software Test Design» Лі Копланд призводить відповіді, які дають фахівці з тестування на питання про те, з якими найбільш поширеними проблемами доводиться стикатися в їх роботі: «недостатньо часу, щоб тестувати ретельно», «занадто багато комбінацій вхідних даних», «недостатньо часу, щоб протестувати добре», «дуже мало часу виділено на тестування» [10, с. 270].

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

Спроби автоматизувати процес тестування відбувалися ще в 80-их роках. У 90-их з'явилися перші інструментальні засоби автоматизації тестування. А в нульові роки автоматизація тестування сприймалася вже як невід'ємна частина більшості проектів.

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

Існують різні підходи до автоматизації тестування. Вона включає всього 3 рівня автоматизації (Рис. 3):

Автоматизовані одиничні тести (Automated Unit Tests);

Автоматизовані сервісні тести (Automated service tests);

Автоматизовані тести інтерфейс користувача (Automated UI Tests).

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



Рис. 3. Піраміда автоматизації тестування

*Джерело: побудовано автором на основі даних [12].

На рис. 3 слід зазначити відразу те, що його насправді називали «Піраміда тестової автоматизації», оскільки вона спочатку була створена саме для цілей автоматизації тестів. Дана дипломна робота присвячена реалізації третього рівня тестування - тестування користувальницького інтерфейсу.

Автоматизовані одиничні тести

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

Тестовій піраміді потрібна міцна база, і саме тут проводяться одиничні тести. Це означає, що вони є найпоширенішим типом тестування в тестовій піраміді.

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

Рамки, такі як Mockito Java або Sinon JavaScript, є загальними інструментами, які можна знайти в тестовому рівні блоку. Макети дають розробникам можливість контролювати поведінку компонентів, які використовуються випробуваним. Наприклад, клас, який залежить від спілкування зі службою Rest, може використовувати клієнтську бібліотеку HTTP. Розробнику, можливо, доведеться знущатися з HTTP-клієнта, щоб контролювати типи відповідей, повернених веб-службою.

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

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

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

Тести автоматизованого обслуговування

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

Автоматизовані тести інтерфейс користувача

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

Інтерфейс користувача (UI) став найбільш звичайним способом взаємодії з програмним забезпеченням. UI реагує на різні події користувача, такі як клацання миші та натискання клавіш. Це дозволяє користувачеві спілкуватися з базовим додатком. UI, в свою чергу, спілкується з користувачем за допомогою викликів методів або якоїсь системи обміну повідомленнями. Велика частина коду присвячена реалізації та підтримці графічного інтерфейсу. Дослідження показали, що до впровадження UI було використано до 60% всього програмного коду [13]. Однак до останніх років підхід тестування графічного інтерфейсу щодо функціональної коректності програмного забезпечення в основному нехтувався. Використання інтерфейсу в важливих для безпеки системах також швидко збільшується, що також підкреслює необхідність тестування функціональних можливостей UI. Правильне тестування інтерфейсу може суттєво сприяти загальному рівню якості, надійності та зручності використання всього додатка.

Функціональний тест UI означає перевірку об'єктів UI, перевірку функціональних потоків за допомогою керуючих об'єктів UI та перевірку вихідних даних, які генеруються в back-end та потім відображаються на перших сторінках [14]. Люди наважилися виконувати ці операції, дотримуючись різних моделей і прийомів, які можуть варіюватися від повністю ручного до напівавтоматичного. Однак тенденція полягає в автоматизації якнайбільше, щоб зробити це дуже швидко і мати величезне покриття, яке б інакше зайняло величезний час для людини.

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

Дослідження в автоматизованих поколіннях тестових випадків показали, що більш високий рівень підтримки може бути досягнутий шляхом автоматичного генерування тест кейсів, хоча програміст все ж повинен кодувати всі можливі моменти рішення у графічному інтерфейсі [16]. Полегшуючи та сприяючи більшій автоматизації, системи, здатні автоматично генерувати та вибирати тестові кейси, виконувати їх та повідомляти про результат, вступають у реалізацію [15]. Ідея автоматизації тестування імітує те, що може зробити людина, використовуючи графічний інтерфейс та тестові дані, тобто взаємодіяти із системою та перевірити, чи досягнуті бажані умови. У цьому процесі є декілька виклики. Однією з найбільш ранніх і найважливіших проблем є визначення об'єктів графічного інтерфейса користувача (GUI) та їх дій та подій. Після цього слід розробити тест-тест, підбір та їх виконання та звітність.

Основна причина тестування GUI, що важко автоматизувати, полягає в тому, що взаємодія між користувачем та додатком є ??інтерактивною. Кілька авторів висловили, що будь-який автоматизований інструмент для подолання цих труднощів повинні мати можливість надавати наступні послуги [17]:

Запис та відтворення фізичних подій у графічному інтерфейсі

Захоплення екрана та порівняння

Сценарії оболонки для контроля та виконання тестів

Люди стикалися з безліччю проблем у процесі автоматизації тестування графічного інтерфейсу [16]. Порівняно з традиційним тестуванням програмного забезпечення, воно стикається з набагато більшими труднощами. Навіть просте завдання визначення критеріїв покриття стикається з ускладненнями, оскільки традиційні критерії покриття на основі коду не обов'язково застосовуються в цій галузі. Введено такий критерій, як "висвітлення подій", який може бути, як і всі доступні події в додатку, принаймні слід викликати один раз. Вирішити, скільки потрібно охопити подіями, може бути дуже важливим, оскільки часто, якщо ми намагаємось захопити всі можливі розгалуження та шляхи, воно може бути занадто великим. Аналогічно перевірити, пройшов чи не вдався тест GUI, також може бути складним.

Як правило, процес включає окрему програму під назвою "Test oracles", яка порівнює очікувані результати з фактичними результатами та вирішує, чи буде пройдений тест. Але все ж вирішити, що потрібно перевірити, щоб прийняти це рішення, може бути непростим. Наприклад, тестовий випадок може призвести до появи екрана, який більше не містить певного рівня, але весь стан програми все ще є правильним. Тепер тест може бути невдалим лише тому, що він не знайшов ярлик у правильному положенні. По мірі прогресу проекту та появи нового графічного інтерфейсу тестовий проект також має бути розширений таким чином, щоб усі сфери GUI були охоплені та протестовані. Регресійне тестування також має особливі труднощі для тестування UI. Тести UI можуть залежати від верстки, і в міру розробки програми незначні позиції можуть змінюватися дуже часто. Це в свою чергу може змінити результат багатьох старих тестів. Так само багато тестових результатів, які використовуються тестовими оракулами, можуть бути застарілими. Виявити часті модифікації та адаптувати старі тести до цих змін може бути дуже дорого.



Розділ 2. Розробка мобільного додатку “Щоденник дієти”

2.1 Особливості програмного проекту з розробки мобільного додатку “Щоденник дієти”

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

Предметом дослідження дипломної роботи є користувальницький інтерфейс мобільного додатку "Щоденник дієти".

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

Android додаток «Щоденник дієти»- особистий асистент, тренер, дієтолог, персональний помічник і об'єктивний контролер у вашій кишені.

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

Основними конкурентами «Щоденник дієти» являються такі мобільні додатки як: «I Eat Better», «Lifesum», «Calorie Counter», «Food Diary» та інші.

Плюси щоденник дієти:

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

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

Велика пам'ять. Користуючись щоденником дієти, ви цілком можете носити з собою «архіви»;

За допомогою електронного щоденника дієти можна задавати циклічні програми. Це заощадить час користувачам;

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

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

Для досягнення поставленої мети потрібно дослідити:

Розробку вимог нашого користувальницького інтерфейсу.

Створення наборів автоматичних тестів;

Звіт про проблеми в разі розбіжності поведінки системи і вимог інтерфейсу.

Перед початком тестування потрібно чітко визначити вимоги до дизайна інтерфейсу нашого додатку.

Мобільний додаток «Щоденник дієти» має такі бізнес вимоги як (Рис. 4)

Додаток повинен забезпечувати можливість запису кожного прийому їжі і мати варіанти вибору;

Додаток повинен автоматизувати дату і час відповідно до системи;

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

Додаток повинен давати можливість записувати нотатки іншого характеру;

Рис. 4. Бізнес вимоги додатку «Щоденник дієти».

*Джерело: розроблено автором в Enterprise Architect.

Визначення та опис об'єктів системи

Актори системи:

Користувач;

Система;

Прецеденти системи:

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

Користувач може здійснювати резервне копіювання свої записів за один або декілька днів. Система дає можливість копіювати та відновлювати данні;

Рис. 5. Use case diagram додатку «Щоденник дієти».

*Джерело: розроблено автором в Enterprise Architect.

Програмний продукт «Щоденник дієти» призначений для створення списку харчування та ліків.

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

Створення ПП щоденник дієти повинен вирішити наступні проблеми:

Запис ваших щоденних вправ та ліків;

Створення нотатків на день/місяць/рік;

Запис водного балансу користувача;

Запис та огляд раціону харчування за день;

Функціональні вимоги додатку «Щоденник дієти» (Рис. 6):

У додатку повинна бути можливість додавати нову задачу;

Користувач за допомогою календаря, який буде міститися в додатку може перейти на будь-яку дату, щоб переглянути свої записи;

При додаванні нової задачі повинна бути можливість вибирати дату і час виконання;

Після запису задачу додаток повинен зберігати записані дані;

Програма повинна працювати без доступа до мережі інтернет;

Повинна бути можливість резервного копіювання;

Додаток повинен вміти копіювати задачі користувача.

Рис. 6. Функціональні вимоги «Щоденник дієти».

*Джерело: розроблено автором в Enterprise Architect.

Розглянемо ризики додатку «Щоденник дієти»

Помилка при створенні резервних копій записів подій;

У соціальну мережу не прийшло повідомлення при використанні функції «поділитися записом за день»;

При створенні нової події не зберігається даний запис;

При встановленні часу у новому записі, додаток не повідомляє користувачеві про подію;

Для того, щоб розпочати роботу в додатку необхідно завантажити додаток на телефон та відкрити його. Після цього додаток відкриває головне меню, де можна вибрати категорію події для створення. Для користувача можливо вибрати одну з трьох категорій події: «Їжа», «Напої», «Інше». Після вибору категорії додаток відкриває сторінку для створення нової події. Користувачу необхідно заповнити наступні поля: «Дата», «Час», «Назва», «Опис» і зберегти подію. Додаток повинен зберегти подію і вивести результат на головну сторінку.

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

Рис. 7. Діаграма діяльності додатку «Щоденник дієти».

*Джерело: розроблено автором в Enterprise Architect.

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

Рис. 8. Діаграма створення нової події «Щоденник дієти».

*Джерело: розроблено автором в Enterprise Architect.

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



Рис. 9. Діаграма компонентів створення резервної копії «Щоденник дієти».

*Джерело: розроблено автором в Enterprise Architect.

2.2 Вибір інструменту автоматизованого тестування мобільного додатку “Щоденник дієти”

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

Основні можливості інструменту для тестування:

створення тест-кейсів і упорядкування їх;

документування змін до кожної версії документа;

складання плану тестування, відображення параметрів тестування, створення звітів;

відстеження та опис помилок і дефектів.

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

До переваг використання комерційних продуктів можна віднести:

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

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

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

В якості використання комерційних інструментів можна відмітити такі недоліки:

Високу вартість;

Відсутність доступу до програмного коду;

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

До переваг використання безкоштовних інструментів слід ввести:

Розумну вартість;

Доступність до вихідного коду.

Легкість використання за рахунок хорошого знання інструменту;

В якості недоліків використання безкоштовних інструментів можна виділити:

Недостатню функціональність, часом неможливість реалізувати всі поставлені завдання;

Ризик відмови від підтримки з боку розробників проекту.

Найбільш відомими безкоштовними продуктами для автоматизації тестування користувальницького інтерфейсу мобільних додатків є на сьогодні такі інструменти, як: Calabash, Appium, Espresso, UIAutomator, Robotium. На рис. 10 можна побачити статистику, якими продуктами частіше користуються.

Рис. 10. Cтатистика використання різних інструментів для автоматизації

GUI-тестування додатків за 2020 рік.

*Джерело: побудовано автором на основі даних [18].

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

Переглянемо в таблиці 2 порівняльну характеристику цих інструментів, та проаналізуємо, який найкраще підійде для додатку «Щоденник дієти».



Таблиця 2. Порівняльна характеристика інструментів для автоматизації UI-тестування додатків

Інструмент	Платформа	Стратегія тестування	Мови	Компанія	Тип додатку
Espresso	Android	White-box	Java, Kotlin	Google	Native,hybrid
Appium	IOS, Android	Black-box	Java, JavaScript	JS Fpundation	Native, hybrid
Calabash	IOS	Black-box	JavaScript	Calabash	Hybrid
UIAutomator	Android	Black-box	Java, Kotlin	Google	Native
Robotium	IOS, Android	Black-box	Python, Javacript	Robotium	Hybrid

*Джерело: побудовано автором на основі даних [19].

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

...