TDD means writing tests before writing actual code, which presupposes writing very granular unit tests. In practice though, what you want is sufficient coverage of your business logic. If you are well versed in TDD, your code architecture will be sufficiently decoupled even if you don't do TDD per se, so you should be able to test whatever is important for your application. However, note that testing each layer indep…
Is it wrong to start testing from the "Manual QA" point of view (But in reality automated.)?
If you want something maintainable in the long run (5-10 years), it's probably not the best idea to start with that approach. But then again, you probably have no idea what direction you should be heading for the next 5-10 years, so it's not a big deal.
I know it's a bit conflicting advice, but that's the point. When you know exactly what you are building (which is seldom the case with web apps), you want to do it right from the get go. When you don't really know, it does not matter since a few years down the line, if successful as a product, you'll be refactoring heavily and probably doing it the right way at that point (iow, full tests come last).