UK Tester Forums

I attended the discussion at the recent TMF concerning the move from traditional to agile testing. The consensus seemed to be that agile testing is equivalent to "Best Practice". Whether working on a traditional life cycle model or an agile life cycle model the testing needs to be "Risked Based". "Good Enough Testing" aims to assure a level of quality within the budgetary constraints of the project. This strategy is independent of the project life cycle model. Note that "Agile Testing" is not a methodology. This raises the question whether it is time to drop the phrase "Agile"?

The term “Test Driven Development” appears far more widely than the term “Requirements Driven Development”. However, I argue that it is the latter which should often be the driving force. That is, unless the project is extremely agile and requirements only emerge through trial and error. T.D.D. seems to be a great approach to unit testing, but for the higher level test phases I argue that we should be looking to elaborate test cases through the exploration of requirements and it is the linkage between successful tests and requirements which ultimately prove the worth of the development.

The discussions I attended shared a common theme:
This was that the focus of testing needs to be on business goals rather than narrow requirements. The best requirements are those that have examples or tell a business story. However, we do need robust stories – throwaway stories do not serve this purpose.
When documenting our tests we can then keep in step with these examples along with our test data.

James Lyndsay is offering free places on this course:
Good testers need to be able to go beyond simply logging a problem. To give value to their stakeholders and integrate with their development teams, testers need to be able to investigate the problems that they find. Diagnostic skills will help a tester to isolate genuine problems from a rash of symptoms, to work out what lies behind field reports, and to communicate her bugs effectively by describing plausible models.

During a presentation at the TMF on 30/04/2008 this boldly provocative statement appeared on a slide: "Testing Equals Quality".

Many thanks to Colin Robb of HP for your hospitality yesterday evening, which furthered a good discussion at the end of the TMF.
Martin Jamieson.

The TPI model would have us believe that an understanding of test techniques is more important and valuable than subject matter knowledge. Is this true? Well, yes it is, but only if a structured approach is followed in system analysis and design. I think that one of the most valuable concepts I have come across in the field of software testing is the concept of equivalence classes. That is, of course, that if certain classes of data are equivalent then we can justify one test case per class, thus drastically reducing the number of test cases.

During a discussion on tester skill sets at the TMF on 30/04/2008 it struck me that there was a cord with Becker's theory on specific and general training: In his seminal article on investment in human capital, Becker (1962) defined completely general training as a human capital investment that raises a worker's productivity at other employers to the same extent as at the employer that provides the training. Similarly, completely specific training is defined as a human capital investment that increases productivity only at the employer that provides the training.