Based on their experiences as software developers and the pair programming practices they use at Oxygen Media, Wendy Friedlander and Oksana Udovitska describe the principles of pair programming, explain why it is a worthwhile practice, and show you how to get started. They share ways to take full advantage of pairing and how to cope with its challenges. For those new to pair programming, this class serves as a good introduction and includes concrete first steps for getting into a new way of programming. For those already working in a pairing environment, Wendy and Oksana include some novel viewpoints and interesting discussions on familiar topics. Additionally, everyone will benefit from the interactive and fun games for improving and enhancing communication skills. Being women in a male-dominated profession gives Wendy and Oksana unique perspectives and insights into pairing which they are eager to share.
Applications deployed with service oriented architectures are implemented as producers and consumers of services. Testing a Service Oriented Architecture (SOA) application is unlike anything you've done before because every service can be invoked by consumers of whom you have no knowledge. This requires you to understand the specifications of those services in order to build valid, robust tests. Before SOAs began appearing in IT organizations, testers often dealt with lack of management commitment, poor testing tools, and minimal testing environments. Now, with SOA, the risks of failure are high, and the powerful processes, protocols, and tools that software developers use to build applications can also be used by testers to verify, validate, and test SOA applications.
Software development methodologies try to improve quality by promoting the tactic of testing "early and often." When a defect is detected, a report is filed, the developer tries to reproduce and repair the problem, and then testing must verify that the modification corrected the problem and did not create any new problems. Because it doesn't prevent the same types of errors from recurring, this approach is time consuming, costly, and inefficient. Errors are introduced into the product at various stages- requirements definition, design, and coding. If we focus our efforts on eliminating defects at the points of error introduction, we can reduce the time spent on error detection and correction. Shankar Krishnamoorthy discusses the best practices for error prevention that Aspire Systems has discovered in their experience of developing almost three hundred products.
Shankar Krishnamoorthy, Krishna Sivaramakrishnan, and Aparna Venkateshwaran, Aspire Systems
The SOA revolution is already underway in many IT organizations. SOA creates new cultural, organizational, and technological challenges that must be met to ensure success. Merely implementing web services and enterprise service buses will not address the key issues in building organizational support and standardized adoption throughout the organization. Without the proper organizational process infrastructure, you will be left with SOA program chaos and SOA infrastructure shelf ware.
Service Oriented Architecture (SOA) is becoming a widely adopted approach for enterprises to attain agility and economy while meeting their Information Technology (IT) needs. Unlike previous attempts at component based software development efforts, development in SOA environments stresses code reuse through development, deployment, and orchestration standards. Frank Cohen explains the major trends currently in play that impact the use of XML in SOA and how a new base of computing technology using composite applications, Registry/Repository, Enterprise Service Bus (ESB,) Master Data Management (MDM), Database, and SOA protocols and practices deliver a solution. Frank begins with the SOA basics, explains their applications, and shares specific metrics that you can use to govern your SOA efforts.
Identify where SOA is applicable, and where it is not
Service Oriented Architecture (SOA) based on Web Services standards has ushered in a new era of how applications are being designed, developed, and deployed. SOA's promise to enable the development of applications that are built by combining loosely coupled and interoperable services poses new challenges for testers and everyone involved with the software reliability and security. Among the challenges are dealing with multiple Web Services standards and implementations, legacy applications (of unknown quality) now exposed as Web services, weak or non-existent security controls, and services of possibly diverse origins chained together to create dynamic application implementations. Join Rizwan Mallal to learn concepts, skills, and powerful techniques-WSDL chaining, schema mutation, and automated filtration-needed to meet these challenges.
As always, the snake oil bandwagons are circling your organization. But unlike snake oil, a purported health supplement of old, modern organizations bet their success on technologies with often equally dubious claims. Did your organization jump on the CORBA bandwagon? It's now dead. How about outsourcing? Have you discovered all the hidden costs and quality problems yet? Perhaps you were mesmerized by Extreme Programming-a fading religion that once had many believers but few actual practitioners. There are many other software religions with many practitioners but few real believers. Do you use sound business judgment in choosing your technologies and methodologies? Or do you choose it because you heard an impassioned presentation by a noted expert? Ungrounded choices based on testimonials place us squarely back in the days when snake oil salesmen crisscrossed the land.
Designing Web services is all about the interface. Although tools for Web services development have advanced to the point where exposing application functionality is simple, the ease of building Web services does not diminish the need for careful planning and a highly functional design. Dave Mount opens his presentation by spinning the cautionary tale of slapping together a Web services interface on a poorly structured application. This scenario serves as a reference point for a subsequent discussion of the pitfalls of a poorly designed interface. Dave illustrates techniques for correcting problems and improving the Web services interface. Looking at high profile Web services provided by Google, eBay, and Salesforce.com, he shows how an external perspective that emphasizes consistency and conceptual clarity is key to Web services interface design.
The system of apprenticeship was first developed in the late Middle Ages. The uneducated and inexperienced were employed by a master craftsman in exchange for formal training in a particular craft. So why does apprenticeship seldom happen within software testing? Do we subconsciously believe that just about anyone can test software? Join Lloyd Roden and discover what apprenticeship training is and-even more importantly-what it is not. Learn how this practice can be easily adapted to suit software testing. Find out about the advantages and disadvantages of several apprenticeship models: Chief Tester, Hierarchical, Buddy, and Coterie. With personal experiences to share, Lloyd shows how projects will benefit immediately with the rebirth of the apprenticeship system in your test team.
Four apprenticeship models that can apply to software testers
Measures of the benefits and return on investment of apprenticeships
Test-driven development (TDD) is a new approach for software construction in which developers write automated unit tests before writing the code. These automated tests are always rerun after any codes changes. Proponents assert that TDD delivers software that is easier to maintain and of higher quality than using traditional development approaches. Based on experiences gained from real-world projects employing TDD, Peter Zimmerer shares his view of TDD's advantages and disadvantages and how the TDD concept can be extended to all levels of testing. Learn how to use TDD practices that support preventive testing throughout development and result in new levels of cooperation between developers and testers. Take away practical approaches and hints for introducing and practicing test-driven development in your organization.