Working with "Closed" applications

Hi Mark,



What platform, tool, language and technology is used for your application?

Have you went through http://support.smartbear.com/viewarticle/12983/ and http://support.smartbear.com/viewarticle/14428/ ? Didn't they help?

Alex,



Yes, I have seen those pages in the documentation. Most all the Testcomplete documentation talks about 'the need' for your programming department to 'open' the application so it can be tested better. While I don't dispute that, I just know our programming department is not about to do that (long story).



I am currently able to use TestComplete with our application but there are a limited number of properties that display for the fields. While some of the fields (such as buttons, links, tabs, menu, etc) I can reference by the text on them there are other fields (editbox, combobox) that I must reference using the index number.



Our programming department is open to making minor accomodations to help with automated testing. I am hoping there is some method they could use to create an additional property for all field types that would expose a 'name' property for TestComplete to use. I just need some type of general guidance on whether this is possible and what is generally require to accomplish this.



I believe our code is mostly written in C and C++.

Hi Mark,



If your application is not open, implementing additional properties in it won't be very helpful since TC will not be able to obtain them. If your application is developed in MFC (you mentioned C++), you need to create a debug build for tests to get object fields and methods which can help in your case, but if there's no way to do this (or if your application is of an unsupported type), black-box testing with only standard (added to all objects) properties and methods available is the only way to test it.



However, you can improve object recognition in this case too.

First, you can enable Text Recognition which will make TC able to get text drawn on controls. This way, you can recognize objects by their text, and this helps if you, for example, have a control where you need to reference some items not available as individual objects.

Also, try MSAA. If should expose more objects and make their contents accessible.



If you have a control whose contents you cannot identify in tests, but this control is similar to a standard Win32 one (like an edit box whose text you cannot get), you can add its window class to object mapping settings.

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.