Amikor tesztelésről beszélünk, szinte mindenkinek valamilyen típusú ellenőrzés, vagy hibakeresés jut eszébe. A hagyományos tesztelési eljárásokra ez a feltételezés teljes mértékig igaz. Ha már automatizált tesztelésről beszélünk, akkor az egy kicsit másképp alakul.
Az automatizált teszteknek már nem az a kimondott feladata, hogy keressen és találjon is hibát. Kétségtelen, hogy több minőségbiztosítási megközelítése van az automatizmusok alkalmazásának.
Az egyik, bár kicsi alkalmazási terület a regressziós tesztek automatizálása. Ezt akkor alkalmazzák, amikor a tesztelési fázisban találnak egy hibát. Ennek a hibának a helyes működési esetére írnak egy tesztet. Ezt a tesztet futtatják a hiba kijavítása után, hogy megjavult-e az adott funkció, illetve a fejlesztés további fázisaiban, hogy nem fordul-e elő újra az adott hiba. A tesztelés ezen válfaja áll a legközelebb a klasszikus hibakereséshez.
Sokkal fontosabb és előre mutatóbb alkalmazási területek a Driven Developement típusú tesztelési eljárások, amikor az automatizált tesztek vezérfonalként szolgálnak a fejlesztés során. Közös jellemzőjük, hogy a tesztek még a termék kivitelezése előtt íródnak, és egy-egy fejlesztési fázis végén futnak, így alkalmazva a teszteket a kivitelezés ellenőrzésére. Ha ezek a tesztek hiba nélkül végrehajtódnak, akkor az adott fejlesztési fázis a végéhez érkezett, és a termék a klasszikus tesztelési fázisba kerül. Ekkor már többnyire csak vizuális ellenőrzés a feladat, de ezzel együtt zajlik a klasszikus funkcionális hibakeresés is. A legelterjedtebb ilyen módszer a Test Driven Development (TDD, UNIT). Itt a fejlesztő a fejlesztendő metódus saját nyelvén ír ellenőrző eljárásokat, mintegy definiálva, hogy az általa írt funkció milyen követelményeknek fog megfelelni, ha elkészül. Amíg a futtatott tesztek hibába ütköznek, addig az adott metódus nem tekinthető késznek. Ezt a fejlesztő addig javítja, amíg a teszt le nem fut hiba nélkül.
Alapelvét tekintve hasonlóan működik az Acceptance Test Driven Development (ATDD) is, de számos különbség lelhető fel. Az egyik, hogy ezek a tesztek már nem a metódusok szintjén vizsgálódnak, hanem a szoftver felhasználók és üzemeltetők által elérhető felületén. Itt is előfordul, hogy saját nyelven íródnak a tesztek (Java), de sokkal elterjedtebb, hogy keretrendszerekben valósítják meg (Appium, Robot Framework). Míg a TDD csak a fejlesztő szemszögéből tervez, az ATDD már bevonja a megrendelőt és a tesztelőt is, és közösen definiálják a termék elfogadási kritériumait. Később ezekre íródnak az elfogadási tesztek.
Az ATDD-hez hasonló módszer a Behaviour Driven Development (BDD). Ez az eljárás többek között abban különbözik az előzőtől, hogy míg az előző a végfelhasználó szemszögéből tervez, ez utóbbi inkább a fejlesztők nézőpontját veszi alapul.
A fenti két eljárás közös tulajdonsága, hogy természetes nyelvi elemekkel, mondatként is írhatók a tesztek, így például a megrendelő is pontosan érti, hogy adott tesztnek mi a szerepe, valamint olyan szereplők is részt vehetnek a tesztesetek írásában, akik nem rendelkeznek fejlesztői előképzettséggel. A fenti módszerek mindegyike más-más szoftverfejlesztési rétegben alkalmazható, épp ezért több rétegű minőségellenőrzés érhető el ez által.
Látható, hogy tesztelés vezette fejlesztések egy precízebb minőségbiztosítást tesznek lehetővé. Ezekre a tesztelési módszerekre már inkább tervezési metódusként kell tekinteni, mintsem hagyományos ellenőrzésként. Alkalmazásuk előnye a sokoldalú felhasználhatóságuk. Ugyanúgy alkalmazhatók visszamenőleges ellenőrzésre, mint a kivitelezés teljesítésének igazolására. Vannak olyan Driven Developement típusú eljárások, melyek a szoftver specifikációját is tesztekkel váltják ki, ilyen az Acceptance Test Driven Development vagy klasszikusan a Specification by Example módszer.