Scrum, Java, Testing and UML in Methods & Tools Fall 2009

Methods & Tools Fall 2009 issue has just been published with the following articles:
* Mature Scrum at Systematic: mixing CMMI and Scrum in the same company
* Implementing Automated Software Testing: metrics that help manage the transition to software testing automation
* The Spring Framework: an introduction to this java framework, aspect oriented programming and inversion of control
* The Learning View: how to improve your learning capabilities as a software developer
* Time and Synchronization in Executable UML

75 PDF pages of software development knowledge that you, your colleagues and friends can download freely from


  1. There’s a really interesting discussion in the “Implementing Automated Software Testing” article about protecting integrity of the test environment. Something that isn’t discussed enough in the testing arena, as the consequences of getting this wrong can be catastrophic.

    I’ve seen a few examples of significant amounts of testing taking place only for the tester to realise, a little too late, that all the work is invalidated because the test environment doesn’t match the production environment. In projects where the deadlines are tight and the test environments are limited it’s only too easy to allow developers or support teams access to a test environment in order to help them out. The only problem is that frequently changes are made to the test environment and then never put back. So in an attempt to help out the project overall a tester can often get caught out and be left with an environment that is effectively useless (testers aren’t wholly blameless for messing up test environments either).

    Thom Garrett in his article, Implementing Automated Software Testing, puts forward some good suggestions on how to safeguard the integrity of the test environment. Isolating the test environment is one suggestion put forward which is arguably the ultimate solution. However, in the real world where it’s difficult to completely restrict access, the suggestion of implementing formal configuration management processes/tools in the test environment has to be an option worth further investigation.

    For anyone who’s been caught out by the issues surrounding test environment configuration this article is well worth a read.

Comments are closed.