Jira Testing

[Ky M]

Hi.

May I ask how should we use test cases?

Should we try our best to reuse the test cases, or should we "tailored-made" for each of the Jira tickets?

Thanks.

[Tomislav Tobijas · Accepted solution]

Hi @Ky M ,

I feel like a bit of context is missing here. For example, what exactly are you testing? Is it your product, CR development, platform migration or something completely else?

I can't say if there are any best practices when it comes to that, but as with everything, it would probably be a good idea to try to reuse what you already have.

When it comes to test cases in particular, it also depends if you're using Marketplace solutions for that, or if you've built something via native features (such as specific issue types or Assets objects).

Cheers,
Tom

[Ky M]

I would like to use test cases for Jira tickets. For example, when I have an update on a button in an application, I have to test whether the function of it works as expected. 

I would like to make a Jira ticket of type "Test", so I can provide a detailed procedure for my teammates to test. However, based on what I know, we have to build a release in Jira, then in the "Test" page, create a cycle beneath the release.   

I would like to ask whether it will be a good practice to reuse the test cases more, or it will be better if we tailored made every test cases.

Thanks

[Tomislav Tobijas]

Ah, I see you're using Zephyr product from SmartBear. To be honest, I've never dug too deep when it comes to test cases with those apps, although I know some of our clients use Zephyr Scale for example.

From my experience, it depends on the things you need to test - for example, if you have a specific product where in each hardware/software version you would need to test the same things (+ additional features that came with the newest version), you would probably make test cases that can be reused.

On the other hand, some test cases will require to be 'mapped' 1-on-1 to Jira issues if these issues/items are quite specific.

When I think about it, I've seen cases/sites where in 1 Jira project, test cases (TCs) are mapped 1-to-1 on Jira issues, and in another project, users would reuse TCs as much as possible.

[Andy Barbet]

Hi @Ky M 

I'm guessing you're using Zephyr Squad.  I'm familiar with the Scale version but not Squad.  Smartbear has user communities which are better for these types of questions as you'll get answers from users of the product.  I've added some links below that should help, and one for The Scale community in case you are a user of that - in which case, I'll see you in that forum!

Category: Zephyr Squad | SmartBear Community

Academy | SmartBear Software <--- this is the Squad 'Basics' training course

Category: Zephyr Scale | SmartBear Community

[Ky M]

Great! Thanks you all a lot!!

[Nick Iles _AssertThat_]

Whatever tool you are using don’t overthink it — most teams end up doing a bit of both, and that’s usually the best place to land.

If it’s core functionality that you expect to behave the same release after release, it’s worth reusing test cases. Things like regression checks, business rules, or anything that would are good candidates.

For changes/new functionality, tailoring tests to the Jira issue often makes more sense. When you’re changing a button, adding a new flow, or tweaking behaviour, writing a test that directly reflects the acceptance criteria is usually clearer for whoever is testing it. Some of those tests won’t be useful beyond that release and that’s completely fine.

One thing that helps regardless is using good descriptive test titles. If someone can understand what a test is covering just by reading the name, without opening the steps, it saves time and avoids confusion for everyone.

Start with tests that make sense for the change in front of you. If a test proves useful again later, promote it into your reusable set. If not, let it go. Test cases should help the team ship with confidence, not become something you maintain for the sake of it.

[Nick Iles _AssertThat_]

Whatever tool you are using don’t overthink it — most teams end up doing a bit of both, and that’s usually the best place to land.

If it’s core functionality that you expect to behave the same release after release, it’s worth reusing test cases. Things like regression checks, business rules, or anything that would are good candidates.

For changes/new functionalty, tailoring tests to the Jira issue often makes more sense. When you’re changing a button, adding a new flow, or tweaking behaviour, writing a test that directly reflects the acceptance criteria is usually clearer for whoever is testing it. Some of those tests won’t be useful beyond that release and that’s completely fine.

One thing that helps regardless is using good descriptive test titles. If someone can understand what a test is covering just by reading the name, without opening the steps, it saves time and avoids confusion for everyone.

Start with tests that make sense for the change in front of you. If a test proves useful again later, promote it into your reusable set. If not, let it go. Test cases should help the team ship with confidence, not become something you maintain for the sake of it.

[Balázs Szakál]

Hey @Ky M ,

couldn't resist to offer a "Tailored-made" solution, from us (Beard & Tailor Studio :D).

Our app called BesTest, a lightweight Requirement & Test Management app for Jira cloud!

Knows basic stuff + trying to offer features that no one else! Feel free to contact me with any matters!

Cheers

[Bogumiła Jarosik]

@Ky M If you are looking for a tool to manage test processes then I recommend you to try a dedicated application for this, such as Requirements and Test Management 

[takahiro.a.tsuchiya]

This might be work fine if you want to manage test cases more efficiently.
Zephyr Scale - Test Management for Jira | Atlassian Marketplace