Ability to customize report summary page to include Company Branding / Logo
A good to have feature would be if the Log report summary can include a logo of your respective company. Branding is important to many organizations and we see this as an advantage when the PDF can be shared with a specific logo.Azure DevOps Advanced Integration Options
Azure DevOps seems to be a popular option these days. Please consider adding the following as a feature in the near future. 1. Post Bugs from Test complete to Azure DevOps 2. Post Work Item from TestComplete to Azure DevOps 3. Upload Test Plan from TestComplete to ADO.
Rename Log Items
Hi there, we have a scenario where a single script decides which tests run and then runs the tests. This causes all logs to have the same name: Script Test Log [ScriptUnit\scriptName] It would be great if this script could rename the log items. More information: http://community.smartbear.com/t5/Getting-Started-with/Rename-test-logs/m-p/116832 Greetings, vatLog location
Log files can take up lots of space on a HDD You have the option to limit the number of log files kept, but this is not always the answer you are looking for The logs could be stored in another location possibly a network location which will save resources on the local computer (would store locally if location not available - drive offline)Sharing test results - Extended Time
While the new sharing results options are quite handy, for an enterprise scenario the 2-week window is too less. An option for unlimited time would be needed. Please consider increasing the time limit duration. Also, the share option saves company information in the Smartbear server. We need an option that will save the log locally without the smartbear URL.
Include Screenshot in the summary log report as an evidence report
Good to Include Screenshot in the summary log report as an evidence report This helps the readability of the execution It can be extracted and share the results to the manual team It acts a TC document which can be used an KT document for the new joiners It acts as a proof for raising a bugincase of failureLimit Amount of Logs Kept by Time Frame
Instead of limiting the number of logs kept by Test Complete by a count, it would be nice if it they could be limited by a time period. For example, keep the last Month of test logs. This would be useful for users who run a high volume of tests in a short amount of time, but would still like to keep their output logs under control and accessible.Add the ability to automatically save the width and height of blocks in the log viewer.
When I check logs, I always have to: enlarge the block with the screenshot to immediately see which elements are in action expand the test case tree on the left to see which test case we are checking at the moment. I suppose that other users also suffer from such inconveniences, and maybe they have other wishes to view the logs. That's why I think it should be possible to adjust the display once and keep it. So that you don't have to change the display of the log window every time you run test cases.TestComplete and Zephyr Enterprise
Hi everyone, This post in mainly for those of you already using both TestComplete and Zephyr Enterprise, or looking into integrating one with the other via the zbot. I'll try to make this discussion have as little gaps in thought as possible, such that I'm not working off of the assumption that everyone is familiar with how the integration works. To begin with, Zephyr Enterprise (ZE) can trigger TestComplete (TC) tests by triggering command line arguments using the zbot (the secure job agent and results parser). The zbot sits on the target location, and when commanded (by ZE) will find the described invocation script path, and use the directed batch file or shell script to launch the automated tests (in our case, the TC tests). It then waits for the execution completion, and looks into another predefined directory for the results file generated by these TC tests in a junit xml format. Attached is what the configuration looks like from the ZE side: Within the dropdown panel that describes the automation framework (where we have selected TestComplete) what this really describes is the junit xml file parser template that the zbot will use to go through our results file to upload our automated TC test results back to ZE. (https://zephyrdocs.atlassian.net/wiki/spaces/ZE/pages/1558445554/Parser+Templates) This means that the zbot will look for certain tags and elements within our junit xml file generated by TestComplete to upload the results back to our test management solution. Typically, a junit xml file generated by TestComplete looks like this: Given the tags, this means that we cannot upload additional information such as attachment files since there is no tags that describe the file location that the supporting docs may reside (i.e the mht files). Now if we wanted to, we could go back in and edit these junit xml files and rerun the tests such that the zbot parses our results (https://zephyrdocs.atlassian.net/wiki/spaces/ZE/pages/1558445158/Vortex+Job+Execution+Events) but that would defeat the purpose of being able to launch our automated TC tests, no? So what we can do is write an additional script, where we have our favorite language of choice run through our junit xml files such that it appends that information for us automatically. This is by no means the right way to do this, just one of the ways! Couple of ways to improve this would be to refactor this script such that it can take additional inputs such as file location (hard coded for now) and also make the attachment subelement recursive so that we can add in multiple attachments. But for now this will do... Now that we have our script that will modify our junit xml results file for us, all we need to do is append a line to our original batch file that triggers our TC job, such that it modifies the generated xml file for us! So the batch file would something like this: where the highlighted portion is just an additional call to the script we wrote above. As you can see the format is familiar for those who have been using command line arguments for TC <TC executable location> <TC pjs. file you want to run> <any additional arugments i.e /r /p /ExportSummary to generate the xml file> <call to our python exe. to run our script> <our python script to append to our xml file> <xml file location ^^> Now our original xml file has been modified to look like this: So now whenever we trigger our TC jobs from within ZE, it will not only carry over the traditional default info such as test case name, run time, failure messages, and execution status, but also the supporting attachment files that we want! More curious users may want to browse our ZE docs to learn how to map it to existing requirements, or add in further information (https://zephyrdocs.atlassian.net/wiki/spaces/ZE/pages/1558445158/Vortex+Job+Execution+Events) On an additional note, we really only went over one portion of the automation integration when it comes to TC and ZE, but we can modify the steps used within this post to apply to the jobs we are running within our CI frameworks as well by adding in an additional build step that will perform the same type of junit xml results file modification we see here. -------------------- How is everyone else utilizing TC with ZE? What additional information do you think could be useful in terms of test management when it comes to your automation jobs? Having supporting attachments, and maybe even automatic code/test coverage is something that can be created with this method, but I'm curious to see what you think could be helpful. Anyhow, I hope everyone is staying safe and sane!
