We're starting the automation of a very large testing effort, and Iím trying to gain a consensus on whether Robot VPs should be used or avoided.
After some searching in this forum, I've found comments indicating that Robot VPs come with a cost of reduced flexibility and robustness. On the other side of the coin is apparent simplicity of Robot VPs, which has some appeal when most of the QA team has excellent testing skills and knowledge of the AUT, but little or no development background. Perhaps even a hybrid of the two is best?
What I'd like to do, if this topic isn't deleted for reason of format or duplication, is solicit as much feedback as possible, based on peoples' direct experiences. Iíd be happy to summarize and post the results if it would be of benefit to anyone.
Someday down the road, we'll have an enormous number of VPs, Robot or not, and we have to balance ease of script creation, maintained and robustness.
Yes VPs are a little inflexible. They are not of much use if the input data (and hence the expected output) varies from one run of the escript to another. At times a better option is to use SQAGetProperty instructions and do string comparisons in code.
When not possible, use the VPs just to get hold of the runtime output data. Then open the .grd files containing the VP base / runtime data using regular file handling instructions and do string comparisons then.
I have been using Robot for quite sometime. Got a chance to automate projects that required to check the values at run time. but VP's could not be used as the values change every min. other places were where a where a tree would be created, no use of VP as again I had the option to add and delete the values in tree.
my 1st project 10% of the verifications were done using the VP option, but other 90% in the project was with SQAgetproperties and all those commands, and so was for all the projects that followed.
I feel one should not use VP and take care of the same using SQAgetproperties e.t.c