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.
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
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.
Some agile methodologists claim that testers are not needed in agile projects--all testing is done either by developers or users. Chris Hetzler has seen the effects of that approach, and they are not pretty. When customers find
bugs in large projects, the costs can be staggering. Chris believes that testers must be involved in agile projects at an even higher intensity since timelines are shorter and the risk of failure is higher. But Chris explains that testers' roles change and testers must be prepared for that change. In agile projects, the testers' role is one of quality engineer rather than the traditional product
What makes security testing different from classical software testing? Part of the answer lies in expertise, experience, and attitude. Security testing comes in two flavors and involves standard functional security testing (making sure that the security apparatus works as advertised), as well as risk-based testing (malicious testing that simulates attacks). Risk-based security testing should be driven by architectural risk analysis, abuse and misuse cases, and attack patterns. Unfortunately,
first generation "application security" testing misses the mark on all fronts. That's because canned black-box probes-at best-can show you that things are broken, but say very little about the total security posture. Join Gary McGraw to learn what software security testing should look like, what kinds of knowledge testers must have to carry out such testing, and what the results may say about security.
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.
Internal test metrics--test progress, defect density, and TPI/TMM measures on process improvement-do not reveal the complete picture of test value and success. By comparing common test metrics with those found in the Balanced Business Scorecard--financial, customer, internal, and learning/innovation metrics-we see the need to also report financial and customer measures. Some of these measures are quantitative (such as profits), and others are more qualitative (for example, customer satisfaction). Learn to measure the financial impact of testing through productivity metrics and measures of how testing affects the total cost of quality. Include in your reporting qualitative assessments such as the customers' perception of the usefulness of testing, the visibility of testing on projects, acceptability measures, and estimation accuracy.
Set measures for all viewpoints of testing's value and success
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.
Find out how teams transitioning to Agile practices must re-think their workflows and project metrics originally designed to handle many hundreds of defect reports that occur in typical testlast development cycles. Richard Leavitt discusses how a real-world implementation of key practices like early testing and continual integration-though not without bumps and bruises-lowered the number of open defect reports by an order of magnitude. These practices also can improve how the team communicates, reduce delays, and provide more direct measures of project status, feature progress, and release readiness.