Hi Sonya, Felipe,
Nice interview, and nice to put some faces to names! 😊
To answer the question you set, Felipe's favourite feature is regarding the recent update to SmartBear's seamless integration of the Jira issue model into Zephyr Scale. As for my favourite feature, there are quite a few that I could choose from but in my role of managing groups of testers, I often spend a lot of time in the Cycle homepage - it's a great place to get an overview of progress being made. I often use the Cycle page as a dashboard and send screen prints to my stakeholders as a quick and easy way of reporting. Plus from the Cycle page you can easily jump into Issues, the Test Player, or get more detail about the overall test execution statuses.
Keep up the good work!
Thanks, Andy
Hey MisterB thanks for the feedback, really valuable!
As a developer, I can't provide any guarantees, but I hope we can get to work soon on the page where you can see an overview of a single Test Cycle.
Would you mind sharing some ideas about this page for missing things or for improvements to the existing ones?
Thanks for sharing, have a nice week 🙂
Hi felipe-munhoz,
Sure, I'd be happy to share some thoughts. When you say, view details on a single Test Cycle, do you mean the pages with tabs for Details, Test Cases, Traceability, etc.?
Thanks, Andy
Hi,
Yes MisterB, that was the page I understood you're referencing in your first comment. Or it was another one?
I will add a screenshot for the page I'm considering:
Hi felipe-munhoz,
I was referring to the page before that, where you can view multiple Test Cycles and filter by different options. But I also use the single Test Cycle pages of course and if that is being developed further, I think what I would find useful is some sort of 'health monitor' area, where we could view potential issues and gaps and pro-actively identify and resolve those issues. I guess this doesn't have to be in the single Cycle page and could be at a higher level or in a report. For example:
- Test execution results that are marked as Blocked or Fail but do not have a linked Issue. These are generally where a tester has forgotten to follow up and create an issue for the block/fail
- Where a Planned Start Date is in the past and the Cycle Status is currently Not Executed, show an alert/flag. Clearly we would be behind plan and need to do something to get back on-plan
- Similar would be Test Cycles that are approaching the Planned End Date and test cases are not yet executed. It would be useful to see some information specific to the Not Executed gap as we approach the Planned End Date.
- And in the same way as above, if the Planned End Date is in the past and there are Test Cases that are Not Executed, flagging these would show where we need to focus effort.
Another suggestion, but not related to the 'health monitor' idea, is for when a Test Cycle has Blocks. For example, when all Test Cases in a Test Cycle are executed but some of them are Blocked. What happens at the moment is that Zephyr Scale automatically sets the status of that Test Cycle to Done. I find this misleading because the Blocked Test Cases still need to be executed and they may Pass or may Fail. I prefer to see the Test Cycle Status remain as either "In Progress" (may be easier to develop), or better still and more accurately, set the Test Cycle Status to "Blocked", meaning that the Test Cycle cannot be closed (have a status of "Done") until the Block is released and the Test Cases are available to be executed.
Also, having some fields in the Test Cycle Detail tab to record and manage the Block status would be useful. Why a Test Cycle is Blocked and who is responsible for unblocking a Test Cycle is the type of information that is useful for managing the problem and can be show on reports to stakeholders. I personally used the Test Cycle Description field as a workaround for this purpose, using the naming format below partly to report to my stakeholders, but more importantly, to help highlight issues and drive actions to unblock those issues:
[Date of update] [Block update comments] [Owner of actions to release Block]
e.g. 27-May: Testing blocked due to xyz in system abc. MisterB to do 123 to fix. Expected unblock 29-May
So fields that would be useful are Update Date, Block Cause, Block Action/Solution, Block Owner, Unblock Date, and Block Status (Under Analysis, In Progress, Pending, etc.)
I could probably come up with some more ideas if this is useful?
Thanks, Andy
