the following questions when utilising these tools:
- What technical knowledge is required to use these tools up?
- Where should the tools various property files, logs, user extensions etc be located in the project architecture?
- ho needs to be involved? Developers, system architects, system administrators, build/configuration administrators?
- How do we integrate the tests into some sort of Continuous Integration process?
With these questions in mind it's clear that the use of test tools within the Agile practices of TDD and Continuous Integration (CI) is not a solitary activity conducted by the test team. This being the case let us look at the high level process of TDD and see where the tester can add value.
The developer(s) has a story that has been planned in for the iteration/sprint and is ready for play. The functional acceptance criteria have been added by the Business Analyst or Product Owner, and from this the tester has extrapolated the test scenarios perhaps in conjunction with the Product Owner/BA.
The developers will use a unit testing framework to unit test their individual lines of code. They add their assertions, verifies etc. They may also write some integration tests. As an aside, there may be some value in the testers viewing these unit tests prior to code check in or at least stepping through the code with the developer. This exercise will often provide a quality audit of the unit tests and allows the coder to explain to the tester what the test coverage is up to this point.
Whilst viewing unit tests may not be mandatory for a tester it is essential that the tester is the guiding force when it comes to functional test scenarios. So let us assume that for this story all our test scenarios are candidates for functional test automation. We want these tests to run as part of CI giving us a higher degree of quality and confidence prior to us perhaps doing any further exploratory or manual testing. But who should script and code these tests?
I would argue that the tester should if they have the technical know-how. The UI presentation layer may not have been finished, all the values and targets to enter into our script may not yet been known, the developers probably haven’t confirmed most of the implementation yet, but the onus is on the QA team to at least determine the structure of the automated testing. This being the case, if its not possible to write the complete functional test up front then the tester should write a draft structure and then collaborate with the developer to flesh out the test as the coding of the story progresses.
To summarise the involvement of the QA in TDD:
- XA story is ready to be played. The developer writes unit/integration tests. Tester codes or drafts the functional automated test.
- As the story is coded the developers and tester collaborate to flesh out the functional test.
- On completion of code effort the developer then demo's the working tests on their local environment to the tester prior to checking in their code and tests.
- All being well the tests pass the CI build. Testers may now do further manual and/or exploratory testing as they see fit.
- The QA team may also use some or all of the functional automated test to integrate into a larger regression script which can be run on a standalone CI server or perhaps on a separate QA environment.
Blockers and impediments to the process
For various reasons the process does not always work this smoothly. Some QA teams may simply not have