Unlike testing applications, where failure is an common sign of some flaws in the code, testing database facilities like stored procedures, user defined functions, views and queries is much harder, because most of the time the result of a code flaw will not be a complete failure but just a little inconsistency in the results. For example, when using an INNER JOIN instead of a LEFT OUTER JOIN to list people with their skills, it might go easily unnoticed that you are missing someone without any registered skill, especially if nearly all of them do have registered skills. Even harder to track down are the small errors introduced in the values of SUMs or COUNTs when someone overlooked the sometimes unexpected behavior of NULLable columnsin JOIN and WHERE clauses.

As a long time developer and DBA, in my humble opinion testing a piece of code should not be the responsibility of the one that implements the feature. No matter how hard you try, you will always have some 'blind spots' and miss some edge cases that someone else will come up with. However, in most smaller organizations the DBA has no colleague to test and review his work, making it even harder to maintain the required code quality standards. I do agree that every part of the application should be tested both separately and in conjunction with other parts. But that is not always feasible without the contribution of testers with other skills then an average developer has in his suitcase.