New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFC: Redefine what bug-tracker integration means #698

Open
atodorov opened this Issue Jan 7, 2019 · 5 comments

Comments

Projects
None yet
3 participants
@atodorov
Copy link
Member

atodorov commented Jan 7, 2019

Here are the currently open issues related to bug-tracker integration:

They are mostly beating around the bush and we'd like to hear all sorts of crazy ideas you may have. What does bug-tracker integration mean for you? What sort of features and workflows do you imagine a TCMS tool will have around reporting bugs.

Post your ideas in comments below or vote for existing comments. This is part of our mission to make Kiwi TCMS more useful to its community! Use 👍 reaction (top-right corner) to vote for ideas you find useful.

@okainov

This comment has been minimized.

Copy link
Contributor

okainov commented Jan 8, 2019

Also #320 is somehow related.

Most important:

  • Ability to put a bug ID and get a link to the bug. (#289) Simple as that. If this does not work - everything else is useless.
  • Not having unnecessary duplication (#320)
  • Getting bug details (#117), that's what we have implemented in our Kiwi fork we use in my team for both types of bug trackers we use. I.e. it will allow to have bug title as a tooltip or something like this which will definitely improve the whole UX.

Most useless (strongly IMHO):

  • Commenting on the existing bugs \ creating bugs from Kiwi UI. I don't see any reason to have this functionality at all in Kiwi, because you may never know the details about required fields for bug creation (i.e. in our JIRA we have ~5 custom mandatory fields). As for comment, it doesn't have any sense unless the team has strong and strict policy "no bugs without test case" which I see too much micromanagement.

Speaking of workflows, that's what we have in our team:

  1. Test execution. Every QA engineer has to link a bug in Kiwi if test case run status is "failed". One executes test case - sees the failure - goes to Jira and reports it - then links created bug id with Kiwi. Seems fine for us.
  2. Statistics & reports. We have additional statistics page on top of Kiwi which shows combined report across couple of products and builds with list of bugs on the bottom of the page. Thus it's important to have additional bugs details here (title, exposure, status; of course, there should be some kind of cron job to update it regularly, i.e. each hour) to make the report readable without going back and forth to bug trackers page. This page is mostly read-only, so it just displays the current data.
@Prome88

This comment has been minimized.

Copy link

Prome88 commented Jan 8, 2019

I strongly disagree with okainov. Creating bug directly from Kiwi to issue tracker is the most used function for us. It saves time for QA to retype bug report. I do agree that having custom fields in JIRA is pain in the butt and feel that Kiwi TCMS should offer this kind of customization (which data from Kiwi goes into which jira field) via control panel.

Second most important integration feature is to show links and number of bugs reported in one test run / build version.

And also having a history and links for previously reported bugs for each test case to avoid duplication of bug reports in bug tracker is a nifty feature.

@okainov

This comment has been minimized.

Copy link
Contributor

okainov commented Jan 8, 2019

It saves time for QA to retype bug report

Just wonder - what do you mean by "retype"? Do you require your QA to put "bug description" into comments field? In our team if QA guy meets a failure, he goes to Jira, creates bug there (typing all the details) and then just links the bug by ID to Kiwi.

@Prome88

This comment has been minimized.

Copy link

Prome88 commented Jan 9, 2019

Instead of manually typing our quite complex use case scenarios (along with prerequisites and expected results) which usually consist of 20+ actions all this data is transferred from Kiwi. Why would you manually insert bug from test run in Kiwi into JIRA if you can do that already directly from Kiwi?

@okainov

This comment has been minimized.

Copy link
Contributor

okainov commented Jan 9, 2019

our quite complex use case scenarios (along with prerequisites and expected results) which usually consist of 20+ actions all this data is transferred from Kiwi.

Thanks for sharing. Our test cases are rather simple (not more than 5 steps) and general (think of "install MyPython. Check MyPython is here and functional". Bug linked to this test could be "MyPython installation directory is wrong"), so there is usually no 1-1 relation between bug description and test steps. Test for us gives tester more like general guidance, but not exact details. And the bugs in 90% of the cases are related to the test case, not explicitly found by the test case.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment