Испробување на програмска опрема — доста значајна фаза во разработката на еден систем. Околу 40 – 50 проценти од буџетот планиран за развој на еден систем е планиран за испробувањето.Estimation of Software Testing Effort: An Intelligent Approach проверено на 01.04.2012 Испробувањето всушност претставува еден вид на истражување со цел да се обезбедат информации за квалитетот на производот и да се пронајдат грешките. Исто така со испробувањето на програмската опрема се обезбедува и објективни и независен пристап и на тој начин се овозможува клиентите да го ценат и разберат ризикот на имплементацијата на софтверот. Техниките за испробување вклучуваат процеси за испробување на програмата или апликацијата, во време на извршување, со цел да најдат програмски грешки или други дефекти.Exploratory Testing , Cem Kaner, Florida Institute of Technology, Quality Assurance Institute Worldwide Annual Software Testing Conference, Orlando, FL, November 2006
Исто така може да се каже дека испробувањето на софтвер претставува процес за валидација и верификација на програмата, апликација или производ за тоа дека: Ги исполнува барањата, наведени во документацијата Работи како што се очекува и Може да биде имплементиран со истите одлики. Испробувањето на програмската опрема, во зависност од методот со кој е избран за испробување, може да биде имплементиран во било која фаза од развојниот процес.Software Testing проверено на 01.04.2012
Различните модели за развој на програмската опремаразлично се фокусираат на тоа кога ќе биде направано испробувањето во развојниот период. Кај новите развојни модели, како што е приспособливиот модел, често се прават испробувања па дури и во процесот на кодирање, пред формално да дојде фазата на испробување. Сепак испробувањето обично се прави откако се дефинирани барањата и кодирањето е завршено.
Преглед Секој програмски производ има определена целна група на корисници. На пример, групата на корисници кои играат компјутерски игри се комплетно различни од оние корисници на банкарскиот софтвер. Па според тоа кога една организација развива или инвестира во некој програмски производ, таа може да процени дали производот би бил прифатлив за крајните корисници, која ќе биде неговата целна група на корисници, кои би биле неговите купувачи. Овде испробувањето на програмската опрема е оној кој ќе се обиде да ја изврши оваа проценка. Едно истражување од страна на NIST во 2002 година покажува дека програмските грешки ја чинеле Американската економија околу 59.5 билиони долари. Доколку било спроведено подобро испробување, оваа сума би била намалена за една третина.Software Errors Cost U.S. Economy $59.5 Billion Annually проверена на 01.04.2012
Историја Во 1979 година од страна на Глендфорд Маерс (англиски: Glenford J. Myers) било направена разграничување помеѓу дебагирање од испробување. Иако неговото внимание било насочено кон успешно испробување за кое морало да има грешка, односно ,, Успешен тест е секој тест кој ќе најде грешка‘‘, покажува дека желбата на програмската инженерска заедница била да се одвојат основните активности за развој, како што е дебагирањето од верификацијата. Дејв Гелперин и Вилијам Хатцел во 1988 година ја направиле следната класификација на фазите и целите кај испробувањето на програмската опрема:
До 1956 – Период ориентиран кон дебагирање (не постоела јасна разлика помеѓу дебагирањето и испробувањето. 1957 – 1978 Период на демонстрирање (покажување). Период во кој се разликувало дебагирањето од испробувањето и се покажувало дека програмската опрема ги задоволува барањата.From 1957–1978 there was the demonstration oriented period where debugging and testing was distinguished now - in this period it was shown, that software satisfies the requirements. 1979 – 1982 Познат како период на уништување, каде што целта била да се најдат грешки.The time between 1979–1982 is announced as the destruction oriented period, where the goal was to find errors. 1983 – 1987 Период ориентиран кон евалуацијата. Целта била да во текот на животниот циклус на програмската опрема да биде овозможена евалуација и мерење на квалитетот.1983–1987 is classified as the evaluation oriented period: intention here is that during the software lifecycle a product evaluation is provided and measuring quality. 1988 – 2000 Период на превенција, каде што испробувањето се прави за да се покаже дека програмската опрема ги задоволува барањата, ги открива грешките и ги намалува испадите.From 1988 on it was seen as prevention oriented period where tests were to demonstrate that software satisfies its specification, to detect faults and to prevent faults.
Теми на испробувањето на софтвер Опсег Основната намена на испробувањето е да се најдат програмските испади, па тие да бидат сместени и коригирани. Со испробувањето не може да се констатира дека производот ќе работи под сите услови, но може да се констатира дека нема да функционира правилно под одредени услови. Опсегот на испробувањето на програмската опрема често вклучува преглед на кодот како и извршување на самиот код во различни средини и услови, како и преглед на аспектите на кодот: дали го работи како што е предвидено да работи? Нивото кое што денеска го има развојот на софтвер дозволува, тимот којшто е задолжен за испробување да биде одвоен од тимот задолжен за развој. Секој член од тимот за испробување има своја посебна задача и улога. Информациите добиени од испробувањето се користат да се коригира процесот кој се користи да се развија софтверот.
Функционално наспроти нефункционално испробување
Функционалното испробување се однесува на оние активности кои ги потврдуваат одредени акции или функционалноста на кодот согласно барањата. Тестовите за функционалноста се обидуваат да одговорат на следните прашања ,,дали може корисникот да го направи ова?‘‘ и ,,дали ова функција навистина работи?‘‘
За разлика од функциналното испробување, нефункционалното испробување се однесува на тоа дали системот ги исполнува нефункционалните барања. Тоа ги покрива следните испробувања:Non-functional testing проверена на 01.04.2012
Испробување на стандардите (англиски: Baseline testing) Испробување на компатибилноста Испробување на издржливоста Испробување на сигурноста Испробување при вчитување Испробување на размерливоста Испробување на употребливоста Испробување на зафатнината
Недостатоци и испади
Некои од недостатоците не мора да се предизвикани како резултат на грешките во кодирањето. Најголем број на грешки доаѓаат од ,,празнините‘‘ во барањата, на пример неразбирливите барања , коишто доведуваат до погрешно дизајнирање на програмата од стана на дизајнерот. Најголем број такви празнини во барањата се во нефункционалните барања како што се барањата за проверливост, размерливост, одржливост, употребливост, барањата за перформансите и сигурноста.
Програмските недостатоци се појавуваат како резултат на грешките од програмерот што ги прави програмерот при пишување на изворниот код. Доколку тој изворен код се изврши, во одредени ситуации ќе продуцира грешен резултат и предизвикува испад.Section 1.1.2, Certified Tester Foundation Level Syllabus , International Software Testing Qualifications Board Не мора да значи дека сите недостатоци би резултирале со испади. На пример, некој недостаток на мртов код (код што никогаш нема да се изврши) никогаш не би довел до испад. Недостатокот може да се претвори во испад кога ќе настане промена на околината. Примери за промена на околината се промена на хардверската платформа, промена на податоци или интеракција со друг софтвер. Еден недостаток може резултира со широк спектар испади.
Брзо откривање на недостатоците Факт е дека колку побрзо се откријат недостатоците, толку помали ќе бидат трошоците тие да се поправат. Следната табела ги прикажува трошоците на поправање во зависност од фазата во која тие недостатоци ќе бидат откриени. На пример, ако се најде проблем во барањата откако производот е завршен, тоа неговото поправање би чинело 10 – 100 пати повеќе отколку тој проблем да се откриел кај прегледот на барањата. Модерните методи би можеле да коштаат помалку за прераспределба и одржување него во минатото.
Цена за поправка Време на откривањеБарањаАрхитектураКонструкцијаИспробување на системотЗавршување на производот Време на појавување Барања 1× 3× 5–10× 10× 10–100×Архитектура - 1× 10× 15× 25–100×Конструкција - - 1× 10× 10–25×
Испробување на компатибилноста
Честа причина за програмски недостаток претставува немањето на компатибилност со другите програмски апликации, оперативни системи (или различни верзии на оперативниот систем, стари или нови) или пак околината. На пример, немањето на компатибилност може да настане поради тоа што програмерите го развивале програмската опрема на најновите околини, а истовремено и таму го испробувале. Па поради ова може да се случи кај некои корисници програмската опрема да не функционира како што треба. Од ова се може да заклучиме дека најновите производи, може да не функционираат на претходни верзии на околината или на стар хардвер, на кој работеле претходните верзии. Понекогаш таквите проблеми може да се решат со превентивна апстракција на функционалноста на оперативниот систем во одвоени програми модули или библиотеки.
Влезни комбинации и предуслови Основен проблем кај програмското испробување е тоа што испробувањето со сите можни комбинации како влезни параметри и предуслови не е возможно, па дури ни кај едноставните производи.pp 17–18Principle 2, Section 1.3, Certified Tester Foundation Level Syllabus , International Software Testing Qualifications Board Ова значи дека е голем бројот на недостатоци кај програмскиот производ и тие недостатоци е потешко да се најдат доколку програмата ретко влегува во состојби каде што има недостатоци. Уште позначајно е дека нефункционалните димензии како употребливост, размерливост, перформансите, компатибилноста, доверливоста може да бидат многу субјективни, односно нешто што содржи задоволителна вредност за една личност може за друга личност да не биде.
Статичко наспроти динамичко испробување Постојат повеќе приоди кон испробувањето на програмската опрема. Прегледот, текот на развивање на програмата (англиски: walkthrough) или испитувањата се сметаат како дел од статичкото испробување, додека пак извршувањето на програмата со дадено множество на тест случаи е динамичко испробување. Статичкото испробување може да биде (а за жал во пракса уште почесто) прескокнато. Додека пак динамичкото испробување се прави веднаш откако програмата ќе биде користена за првпат (генерално се смета за почетна фаза на испробувањето). Исто така динамичкото испробување може да почне и пред програмата комплетно да биде завршена, со цел да се испробаат одредени делови од кодот(модули или функции). За оваа цел се користат таканаречени стабови (англиски: stub), драјвери или околина за дебагирање. На пример, програмите за табеларни пресметки се испробуваат на поголема проширена интерактивност, и како резултат на тоа веднаш се прикажуваат резултатите при некоја промена на бројки или текст.
Верификација и валидација на програмската опрема Испробувањето на програмската опрема се користи за негова верификација и валидација.
Верификација: Дали програмската опрема правилно сме го развивале? (дали е во согласност со спецификацијата) Валидација : Дали сме го развиле вистинскиот софтвер? (дали е тоа што клиентот го бара)
Термините за верификација и валидација обично се мешаат во индустријата, исто така тие и неправилно се дефинираат. Нивните дефиниции според IEEE речникот за терминологии од програмското инженерство се:
Верификација – процес на проценка на системот или компонентите за да се одреди дали производот во одредена фаза на развивање ги исполнува условите дадени на почетокот на секоја фаза.
Валидација – процес на проценка на системот или компонентите, во текот или на крајот од фазата за развивање, со цел да се одреди дали ги задоволува наведените барања.
Според ISO 9000 стандардот: