Solution to Ivan Indispensible

Ivan is the test architect and test automator for the project. He designed the automation using good programming practices, since he has a good background as a developer. His scripts are well-structured, and there is little if any duplication because he knows to create a new script with the common code which is called by each test that needs to do whatever is in that common script. The automation is a great success, with more and more tests being automated.

But the company has recently merged with a company that doesn’t have any automation, so they want to apply the automation to the applications that have recently been acquired. The new company has assigned Ramesh to find out about Ivan’s automation and apply it to their own systems. This is being done remotely, as the acquired company is in a different country (and time-zone). However, Ramesh is struggling to know what is going on, because Ivan hasn’t written much (if any) documentation or comments about the automation. To be honest, Ivan considered it a waste of time, as he was the only person using the automation at the time, but he now recognises that if the automation is to be more widely used, he may need to do things differently.

Exercises:

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 Ivan's main problem.

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 Ivan.

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

Solution:

• Using the Diagnostic, the most appropriate choice is Improve or revive test automation.
• At the next level, the most appropriate choice is Maintenance expectations not met as it mentions undocumented test data or scripts.
• The best choice now is the one about other people not understanding what the automation is doing, so the issue is INADEQUATE DOCUMENTATION (Process Issue).
  • There are three patterns listed in the Issue: DOCUMENT THE TESTWARE, DESIGN FOR REUSE and SET STANDARDS. All would be useful for Ivan.
    • DOCUMENT THE TESTWARE (Process Pattern) is the one that Ivan should have used, and is probably the best one for him now as well (even if he doesn’t like the idea! There is good advice here for producing good automation documentation. One suggestion that may be very useful for Ivan is to let a “newbie” update the documentation. In this case, get Ramesh to write documentation based on what he can glean from the scripts etc. Ivan can then review this and between them, they should come up with good documentation. Ramesh would gain familiarity with all the automated testware by trying to write up what it does, and the discussions about this will help to bring him “up to speed” with Ivan’s work.
    • [[DESIGN FOR REUSE] (Design Pattern) may also be appropriate.
    • It is important to SET STANDARDS (Process Pattern) for the documentation - not just set them but also keep to them!

Back to Solutions