GBiB Testing

This page is mainly for the QA team. For a more general overview of the GBiB release process, see Gbib release.

Testing During the Final Build week

All QAers do normal CGI testing on hgwbeta (in IE on winqa).

Official GBiB Tester

1. Official GBiB tester downloads gbibbeta.zip.
2. Tests his/her CGIs & tickets on GBiB.
3. Keeps Virtual Box updated (to ensure continued compatibility).
4. Tests hgMirror by downloading a track and ensuring it works.
   1. You may be interested in Max's hgc clicks per track plot when picking popular tracks to Mirror

• • NOTE: In a Mac OSX, to fix free memory you may have to occasionally restart while holding "command-R" (repair), then click "repair disk" on your selected HD.

All Other QAers

All other QAers test everything that they tested on hgwbeta (CGIs & tickets) on the GBiB beta VM so they don't have to wait for the download (see tunneling into hgwdev for more info on accessing the GBiB beta VM).

1. GBiB testing can be in any web browser.
2. Additionally, the hgTracks tester will turn on GbibSlowNet and open hgTracks to just the defaults, click into hgGene (report anything unusually slow).

Build Patches

1. Buildmeister rebuilds, including recreating gbibbeta.zip.
2. QA/buildmeister decide what needs, if anything, to be retested.
3. Buildmeister spawns a new GBiB beta VM on hgwdev of GBiB release candidate.

Release Day

1. No GBiB testing needs to be done on release day (as long as all goes to plan!)
2. As part of the post-release wrap-up, buildmeister requests a push of gbibbeta.zip to genome-store, which gets renamed to gbib.zip.

Urgent GBiB updates

• If we discover something really urgent, such as a critical security update, we can add things into released GBiB using the "push directory" (only rsyncable: mirror/data/gbib/push), which updates updateBrowser.sh. We don't expect to use it, but we can if there is something really urgent.

Genome-store

1. QA will test the functionality of the store itself only if there are changes to the store. In which case, a ticket would be created to track the change and would be assigned to a QAer for testing.
2. Official GBiB tester should check the first few releases to make sure gbib.zip made it to store.
3. In the future, we plan to create script (based on Steve's 2bitcompare) that compares the md5sum of the gbib.zip at the store to the gbibbeta.zip on Thurs or Fri after release to make sure the new GBiB file made it to the store.

Other

1. Brian Lee created a Selenium script that checks little things (like he has with Genome-euro). We hope this will detect small changes to the CGIs not captured in redmine that are fine on the hgwdev, hgwbeta and the RR, but break in GBiB.
2. Changes to GBiB only (vs. changes to CCIs and GBiB) will be tracked in redmines, then official GBiB QAer will address issues.
3. We don't think it is necessary to test GBiB on various OS because they are all running in a VM. Also, VB seems to use the same versioning for each operating system, so we don't think we need to worry about different VB versions on different OSs either.