We need two kinds of tests: a) enough tests to merge the feature and b) additional feature that can be added later as time permits (open ended).

We agreed to treat this QA work items as a), i.e. they block the feature completion.

I don't know how QA wants to track part b). Filing issues is not particularly useful because of the open scope.

At this point, https://github.com/intel/intel-iot-refkit/pull/97 has one test which covers this functionality, which I consider good enough to close this issue once the PR is merged.

(In reply to comment #1)
> We need two kinds of tests: a) enough tests to merge the feature and b)
> additional feature that can be added later as time permits (open ended).
> 
> We agreed to treat this QA work items as a), i.e. they block the feature
> completion.
> 
> I don't know how QA wants to track part b). Filing issues is not
> particularly useful because of the open scope.
> 
> At this point, https://github.com/intel/intel-iot-refkit/pull/97 has one
> test which covers this functionality, which I consider good enough to close
> this issue once the PR is merged.

Hi Patrick, 
This also can be closed once the patch got acceptance right?

After an agreement with the Refkit team, the progress on the minimal required sanity tests to release a feature will be tracked on the same bug issue used to track the feature's development. Analogous QA bugs like this one may be created if required, and will be used to track the development of more extensive test cases.

According to this, the dependence will be inverted in relation to the feature bug.

Test Cases implemented at: "~/meta-refkit/lib/oeqa/selftest/secureboot.py"