Absent Member.
Absent Member.
1875 views

Starting test cycle unassigns manual tests

Hello,

I am using a Project with approx 1400 test cases that have been assigned to a testing cycle and manually executed many times before. But about 1 week ago (01/19/2017) I created a new manual testing cycle in my project, assigned testers, and allocated tests to testers. I had 149 tests in this cycle, taken from different Containers, but when I "Start Testing Cycle" the # of Tests to Execute went from 149 to 50 and Silk timed out. I see that 99 of the tests aren't being recognized as "manual test cases assigned". When I try to move around the allocation of these tests Silk will time out, even if I only try to move one. I've restarted the host box and check that all licenses are up to date and nothing has changed on the host box. I am able to manually execute and move the manual tests that are recognized as assigned. I tried creating a new testing cycle, same problem. I noticed that the problem tests are isolated to certain Containers, but nothing in this Project has changed since I created it a year ago.

Does anyone have an idea as to this problem? Has something changed on Silk Cental's end? Has anyone run into this before? My teams workaround is to simply keep track of the tests they manually execute on a notepad or in excel, we are still able to view the content of the manual tests. But we cannot use Silk to mark our progress.

0 Likes
5 Replies

Hi,

please open a support case for this - as it seems to need more detailed analysis.

Thanks,

Florian

Product Owner - Silk
0 Likes
Cadet 2nd Class Cadet 2nd Class
Cadet 2nd Class

Hi ddanevich,

The problem you have encountered is with the silk central execution server. In "C:\Program Files(x86)\Silk\Silk Central <Version> Execution Server\conf\execserver" you need to edit the SccExecServerBootConf.xml where the ForceRestartAfterNtestCases tag is  to be set to 150.

<SilkTest>

<!-- Note: script mode delievers more detailed results but is more difficult to configure. -->

<!-- Default: false ... use plan mode -->

<DataDrivenScriptMode>false</DataDrivenScriptMode>

<!-- Default: 50 ... changed to 150 -->

<ForceRestartAfterNtestCases>150</ForceRestartAfterNtestCases>

</SilkTest>

Check if this solves your issue

0 Likes
Absent Member.
Absent Member.

saikiran40cs,

Thank you for taking the time to share this solution. Before trying it out can you tell me what this will fix, and if you know what the problem I'm having is? Sadly my technical skills aren't much better than an end user

Thanks

0 Likes
Cadet 2nd Class Cadet 2nd Class
Cadet 2nd Class

ddanevich,

This might solve the problem "# of Tests to Execute went from 149 to 50 and Silk timed out." Hence increasing the number of tests to run from 50 to 150. If this workaround does not solve your problem ,better raise a ticket with microfocus as they are very prompt in resolving issues.

Also a suggestion to you, whenever you are raising an issue please mention which version of the tool you are using, Operating system version etc... This will help also you to find whether it is a known issue or not.Smile

Cheers,

Sai Kiran.

Tags (1)
0 Likes
Absent Member.
Absent Member.

Hi,

This case has been handled via Support, if you have a similar incident when starting Manual Testing Cycles please reference case number 2887064 when logging an incident, and we will be able to provide further information.

The issue was caused by duplicate Test Step Properties, in the Tests Section.

Thanks,

Matt

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.