Általánosan akkor beszélünk szoftvertesztelésről, amikor ellenőrizzük a program működését és használhatóságát az alkalmazás kijelölt célja tükrében. A minőség mércéjét és a specifikációt a megrendelő dönti el, aki előre felállítja az elvárásait a programmal kapcsolatban, majd a megrendelés tolmácsolásra kerül a fejlesztők felé, akik közül a vezető fejlesztő, más néven architect, szabja meg a fejlesztés lépéseit és osztja ki a részfeladatokat.

Különbség statikus és strukturális tesztelés között

A fejlesztők által létrehozott programot adják át végül a tesztelő csapatnak, akik meghatározzák a tesztelés módját. A statikus tesztelés a hibákat a program futása előtt kutatja fel. Egyszerre végbemehet dokumentáció és kód szinten. Az utóbbinál a programkód vizsgálatán alapul, míg az előbbinél analízissel történik a hibák keresése.

A strukturális tesztelésnél hozzáférünk a program forráskódjához, aminek logikáját követve futtatjuk a tesztet, de mindezzel egyetemben vizsgáljuk a program belső struktúráját is. Ez a módszer kiválóan alkalmas a program moduljainak egyenként történő tesztelésére.

Könnyen felismerhetőek a programozói tévesztések, hiszen ismert a program konkretizál, végső megvalósítása. Hátránya, hogy erős informatikai ismeret szükséges hozzá.

A funkcionális tesztelés elhagyhatatlan lépés

A funkcionális tesztelésnél a program működésé hasonlítjuk az elvárásainkkal és a felhasználó személyét öltjük magunkra a teszt futtatásakor. A tesztelés menete viszont erősen függ attól, hogy milyen adatokkal vagyunk képesek dolgozni.

Csak azzal vagyunk tisztában ebben az esetben, hogy milyen adatok mennek be, mi az eredmény az elvárásokhoz képest, és hogyan specifikáljuk a programunkat.

A Végfelhasználói Teszt, vagy az UAT nagyon ragaszkodik a minőségi követelmények maximalizálásához

Az UAT célja, hogy minél korábbi fázisoknál, minél jobban csökkentse a hiba és a minőségi romlás kockázatát, ezzel egyöntetűen csökkentve a termék létrehozásának költségeit. A nagy szolgáltatók, mint a Doclernet is, kifejezetten nagy hangsúlyt fektet a belső teszteket követő végfelhasználói tesztek elemzésein és szükség szerinti utánhúzásain alapuló minőségbiztosításra, így  hibamentes  szolgáltatás kialakításra.

Ehhez a fázishoz szükséges, minden előzetes piaci specifikáció és felmérés előkészítése, továbbá a programnak is teszt kész állapotban kell lennie az üzleti tervvel egyetemben.

A hibajavítási besorolások minden tekintetben az üzleti értékük alapján kerülnek besorolásra. A dokumentáció nem csökkenti a hibák jövőbeni előfordulásának gyakoriságát, mindettől eltekintve irányelv a lehető legtöbbet orvosolni a program kiadását megelőzően.

Összességében tanulságként szűrhetjük le, hogy a hibakeresés és javítás elöljáróban, noha felülmúlhatatlan fontosságú, de nem váltja ki a helpdesk szerepét, fontosságát és munkáját.