All related posts: Reference Page – GP/QTP Automation  

            1) Automation Requirements Summary             

• Automated Testing solution should be open, scalable, robust, and friendly for the continuous maintenance
• Test Data model should be open, scalable, and extendable. All the settings must be customizable without code changes. Test Case scripts dependency on a specific spreadsheet or file structure should be minimal
• Test Logic implemented in the scripts should be as much transparent as possible for the end-user with no or minimal skills in programming
• Multi-layer verifications and error handling must be implemented in order to provide robust execution, extend test coverage, and reduce maintenance cost
• Test Results must be embedded from Testing Tool and compliant with the expectations provided above 

            2) Evaluation and Tools 

• Evaluation included: GUI recognition, GUI interaction, and GUI mapping
• Selected tools: HP Quick Test Professional and AutomatedQA TestComplete
• Evaluation methods: using GUI Spying tools, using Record/Playback mechanism, using GUI mapping tools      

            3) MS Dynamics Great Plains GUI 

A typical business-specific window in Great Plains application is presented by .NET form hosting MS Dexterity panel (window or dialog type) that renders custom GUI objects and processes all mouse and keyboard events.

GUI elements include regular controls like buttons, text boxes, list boxes, labels, etc., and complex controls like toolbars, image groups, and input/output tables.

Structure and navigation components in Great Plains application are presented by .NET form hosting web-page type panel that renders web-type GUI objects. Objects belong to System.Windows.Forms namespace.

GUI elements that were identified include clickable links and web tables.

            4) Results with TestComplete 

• Dot NET – Standard System.Windows.Forms GUI objects – GUI Recognition and Interaction worked well
• Dot NET – Custom System.Windows.Forms GUI objects – GUI Recognition and Interaction worked with limitations (Update: in the lastest version of TestComplete there is quite powerful Object Mapping feature. Now custom controls is a no problem.)
• Dot NET – System.Windows.Forms Table objects – GUI Recognition and Interaction worked well.
• Dexterity GUI – Non-Windows Platform – GUI Recognition is very poor, some elements (input boxes, check/radio buttons) were completely invisible for the tool. GUI Interaction – didn’t work, recorded as hard-coded events for the parent window.  Workaround with using SanScript through COM is possible but due to limitations of trial version (only 2 modules, with a limited number of code lines) could not be implemented as a demo project.

            5) Results with Quick Test Professional 

• Dot NET – Standard System.Windows.Forms GUI objects – GUI Recognition and Interaction worked well
• Dot NET – Custom System.Windows.Forms GUI objects – GUI Recognition and Interaction worked well
• Dot NET – System.Windows.Forms Table objects – GUI Recognition and Interaction worked well
• Dexterity GUI – Non-Windows Platform – direct GUI Recognition and Interaction is very limited. Workaround with using SanScript through COM enabled object-oriented GUI Recognition and Interaction, so finally worked well 

            6) Next steps 

• TestComplete: Test Automation of Great Plains is not possible with demo version; further investigation required to find out about COM mechanism support, scalable object-oriented architecture support
• Quick Test Professional: custom component needs to be developed to enable support of Non-Windows Platform Dexterity GUI