What happened to Unit Testing ?

As teams move towards more Agile approaches to development, there is an almost total reliance on automated unit testing as this is widely supported by accepted tools such as JUnit, NUnit and even DBUnit alongside other products for Continuous Integration (CI).  Whilst thoroughly written automated unit tests can be fine for server-side code, I am noticing that more and more time is being needed in Independent Testing/System Testing where there is a significant element of User Interface (UI) development, as too many defects are being discovered.

There are so many events and complications when building a UI that the lack of hands-on, post-build developer testing causes far too many defects and too much rework.  In an Agile environment, this causes a high volume of Change Stories; in a traditional environment, this causes an extended System Testing period.  In both cases this causes delays in delivering value to the business.

The closer to the coal face that issues are found, the quicker and cheaper it is to resolve them, so it is imperative that this gap in Unit Testing is resolved.

I should point out that not all Agile testing falls foul of this, however, the problem appears to be more prevalent in teams caught in a halfway house between Agile and more traditional software development lifecycles (SDLC).  This is probably a result of trying to work to Agile delivery cycles without the close, end-user involvement and other supporting practices.

Failure to adhere to any one methodology appears more prevalent where the development is performed by globally dispersed teams, however, I have also seen this problem arise due to development teams trying to respond to business demands of faster turnaround times, particularly where multiple development streams are used to try to meet demanding deadlines.

These pressures are leading teams to move towards Agile practices even when the overarching project setup within their organisation is more traditionalist and this is causing more problems than it solves.  Although there are benefits to be had from adopting some Agile practices, there is a real danger of becoming stuck in the middle. 

I have worked successfully in both environments, so I would argue that it doesn't matter which SDLC you follow; however, once you've picked one make sure you stick with it.  It is possible to mix-n-match across SDLCs, but this must be done with great care and requires indepth understanding of the likely issues.  It is rare that a single practice can be surgically implanted into a foreign SDLC.