Brace yourselves; we’re about to dive into an exciting lesson on software quality assurance history.
Quality Assurance, paying precise attention to an expected output, has its roots in Guilds and their manufacturing processes during the Middle Ages. However, it was only seventy years ago that safety concerns over high-volume production of the United States’ military equipment began to appear and forced the service to enact MIL-STD-105. As you can see in this Reference Table the military helped alleviate safety concerns from their soldiers and the public by instituting controlled sampling of wartime products and ensuring they met, or surpassed, an agreed upon standard. QA is still a vital part of the manufacturing process and is performed in other fields that produce a variety of products - tangible or not.
Software QA was born from manufacturing and editing’s groundwork but the new-age intricacies of this practice include tasks never imagined by yesterday’s red-penners. Browser compatibility, link testing, form testing, and destructive testing are just some of the current QA practices employed in web development - and it’s constantly evolving. Without these critical twenty-first century checks and balances a project can run over budget and have a negative impact on both Client and Company.
Previous to immediate publication through blogs and online forums becoming the new norm writers employed proofreaders to take a first look at their words one step before mass production - the authors needing constructive criticism on their grammar and syntax - not to mention flow, digestibility, and a bit of fact checking. A proofreader’s first look at a piece of literature took place after the author determined their work to be complete (short of editing). With a mass of text across many pages the piece was combed through by a word wizard who marked and annotated the pages. Oftentimes proofreading involved heavy back-and-forth between the author and proofer(s) - most projects going through multiple rounds of edits to ensure the final form lacked any errors. However, unlike literary proofing, web development needs a more dynamic and involved QA process to avoid costly issues rearing their ugly head later on in the project’s life cycle.
Unlike an author’s text on a certain page - Developer’s code and the changes made to it will often have a ripple effect (positive or negative) on other parts of the project. A quick edit on Line 53 could allow for a continuous carouseling image display but it could also render a break to that same carousel when rendered through a backdated browser. Because of the dynamic changes that result from even the smallest code adjustment, unlike the isolated edit of an error on Page 110 that occurs in a vacuum, it is imperative that QA is along for the ride with the Development team during each phase of production.
While final product proofing has worked well for manufacturers and publishers for years - proofing of websites does not need to, and shouldn’t, follow this static standard. With multiple Developers working on a project simultaneously QA has the ability to proof pieces of the site long before the final product is ready to be delivered. Blocks of a website can be sifted through for errors while the Design and Development teams continue to lay down their first lines of code elsewhere on the project. By encouraging a fluid relationship between Designers, Developers, and QA the teams can produce a more refined product throughout each stage of the project - ultimately leading to the delivery of a better final product.
Effective software QA begins in a meeting with the Client during the Discovery Phase, before production starts, to ensure the Development team’s final product agrees with, and in critical areas exceeds, Client expectations. After work begins the site’s flow and function is checked often during the Development Phase with QA ensuring that the product is in congruence with the Compositions and Wires agreed upon by the Client and Company. This initial phase is referred to as Breadth Testing, meaning that specific features of the project are not tested in detail. Breadth Testing occurs during the Development Phase because the product is too young to benefit from in-depth testing but its developing skeletal structure benefits from examination and relentless checking of the product against agreed upon expectations.
As a project moves out of the Development Phase and into the Revision Phase(s) QA begins checking under rocks (links), off-the-beaten-path (Destructive Testing), and in the shadows (back-end) to make sure various features are properly integrated into the expected function of the site. With major development in the rearview mirror QA moves into Depth Testing - exercising features of the project in full detail. Any errors noted by QA are entered into issue tracking software that is reviewed by Project Managers and the Development team. Inside this software the team discusses issues, and potential issues, within the project while creating and implementing effective solutions. Cost-effective solutions are easier to develop when issues are discovered early - QA from the get-go is of critical importance to the bottom-line. Issues are tracked by the team according to their severity and their date of discovery to assure the Client that all identified hiccups are given the time and attention necessary to correct or remove them long before delivery of the final product.
Software QA is constantly evolving with the ever-changing web and new practices will debut over the next few years that will supplant many of the current testing procedures. It is of high importance that the QA process is fluid enough to change with the landscape of the web in order to keep a high ROI for Clients. Red pens are a thing of the past - is your Company ahead of the curve? Contact Unleashed Technologies to learn how we can get you there.
Return to the Unleashed Technologies Home Page