One issue that we already mentioned in the section GeneralTesting, and what seems to me is a good example is:

* Provide Continuous Feedback

As a tester you can provide different kinds of feedback status acceptance tests, number of written acceptance tests vs. stories, etc) to several people (Customer, Developer, Projectmanager)

* Clear everything out

A lot of assumptions are made in a software project - by the customer, by the developers, by the project manager and by the testers. You need to question out a lot, without being negative. It's about carefullness and risk management.

Note from LisaCrispin - "Rules" implies there is generally a right way to do something. I think rules can be helpful as a guide or starting point, but my experience lately has been that each team has to find what works for themselves and their project. My earlier teams were concerned about whether we were 'really' doing XP. Does that matter, or does it matter more that we are achieving our goals ('our' referring to the entire team including the business experts)? Should we change the name of this page from "Rules" to something else? Patterns? Practices?

AT: I'm not sure. If the definition of those Rules is on quite an abstract level, it wouldn't be such a point, would it? But then again: you are the native speakers, you know how it sounds the best. Just as with the Context Driven School, there are no Best Practices, but there are Lessons.

DavidEvans thinks: The other pages on the wiki seem to deal with Practices (and Anko is right, recalling Bach, Pettichord and Kaner: "There are no best practices, only good practices in context".) I think this page, on the other hand, could be about "Codes of Conduct" for a tester on an agile team. This could consist of statements about the way in which a tester will conduct themselves for the benefit of the team. Less restrictive than rules, but similar intention.

back to AgileTesting