It depends on budget, priorities and the type of application you're trying to build. I often work with ad agencies on reasonably simple cms and e-commerce sites. For those, we just agree high level features, they work with the client on an approved look and feel and then we turn the provided psd files into HTML/CSS and drop them into the system.
For the 20% of the projects we do that are more functionally interesting, we'll often do a short fixed-effort discovery phase to clarify business intent, audiences and the key tasks each role needs to be able to perform (user stories). We'll also do spikes around any large areas of tech risk like new third party API integrations and will then provide an estimate and a suggested dev plan (usually scrum with 2 week iteration for greenfields, sometimes kanban). We don't schedule all the sprints - just the first sprint or enough stories to fill our kanban WIP limits.
In parallel with the dev, the designers will work with the client on look and feel, but I often like to get most of the way there functionally before getting locked into designs that may not be consistent with the UI requirements from a usability perspective. I also try for much more simple and flexible markup on such projects so if we have to iterate over the designs, we can do so fairly inexpensively.
In terms of testing, we discuss business objectives and how they could be tracked before we start the project so the client can measure some kind of ROI. We use cucumber for acceptance testing (as part of agreeing story specs so usually as part of sprint planning) and either rspec (for ruby) or a similar BDD influenced framework (e.g. spock for Groovy) for unit tests.
Most coding is 1 up, although we pair on anything interesting and I pair whenever I meet someone at a conference I'd like to learn from. We use git for source control and projects with more than 2 devs we always use Hudson for Continuous integration.