Suborbital-Systems-Public/ReadySetGit
3
0
Fork 0
Code Pull Requests Packages Projects Releases Activity

Fix linter warnings

Browse Source
This commit is contained in:
William Sandner
2021-08-01 15:15:57 +02:00
parent 70a43d171f
commit 704e13c18f
30 changed files with 135 additions and 106 deletions
Download Patch File Download Diff File Expand all files Collapse all files

17
QA-Plan.md
View File

@@ -1,3 +1,6 @@
<!-- markdownlint-disable MD033 -->
<!-- markdownlint-disable-next-line MD041 -->
*TODO: For each release, update this file by filling in answers to the
questions. In cases where multiple answers are already written, delete
those answers that do not apply.*
@@ -6,18 +9,18 @@ those answers that do not apply.*
::[PROJECT-NAME](Home)
##### Internal Release Number:
##### Internal Release Number
::X.Y.Z
##### Release Audience:
##### Release Audience
- ::General availability release ||
- ::Customer-specific release: CUSTOMER(S) ||
- ::Developer release (Internal usage only) ||
- ::Early access release (Controlled external access)
##### Attached Worksheets:
##### Attached Worksheets
- QA plan > [Review meeting notes](Review-Meeting-Notes)
- QA plan > [System test case suite](Test-Suite)
@@ -67,7 +70,7 @@ coordinate all the QA activities.
#### What is the scope of this QA plan?
::All components and aspects of the system will be evaluated in
::All components and aspects of the system will be evaluated in
this release.
::There are many quality goals and approaches to assuring them. Since
@@ -141,7 +144,7 @@ achieve. If you do not plan to perform an activity, write "N/A".*
|--------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| ::Preconditions | <ul><li>::Every public method</li><li>::Every public method in COMPONENT-NAME</li><li>::All public methods that modify data</li></ul> | ::We will use if-statements at the beginning of public methods to validate each argument value. This helps to document assumptions and catch invalid values before they can cause faults. |
| ::Assertions | <ul><li>::Every private method</li><li>::Every private method in COMPONENT-NAME</li><li>::All private methods that modify data</li></ul> | ::Assertions will be used to validate all arguments to private methods. Since these methods are only called from our other methods, arguments passed to them should always be valid, unless our code is defective. Assertions will also be used to test class invariants and some postconditions. |
| ::Static analysis | <ul><li>::Strict compiler warnings</li><li>::Automated style checking</li><li>::XML validation</li><li>Detetect common errors</li></ul> | ::We will use source code analysis tools to automatically detect errors. Style checkers will help make all of our code consistent with our coding standards. XML validation ensures that each XML document conforms to its DTD. Lint-like tools help detect common programming errors. E.g.: [lint](http://www.freebsd.org/cgi/man.cgi?query=lint), [lclint/splint](http://www.splint.org/), [jlint](http://artho.com/jlint/), [checkstyle](http://sourceforge.net/projects/checkstyle/), [Jcsc](http://sourceforge.net/projects/jcsc), [PyLint](https://www.pylint.org/), [PyChecker](http://pychecker.sourceforge.net/), [Tidy](http://www.html-tidy.org/) |
| ::Static analysis | <ul><li>::Strict compiler warnings</li><li>::Automated style checking</li><li>::XML validation</li><li>Detect common errors</li></ul> | ::We will use source code analysis tools to automatically detect errors. Style checkers will help make all of our code consistent with our coding standards. XML validation ensures that each XML document conforms to its DTD. Lint-like tools help detect common programming errors. E.g.: [lint](http://www.freebsd.org/cgi/man.cgi?query=lint), [lclint/splint](http://www.splint.org/), [jlint](http://artho.com/jlint/), [checkstyle](http://sourceforge.net/projects/checkstyle/), [Jcsc](http://sourceforge.net/projects/jcsc), [PyLint](https://www.pylint.org/), [PyChecker](http://pychecker.sourceforge.net/), [Tidy](http://www.html-tidy.org/) |
| ::Buddy review | <ul><li>::All changes to release branches</li><li>::All changes to COMPONENT-NAME</li><li>::All changes</li></ul> | ::Whenever changes must be made to code on a release branch (e.g., to prepare a maintenance release) the change will be reviewed by another developer before it is committed. The goal is to make sure that fixes do not introduce new defects. |
| ::Review meetings | <ul><li>::Weekly</li><li>::Once before release</li><li>::Every source file</li></ul> | ::We will hold review meetings where developers will perform formal inspections of selected code or documents. We choose to spend a small, predetermined amount of time and try to maximize the results by selecting review documents carefully. In the review process we will use and maintain a variety of checklists. |
| ::Unit testing | <ul><li>::100% of public methods, and 75% of statements</li><li>::100% of public methods</li><li>::75% of statements</li></ul> | ::We will develop and maintain a unit test suite using the JUnit framework. We will consider the boundary conditions for each argument and test both sides of each boundary. Tests must be run and passed before each commit, and they will also be run by the testing team. Each public method will have at least one test. And, the overall test suite will exercise at least 75% of all executable statements in the system. |
@@ -267,7 +270,7 @@ and tracked to completion.*
this plan as needed.
::No, this plan leaves open several quality risks that have been noted
in the [Risk Management](Project-Plan#Risk-Management) section of the
in the [Risk Management](Project-Plan#Risk-Management) section of the
[Project Plan](Project-Plan).
#### Have human resources been allocated to carry out the QA activities?
@@ -300,5 +303,5 @@ is welcome.
::No, some developers are not aware of the quality goals and planned
QA activities for this release. This is a risk that is noted in the
[Risk Management](Project-Plan#Risk-Management) section of the
[Risk Management](Project-Plan#Risk-Management) section of the
[Project Plan](Project-Plan).