When creating an entirely new QA organization, where do you start? Although establishing QA processes and standard practices is important, you must communicate with and obtain buy-in from QA staff, developers, customers, and business analysts. Walk in Karl Shearer’s footsteps as he describes the initial stages of QA's formation at Erie Insurance, the challenges and roadblocks he faced, and, ultimately, the successes he has enjoyed. From organizational issues, the mission statement, and job descriptions to selecting and hiring QA staff, you’ll take away a checklist for starting up a test group or improving your test organization. Employing a risk-based approach to define the levels of testing and a multi-pass system test strategy, Karl established basic test processes. Then, he added defect tracking, automation, and requirements management to the mix and designed templates for all QA deliverables.

Has it ever happened to you? Due to an immovable delivery schedule, time for testing is squeezed and long hours are the norm at the end of a project. Well, let’s move the testing forward in the development process. In fact, teams are learning that, rather than relegating tests to near the end of a project, there are huge benefits to adopting a test-driven process-a more maintainable and robust design, testable code, fewer defects, and a cross-functional highperformance team. By combining unit test-driven and acceptance test-driven processes in a more agile setting, you can deliver on shorter schedules without sacrificing quality. Mike Cohn shares his experiences with test-driven development, including the flexibility it offers for dealing with schedule pressure, the role of documentation, and the steps for getting started. He also describes a test “pyramid” and how to separate test specifications from test writing.

For decades quality assurance (QA) has been a back-end loaded process. Developers put the bugs in, and QA tests the bugs out. For nearly as long, testers have bemoaned the fact that quality can't be put in at the end, that quality must be built in from the beginning. Support for this view has grown from the grassroots within the development community and is now spreading like wildfire in the software industry. The practice of building (and testing) quality in throughout the development process has come from an unexpected source: Agile methods. Agile methods demand a strong reliance on both automated component testing and acceptance testing. Agile practices recommend that those tests be developed before the code is written and that the tests act as the true requirements for the software.

"QA is the bottleneck” ... "Why does QA take so long?" ... "You need to test faster." Often, key project stakeholders either do not understand QA or have difficulty quantifying the effects that increasing or decreasing test time will have on the project. First American CREDCO found the solution was to turn QA into a full service organization, complete with a "Quality Rainbow" menu of options to be purchased. Want it quicker and willing to accept a higher risk? Then select from Column 1. Want low risk and willing to take the time to ensure the product is pristine? Then select from Column 5. Whether your test team is small or large, you can learn to "in-source" QA services, set time and efforts expectations up front, and measure the value of QA activities so that QA does not become a roadblock to project success.

• A method to specify and quantify the services provided by a QA group