Add test suite to validate Reference kit provides a mechanism based on whole-disk encryption to store data in a secure manner.
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, I have a question, so based on this can we close this bug? because it has one test that covers this funct. I am going to check how this test works and reply with feedback.
(In reply to comment #2) > (In reply to comment #1) > > 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. > > I have a question, so based on this can we close this bug? Once it is merged, yes (IMHO). > because it has > one test that covers this funct. I am going to check how this test works and > reply with feedback. Thanks.
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.
(In reply to comment #3) > (In reply to comment #2) > > (In reply to comment #1) > > > 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. > > > > I have a question, so based on this can we close this bug? > > Once it is merged, yes (IMHO). > > > because it has > > one test that covers this funct. I am going to check how this test works and > > reply with feedback. > > Thanks. Hi Patrick, I am running this one in oe-selfetst $ oe-selftest -r image-installer.ImageInstaller.test_install_no_tpm I am planning to add one or two more for this implementation. I have a suggestion. As a good practice would be good to add decorators to the test cases, in order to have more control when raising bugs and with test reports.
(In reply to comment #5) > I have a suggestion. As a good practice would be good to add decorators to > the test cases, in order to have more control when raising bugs and with > test reports. I'm not familiar with OEQA decorators. Feel free to improve the existing tests by adding that.
I am going to close this bug due Trusted Platform Module (TPM), no TPM and fixed password are enough test scenarios for testing “disk encryption”.