Project

General

Profile

Quality management » History » Version 8

Detlef Hühnlein, 10/22/2015 01:21 PM

1 1 Hans-Martin Haase
h1. Quality management
2
3 7 Detlef Hühnlein
The main aspects of the quality management within the Open eCard project are explained in "[NHHW15]":https://ecsec.de/pub/OID_2015_QMS.pdf.
4 1 Hans-Martin Haase
5 7 Detlef Hühnlein
The quality management consist of two big parts. The first part is covered by the [[Developer Guide]], which contains the rules regarding to the code quality, code style, etc. The second part is a description of test which ensure have to be completed before a new version of the Open eCard App is released.
6
7 1 Hans-Martin Haase
h2. Quality Assurance Process
8
9 7 Detlef Hühnlein
"[ISO 9000:2015]":https://www.iso.org/obp/ui/#iso:std:45481:en defines quality assurance as a "part of quality management [...] focused on providing confidence that quality requirements will be fulfilled." In this sense quality assurance is a process targeting the objective to guarantee that a product works as intended. This task is mostly done by specifying tests which may be automated or not. The Open eCard project uses a mixture of manual and automated tests in the form of Continuous Integration and acceptance tests where automation is not feasible.
10 1 Hans-Martin Haase
11
h3. Continuous Integration 
12
13
The Open eCard team uses Jenkins as tool for this task. The Jenkins server builds the complete project after a new version has been uploaded to the main Git repository after that all unit and integration tests available and enabled are performed. If an error occurs while this procedure the responsible release manager and if contact information are available the developers are informed. In the case that are all test successfully executed the release manger has to decide whether to accept or reject the changes.
14
15
h3. Acceptance Testing
16
17 7 Detlef Hühnlein
The main focus of the acceptance testing is the compliance to the technical guideline "BSI TR-03124 part 2":https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR03124/TR-03124-2.pdf?__blob=publicationFile and the practical usability with
18 1 Hans-Martin Haase
existing services, which accept the "supported cards":https://www.openecard.org/ecards/. 
19
20
Therefore the acceptance tests currently comprise the following areas:
21
# *eID-Client-Test-Suite*
22 7 Detlef Hühnlein
The conformance is tested with the latest available version of the official "test suite": issued by the BSI. This is a specialized test which ensures that the Open eCard App works as described in "BSI TR-03124 part 1":https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR03124/TR-03124-1.pdf?__blob=publicationFile. So it covers just the functionality of the German eID card but there are general parts, which are also usable for other cards like the directions regarding error messages, information to display on the UI e.g retry counters of a PIN, etc.
23 1 Hans-Martin Haase
# *Services which accept the German eID Card*
24 6 Detlef Hühnlein
An important requirement is that the Open eCard App works with existing services, which accept the German eID.
25 7 Detlef Hühnlein
# *Services which accept cards with X.509 certificates for TLS-Client-Authentication*
26
Finally the Open eCard App is meant to be used for TLS-Client-Authentication at corresponding services, which accept the supported cards with X.509 certificates.  
27 1 Hans-Martin Haase
28 7 Detlef Hühnlein
The *policy* for performing acceptance tests is as follows:
29 5 Detlef Hühnlein
30 6 Detlef Hühnlein
# The set of required acceptance tests depends on the implemented changes since the last accepted version.
31 7 Detlef Hühnlein
# At least the tests corresponding to the affected module (cf. Figure 3 in "[NHHW15]":https://ecsec.de/pub/OID_2015_QMS.pdf and Figure 1 in "[WHP+13]":http://www.ecsec.de/pub/2013_OID_Platform.pdf) *MUST* be tested completely.
32
# Additionally there *MUST* be a reasonable number of randomly chosen additional samples, which are selected in a way which makes it extremely likely that all requirements are indeed fulfilled.
33
# The execution of the tests and the corresponding test results *MUST* be documented in a conclusive manner.