As large organizations adopt agile, many are running into a common issue where each team wants to choose their own tool – after all, they are supposed to be self-organizing? I think this might be a bit short sighted.
One of the premises of eXtreme Programming is shared code ownership, and if you ask any programmers working on one product, they will all be using the same tool for their unit tests. For example, jUnit if they are coding Java. They may use different IDEs (editors) but the unit testing framework remains the same. We need to apply some of those ideas to choosing our functional test tools.
If we think about an extended team, say one that included the support or operational folks, would we still want each individual project team selecting a different tool? If multiple teams are working on the same product, can we really support the automated regression suite mixed and matched arbitrarily?
One suggestion I have for organizations facing these problems is to define a class of tools for teams to select from. For example, for API level tests, you can choose from FitNesse or Cucumber or for tests through the GUI, Selenium or Ruby and Watir. One way to determine these selections is to have product teams experiment with several tools, and then compare pros and cons, and select one for each type of testing they want to perform.
It is important to understand who will using them, and the teams they impact.
One comment on “Choosing Functional Test Tools for Large Organizations”
I think large organizations should have standard tools for people to use, and it should be only one for each category. Otherwise, it is just too confusing and it hampers productivity. Sure, agile teams are supposed to be 'self organizing' but it still needs some rules and constraints. Requiring use of a certain tool is not a lot to ask. Sure, not everyone will be happy, but you can never please all.