I don't have enough vision to put forth a worthy guess as to whether the future could be scriptless. We are an agile software shop and testing is always behind the curve when attempting to keep up with the changes coming from the business. We have some inherent problems with our testing approach such as test dependencies and relying too heavily on mapping but I believe we would still be behind the curves were it not for these things. I could very much guess as to what the developers would name a newly added object but using the Find method is far too slow to be usable.
The ability to analysis the impact of a change up front would be very helpful but the webinar seemed a little "smoke and mirror" to me. I don't recall the verbiage used but it was something like, "Use the app like a user would and it will gather requirements, create impact analysis and nearly write the test for you." A bit too "pie in the sky" for me.
Given there is no migration path from TestComplete to TestLeft I doubt we'll ever see the day our company will re-invest in starting over..
It will be interesting to follow this thread.
william_roe Thanks very much for your comment.
I am interested in future comments on this thread as well. Especially by Smartbear / TestComplete staff (management).
Also, and this might be a little bit offtopic: I have no experience with the Find method, as you describe it, I take it that you use it somehow to recognize changes in the application?
We have tried using the Find method to deal with GUI changes but have found it unusably slow (sometimes minutes per object). There are a few places in which we've had to enable extended find but use this feature extremely sparingly due to onerous memory issues.
mgroen2 wrote:william_roe Thanks very much for your comment.
I am interested in future comments on this thread as well. Especially by Smartbear / TestComplete staff (management).
Also, and this might be a little bit offtopic: I have no experience with the Find method, as you describe it, I take it that you use it somehow to recognize changes in the application?
thanks for explanation on the Find method...
You say you have used it (although not usable because it was unusably slow), to find changes in the GUI, but what if (for example) a control was removed from a particular screen in the UI? If you use the find method you fail to find it, but would that give you enough safety that the control was indeed moved? Or maybe the find method has not been given enough time to search for the control?
Do you see what I mean?
mgroen2 wrote:thanks for explanation on the Find method...
You say you have used it (although not usable because it was unusably slow), to find changes in the GUI, but what if (for example) a control was removed from a particular screen in the UI? If you use the find method you fail to find it, but would that give you enough safety that the control was indeed moved? Or maybe the find method has not been given enough time to search for the control?
Do you see what I mean?
mgroen2 The Find method would tell you if the control is no longer on the page (by testing the Exists method of the stub object returned) and any test steps which reference the control would need to be removed (after root cause analysis) to determine if, in fact, it should have been removed. Communication is VERY poor among our team and I seldom get advanced notice of such things. There are half a dozen places where we've use Extended Find when the control is located in differing places within the hierarchy based on external conditions.
