From Tuesday 21st meeting exchange
RICH
I don't. We will be able to answer it positively. So that's was the first ish. The first point, the second one that the same team has raised is about being able to create defect. But at that step level.
Smartbear
What we've discussed in the past and I'll I'll reiterate this is that defect cannot be raised at a step level. However, when you raise the defect itself from zephy into JIRA via the zephy that there is an area, the description area where you can populate that description area with the steps to reproduce.
So that when the defect is is looked at in JIRA, you can see the respective.
Steps or actions that were undertaken to reach the point where the defect was necessary to be raised.
You can observe the detail of the steps. You can also observe the the execution status, but more importantly, you can observe the context of the test.
So that is the main reason why.
Defects are not raised at a specific step level.
You raise the defect at a test case level, thus providing the full end to end context of the entire test along with the points at which the failure occurred and defect was necessary. So I understand.
You know the kind of response to that that, you know, even that even though the team would like to raise it at a step level, but technically that's not possible and hopefully and hopefully now you understand the logic behind why.
We have not implemented that over the last few years.
RICH
you just a question?
Is it possible to open several defect on the same test?
Smartbear
So you can do two things. You can look at a test case failure and say, look, this relates to this bug and this bug and this bug. Link it to an existing ones.
Link it to an existing one or many, but you can also open new bugs and link them many to one as well.
And a mixture and a mixture. So you can have you can have two or three.
Existing bugs and then you can open more so you can do. Yeah, you can definitely have a many 21 relationship in this way.
RICH
K So yeah, from my understanding. So when you open the bug, you have a field and description field where you can.
Describe at which step the issue was raised in the test scenario is that that Milan OK, but is it? Yeah. Just to finish. Yeah. So it if it's done, is it possible in this description to to allow the user to reference a test tab of a kind of?
Smart link or something like that. Just to imagine you have a 100.
Manually that step 70 there was an issue.
How can you do it? It's it's complicate. So is there a way to to to have a smart link or a smarter writing tool to yeah to browse this this test in the description?
Smartbear
I understand in fact, because we use Zephyr for our own internal testing as well, that's the way I use it. So when when we when a bug needs to be raised for a test case and it may have, like you said, you know might might have 20 steps in there.
I go to copy to step to copy steps to reproduce. Then I decide is it plain text or is it wiki markup? But either case we automatically it's like copy and paste.
It pastes the steps into the description, but I don't stop there. I go back to that description area and I write a note at the top. I write a note to say you know, please Dev team as this is being evaluated in the queue. Please ask the aligned person to focus on step 20 or something like that or what I've done in.
The past as well is I'll go if it's not wiki markup you can go down to step 20 or whatever whatever step it is and just use a particular like symbol like I used asterisk the stars.
I used like few of those right at that on that line and everyone knows when I do that it means focus on that line. But yeah, you can write some text or you can just you can edit because that description area is editable so you can paste the steps into there but then you can go in and and make a change. Now with time yeah with time.
RICH
There you go. Yeah. So you can copy paste the description of the test tab to the description easily.
Smartbear
Exactly. Yes, it. That feature is called copy steps. So in the description box for the bug it says copy steps and copy steps will be in plain text or wiki markup, so that's that's good news with time and experience, even if you use Wiki markup then what you can do is go down to the markup for that step and just change it change.
A couple of things in the markup. So for example you can if you know how to make text read.
Then you can go down to the wiki markup where their line is line 20 and then you can make that text read so you know there's several.
Levels of maturity. You can have one is to write some text at the top of the description to say look, read below and focus on 22nd is to go down to line 20 and put a marker there with your keyboard. Third step is actually the change the markup so it becomes visible.
When you raise a defect under a particular step.
You're relying upon the judgement of the person raising the bug to choose the right step, but they may not be operationally aware or developmentally aware of of how.
The application is being hosted or being built, so the context really helps to know. OK this this person is tested thinks that it's related to this particular step because that's when the symptom occurred, but actually it's related to, you know, or I get an idea that this happened before then actually the problem isn't there. The problem is somewhere else.
You hopefully that that helps, but if you still feel that we need step level defects.
Then we respect that and we continue with pushing for that. If you feel that you need it.