Comment 7 for bug 1502816

We need some info from the HWE team, for:
* why the uefirtvariable test is a blocker but other uefi related test cases are not?

And as Jerry mentioned on the IRC:
<JerryKao> spineau, PHLin it is not a good idea to run the test twice, once it fails, QA will file duplicate bugs for one issue.

It's better to figure out how to not duplicate them.

* uefirtvariable test: if we're gonna keep it explicitly in the test plan, we can move the test from QA_TESTS list to NON_CERT list. So it won't be triggered in the fwts_desktop_diagnosis nor the fwts_desktop_diagnosis_hwe test. And yet it's still visible with "fwts_test --list" command, so it can be generated with the local job.

* wakealarm test: we do have it in the fwts_test script, but I don't know why we have it in the "--all" flag, I guess we accidentally left it behind:
   elif args.all:
        tests.extend(['wakealarm', 'cpufreq', 'maxfreq'] + TESTS)

As stated in comment #1, to make the local job work, it needs to be relocated into one of the list (QA_TEST / NON_CERT_TESTS / HWE_TESTS), otherwise it won't be generated at all.

In the power-management/fwts_wakealarm job, it looks like it won't check the fail status, unless it's aborted. We just run it and get the log (correct me if I was wrong about the "-f" flag).
fwts_test -f aborted -t wakealarm -l $PLAINBOX_SESSION_SHARE/fwts-wakealarm.log

If we're going to integrate the power-management/fwts_wakealarm and firmware/fwts_wakealarm and retain the blocker pass / fail status (which means that we will check the return value of this test), those jobs that depend on this wakealarm test might be skipped if this one fails.