Closed Bug 1457388 Opened 6 years ago Closed 6 years ago

Telemetry QA coverage for the GeckoView consumer application

Categories

(Toolkit :: Telemetry, enhancement, P3)

Unspecified
Android
enhancement

Tracking

()

RESOLVED FIXED
Tracking Status
firefox-esr52 --- wontfix
firefox-esr60 --- wontfix
firefox61 --- wontfix
firefox62 --- affected
firefox63 --- affected

People

(Reporter: Dexter, Assigned: cpeterson)

References

Details

(Whiteboard: [geckoview:klar:p2])

In bug 1454902 we'll validate how Telemetry behaves up to the GV API level. We might need to make sure to run a QA pass on the end application as well (Klar). Klar already seems to have a QA process/testplan in place: https://wiki.mozilla.org/QA/Fennec/Klar%2BGeckoView

This bug could just be about adding a few new test cases to that:

- Making sure that pings are correctly assembled;
- Making sure that pings are sent at the right time.
Anything else we should call out here?
Blocks: 1454902
Flags: needinfo?(gfritzsche)
Flags: needinfo?(fbertsch)
Priority: -- → P3
Maybe not all of the below needs to be in QA testing, but here are some thoughts.

Some light testing around some edge scenarios (or combinations thereof) seem interesting to me:
- app getting killed
- ping is triggered close to app launch (e.g. GeckoView not yet started / GeckoView just started / ...)

We should use (say) 1-5 important performance metrics, for which to confirm their values make sense in standard scenarios.
Flags: needinfo?(gfritzsche)
Also to consider for QA:
- upload limits on number of pings

Luckily this library has been in use for >1 year now, so most of the semantics around sending of pings are already pretty well vetted. Bug 1452166 could also be useful for QA.
Flags: needinfo?(fbertsch)
One thing that I noticed in review of the persistence layer is that we now have a longer period between app start and Telemetry being ready. Possibly testing for probes recorded early would be illuminating?
Adding whiteboard tag [geckoview:klar:p1] because Alessio says this bug should blocker Klar+GeckoView release. This bug is to make sure that Klar correctly sends the data out.
OS: Unspecified → Android
Whiteboard: [geckoview:klar:p1]
Blocks: 1452550
Emily or Alessio, is Klar+GeckoView telemetry now working end-to-end? Should I submit a PI Request asking QA to test Klar+GeckoView telemetry now?

Where is the Klar+GeckoView telemetry data available? Is it mixed in with the "Firefox Mobile" Product on telemetry.mozilla.org?
Flags: needinfo?(ekager)
Flags: needinfo?(alessio.placitelli)
(In reply to Chris Peterson [:cpeterson] from comment #6)
> Emily or Alessio, is Klar+GeckoView telemetry now working end-to-end? Should
> I submit a PI Request asking QA to test Klar+GeckoView telemetry now?
> 
> Where is the Klar+GeckoView telemetry data available? Is it mixed in with
> the "Firefox Mobile" Product on telemetry.mozilla.org?

That's more of an Emily question :)
Flags: needinfo?(alessio.placitelli)
Hey Chris, 
This should be working end-to-end now and we can test it! I believe we do use telemetry.mozilla.org (for example https://sql.telemetry.mozilla.org/dashboard/android-focus-vs-klar), but I don't think we have any GV specific queries up yet.
Flags: needinfo?(ekager)
Chris will follow up.
Assignee: nobody → cpeterson
This is an administrative bug that does not need to block Focus+GV.
Whiteboard: [geckoview:klar:p1] → [geckoview:klar:p2]
:dexter shared a Redash query to the mobile metrics dataset, so it appears the telemetry data is being reported as expected.

https://sql.telemetry.mozilla.org/queries/57750/source
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.