program selection system

In this talk, I intend to do the following:

Show how the intended quality can and should be made explicit in the Definition of Done.
Note how difficult it can be for a team, to write down their Definition of Done, and implement it in a uniform fashion.
Highlight the amount of testing activities in a good Definition of Done.
Advocate the need for specialized testers in a team.
Give examples on the required openness and communication. (Involve the audience by asking a few questions.)
Argue that the complexity and (tiered) structure of today’s applications has increased the need for unit testing.
Summarize the Agile development and testing process into the same four keywords: Teamwork, Feedback, Flexibility, and Simplicity.
Give recommendations and examples that involve those four keywords. (Not merely a list of DO’s and DON’Ts; also some actual situations to make it more real, less theoretical.)
Enable non-specialized testers (such as developers and end users) to apply test techniques in a simplified format.
Suggest how the tester should behave on an Agile team.
Explain the testing spikes each iteration, and how to cope with them.
Stress the importance of test automation to meet the testing demands in later iterations.
Conclude by showing how the suggestions given will help the team to achieve their quality goals.

Answer questions from the audience.

I intend to give substance to the four keywords I mentioned, by adding several examples and suggestions.
For instance, during the daily stand-up meeting, team members give updates on their progress. This includes requests for feedback. For testers, the requests are often implicit: the fact that a feature has been added to the project should alert them that their feedback is wanted. In fact, a tester that is flexible enough to switch testing to the new functionality at a moment’s notice, will be highly valued as a team player. Sure, a tester who switches tasks will lose a bit of focus. The fact that he is giving feedback where it is wanted the most should outweigh that, any time of the day.
About the testing spikes, the explanation of their natural occurrence is simple: the time-box is a deadline that is shared by all of the stories in a sprint. In the ideal situation, that is no problem: assuming that enough testing can be done in parallel with development, and stories are ‘burned down’ as Done early on. Some of the suggestions aim to stay close to the ideal burndown line. For example, story granularity. Splitting stories may create overhead, and introduce dependencies. It also yields focus, and enables getting things Done quickly. The latter argument should be stronger, most of the time.
A general concern is that much of the testing in a typical iteration, is performed by non-specialized testers, such as developers, and end users. Ideally, one would want those non-specialized testers to apply test techniques to derive test cases, same as regular testers do. (Why? Well, let’s say that not all developers in a team use the same methods to draw up their unit tests. It follows that there will be differences in the quality of the tests. It could be said that not all team members are following the same Definition of Done.) Rather than formal training in testing techniques, I’d want to suggest providing some tools: one-page reference cards, explaining a testing technique, or a simplified version thereof. It’s usually okay to simplify a technique somewhat, if the resulting test cases are like 90% the same: good is good enough.