last week I submitted a paper proposal to StickyMinds on thoughts I came up with for Agile testers mainly influenced by the reocurring questions on how to test on Agile projects on the AgileTesting Yahoo-Group. Here is the essence of that paper. You can find the whole article here.

Agile Testers face the problem that there is few literature on how to test on Agile teams while there are a lot of recommendations for the development staff. Nevertheless Agile testers need to know the working habits of an Agile team. One thing reoccuring on the Agile-Testing group is the question how agilsm changes the way a tester works. Attracted by the principles in The Art of Agile Development from James Shore and Shane Warden here are those additions that apply for the testers on an Agile team. When appropriate I will make cross-references to chapters in their book, that also apply for testers on Agile teams.

Thinking
Beside an Energized Work and Informative Workspace, a tester should be able to apply Root-Cause Analysis when finding severe bugs so that they are unlikely to reoccur. Furthermore Retrospectives help improving the overall process. Beside these practices from The Art of Agile Development Pair Testing is useful for improving the brain power on your daily work.

Pair Testing
Pair Testing improves the work within the testing process – just like Pair Programming improves the brain power during development. Pair Testing can be applied with different expertise and techniques. Nearly all types of combinations are possible. An experienced tester can pair together with a junior tester or a customer may join a tester to help building test cases for a critical or difficult business logic. The feedback from the on-site customer can be spread to the programmer, when the tester pairs with a programmer while she is working on the story.

The first time I got to know pair testing was during a critical phase of a software replacement at a larger company. The department lead decided that I should pair together with another experienced tester with extensive on-site epxeriences from the user acceptance tests. We had a timeframe of four weeks left for the acceptance of our customer. Based on our previous working habits we would have needed three to four months of work that had to be done within one month. We were asked to exercise the user acceptance test cases documented and agreed with the customer. Our customer and user acceptance test team was located 1000 kilometers from our location and we needed more direct feedback for our development department. We both had quite impressive knowledge of the system under test, but each of us just knew one of the larger sub-systems very good. Therefore combining the knowledge of two adjacent views of the system lead to an impressive work-output. We managed to find critical bugs at a rate of ten per day. In the end we achieved to drive the development to meet the upper organisational goal within the given timeframe.

Collaborating
In the Collaborating section The Art of Agile Development lists many practices that are also worthwhile to apply to the testers in the team. When the team members Trust each other because they are Sitting Together and have an Ubiquitous Language, it is easier for the testers on the team to do the neccessary Bug Reporting.

Bug Reporting
Though No Bugs is a core practice under the Agile practices, during the development process of new functionality software defects slip in. When a tester finds a bug, it is up to his personal intentions on how to report it. Based on the particular level of Trust in the team there are several possibilities.

Write a test
This is the easiest way for the tester. He simply builds a test case that catches the bug and submits it into the revision system. When using automated build tools the next automatic build that the tests are run on will show up with the bug and the developers start fixing it.

Open a bug
The classic approach to report bugs is of course by opening an entry in the projects bug tracking tool. The advantage here is that any additional information useful for the resolution of the bug, i.e. logfiles and screenshots, can be put in, too. The programmers will start to fix the issue when working on the bug.

Report directly
For severe problems that need immediate attention during the fast paced devlopment cycle of an Agile team, a bug may be reported directly to the development lead in the team. This ensures immediate attention to the issue slipped in and makes sure that the bug can be resolved if it would lead to a critical outcome, i.e. during the iteration demo when Exploratory Testing is done in front of the stakeholders. Based on my experience this level requires the largest amount of Trust within the whole team.

Personally I prefer to do direct reports when appropriate. The flavour of throughing bugs back over the wall by opening some entry in the tracking tool or by writing a test which fails during the automatic build process which will sooner or later execute reminds too much to the days when software was thrown over the wall to the testers. Anyways it is usually better to open a bug or write a failing test for non-severe problems. Disturbing a programmer just due to some typo in the user interface does not account for the amount of thinking neccessary to get her back to work.

Developing
The Art of Agile Development mentions Customer Tests. Based on my personal impressions I would like to add a chapter named Business Facing Tests that is a combination of the original Customer Tests chapter and the Exploraty Testing chapter flavored with the personal realisations I came up with.

Business Facing Tests
Business Facing Tests are the key compound for Agile testers. By defining test cases in terms of the business language the test cases can be defined simultanously with the software development work. Therefore they provide immediate feedback for the software under test and provide valueable feedback directly after the story is developed.

After establishing the first tests in FitNesse in my company I noticed the following on the next project. My test team was able to apply the same principles that are driving the development during Test-Driven Development just on a higher level. We were able to define test cases beside the development work. After adding some smaller fixtures the test cases could be directly run and provided immediate feedback on the code under test. Additionally I noticed that our developers noticed this improvement and started to ask us about input for their bugfixes. By concentrating on the business value we achieved to build up Trust between the members of the teams beside the fact that we managed to get enough time for Exploratory Testing.

Based on my experience Business Facing Tests result in quick feedback that is needed during the fast development cycles. While being able to give this feedback nearly instantly Test-Driven Development is applied on a higher level.