Функціональне випробування. Функціональне тестування програмного забезпечення Система функціонального тестування

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

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

Етапи функціонального тестування:

1. Аналіз вихідних даних (технічних вимог) та узгодження плану тестування, тест-кейсів, термінів виконання проекту, кількості ітерацій;
2. Проведення функціонального тестування за тестовими сценаріями із занесенням виявлених багів у систему багтрекінгу;
3. Складання звіту про проведене тестування та надання рекомендацій щодо покращення системи.

Використовувані інструменти:

Для функціонального тестування ми використовуємо інструменти TeamCity, Selenium, Web Driver, Firebug, XPather, IE Developer Toolbar, JUnit, JMeter, VMWare, TestLink та ін., а також багтрекінгові системи Bugzilla, Mantis, Jira, XBtrack.

Ми проводимо функціональне тестування за такими напрямками:

1. Регресійне тестування

Ми тестуємо продукт на його працездатність після внесення змін до функціональності.

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

Ми також тестуємо на коректність окремі компоненти (модулі) програми.

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

Ми перевіряємо на коректність взаємодії між компонентами однієї системи та правильності обробки інформації.

4. Димове тестування

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

5. Тестування безпеки

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

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

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

7. Тестування документації

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

8. Тестування мобільних додатків

Ми перевіряємо коректність роботи мобільних додатківна різних мобільних пристрояхта платформах.

9. Тестування процесу інсталяції

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

10. Стрес-тестування

Ми також проводимо тестування на відмову системи та її здатність до відновлення у разі виникнення збоїв.

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

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

12. Забезпечення тестового покриття

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

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

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

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

І цей засіб називається ТЕСТУВАННЯ програмного продукту.

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

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

Коли та хто?

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

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

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

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

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

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

Для проведення функціонального тестування персоналом відділу технічного контролю розробляється документ програма та методика випробувань функціоналу додатку (ПМІ). Документ ПМІ містить перелік сценаріїв тестування програмного продукту (test cases) з докладним описомкроків. Кожен крок сценарію тестування характеризується діями користувача (фахівця з тестування) і очікуваними результатами – реакції реакції програми на ці дії. Програма і методика випробувань має імітувати експлуатацію програмного продукту реальному режимі. Це означає, що сценарій тестування має бути побудований на основі аналізу операцій, які виконуватимуть майбутні користувачі системи, а не бути штучно складеною послідовністю зрозумілих тільки розробнику маніпуляцій.

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

• Компонентне (модульне) тестування. Тестування окремих компонентів програмного продукту, сфокусоване на їхній специфіці, призначенні та функціональних особливостях.
• Інтеграційне тестування. Даний вид тестування проводиться після компонентного тестування та спрямований на виявлення дефектів взаємодії різних підсистем на рівні потоків управління та обміну даними.

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

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

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

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

Тестування вбудованого ПЗ та дотримання стандартів в еру Agile

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

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

Тестування продуктивності

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

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

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

Документація для тестування

Як уже було зазначено вище, тестування проводиться відповідно до програми та методики випробувань, яка розробляється відповідно до ГОСТ 34.603-92.

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

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

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

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

Дослідницьке тестування

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

Тестування навантаження

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

1. Генерація тестових сценаріїв

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

2. Розробка тестової конфігурації

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

3. Проведення тестового випробування

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

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

Основна особливість автоматизованого тестування – можливість швидкого проведення регресійних тестів. Головними плюсами автоматизації (за даними звіту компанії Worksoft) є збільшення ефективності персоналу, більш раннє виявлення дефектів і більше висока якістьбізнес-процесів. Ці переваги компенсуються суттєвим недоліком: дорожнеча, через високу ціну на впровадження та підтримку автоматизації тестування, близько 50% компаній досі застосовують в основному ручне тестування.

Тестування юзабіліті

