View source for Bringing Testers into an Agile Team

==Topic==

The topic of this session was what role a full time tester can play on an agile team.

==Session Notes==

===First Problem Posed===

The session was started with an explanation of the current situation. The team in question practices 6 week iterations. The first 4 weeks of the iteration are normally used to put together the features that are needed. For the last 2 weeks of the iteration, the emphasis shifts from developing features to testing what has been developed. The question was then posed as "what would the tester do for the first 4 weeks?"

===First Problem Discussion===

How do you tell if things are done without testing during the iteration? Done isn't until the end of the iteration without that.

Testing will speed you up

The app cannot be tested earlier because there is nothing to test earlier. The app is developed over the 4 weeks in horizontal slices from the bottom up. So until the last layer is developed there isn't much to test.

An explanation of advantages of finding (small) vertical slices, rather than horizontal slices
* Less wasted work at each layer
* Less missed work at each layer
* Faster feedback since each slice is a fully functioning part

An explanation of finger charts (also called cumulative flow diagrams) {{ref|http://bdn1.borland.com/borcon2004/article/paper/0,1963,32096,00.html}} which can be used to see where bottlenecks are

There needs to be also concentration on making what is currently done testable. Once it is testable then the tester can do things early.

How do you deal with developers distancing themselves from the job of testing when the tester joins the team? ("It ain't my job.")

An experience of how it is done on someone's team was told: They use 2 week iterations. Throughout the iteration the developers and testers pair. The developer automates the tests that the tester comes up with and has feedback from the tester.

A small disagreement:
Person A: Need to have a software architect before you get a tester to make sure that the architecture supports testing.
Person B: I wouldn't suggest that. Testable architecture needs to be a part of the team dynamic.
PJ: Best teams I've worked on, everyone rotated through everything (Dev, Test, Analyst, etc.). Used fingercharts to balance the work and find the bottlenecks that need to be broken

===Second Problem Posed===

How do you deal with branching the code during the testing phase. Changes will need to be made and brought back in to the trunk. Developers are eager to move on to the next iteration.

===Second Problem Discussion===

Don't do the test phase

Shorten the iteration: Fewer features, better testing, fix the bottleneck

Perform code reviews
* But the functional tester can't check the functional part that way

What do people understand as a "code review"
* checking naming conventions
* checking maintainability
* checking future changability: simplicity

Try pair programming with a functional analyst.

Tester works ahead and figures out tests before the iteration starts. Make the tester more business focused.

==Summary==

The last few minutes we went back over some of the suggestions:
* Vertical vs. Horizontal slicing
* Get rid of phases
* Smoke tests (to shorten the testing cycling)
* Have a tester with technical abilities so that they can get into the system
* Devs talk to testers more
* Use the tester as a proxy to the customer (I think "advocate for" is what was meant here)
* Foster an attitude of wanting to interact with the tester
* Foster an attitude of all parts of creating software are their job
* Drive to testability