About Agile Testing

Book ‘Agile Testing’ of Lisa Crispin & Janet Gregory in my interpretation. Basic ideas, concepts…
To begin I remind Agile Manifesto:

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

The main purpose of agile team – quality! And all members of the team are responsible for the quality! For this agile team uses short histories to create the product (usually 2-4 weeks). It is convenient because after each history, we have a small, but the working part of the program. It is also important to make them as simple as possible, so you can easily make changes and additions, if customer wants it suddenly. A good point is the fact that the customer can understand that things works such as not expected or wrong, even in the initial stage, until the case had gone too far, as often happens with long iterations (in six months or more).

Bug Tracking System should not be a panacea. The agile development offers the use of Board of Stories. In this case is using psychological moment: 500 errors in the BTS – it’s just a number, but a stack of 500 cards makes a much stronger impression. But if the team is distributed geographically, or if we are dealing with a legacy system that contains a large number of defects, or if team wants to track errors in order to audit – then, of course, the BTS is needed. But not necessarily log all the problems. It should be approached with intelligence. Also it’s possible to use BTS with board stories together.

Also for productive teamwork is important that all trust each other. Joint testing helps to increase the speed of the work. For example, programmer wrote some part of code and then showed it for the tester locally. They together sawtested it, and if tester accepts it, then programmer implemented it. This scheme really saves teams time.

Team will be more effective if in any major discussions or conversations should include: programmer, tester, customer (so-called rule of “Power of Three”). Dense communication helps to avoid unnecessary mistakes, identify the points that were understood by the parties in different ways. Also, the presence of experts from each area helps raise and resolve issues on which experts from other areas might have forgotten.

more schematic >>>

The Role of Testing
Testing is the headlights of the project
• Where are you now? Where do you headed?
Testing provides information to the team
• This allows the team to make informed decisions
A “bug” is anything that could bug a user
• Testers don’t make the final call
Testing does not assure quality
• The team does (or doesn’t)
Testing is not a police establishment
• Find ways to set goals, rather than focus on mistakes

Test-First Programming
Developers write unit tests before coding.
• Motivates coding
• Improves design (reducing coupling and improving cohesion)
• Supports refactoring

Refactoring: Improving the Design of Existing Code
“Changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure” Make the simplest design that will work.
Add complexity only when needed. Refactor as necessary. Refactoring requires unit tests to ensure that design changes (refactorings) don’t break existing code.

Acceptance Testing
User stories are short descriptions of features that need to be coded. Acceptance tests verify the completion of user stories. Ideally they are written before coding.

A Practice for Agile Testing
Conversational Test Creation
Coaching Tests
Providing Test Interfaces
Exploratory Learning

>Conversational Test Creation
Who should write tests?
• Customers are often too busy. Defining tests is a key activity that should include programmers and customer representatives. Don’t do it alone.

>Coaching Tests
A way of thinking about Acceptance Tests.
Turn user stories into tests.
Tests provide:
• Goals and guidance
• Instant feedback
• Progress measurement
Tests are specified in a format:
• That is clear enough that users/customers can understand
• That is specific enough that it can be executed Specification by Example

>Providing Test Interfaces
Developers are responsible for providing the fixtures that automate coaching tests in most cases agile teams are adding test interfaces to their products, rather than using external test tools

>Exploratory Learning
Plan to explore the product with each iteration. Look for bugs, missing features and
opportunities for improvement. We don’t understand software until we have used it.