650983 - Results: Implement list of Test Results

Status: RESOLVED FIXED

(Mozilla QA Graveyard :: MozTrap, enhancement, P1)

Description

[Cameron Dawson [:camd]]

These are the "leaf" most objects in this hierarchy.  A given testrun
or testcycle can have the same test case executed multiple times for different
environments, or by different users, etc.  So these will be results of one test case

This list should be filterable with unified filtering interface
Paginated
Each line should show some summary data without expanding, such as:
- result status
- whether the result is approved or not

Expansion shows:

When expanded, it should show:
- team member
- environment values

Comment 1

[Carl Meyer (:carljm)]

I think seeing the environment values for all the results is pretty critical to making this screen comprehensible, so that needs to go in the unexpanded summary.

Comment 2

[Cameron Dawson [:camd]]

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

Comment 3

[Cameron Dawson [:camd]]

Eric Meyer changed story state to started in Pivotal Tracker

Comment 4

[Cameron Dawson [:camd]]

Carl Meyer added a comment in Pivotal Tracker:   
   
A few couple notes on this page (I've gone ahead and deployed it to staging as-is, even though Eric hasn't done cleanup on it yet, so Cam can weigh in here too):

1. Eric, the list of steps for the test case in the page header needs to be split into "action" and "expected result" for each step. Right now I just have it split with a dash, but I think the distinction should be in the markup and visually clearer. I have a @@@ marker in the template for this.

2. In the main list of results, I think the environment variables should appear in the summary row, not the detail expansion. In this list the environment variables are the primary meaningful thing that distinguishes one row from another. This may cause issues if we have large numbers of environments in a group, but we'll just have to cross that bridge when we come it it (something with hover?). This also means in the expansion we can get rid of the not-very-useful "notes" header, since "notes" is all that will be in the expansion.

Comment 5

[Cameron Dawson [:camd]]

Carl Meyer added a comment in Pivotal Tracker:   
   
Eric: there's also some inconsistencies around class names for passed/failed/invalidated that's causing problems. I need to have a single consistent class name that I can use in various places for a given state. I adjusted to your use of "pass/fail" rather than "passed/failed" on this screen, but if I use "invalid" as my standard class instead of "invalidated" (which is what your code wants on this screen), it breaks layout on the runtests page. Currently I have this screen working, and the runtests page is broken. Ping me and we can talk about what we want to standardize on.

Comment 6

[Cameron Dawson [:camd]]

Carl Meyer added a comment in Pivotal Tracker:   
   
Oh, and any results in "started" state on this screen, the result status appears with no styling. Since we display started results lumped in with pending on the summaries, it'd probably make most sense if you just style "started" the same as "pending".

Comment 7

[Cameron Dawson [:camd]]

Eric Meyer added a comment in Pivotal Tracker:   
   
#2 needs a better solution. I see the problem, but I don't think either hover or punting is a good solution. If we want environments in the summary, we need a way to summarize environments. I'll think on that.

I don't understand you concern about class names at all. Those various names are used all over the place - several times on each item in every list we have on the site. you will have to give me more detail on what you mean. We can chat about it on Monday.

I thought we had decided on a phone call that "started" would not be a state of it's own. Has that changed?

Comment 8

[Cameron Dawson [:camd]]

Carl Meyer added a comment in Pivotal Tracker:   
   
Re environments in summary, keep in mind that for results its just a single list (i.e. "Chrome, English, Linux"), not a list of lists like for every other object type. So it's possible that single list could get long, and we should definitely think about how to handle it if it does, but it currently wouldn't be a problem for any of the data we have. (Maybe you already had this in mind, just making sure).

Re class names, the issue for consistency is dynamically displaying a class name for the status of an individual object in a list. When we display result summaries, the classes for those are coded directly into our template for result summaries, so that's different (though it'd probably be least confusing if we had consistency across the board). This is the first list where passed/failed are statuses for individual objects. Yes, let's figure it out tomorrow.

Re "started", it is its own state regardless, the question is just how we display it. For result summaries, we decided that it wasn't worth a separate chiclet for splitting those out in the summary. For displaying individual result rows, I don't see any reason for us to actively hide from the user the known fact that a given single result was "started" (unlike in the summary case, displaying the text "started" instead of the text "pending" for a single result doesn't take up any additional room or otherwise complexify the layout). My suggestion is that we display the text "started" instead of "pending" but use the same icon/color as for pending. This implies that they are similar states (and is a nod towards the fact that they are combined in the results summaries), but still makes the information we have available.

Comment 9

[Cameron Dawson [:camd]]

Carl Meyer changed story state to finished in Pivotal Tracker

Comment 10

[Cameron Dawson [:camd]]

Carl Meyer changed story state to delivered in Pivotal Tracker

Comment 11

[Cameron Dawson [:camd]]

Cameron Dawson changed story state to accepted in Pivotal Tracker