Service-Oriented Architecture (SOA), incorporating methods for Web services to communicate dynamically, promises to significantly improve organizational operating efficiency, change the way companies conduct business, and even alter the competitive landscape. However, Service-Oriented Architecture is a strategy rather than an objective, and, like any strategy, it is of no value unless it is implemented. With illustrations from companies who today are using SOA to transform their organizations, Sharon Fay shares current practices for exposing Web services and XML to internal development teams, outsourced development, external trading partners, and customers. Learn why reuse is a key method for supporting integration of SOA implementations and how it is being accomplished. Take away a set of metrics that you can use to measure the level of SOA adoption, development productivity gains, and organizational agility.

Requirements are supposed to be the basis of most test cases, but can you use test cases to define what the system needs to do--to improve or to actually become the requirements? To some degree, your development process dictates the opportunities you have for test cases to define or refine requirements. However, everyone can benefit from test case writing techniques to identify missing requirements, surface ambiguous statements, and expose implied requirements early in the process. Find out how Tanya Martin-McClellan produces test cases that accurately reflect the requirements, as they are understood at the time, and conducts team reviews to find the gaps and misunderstandings. Although more time is spent writing and rewriting test cases, less time is spent later discussing requirements.

• Find the vaguely defined parts of the requirement definition
• A template of implied requirements you can customize

You must successfully test your browser-based applications before hackers do the job for you! Whether you have to worry about critical business applications or government compliance issues like HIPPA (Health Insurance Portability and Accountability Act of 1996) or GLBA (Financial Services Modernization Act of 1999), security failures can cost your organization big dollars, unnecessary embarrassment, or both. Hackers have gone beyond simple exploits of open IP ports and standard applications such as Telnet, FTP, and Sendmail, turning their attention to commercial and custom Web applications. To thwart the hackers, test engineers must focus their efforts on common and uncommon security vulnerabilities within the application, including SQL injections, session hijacking, cross-site scripting, and more.

Developers and testers sometimes get into a frustrating dance in which the developers provide code for test, the testers run tests and document findings, developers fix the problems and re-release for testing, and the testers rerun and document new, different problems, and so on. For good reasons teams often begin "formal" testing on new software while it is still being coded. In this case the testers are working full tilt: running tests, investigating and isolating faults, writing up defects, rerunning the tests, and verifying fixes; but a lot of time is wasted by everyone on problems the developers already know about. As a manager, developer, or tester, you can break out of this vicious cycle and get to a better place. Douglas Hoffman shares his experiences seeing, participating in, and getting out of the test and test again syndrome.

• How to know when the test and test again syndrome is happening to you