Fix markdown lint errors
This commit is contained in:
William Sandner
71
QA-Plan.md
71
QA-Plan.md
@@ -1,9 +1,7 @@
|
||||
|
||||
<!-- markdownlint-disable MD033 -->
|
||||
<!-- markdownlint-disable-next-line MD041 -->
|
||||
*TODO: For each release, update this file by filling in answers to the
|
||||
<!-- markdownlint-disable-next-line first-line-h1 -->
|
||||
_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.*
|
||||
those answers that do not apply._
|
||||
|
||||
##### Project
|
||||
|
||||
@@ -76,7 +74,7 @@ this release.
|
||||
::There are many quality goals and approaches to assuring them. Since
|
||||
we have limited time and resources for this release, we will focus
|
||||
on the following components and aspects:
|
||||
|
||||
|
||||
- ::COMPONENT-1
|
||||
- ::COMPONENT-2
|
||||
- ::COMPONENT-3
|
||||
@@ -99,8 +97,8 @@ activities:
|
||||
|
||||
### Quality Goals for this Release
|
||||
|
||||
*TODO: Add or edit goals to fit your project. Group them by priorities
|
||||
that make sense for your project on this particular release.*
|
||||
_TODO: Add or edit goals to fit your project. Group them by priorities
|
||||
that make sense for your project on this particular release._
|
||||
|
||||
- ::Essential
|
||||
- [Functionality > Correctness](Glossary-Standard-Terms#functionality--correctness)
|
||||
@@ -133,18 +131,18 @@ that make sense for your project on this particular release.*
|
||||
|
||||
### QA Strategy
|
||||
|
||||
*TODO: Consider the activities listed below and delete those that are not
|
||||
_TODO: Consider the activities listed below and delete those that are not
|
||||
applicable to your project. Edit and add new activities if needed. For
|
||||
each activity, specify the coverage or frequency that you plan to
|
||||
achieve. If you do not plan to perform an activity, write "N/A".*
|
||||
achieve. If you do not plan to perform an activity, write "N/A"._
|
||||
|
||||
<!-- Hint: view this large table with text wrapping turned off -->
|
||||
|
||||
<!-- markdownlint-disable no-inline-html -->
|
||||
| Activity | Coverage or Frequency | Description |
|
||||
|--------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|
||||
| ------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
|
||||
| ::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>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/) |
|
||||
| ::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. |
|
||||
@@ -155,24 +153,25 @@ achieve. If you do not plan to perform an activity, write "N/A".*
|
||||
| ::Beta testing | <ul><li>::4 current customers</li><li>::40 members of our developers network</li><li>::1000 members of the public</li></ul> | ::We will involve outsiders in a beta test, or early access, program. We will beta testers directions to focus on specific features of the system. We will actively follow up with beta testers to encourage them to report issues. |
|
||||
| ::Instrumentation and monitoring | <ul><li>::Monitor our ASP servers</li><li>::Remotely monitor customer servers</li></ul> | ::As part of our SLA, we will monitor the behavior of servers to automatically detect service outages or performance degradation. We have policies and procedures in place for failure notification, escalation, and correction. |
|
||||
| ::Field failure reports | <ul><li>::Prompt users to report failures</li><li>::Automatically report failures</li></ul> | ::We want to understand each post-deployment system failure and actively take steps to correct the defect. The system has built-in capabilities for gathering detailed information from each system failure (e.g., error message, stack traceback, operating system version). This information will be transmitted back to us so that we may analyze it and act on it. |
|
||||
<!-- markdownlint-enable no-inline-html -->
|
||||
|
||||
### QA Strategy Evaluation
|
||||
|
||||
*TODO: Use the following table to evaluate how well your QA Strategy will
|
||||
assure your QA goals.*
|
||||
_TODO: Use the following table to evaluate how well your QA Strategy will
|
||||
assure your QA goals._
|
||||
|
||||
| Goal | Preconditions | Assertions | Buddy review | Review meeting | Unit testing | Manual system testing | Overall assurance |
|
||||
|-----------------|-----------------|--------------|----------------|------------------|----------------|-------------------------|---------------------|
|
||||
| Functionality | ::Medium | ::Medium | ::Medium | ::High | ::High | ::High | ::Strong |
|
||||
| Correctness | ::High | ::High | ::Medium | ::Medium | ::High | ::Medium | ::Strong |
|
||||
| Robustness | ::High | ::High | ::Medium | ::Medium | ::High | ::Medium | ::Strong |
|
||||
| Usability | ::None | ::None | ::None | ::High | ::None | ::Medium | ::Strong |
|
||||
| Security | ::Medium | ::None | ::Medium | ::High | ::None | ::Medium | ::Strong |
|
||||
| Reliability | ::None | ::Medium | ::Low | ::Medium | ::Medium | ::Medium | ::Weak |
|
||||
| Efficiency | ::None | ::None | ::Low | ::Medium | ::None | ::Low | ::At-Risk |
|
||||
| Scalability | ::None | ::None | ::Low | ::Medium | ::Low | ::Low | ::At-Risk |
|
||||
| Operability | ::None | ::None | ::None | ::Low | ::None | ::Low | ::At-Risk |
|
||||
| Maintainability | ::Medium | ::Low | ::Medium | ::High | ::Low | ::None | ::Weak |
|
||||
| Goal | Preconditions | Assertions | Buddy review | Review meeting | Unit testing | Manual system testing | Overall assurance |
|
||||
| --------------- | ------------- | ---------- | ------------ | -------------- | ------------ | --------------------- | ----------------- |
|
||||
| Functionality | ::Medium | ::Medium | ::Medium | ::High | ::High | ::High | ::Strong |
|
||||
| Correctness | ::High | ::High | ::Medium | ::Medium | ::High | ::Medium | ::Strong |
|
||||
| Robustness | ::High | ::High | ::Medium | ::Medium | ::High | ::Medium | ::Strong |
|
||||
| Usability | ::None | ::None | ::None | ::High | ::None | ::Medium | ::Strong |
|
||||
| Security | ::Medium | ::None | ::Medium | ::High | ::None | ::Medium | ::Strong |
|
||||
| Reliability | ::None | ::Medium | ::Low | ::Medium | ::Medium | ::Medium | ::Weak |
|
||||
| Efficiency | ::None | ::None | ::Low | ::Medium | ::None | ::Low | ::At-Risk |
|
||||
| Scalability | ::None | ::None | ::Low | ::Medium | ::Low | ::Low | ::At-Risk |
|
||||
| Operability | ::None | ::None | ::None | ::Low | ::None | ::Low | ::At-Risk |
|
||||
| Maintainability | ::Medium | ::Low | ::Medium | ::High | ::Low | ::None | ::Weak |
|
||||
|
||||
Cell values in the table above are subjective estimates of the
|
||||
effectiveness of each activity. This table helps to identify quality
|
||||
@@ -204,12 +203,13 @@ rating.
|
||||
|
||||
### Plan of Action
|
||||
|
||||
*TODO: Adjust this plan to fit your project.*
|
||||
_TODO: Adjust this plan to fit your project._
|
||||
|
||||
*TODO: Once the plan is outlined, tasks should be assigned to individuals
|
||||
and tracked to completion.*
|
||||
_TODO: Once the plan is outlined, tasks should be assigned to individuals
|
||||
and tracked to completion._
|
||||
|
||||
1. Preconditions and Assertions
|
||||
|
||||
- ::Refine requirements document whenever preconditions are not
|
||||
already determined
|
||||
- ::Create validation functions for use by preconditions and
|
||||
@@ -217,6 +217,7 @@ and tracked to completion.*
|
||||
- ::Write preconditions and assertions in code
|
||||
|
||||
2. Review meetings
|
||||
|
||||
- ::Assign buddy reviewers whenever a change to a release branch is
|
||||
considered
|
||||
- ::Select an at-risk document or section of code for weekly review
|
||||
@@ -228,6 +229,7 @@ and tracked to completion.*
|
||||
repository and track any issues identified in review meetings
|
||||
|
||||
3. Unit tests
|
||||
|
||||
- ::Set up infrastructure for easy execution of JUnit tests (this is
|
||||
just an Ant target)
|
||||
- ::Create unit tests for each class when the class is created
|
||||
@@ -241,6 +243,7 @@ and tracked to completion.*
|
||||
- ::Update unit tests whenever requirements change
|
||||
|
||||
4. System tests
|
||||
|
||||
- ::Design and specify a detailed manual [test suite](Test-Suite).
|
||||
- ::Review the system test suite to make sure that every UI screen
|
||||
and element is covered
|
||||
@@ -266,12 +269,12 @@ and tracked to completion.*
|
||||
#### Do the selected activities in the QA Strategy provide enough assurance that the project will meet it's quality goals?
|
||||
|
||||
::Yes, if all activities are carried out as planned, we are confident
|
||||
that the quality goals will be satisfied. We will, of course, adjust
|
||||
this plan as needed.
|
||||
that the quality goals will be satisfied. We will, of course, adjust
|
||||
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
|
||||
[Project Plan](Project-Plan).
|
||||
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?
|
||||
|
||||
|
||||
Reference in New Issue
Block a user