Будь-яка програма створюється для того, щоб ним скористалися. Зручність використання – важливий якісний показник програми. IT-індустрія знає безліч прикладів, коли проекти злітали після вдалого виправлення зручності використання. Чим ширша аудиторія, тим важливіший чинник юзабіліті. Тестування юзабіліті включає детальний аналіз поведінки користувачів. Для оцінки ергономіки важливо мати дані не тільки про швидкість виконання бізнес-завдання, а й про емоції користувача, міміку обличчя, тембру голосу.

Конфігураційне тестування

Конфігураційне тестування дає впевненість, що програма запрацює на різних платформах, а значить у максимальної кількості користувачів. Для веб-додатків зазвичай вибирають тестування на крос-браузерність. Для Windows додатків - тестування на різних операційні системита бітностях (x86, x64). p align="justify"> Важливою складовою конфігураційного тестування є тестова інфраструктура: для проведення випробувань потрібно постійно підтримувати парк тестових машин. Їх кількість варіюється від 5 до кількох десятків.

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

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

Стрес тестування

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

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

Розглянемо процес тестування, виходячи з рекомендацій стандарту ISO/IEC 12207, і наведемо типи помилок, які виявляються кожному процесі ЖЦ.

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

Характерними помилками цього процесу є:

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

Процес проектування.Помилки при проектуванні компонентів можуть виникати при описі алгоритмів, логіки управління, структур даних, інтерфейсів, логіки моделювання потоків даних, форматів введення-виведення та ін В основі цих помилок лежать дефекти специфікацій аналітиків та недоробки проектувальників. До них відносяться помилки, пов'язані:

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

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

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

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

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

Усі помилки, що виникають у програмах, прийнято поділяти на такі класи [7.12]:

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

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

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

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

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

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

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

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

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

Зв'язок помилки з відмовою.Наявність помилки в програмі, як правило, призводить до відмови ПЗ при його функціонуванні. Для аналізу причинно-наслідкових зв'язків "помилка відмова" виконуються такі дії:

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

Кінцева мета причинно-наслідкових зв'язків "помилка відмова" полягає у визначенні методів та засобів тестування та виявлення помилок певних класів, а також критеріїв завершення тестування на безлічі наборів даних; у визначенні шляхів удосконалення організації процесу розробки, тестування та супроводу ПЗ.

Наведемо таку класифікацію типів відмов:

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

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

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

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

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

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

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

• тестування black box (чорна скринька) – проведення функціонального тестування без доступу до коду системи,
• тестування white box (біла скринька) – функціональне тестування з доступом до коду системи.

Тестування black box проводиться без знання внутрішніх механізмів роботи системи та спирається на зовнішні прояви її роботи. При цьому тестуванні перевіряється поведінка ПЗ при різних вхідних даних та внутрішньому стані систем. У разі тестування white box створюються тест-кейси, що базуються переважно на коді системи ПЗ. Також існує розширений тип black-box тестування, що включає вивчення коду, - так званий grey box (сірий ящик).

Ключові переваги

1. Функціональне тестування ПЗ повністю імітує фактичне використання системи.
2. Дозволяє своєчасно виявити системні помилкиПЗ і ​​тим самим уникнути безлічі проблем при роботі з ним надалі.
3. Економія з допомогою виправлення помилок більш ранньому етапі життєвого циклу ПЗ.

Основні етапи функціонального тестування

Підготовка

Проведення

Підготовка

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

Проведення

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

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

Інструменти

Управління тестуванням ведеться у спеціалізованих системах.

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

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

Таке тестування проводитиметься функціональними тестами,які проектуються та створюються за допомогою тест-дизайну. Інакше їх називають тест-кейси (тестові випадки). Про тест-кейси поговоримо докладніше.

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

Функціональне тестування зазвичай можна проводити всіх рівнях тестування ().

Також функціональне тестування досить часто потрапляє під поділ понять (за ознаками позитивності сценаріїв):

• Позитивне функціональне тестування
• Негативне Функціональне тестування

Переваги функціонального тестування

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

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

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

Недоліки функціонального тестування

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

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