Working with "Closed" applications
The main application I need to test is a very "closed" application. This makes it difficult for testing because I don't have any good methods for referencing and identifying certain fields types becau...
Forum Discussion
Hi Mark,
And as a last resort in addition to all said above by Jared, for the most 'unrecognizable' parts of UI you can try the method of shortcuts and/or 'blind' navigation and typing. As an example of this method, I can mention one application automated long time ago that was also 'closed' for TestComplete. We ended up with the approach, that for every form test emulated press of Ctrl-Home keys combination. This was moving input focus to the top left input field regardless of its type (input box, drop-down, etc.). Then the script emulated pressing Tabs, Down, Left and Right keys to navigate to the required control. It might sound strange, but this approach worked for us quite good and reliably. The reason of reliability was because of UI and controls stability - controls were standard and UI was designed before the functionality was implemented and any subsequent (even minor) change in UI had to be approved according to the defined process, so we, testers, were aware about changes in advance and were able to correct test code accordingly.
I don't know what application you have to test, but in general, I see no good reason why Development (actually, not Development, but the Management and Build Masters) should resist to include debug information into the build. Usually, debug information is the only thing needed by TestComplete to make application 'Open'. With the help of the TDStrip utility supplied with TestComplete (or AutomatedBuildStudio?), it is possible to extract debug information from the built binaries and put these debug information files into separate folder accessible for automation testers only.
And as a last resort in addition to all said above by Jared, for the most 'unrecognizable' parts of UI you can try the method of shortcuts and/or 'blind' navigation and typing. As an example of this method, I can mention one application automated long time ago that was also 'closed' for TestComplete. We ended up with the approach, that for every form test emulated press of Ctrl-Home keys combination. This was moving input focus to the top left input field regardless of its type (input box, drop-down, etc.). Then the script emulated pressing Tabs, Down, Left and Right keys to navigate to the required control. It might sound strange, but this approach worked for us quite good and reliably. The reason of reliability was because of UI and controls stability - controls were standard and UI was designed before the functionality was implemented and any subsequent (even minor) change in UI had to be approved according to the defined process, so we, testers, were aware about changes in advance and were able to correct test code accordingly.
I don't know what application you have to test, but in general, I see no good reason why Development (actually, not Development, but the Management and Build Masters) should resist to include debug information into the build. Usually, debug information is the only thing needed by TestComplete to make application 'Open'. With the help of the TDStrip utility supplied with TestComplete (or AutomatedBuildStudio?), it is possible to extract debug information from the built binaries and put these debug information files into separate folder accessible for automation testers only.