This is a trick question, right? In agile, everyone works on the same items together, at the same time. Yet, the reality is we’re not all interchangeable cogs. Developers and testers each bring their own, unique skills to the table. The key to effective agile is not minimizing our differences, but building upon the strengths each person brings to the team. Join us for this hands-on simulation and retrospective as developers and testers explore how agile teams build quality into their process, how each member contributes to that quality, and how we can avoid traditional testing pitfalls.

Why is testing so slow? Why is testing taking so long? We’ve done lots of things to speed up testing, but we still face this time crunch when we get to the end of the iteration; then we find out from the field that there are problems that we didn’t anticipate. In this workshop, we’ll gather familiar patterns that slow down testing, and discover a few more in the process—and maybe we’ll find that the slowest parts of testing have nothing to do with testing at all. If you have problems that you’d like to solve or solutions that you’d like to offer, come along.

Testing can be a complex and thankless task. The technologies change so fast that your tools don’t work as they should. Your tests become brittle and are hard to relate to customer requirements. This talk looks at the latest techniques and tools for easing some of these burdens.

Topics include behavior driven development (BDD), domain specific testing languages (DSLs), scripting languages (Groovy) and a range of web, SOAP, and database testing libraries (JUnit, EasyB, WebTest, HtmlUnit, Tellurium, Robot Framework, JBehave, Cucumber, DbUnit, SoapUI, JMeter and more) and testing techniques.

I’ve been on teams with way too little and (heresy) way too much testing. There have been lots of talks about how you should test more, but I’m going to dare to talk about when you should test less. Too much testing can lead to backlash, gridlock, morale problems, and poor velocity. Of course lack of testing can lead to bad design, gridlock, morale problems, and poor velocity. The level of testing a team can support depends on many factors including: team size, developer buy in, managerial approval, company size, IT support, and testing experience.

This session will focus on the unique challenges companies face when using agile on projects that involve FDA governance: large company conservative culture, regulatory documentation, requirements tracing, and a bias towards waterfall development.

Skeptics argue that agile is best suited to small- and medium-sized companies and wrongly perceive agile as a limited, negating its use in the highly regulated corporate world.

In reality we will show you how we’ve successfully implemented agile in large sized companies operating in a highly regulated world.

Many an agile developer has gotten stuck in the AJAX mud when trying to develop Web 2.0 applications. Google Web Toolkit (GWT) applications are written in Java and compiled to JavaScript. This helps developers stay unstuck by leveraging the power of well-established Java tools and techniques. Learn how GWT works with refactoring Java IDEs, supports Test-Driven Development with JUnit, and handles all the cross-browser JavaScript for you.

End-to-end tests appear everywhere: test-driven development, story-test-driven development, acceptance testing, functional testing, and system testing. They’re also slow, brittle, and expensive. In this expert-level workshop, we will discuss why end-to-end testing is used, examine where and why it breaks down, and generate more effective solutions. We will spark ideas for participants to explore further on their own.

We will not be debating the premise (that end-to-end tests are problematic). This is an expert-level workshop and attendees will be expected to participate fully.

One of the barriers to wider adoption of TDD is that it is best taught from within a team, and the technical challenges of writing tests frequently thwart those looking to teach themselves. This session will be a live demonstration of Test Driven Development in Java, using Eclipse and JUnit, aimed at those new to TDD and looking to learn. Audience members will be encouraged to follow along on their own laptops as we walk through common scenarios that frequently discourage new TDDers, and demonstrate some techniques for overcoming them in a live coding session.

Continuous Testing (CT) is a developer practice that shortens the feedback loop established by Test Driven Development. It gives you near instant feedback about the correctness of your code, and helps you find bugs as quickly as syntax errors. This session will cover how CT has evolved in the last year, it’s current capabilities, and limitations. The presenters will also show several demos of the practice using freely available continuous testing tools, and examine how these tools can be integrated with existing infrastructure to bring the benefits of CT to a wider audience.

Integration tests are a scam, a self-replicating virus that takes over your project and burdens you with long-running, fragile, hard-to-understand test suites. You’re probably writing 2-5% of the integration tests you need to test thoroughly. You’re probably duplicating unit tests all over the place. Your integration tests probably duplicate each other all over the place. When an integration test fails, who knows what’s broken? When you refactor, you have to fix dozens of integration tests. Stop it. Learn the two-pronged attack that solves the problem: collaboration tests and contract tests.