To ensure the quality and safety of Web applications, security testing is a necessity. So, how do you cover all the different threats-SQL injection, cross-site scripting, buffer overflow, and others? James Knowlton explains how Ruby combined with Watir-both freely available-makes a great toolset for testing Web application security. Testing many common security vulnerabilities requires posting data to a Web server via a client, exactly what Watir does. The Ruby side of Watir, a full-function programming language, provides the tools for querying the database, checking audit logs, and other test-related processing. For example, you can use Ruby to generate random data or large datasets to throw at a Web application. James describes common security attacks and demonstrates step-by-step examples of testing these attack types with Ruby and Watir.
Users are the ultimate judge of the software we deliver because it is critical to their success and the success of their business. However, as a tester, do you really understand their tasks, skills, motivation, and work style? Are you delivering software that matches their needs and capabilities-or yours? Personas are a way to define user roles-imaginary characters-that represent common sets of characteristics of different users. David shares how his team at Microsoft defined and used one persona named “Ellen” to help them design, develop, and test the first version of a new product. David shares before Ellen and after Ellen examples of the product, showing how the product changed when Ellen joined the team. See examples of the robust test cases and acceptance scenarios they defined from unique insights that Ellen provided.
Lean production has made it possible for many industries to develop products faster and more profitably, building a loyal customer base while lowering business risk. Now, Lean has proven it can do the same for software development-and do so better than any development approach to date. Lean is more than a management system, method, tool, or environment; the areas where software methodologies normally focus. Lean is a worldview-a way of thinking that fundamentally changes and humanizes industry. The power of Lean is in the goals it leads us to pursue and the ways in which we coordinate our work. Therefore, Lean allows us to continue using many of our current software techniques. James Sutton returns to the beginnings of Lean, as conceived in the mind of W. Edwards Deming, and moves forward in time to compare and contrast Lean with agile development.
A major challenge for software organizations is to create software that can continue to adapt and change over time-a codebase the team can live with "forever." Jeffrey Fredrick and Paul Julius review the concepts and features of CruiseControl, a popular continuous integration tool that provides an architecture for habitable code. CruiseControl is an open source success story, contributed to by more than 200 different developers and downloaded more than 400,000 times. For developers who are tired of brittle code that often must be discarded and rewritten instead of reused, CruiseControl provides valuable lessons and a design that encourages reuse. Jeffrey and Paul discuss inversion of control, dependency injection, separation of concerns, and the role of a project architect in creating habitable code. Although the code examples will be in Java, the principles are language independent.
Test-Driven Development (TDD) is the practice of writing a test before writing code that implements the tested behavior, thus finding defects earlier. Rob Myers explains the two basic types of TDD: the original unit-level approach used mostly by developers, and the agile-inspired Acceptance-Test Driven Development (ATDD) which involves the entire team. Rob has experienced various difficulties in adopting TDD: developers who don't spend a few extra moments to look for and clean up a new bit of code duplication; inexperienced coaches who confuse the developer-style TDD with the team ATDD; and waffling over the use of TDD, which limits its effectiveness. The resistance (overt or subtle) to these practices that can help developers' succeed is deeply rooted in our brains and our cultures.
Joining an agile team can be very challenging-new programming styles, new coding standards, new check-in requirements, new leadership styles, and more. Adding pair programming to the mix can be "the straw that broke the camel's back" or it can be key to team empowerment. Paul Julius has been a dedicated pair programmer since 1999, working on many projects with 100 percent pairing. Paul has distilled a set of positive and negative patterns that can develop when teams attempt pair programming. He begins by discussing the most frequent objections to pairing and then outlines why pair programmers deliver better applications. Paul demonstrates the techniques and skills you-or members of your team-need to become a successful pair programmer.
"Quality" is one of the most misunderstood and elusive aspects of system development. Ask five people to define quality and you'll probably get five different answers. Although everyone thinks he knows what it is, very few can really define it in context. High quality software doesn't just happen-quality must be built in from the start. In this highly interactive presentation, Tom Staab defines quality and explains why quality planning is important. Join in the discussion about where most defects are injected into software, how to establish meaningful quality metrics, ways to communicate results to management in language they understand, and how to calculate the return-on-investment that can be expected from quality improvement activities. Quality must be defined in a project's specific context, quantified at the beginning of the project, and measured throughout the development lifecycle.
Agile processes are revolutionizing the software development industry. Projects embracing agile development are expected to be faster and more efficient than traditional software development. Agile processes enable developers to embrace requirement changes during the project, deliver working software in frequent iterations, and focus on the human factors in software development. Unfortunately, most agile processes were designed for small or mid-sized software development projects-bad news for large teams. Having worked with many larger teams transitioning to agile processes, Jutta Eckstein shares her insights into ways to tune your practices as you scale up to larger projects. Harness the adaptability of agile software development for large projects to ensure frequent releases even with several teams working together.
As agile software development leaves the early adoption stage and moves solidly into the mainstream, Mary Poppendieck reminds us that fads in software development have come and gone before. What makes us think that agile is different? Unless we learn from previous attempts to improve development practices, we are destined to repeat the mistakes of the past. Mary describes three proven paths to failure: (1) Copy what successful companies are doing-You don't get to be world class by chasing after best practices, you get there by inventing them; (2) Force everyone to follow the standard process-The best path to success is leveraging the intelligence of "ordinary" people in the relentless improvement of your current process; and (3) Focus on technical success-Technical success is a euphemism for business failure.
Due to the increased emphasis on computer security, great advances have been made in static analyzer tools that can detect many code errors that often elude programmers, compilers, test suites, and visual reviews. Traditional tools such as "lint" detectors are plagued with high false positive rates. Gregory Pope discusses the steps his organization used to evaluate and select a static analyzer tool and pilot its implementation. He describes how they rolled out the tool to developers and how it is being used today. Greg shares the results they achieved on real code (C, C++, and Java) and the valuable code metrics they obtained as a byproduct of its use. Greg discusses the skills needed to use the tools, ways to interpret the results, and techniques they used for winning over developers.
The features of static code analyzers
Defects that can be found with these tools
Gregory Pope, William Oliver and Kimberly Ferrari, Lawrence Livermore National Laboratory