Ivan Indispensable Solution
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.
- Looking through the Issues, the most relevant one is INADEQUATE DOCUMENTATION.
- Looking through the Patterns, 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!)
- DESIGN FOR REUSE (Design Pattern) may also be appropriate.
3) Go to the Diagnostic. Answer the questions on Ivan's behalf and see if you find the same issues and patterns.
Using the Diagnostic, the following path is one possibility:
- The most appropriate choice is to “want to improve or revive your test automation”.
- At the next level, the most appropriate choice is “Maintenance expectations not met” (although some of the others may also apply).
- The best choice now is the one about other people not understanding what the automation is doing, so the issue is INADEQUATE DOCUMENTATION.
- There are three patterns listed in the Issue: DOCUMENT THE TESTWARE, DESIGN FOR REUSE and SET STANDARDS. All would be useful for Ivan.
- Looking at DOCUMENT THE TESTWARE, there is good advice for producing good automation documentation. One suggestion that may be very useful for Ivan is to let a “newbie” update the documentation, or 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 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.
- It is important to SET STANDARDS for the documentation - and also to keep to them!
Back to Exercises