Here's a straight forward process cycle you can follow that's worked for me.

The flow here starts with the idea and ends only when the client has signed off on the project. Everything in between is a loop of design & development shortly followed by testing & feedback from the client. The more you work in iterations this way, the better you'll get at working out good logical places to break each sprint. You can even plan them in advance.
You'll want to strike a balance between keeping the client updated and getting their feedback, but avoiding showing the client much broken / unfinished code.
Generally the faster you get feedback though, the easier the process will be later on.

Idea stage

• Before starting changes, engage with the client and review the brief of exactly what is needed. This is important to make sure you know what they are looking for. Sketches and simple mockups are very useful here to assure the client and yourself that you are both on the same page.
• Is the site fully responsive? Or does it have a mobile only view? Make sure consideration to this is given in any mockups and estimates for the work.

First iteration

Depending on the changes, the first iteration may be designing a mockup. Following the above image you would design the mockup and then contact the client for feedback. This could then go through several iterations before moving into development.

Following iterations

Each following iteration involves a sprint of work followed shortly by a review by the client. These are not formal reviews, more to keep the client informed that work is happening. It's also useful as clients often change their minds or can only work out what they truly want when they see it. This way you'll find out quickly if you're going the wrong way.

I wont intrude much into your design / development process here, I have another post that does this already, but make sure you're regularly involving the client for feedback.

Tips while developing

• Try not to copy content directly from legacy templates into responsive, but instead apply a fresh design over the responsive-site.
  E.g. if this is a responsive redesign it's tempting to copy say a product page template file from legacy, but this likely wont work. Instead use the existing design as a mockup, you can reuse imagery but coding new css and additional html structure will be less work than you'd think.
• Keep track of new features you've added, you'll want this for testing later, and for your support documentation.

Testing

• Browser test main site + special new features that the client may have requested!
• Google Analytics > Check browsers bringing in most visitors & enquiries or orders. Check out my other post on Modern web design.

Things to look out for especially while testing:

• Check your site's performance and mobile friendliness with Google's new tool.
• Do the changes affect ecommerce? E.g. a responsive redesign? or changes to products etc. You'll need to test the full cart process: finding a product on the site, add to cart, registration, checkout page, payment processor (no need to pay, but at least get it into paypal or wherever to check the order values) and thanks page, this will help you spot anything weird or broken. Best to do so with the browser console
• Any specific custom functionality already on the site? Such as a custom app. Make sure this is still working, or brought through into the new design.

Getting useful feedback

Try to make sure the client actually looks at the design of all changed pages. Sometimes they can just load the homepage up and that's all, later after release they then may complain that other things are not right. It's also easy for them to miss stuff too :).
Set expectations during early iterations about exactly what functionality is loaded up and therefore for review.
Get their feedback, make any changes, re-browser test the changes, etc. repeat! You can send them a link to a dev site if that's where you're working, or a preview link if working on the live site but in a different template folder.

Release

• Get written proof of client sign off on entire site before making it live.
• Finally you're ready to go live, but wait it's Friday, DONT! DON’T DO IT! NOPE NOPE NOPE.

Related articles

If you're interested in a more in-depth look at workflow and processes, I recommend Redesign the Web - The Smashing Book #3, chapter 10 is on workflow redesigned and really worth a read.

• Modern web design
• CSS structure & anti patterns

Browser support is browsers you're willing to support.

While browser testing is the act of testing and maintaining support.

Browser testing need not involve testing the full browser support list. In fact I find a graded view browser support makes this a bit clearer.
Testing every combination would take far too long and the client likely wont be paying for that extra time.

But why is this important?

When a client calls you up and says:

"There's a bug on OSX Firefox 23, why wasn't this picked up during browser testing?!"

You'll need to let them know the difference to explain clearly to the client why this was likely untested but assumed working (which is perfectly acceptable).

Eloquently put back to the client:

"It is not practical to test every combination of Browser, version and OS as there are so many. Instead we follow standard industry practice of testing the latest range of browsers, plus typically those which make up the majority of your traffic and sales. "

Depending on the browser support level, It's an a A or B grade browser, this would generally followed by:

"We'll take a look into this right away for you."

However in the case of a C grade browser, you would need to work out if this is a style tweak or core functionality.

"Unfortunately this is an older browser where fixing it can lead to complications. The cost of working on these older browsers is often not worth the return. If you'd still like us to work on it we can but we will need to quote for the time involved."

You could also then offer a service to the client of checking and testing the current highest converting traffic browsers. This could even be an ongoing / regular process you could offer.

Graded support

Inspired by Yahoo, we use A, B and C grades for our browser support, here's an example of this:

"A" grade support
These browsers should be actively tested on, along side browsers that bring in higher amounts of traffic and sales on the site:

• Google Chrome Desktop ~ latest
• Google Chrome Mobile (Android) ~ latest
• Firefox Desktop ~ latest
• EDGE Desktop ~ latest
• IE 11 Desktop
• IE Mobile 11 (Windows Phone)
• Safari Desktop (Mac OSX) ~ Latest
• Safari Mobile (IOS / iPhone / iPad) ~ Latest

"B" grade support
Though not actively tested on, these browsers should work fine, and bugs can be fixed when reported:

• Google Chrome ~ previous recent versions
• Firefox ~ previous recent versions
• IE 10
• Opera ~ any modern version
• Android browser version 4+
• Mobile versions of the above browsers in recent versions, such as on IOS, Android and Windows Phone

"C" grade support
Core functional support only. These browsers may not offer all the same effects and may visually look different, however any issues that cause functional issues will be fixed, such as an issue that hides or makes it impossible to click a call to action button.

• IE 8 & 9
• Older browser versions than mentioned.

Related posts

• Modern browser testing
• Reading list for modern web design
• CSS structure & anti patterns

And even some tools that offer excellent detection of media queries / breakpoints and then automatically create iframes of each so you can quickly view them, such as: http://breakpointtester.com/ and http://re-view.emmet.io/

The 1st set of tools are great, especially when demoing to clients to help them see different specific devices.
While the 2nd set of tools are also really useful when developing to see the different breakpoints built in and to quickly demo them side by side too.
The minor downside to these 2nd set of breakpoint tools however is they are either browser plugins or bookmarklets, which for some clients will not make a lot of sense.

Instead we need a tool like the 1st ones where you can link to it, but with breakpoint detection like the 2nd set of tools.

And so, here's a new tool you can use:
http://responsive.stapps.io/

Like the other tools, this only works on sites that don't block iframe access, e.g. google blocks it's site from being viewed in an iframe.

Also, unlike some of the other tools, it currently only works on sites with css breakpoints / media queries.

It has 2 display modes, the default one is a slider of each display size, you can use the arrows on the side or keyboard to navigate between them.
Then the other display mode is to show all the sizes next to each other, like the other breakpoint based tools, which is useful for quick comparisons.
You'll need to click "run" again to change the display modes.

It's pretty new so message me about any bugs, but enjoy :).

If you're an REC user, you can find a link to this under the preview url in Admin > Templates > Open/Edit Template