program selection system

Automated unit testing is the agile software development equivalent of “in-process inspection” in Lean Production systems. xUnit is the generic name given to the family of tools/frameworks used by developers when developing automated unit tests. The community has now had enough experience with using XUnit to start cataloging “best practices” and “not so best practices” as patterns and smells. This tutorial introduces a number of these “test smells”, describes their root causes, and suggests possible solutions expressed in the form of patterns.

In the playground world of software development, Agility has cool shoes and the latest gadgets. Testing has asthma and sticking plaster on his glasses.

Does testing have anything desirable at all to bring to the party? This discussion-based track proposes that testers bring something at odds with Agile approaches; disbelief, cynicism, pessimism. It is by defeating these that the software shows that it is genuinely ready to meet the real world.

Can one truly be an ‘agile tester’? Would that be a good thing?

** End of 90-word summary **

This experience report outlines technical lessons learned over a several year period across several projects within an organisation which aggressively applied most of the agile practices with much success. The success, however, was not been achieved without challenges and lessons learned along the way. This paper outlines the interesting observations we made while trying to turn the agile dials to eleven. Our starting assumption when we began this journey several years ago was that productivity and quality were opposing forces; you had to trade one off against the other. However, after turning the dials to eleven, we now believe that you can much more of both than we previously thought possible. In fact, we believe that applying the practices outlined in this experience report allow both much higher quality and higher productivity than traditional development.

In the Web 2.0 age, end-to-end web testing provides tremendous feedback on the quality of your Web application. However this feedback cycle is typically quite long and comes at a high maintenance price. This talk shares our field experience in establishing web acceptance test suites with high return on investment (ROI) for Web applications.

Printed Program Guide Blurb
Books on Test-Driven Development abound for C# and Java, but there are few directed towards C++ programmers. Yet much software is written is C++, and C++ is an extremely powerful language, one that I’ve found to be quite well-suited for doing TDD. I will present a series of practical and efficient testing patterns specifically for C++. Most of the techniques involve templates; one of them involves lexical closure. Many of these techniques are also well-suited for dealing with legacy code.

Testers often get left out in the cold when their development team transition to agile. We’ll look at “the wall” of challenges they face, and explore the support testers need to break through it. The goal is to get testers and QA teams get traction understanding agile development. We’ll poll participants for problems, and explore what they need to know and where to find it. Training, physical logistics, new roles as agile testers and QA managers, adapting traditional testing activities such as audit requirements are just a few of the areas we’ll touch on.

Success in object-oriented agile development is currently being achieved with a technique known as test driven development (TDD). In database development however, TDD practices are not wide-spread and development teams struggle with applying the TDD principles to the SQL language. This is a problem, because it leads to poorly tested code. In turn, not having the appropriate test cases, makes it difficult to improve your existing database design. Not implementing TDD practices in the database, overtime, leads to a decaying architecture and can hinder the evolution of the overall

Achieving quality in Agile projects starts with a clear Definition of Done, listing all of the quality criteria that the team wishes to satisfy. It is not easy however, to integrate testing in such a way that the Definition of Done can also be met in later iterations. The natural progression of the required amount of testing effort is to spike sharply at the end of each iteration, and to increase overall in later iterations. This talk is about highlighting the problem areas in maintaining one’s Definition of Done, and about teamwork in testing.

Abstract:

When test-driving a GUI component, some aspects are best checked by manual, exploratory testing. JDemo, inspired by JUnit and in extensive use and refinement since 2003, eases bringing the component onto the screen in the desired state and thereby allows the developer to concentrate on the task at hand and rapidly iterate through different versions of the component. The session will give an introduction to the framework, and by means of a live example show how it can be used to effectively integrate exploratory testing into the TDD cycle.

Projects that fail do so mostly because they build the wrong thing, not because they do a bad job building whatever they do build. A big part of the difficulty is getting the users to tell us what they want. Traditional requirements engineering approaches have had mixed results, but requirements capture through “checked examples” (eg Fit -style tests) seems to work very well. Why should that be? Are there clues to be had from post-Aristotelian notions of “category” in the cognitive sciences? If so, how can that help find better examples?

This is a follow-on from a reasonably well-received talk given at Agile 07.

The session will be a work-torial. Or possibly tut-shop.