Solution to Ted Toolswitcher

Ted’s automation was going just great – lots of tests automated, regression suites run every night, scripts were well-structured, and Ted was really happy with the tool they have build their tests in. It was a well-established tool and they were confident if would be around for a long time – that’s why they went for it.

But now there is a problem. The tool development is headed in one direction, and the applications Ted is testing are going in a completely different direction. Ted has tried to convince the tool vendors to support their company, but they won’t do it. They will no longer support the version Ted is using, which is several releases out of date already, since the new features in the tool were not compatible with their tests. What should Ted do? Does he need to start again from scratch with a new tool? How can he make sure things will be better next time?

1) Go to Test Automation Issues Mind Map or Test Automation Issues Mind map with clickable links. Look through the Issue names and see if one stands out as Ted's main problem. See which patterns would solve it

2) Go to Test Automation Patterns Mind Map or Test Automation Patterns Mind Map with clickable links. Look through the Pattern names and see which stand out as possible solutions for Ted.

3) Go to the Diagnostic. Answer the questions on Ted's behalf and see if you find the same issues and patterns.

Solution:
If you searched the wiki for “tool”, there are a number of Issues and Patterns listed.

• TOOL DEPENDENCY (Design Issue) is probably the most appropriate issue.
• Using the Diagnostic would take you from Improve or revive test automation
  • to Maintenance expectations not met,
    • which would take you to TOOL DEPENDENCY. There are a few Patterns listed in this Issue, all of which may be applicable to Ted’s situation:
      • TOOL INDEPENDENCE (Design Pattern) looks like the best one to apply for Ted - or at least a Pattern that he should have applied when he was implementing his automation!
      • RIGHT TOOLS (Management Pattern) is perhaps less relevant for Ted; when they began their automation the tool did seem to be the right tool for them, but now their paths are diverging. Hopefully Ted can learn from his experience for the next time he is selecting a new tool to use.
      • ABSTRACTION LEVELS (Design Pattern) is probably the most important one for Ted to use now. If he had a better testware architecture to begin with, the actual tool would have less effect on the automation, they would have had less to change, and the time and effort invested into automated tests would be largely preserved when going to a different tool.
      • OBJECT MAP (Execution Pattern) is useful if the automated tests are at GUI level but the names of objects tend to change often - probably not very relevant for Ted at this point.

Changing the basic approach to automation by implementing a good TESTWARE ARCHITECTURE will take a fair amount of effort now, but that effort is essential in any case to change to a new tool. If the testware is re-designed as it is converted, this will prevent such problems in the future (or at least make them not as serious).