654794 - a user should be able to apply tags to test cases

Status: RESOLVED FIXED

(Mozilla QA Graveyard :: MozTrap, enhancement)

Description

[Cameron Dawson [:camd]]

these should be arbitrary text.  Though perhaps when a user wants to add a tag, it will provide a list of already-existing tags to choose from to mitigate spelling/capitalization discrepancies.

Comment 1

[Cameron Dawson [:camd]]

or do Test Suites cover this?  A test case can belong to several suites, so that is kind of like applying a tag to it.  Depends on the workflow.

Comment 2

[Cameron Dawson [:camd]]

A Pivotal Tracker story has been created for this Bug: http://www.pivotaltracker.com/story/show/13298801

Comment 3

[Cameron Dawson [:camd]]

Cameron Dawson added a comment in Pivotal Tracker:   
   
This will need a tag management interface of some kind.  
Test: user wants to merge two tags
Test: user wants to create a new tag
Test: user wants to delete a tag
Test: user wants to add all the cases with a tag to an existing test suite

Comment 4

[Cameron Dawson [:camd]]

Cameron Dawson changed story state to unstarted in Pivotal Tracker

Comment 5

[Cameron Dawson [:camd]]

Cameron Dawson changed story state to started in Pivotal Tracker

Comment 6

[Cameron Dawson [:camd]]

Carl Meyer added a comment in Pivotal Tracker:   
   
Eric and I were just looking at this story, and from our end it would be helpful to break it up into smaller stories. This story should just cover adding tags to a test case, with tokenizing autocomplete to avoid typos.

Cam, here are the additional stories I think should be added to cover other things you've listed:

1. Management UI for creating, deleting, and editing tags. (Much like other existing management UI pages we have).

2. A "merge tags" bulk action on that management screen. I'll need to dig in and see if this is really feasible given the platform API. Also it'll require adding a bulk action to a management page for the first time, which means some UI adjustments.

3. Implementing filtering-by-tag on the test cases management screen.

4. Ability to bulk-add filtered test cases to a suite. (I think this would already be covered by what we had envisioned for https://www.pivotaltracker.com/story/show/12968421, though that's currently prioritized fairly low on the list).

Comment 7

[Cameron Dawson [:camd]]

Eric Meyer added a comment in Pivotal Tracker:   
   
How do we want to handle tagging on bulk test-case creation? same tokenized approach, with tags added to all cases? add a tagging syntax?

also, I have some ideas on how we might do #2 without a standard 'bulk actions' approach. Still requires some new UI, but may not be as invasive.

Comment 8

[Cameron Dawson [:camd]]

Cameron Dawson added a comment in Pivotal Tracker:   
   
eric: I think to keep it simple at this point, for bulk creation, presume that tags you specify there apply to all the test cases.  So, add a separate field for "Tags"

Comment 9

[Cameron Dawson [:camd]]

Cameron Dawson added a comment in Pivotal Tracker:   
   
eric: to be honest, I kind of like the way we add tags to tracker stories.  It's similar enough to our filtering UI, too.  would that work for us?

Comment 10

[Cameron Dawson [:camd]]

Cameron Dawson added a comment in Pivotal Tracker:   
   
carl: for #4, I think this story for suites should have been higher priority (Matt E called me out on this).  Would you prefer this broken into separate stories?

Comment 11

[Cameron Dawson [:camd]]

Cameron Dawson added a comment in Pivotal Tracker:   
   
ok, this story is now only #1 from Carl's comment above.

Comment 13

[Cameron Dawson [:camd]]

Cameron Dawson added a comment in Pivotal Tracker:   
   
changed my mind.  This story is now only about APPLYING tags to test case.  A new story is about CRUD operations for tags.

Comment 14

[Cameron Dawson [:camd]]

Jonny Gerig Meyer added a comment in Pivotal Tracker:   
   
the JS is mocked in. it looks like i'm passing this to Cam for approval before Carl implements the back-end? In that case, just remember that you're seeing fake data, so the autocomplete suggestions look a little funny. :-)

Comment 15

[Cameron Dawson [:camd]]

Carl Meyer added a comment in Pivotal Tracker:   
   
I pushed this to cc-dev.oddsites.net. Note that the autocomplete mockup only works on the case edit page currently, not on the case add page.

Comment 16

[Cameron Dawson [:camd]]

Cameron Dawson added a comment in Pivotal Tracker:   
   
this looks so cool, I swallowed my gum.  Can't wait!  :)

Comment 17

[Cameron Dawson [:camd]]

Carl Meyer added a comment in Pivotal Tracker:   
   
Note to eric and jonny - make new features less cool. We don't want Cam's health to suffer from excessive gum-swallowing ;-)

Comment 18

[Cameron Dawson [:camd]]

Jonny Gerig Meyer added a comment in Pivotal Tracker:   
   
JS is mocked on both pages now (testcase editing and creation), but I've discovered another problem. Eric, you're using the same _tagging.html template for both single and bulk testcase creation, which means we have duplicate element IDs on the testcase creation page (because both single and bulk templates are used on that page). I'm passing this to you to fix that, then pass it back so I can make any necessary adjustments to the JS.

Comment 19

[Cameron Dawson [:camd]]

Jonny Gerig Meyer added a comment in Pivotal Tracker:   
   
Eric: I made one more change to your HTML to avoid duplicate IDs (the input textbox for tags). Also, I specifically wrote the JS so that the single and bulk forms are independent of one another, and I like that approach better. We can talk more if you feel strongly that the tags should be "remembered" from one form to the other.

Comment 20

[Cameron Dawson [:camd]]

Eric Meyer added a comment in Pivotal Tracker:   
   
I had assumed everything transferred between the two forms. I thought that had been requested. I don't have strong feelings.

Comment 21

[Cameron Dawson [:camd]]

Cameron Dawson added a comment in Pivotal Tracker:   
   
I think what's analogous between bulk and single should be moved over if the user switches between them.  I think the user would expect not to have to re-enter the data.

Comment 22

[Cameron Dawson [:camd]]

Carl Meyer added a comment in Pivotal Tracker:   
   
jonny: on stories like this, when you do the JS before I do my part, it's really helpful if you can comment on the story with exactly what your JS is expecting from me. For instance on this story I had to spend a little while digging through your JS and ICH templates in order to figure out what you were sending me for the autocomplete and what format you expected the suggestions to come back in.

Comment 23

[Cameron Dawson [:camd]]

Jonny Gerig Meyer added a comment in Pivotal Tracker:   
   
carl: understood, sorry. in this case it was identical to some of the other autocomplete stuff we've done, but i'll clarify in the future. also, just so you know, from now on (and including this case) whenever i have some ajax mocked, you can always check ajax_setup.js to see what response i'm expecting from the server.

Comment 24

[Cameron Dawson [:camd]]

Carl Meyer changed story state to finished in Pivotal Tracker

Comment 25

[Cameron Dawson [:camd]]

Carl Meyer changed story state to delivered in Pivotal Tracker

Comment 26

[Cameron Dawson [:camd]]

Cameron Dawson changed story state to accepted in Pivotal Tracker