DUCOA 24 - DUCOA Summary

DUCOA is not about just the architecture or design of a Test Automation Framework. It is also about a Philosophy and a set of Practices. As far as the philosophy is concerned, it is about:

1. Getting more done with less: That is about getting more automation done with the least possible amount of code.

2. Just-In-Time Creation (Build it only when you need it): That is, do not create the complete framework at once. Build the part that is enough to satisfy the need or requirement in hand. Create and add more stuff to it when more requirements come into picture. In that way, you have the opportunity to use it sooner and get benefits out of it earlier. The framework is built on an 'On Demand' basis. Eventually, you get done with creating the complete framework. Once that state is achieved, no more coding is required to get additional features into the test automation done.

3. The power of simplicity: The whole affair (Architecture | Design, Workflow, Code, Troubleshooting, Result Analysis, Test Reporting etc.) is kept as simple as possible. The goal is to minimize opportunities for committing mistakes | errors.

As far as the practice part is concerned, it talks about who does what, when and how. It describes vividly the roles that are played and the contributions that are made, in the context of DUCOA, to achieve efficiency as well as effectiveness. It is about:

1. Excellent Collaboration
2. Clear and Precise Communication
3. Shorter Delivery Cycles
4. Highly Effective and Maintainable Automated Tests

This is how it is done in the context of the DUCOA Test Automation Framework when there does not exist any automation framework or infrastructure and a TEST is required to be converted into an Automated Test:

1. The Test Engineer in question breaks the steps of THE TEST into more granular steps and sends that test (Translated Test) across to the Test Automation Engineering or Development team.

2. The Test Automation Engineering or Development team adds more details to the Translated Test.

3. The Test Automation Engineering or Development team creates the Automation Infrastructure or Framework Code for the TYPES or Classes of UI Controls or GUI Objects required to be interacted within the context of the Translated Test in question.

4. The Test Automation Engineering or Development Team creates a Test Driver File that is used to list all the tests to be run automatically. And, an entry for THE TEST in question is added to the Test Driver File. The Automation Engineering or Development Team also performs any remaining tasks to have a Composed Test completed.

5. The Test Automation Engineering or Development team also creates a generic Test Run Engine that can select and run the Automation Code pertaining to the TYPES or Classes of UI Controls or GUI Objects as per the Composed Test in question. The Test Run Engine is guided by the Test Driver File to select and run the appropriate TEST by invoking the corresponding pieces of Automation Code for the TEST STEPs in question.

6. The Test Run Engine is invoked and it runs the Automation Code for the TYPES or Classes of UI Controls or GUI Objects required to be interacted with in the context of THE TEST in question. And, that is the automated form of THE TEST in question in action.

Once the Test Driver File, Test Run Engine and Automation Code for all TYPES or Classes of UI Controls or GUI Objects available in the Software Under Test are created, to automate another Manual Test, the Test Automation Engineering or Development team just adds an entry for that TEST in the Test Driver File, adds more details to the Translated Test and adds the Composed Test file to the existing set of Tests that can be run by the Test Run Engine. In that case, neither any code is written, nor any code is touched or modified to automate this Test in question. That keeps the whole affair simple, efficient and effective.

Comments

Popular Posts