Make TC capable of reading/writing test data out of online storage locations (like Google Drive)

https://developers.google.com/drive/v3/web/about-sdk

Help yourself.

They provide a RESTful API. nothing to stop you writing an extension to allow your stuff to use it. I already have something similar I wrote as an extension to allow my tests to update test suites on TFS using their RESTful API.

Only drawback is that I don't see JScript or VBScript listed as supported by them natively (Google Drive). So you'd probably have to do a full-fat plugin using the SDK, rather than a simpler (to create) Script Extension.

But it's doable as I type this ......

I would prefer if this would be supported by TC out-of-the-box (not having to write plugins) - as a test engineer I need to focus on QA/testing work, and don't have time to code plugins....

I get where you're coming from.

But there are many, many, services like this that I suspect people would like functionality out of the box for.

So which ones do they build functionality for? Strikes me more as a nice to have as it doesn't add anything much functionally to TestComplete itself. Just makes an easy interface for the small subset of people who happen to use Google Drive for storage.

And given that most of them provide the tools for people to tailor their own solutions, so it's not currently a dead end, I can't see it getting priority any time soon.

I'd rather have not had to write my own TFS plugin. But if it's that or nothing? And by writing a plugin you would be focusing on testing work as you'd use said plugin for testing purposes .... :smileywink:

I agree with Colin_McCrae.  I need TestComplete to work on things that I can't change, for instance the name mapping.  If I have a tool to do something myself another way, then I can take care of it.

Marsha_R I am guessing you are referring to the feature requests regarding namemapping.

In that sence, I agree with you. In my opinion feature requests regarding name mapping deserve higher priority than (for example) this one. No discussion about that.

However there are other things in a tester's world other than namemapping. We should keep a broad and openminded view as to how we can deliver good ideas to improve TestComplete. In my opinion this feature request forum should focus on spreading ideas and let it be a starting process for the voting / discussion on these requests. Of course some feature requests are not relevant for other users but please respect the idea to improve TC and be limited as posting your personal opinion if you don't "get the idea" of the specific feature request.

Keep in mind that all registered users can vote for feature requests, and in my opinion the best way to go forward is improve the system by seriously looking at the amount of votes (or 'kudo's') a feature requests has received. And that Smartbear focuses on the top-5 (for example) feature requests for every release. 

Sometimes multiple feature requests can be 'tackled' at once, when redesigning some functionality. So if Smartbear processes this 'feature request backlog' efficiently, the list could be handled efficienlty.

I get the idea of your requests.  I just don't agree with them.  

Marsha_R But what exactly is it that you don't agree with upon?

Could you please explain? Or, give an example?

1) Like I said before, I agree with Colin_McCrae in his point that we aren't ever going to get everything we need in TestComplete.  It's impossible.  If there's a workaround, then use it.

2) I don't agree that a Feature Request with many votes should automatically get worked on.  Looked at, yes, worked on, no.  

3) I don't agree with telling SmartBear how to focus on their priorities or that they are being inefficient.  They have given us a product that does a lot of work for a lot of people, and that is already a difficult task.  They have kindly given us several feedback systems already.  What they do with the information and how they do it is up to them.  

4) I don't agree that test engineers have boundaries on what tasks they perform.  If a keyword test won't do what I need, then I find another way around.  It could be a script, it could be a redesign of my test.  It's not SmartBear's responsibility to make my tests work.  I appreciate their help, but in the end, that's my responsibility. 

Marsha_R I see we look at things from a different perspective. That's ok. That's where discussion boards are all about :)

1) Of course we aren't ever going to need everything we need. But it's my opinion that SmartBear does/should do it's best to fullfill the clients most urgent needs. I mean, they want to maintain a base of happy clients, right?

To get a notion of most demanded feature requests I welcome the Feature requests report forum and the 'kudo-system'. It is my opinion that this system should be kept as open and as democratic as possible: most kudo-ed feature requests should get most priority by SmartBear team. Also, think of the ways SmartBear could make TestComplete 'stand out of the competition', by providing functionality which other (competitors) tools don't support.

2) Not automatically get worked on (some feature requests are just not realisticly possible and/or feasable with currently used technology. But I think the top xx (say, top 10), should be aligned with planned / future releases. And these plans should be communicated back to the forum users, so they know their kudo-voting hasn't been done for nothing, and also they know what to expect in future TC versions.

3) SmartBear is a commercial organization. They have ideed helped us a lot with a great product, so far. But, that's what their job is and they get paid for that. That's nothing special, all commercial systems work like that. SmartBear should be happy with the help the forum users provide by addressing the most common issues or improvements in the form of feature requests.

4) Completely true, but what is your point? It's not an issue I need to discuss. I think SmartBear should go for making TestComplete 'the best' product available by listening well to the input the forum users provide.