Our Roadmap for Testing
Levels / Categories of Testing:
Every Web Site (application) is different and so are the levels and standards of testing. Normally, testing takes more resources than development. The following is a partial list of important levels of validation/testing that should be considered for applicability to a specific project or product.:
-
Functional testing - generally required for all products. The purpose of functional testing is to reveal defects related to the product/component’s functionality and conformance to documented functional requirement specifications.
-
Unit testing - usually accomplished by developers; computer software unit testing.
-
-
Exploratory testing (Always write down what you do and what happens when you run exploratory tests.
-
Component/Sub-component testing Computer Software Component testing. Walkthroughs, inspections, desk-checking.
-
Verification (e.g., reviews, examinations, walkthroughs, desk-checking, or inspection of interim work products such as requirements, design, specifications, documentation, prototypes, code; early detection of errors are highly cost effective.)
-
Developmental integration testing.
-
Developmental system testing.
-
User acceptance testing (Generally required for all products. The purpose of acceptance testing is convincing the user that the product fulfills expected user needs.)
-
Performance/load/stress testing.
-
-
-
Operational procedure documentation verification.
-
Regression testing (Reliability).
-
-
Smoke Test - …establish that the system is stable and all major functionality is present and works under ‘normal’ conditions
-
-
Recovery testing - …can involve the manual functions of an application, loss of input capability, loss of communication lines, hardware or operating system failure, loss of database integrity, operator error, or application system failure.
-
Operations testing / Usability Testing (Ease of Operations).
-
Compliance testing - …verifies that the application was developed in accordance with information technology standards, procedures, and guidelines.
-
Manual-Support Testing - Systems commence when transactions originate and conclude with the use of the results of processing. The manual part of the system requires the same attention to testing as does the automated segment.
-
Intersystem [interface] Testing.
-
Parallel Testing (e.g., matching test results between current live system and new system.)
-
Compliance Testing (Authorization) - Testing should verify that the authorization rules have been properly implemented and evaluate compliance with them. Test conditions should include unauthorized transactions or processes to ensure that they are rejected, as well as ensuring authorized transactions is accepted.
Test (Validation Design, Methods, & Techniques:
Evaluating a system…to determine if it satisfies specified requirements. For a specific project, an analysis should be accomplished to determine all appropriate/applicable test design, methods, and techniques. Those selected should be documented along with rational/justification. The following is a partial list of various test design, methods, and techniques that, as a minimum should be considered for applicability to a specific project or product:
|
requirements based functional testing
|
domain analysis testing
|
|
data flow testing
|
>control flow testing
|
|
orthogonal array testing
|
waterfall testing
|
|
boundary value testing
|
risk based testing
|
|
error guessing
|
test automation
|
|
string testing
|
extreme testing
|
|
test attacks
|
greybox testing
|
|
white box testing / structural testing / glass box testing
|
black box testing/ behavioral testing
|
|
transaction testing
|
state transition testing
|
|
all pairs / pairwise testing
|
decision table testing
|
|
equivalence class testing
|
translucent-box testing
|
|
operation testing
|
recovery testing
|
|
compliance (to process) testing
|
execution testing (desired level of proficiency)
|
|
path testing
|
error handling / messages testing
|
|
business rules decision tables
|
Inter-systems/interface testing (data passing)
|
|
manual support (people-computer interaction) testing
|
fault model
|
Test Attack Summary - User Interface Attacks
|
1. Apply inputs that force all error messages.
|
10. Force the screen to refresh.
|
|
2. Apply inputs that force software to establish default values.
|
11. Apply inputs using a variety of initial conditions.
|
|
3. Explore allowable character sets and data types.
|
12. Force a data structure to store too many or too few values.
|
|
4. Overflow input buffers.
|
13. Investigate alternate ways to modify internal data constraints.
|
|
5. Find inputs that mat interact and test combinations of their values.
|
14. Experiment with invalid operand and operator combinations.
|
|
6. Repeat the same inputs numerous times.
|
15. Force a function to call itself recursively.
|
|
7. Force different outputs to be generated for each input.
|
16. Force computation results to be too large or too small.
|
|
8. Force invalid outputs to be generated.
|
17. Find features that share data or interact poorly.
|
|
9. Force properties of an output to change.
|
|
Test Attack Summary - System Interface Attacks
|
1. Fill the system to capacity.
|
4. Assign an invalid file name.
|
|
2. Force the media to be busy or unavailable.
|
5. Vary access permissions.
|
|
3. Damage the media.
|
6. Vary corrupt file contents
|
|