These forums are a place for learning, helping and sharing experiences with others about any of our products. Feel free to ask a question and get answers from our community and our most advanced users.
Note that these are public forums - anyone can view the discussions here.
VISIT OUR DIFFERENT FORUMS:
Announcements > | |
CloudShell > | TestShell > |
Developers > | BI (Business Inteligence) > |
This is where you can suggest your ideas to help and improve the product for everyone.
Please make sure to read the following article before posting a new idea, to get more information about the required information and ideas lifecycle.
Feel free to vote and comment on other ideas to promote them.
Thanks for everyone who suggested the ideas and voted for them.
Find, download and share integrations that can extend and enhance the CloudShell experience.
Integrations have several levels:
Certified - Officially tested and supported by Quali.
Preview - Provides a sneak peek to what the Quali team is developing. Officially supported by Quali. Feel free to experiment and comment, but please take into consideration that it is not yet tested and released.
Community - Integrations shared by community users. Feel free to look into what other users have contributed, please take into consideration that these integrations are not tested by Quali.
To learn more about creating Shells and integrating with CloudShell, use the following links:
CloudShell's Dev Guide > | Configuration Management > |
Getting started with Shells > | Extending CloudShell with Cloud Providers > |
Getting started with Orchestration > | API Guide > |
To share your integration, follow the instructions in this guide >.
Ben Linford suggested an idea (#2358) · Dec 12, 2017 at 11:59 PM · testshell
The current TestShell Refactoring cache file is a composite of local content and DB content
It's located under C:\Users\user\AppData\Local\QualiSystems and is called refactoringCache.dat
This works well in theory, but there are downsides to it.
After an upgrade or patch, all users will need to update their refactoring file which puts additional stress on the system. The larger the userbase, the higher the impact on the server and DB.
Additionally, if terminal servers are used to host the clients i.e. Windows 2012, then the server has higher impact due to multiple users all refactoring at once.
My proposal is to separate the refactoring file into 2 parts: 1. for local and 1 for the DB
At login (via a scheduled task) or manual script execution post an upgrade/patch or other impacting event and before users login to TestShell Studio, an already updated DB refactoring data file could be copied into the user's local windows folder to overwrite the DB refactoring file, thus greatly reducing overheads and the time required to refactor after the change to the system.
This could also be an option after a long time of no use or at 1st time using TestShell on a different machine i.e. where users can migrate between various Client VMs based on system load.
This capability to re-use an updated refactoring cache file has been proven to great effect in our environment (better to use a user with no local content to perform the 1st refactoring after the update).
Alona Getzler commented · Feb 12, 2018 at 07:31 AM
Hi, thank you for posting this idea. I checked your suggestion with engineering and it seems like this approach isn't feasible as there are dependencies between local and shared tests.
Anyway, investing in this area is currently not in our roadmap. If anyone thinks we should reconsider, please vote for this idea. Thank you.
These forums are a place for learning, helping and sharing experiences with others about any of our products. Feel free to ask a question and get answers from our community and our most advanced users.
Note that these are public forums - anyone can view the discussions here.
Announcements | |
CloudShell | TestShell |
Developers | BI (Business Inteligence) |
This is where you can suggest your ideas to help and improve the product for everyone.
Please make sure to read the following article before posting a new idea, to get more information about the required information and ideas lifecycle.
Feel free to vote and comment on other ideas to promote them.
Thanks for everyone who suggested the ideas and voted for them.
Find, download and share integrations that can extend and enhance the CloudShell experience.
Integrations have several levels:
Certified - Officially tested and supported by Quali.
Preview - Provides a sneak peek to what the Quali team is developing. Officially supported by Quali. Feel free to experiment and comment, but please take into consideration that it is not yet tested and released.
Community - Integrations shared by community users. Feel free to look into what other users have contributed, please take into consideration that these integrations are not tested by Quali.
To learn more about creating Shells and integrating with CloudShell, use the following links:
CloudShell's Dev Guide | Configuration Management |
Getting started with Shells | Extending CloudShell with Cloud Providers |
Getting started with Orchestration | API Guide |
To share your integration, follow the instructions in this guide.
Help us make things better. Share your great idea or vote for other people's.
Beeing able to create Structure like C/C++ in TestShellStudio
Retrieve the output of a REST Client request if the response was 4xx or 5xx
Silent/Batch installation of CloudShell client applications
Attachement in Quali report is not accessible outside the machine of where Quali runs.
Add “Failure Handling” feature
Using a function ( or a test) in the terminal module in Testshell Studio
Add a “SOAP Client” library to TestShell Studio
Copy TestShell Studio modules into CloudShell Authoring
Expanding the upper limit of the number of characters in TextToReport