A szerver oldal nem csak html kiemenet előállítását jelenti (főleg, ha webalkalmazásokról beszélünk). Egy-egy funkció megvalósítása, művelet elvégzése nincs feltétlenül hatással a megjelenítésre. (pl.: számítások pontosak-e, figyelembe veszik a szükséges kritériumokat, vagy például létre jönnek azok az objektumok futás időben,amiket várunk vagy sem)

A hibák tényleg előjönnek használat közben (pl.: nincs egy adott objektum -> nem jelenik meg a kimeneten), de nem biztos, hogy észre vesszük őket (pl.: több, komplex feltétel alapján számított kedvezméynes ár).

Na, a lényeg, hogy ha az ember rászánja az időt a tesztelésre, nagyon sok szívástól kímélheti meg magát.

Ha szorosan a kimenetre koncentrálok, akkor a szerver oldal html kódot állít elő, szóval ha hibás ott a html részben jelenik meg.

Kisebb projectek esetében a magam részéről ráeresztem a feleségem (aki abszolút nem ért hozzá), ő szűri ki a user experience hibákat. Érdekes tapasztalat szokott lenni. Aztán meg megpróbálok betörni magamhoz pár alapvető biztonsági teszttel (js beoltás, meg ilyenek). A hibák többnyire úgyis kiugrálnak használat közben.

Nagyobb project esetében jobb ha egy (sok) külön ember tesztel.

Mi a cégnél mostanában RSpec-et használunk. BDD szerint megírjuk a teszteket (minden model-re,controller-re,stb) és csak akkor mehet ki az aktuális változat élesbe, ha minden teszt hibátlanul átmegy.
http://rspec.rubyforge.org/

Te mit használsz az alkalmazás működésének tesztelésére?

Mivel a generált html-ek sorai a legritkább esetben vannak helyesen behúzva, így nehéz megtalálni, ha valamelyik elem rossz helyen van lezárva. Az áttekintést nagyban növelheti ez a html kódszépítő:
http://tools.arantius.com/tabifier

Néha a request és response headerekben lehet az ok, amiért az oldal nem úgy néz ki, ahogy (főleg kódolásoknál). Ilyenkor jön jól a fiddler:
http://www.fiddlertool.com/fiddler/
vagy csak ff alá a liveHttpHeaders

hajrá!