This last month has seemed to be themed “Whaaaatt, that made it through QA?!?!?!?!” And by QA I mean Quality Assurance. Currently at work, I’m writing up a bunch of verbal QA scripts, later to be ran through either by a QA tester and/or handled automatically through some scripts.
As much as it hasn’t been fun to go through this process, it has taught me the importance of making sure all your “T’s” are crossed and “i’s” are dotted. I’ve heard from multiple developers at various firms that say “Develop in Firefox, and when the site is completed, debug your IE(6)”. The problem is, as true as that is for CSS and formatting your site, it’s becoming increasingly difficult (and will continue to be as the web develops and IE6 stays the same) to hold that philosophy when it comes to functionality (and I believe a lot of the developers that made that statement would or will start to agree in the next few years, if not already).
What we’re finding as an overall trend is that a lot of data is being pulled through the web through client side scripting, as opposed to server side. While libraries like jquery and mootools have done a tremendous job at making IE6 (Internet Explorer 6) work, I still find a lot of quirky things I have to work around in development. And although, most of it still comes back to CSS preferences, I still waste a tremendous amount of time at the end of the project going through and trying to figure out why IE6 doesn’t like a particular div, span or more recently <body> tag (dealing w/ graybox – which could be it’s own post in bashing how they decided to structure their iframes), than I would had I just debugged IE along the way.
The other benifit would be as a particular site enters into our clients QA process and the client is chomping at the bit to get their hands on the site, we’ve had and have taken time to make sure IE (and really, all the major browsers) have going through multipule QA tests, over a period of time. The payoff is that if you’ve only been given 10 days for developement, by doing QA along the way, you also have 10 days of QA. Now we can’t really fit 20 days of work into 10 days (although at Blend we seem to do this on a regular basis), but knowing when and how a particular issue arrose is extremely valuable when it comes to debugging, esp when it comes to IE (which doesn’t have firebug (it does have a development tool bar, but I find many times it is less helpful than just adding a 1px solid red border to the <div>’s of a particular section I’m working on.
All in all, QA is and has been knocking on my door, and I cannot strees how important it is for those developers out there to go through some sort of QA process. It’s ok to do your QA at the end (and I still recommend for some projects, esp larger, longer deadline ones), but if you’re in the type of business where your deadline typically doesn’t allow for the nessesary QA time, doing QA all throughout the development life cycle may prove benifical to you.
Thanks for the useful info. It’s so interesting