|
Acceptance Testing
|
Conducted after System Testing this test type focuses on the application being tested either by the customer, with customer data or on the customers site. Emphasis is on ensuring the customer agrees the application is as required, that it can be used in the way expected and can be installed and deployed. This test type includes sub-types of Alpha, Beta, UAT and OAT |
- Relationship: Functional > Black Box > Dynamic > Validation > Testing
|
|
Accessibility Testing
|
This testing type ensures that the application’s functionality and design allows access for people with various disabilities and complies with agreed accessibility standards. The expectation is these standards will be the W3C WAI standards. This type of testing is a correlative to Usability Testing. |
- Relationship: Non-Functional > Black Box > Dynamic > Validation > Testing
|
|
Alpha Testing
|
Once the System Testing is completed the application is moved into an environment within the development organisation and is set-up to use data derived by the same to allow the demonstration and first exposure of the application to the customer in a controlled environment. The next step is Beta Testing. |
- Relationship: Sub-Type of Acceptance Testing
|
|
Automated Testing
|
<please define> |
|
|
Beta Testing
|
Once Alpha Testing is completed the application is released to the customer for use on site at their organisation and with their data. This testing allows the customer to test the software with more realistic data in a closer to ‘live’ setting. After this testing is completed the next step is User Acceptance Testing (UAT). |
- Relationship: Sub-Type of Acceptance Testing
|
|
Black Box:
|
The test types under this category of testing are conducted from the perspective of having no knowledge of the underlying code. Examples Black Box of test types includes Inspections, Acceptance Testing and Security Testing. |
- Relationship: Static > Verification> Testing
- Relationship: Dynamic > Validation > Testing
|
|
Compatibility Testing
|
This type of testing is used to ensure that the application, its environment and other applications running there, can work together within the shared environment or exchange data without issues. Also known as Interoperability Testing. |
- Relationship: Non-functional > Black Box > Dynamic > Validation > Testing
|
|
Component Integration Testing
|
After Interface testing has been completed components can be integrated and then tested together. This is also referred to as Integration in the Small or Link Testing. Testing at this level ensures defects discovered are more likely related to the integrated components and not other aspects of the design or code.
|
- Relationship: Structural > White Box > Dynamic > Validation > Testing
|
|
Component Testing
|
Also known as Unit Testing this focuses on testing the internal code of a component at the statement, branch, condition and decision level. The expectation is that the development team will complete this testing before Integration Testing. |
- Relationship: Structural > White Box > Dynamic > Validation > Testing
|
|
Context Driven Testing
|
<please define> |
|
|
Disaster Recovery
|
As part of OAT this testing ensures that all recovery systems that will provide back-up data or that are there to ensure failed systems the application uses are working as expected. |
- Relationship: OAT > Acceptance > Functional > Black Box > Dynamic > Validation > Testing
|
|
Dynamic Testing
|
Whenever testing is conducted on the code as it is executed or the application being run the testing is referred to as Dynamic. Dynamic and Static testing are the two sub-divisions of both Verification and Validation testing. |
- Relationship: Sub-Division of Validation
|
|
Exploratory Testing
|
|
|
|
Functional Design
|
This document is created by the development team and is based on analysis of the Functional Specification document. The aim of the document is to provide details of how the application will be structured and built to support the functionality specified against the Requirements provided by the customer. |
|
|
Functional Specification
|
This document is based on the Requirements provided by the customer. It aims to describe what technical implementation specifics are needed to realise the requirements the customer has. |
|
|
Functional Testing
|
This group of testing types is related to testing defined characteristics and behaviours of the system as detailed in the customer Requirements and as specified in the Functional Specification and described in the Functional Design. |
- Relationship: Black Box > Dynamic > Validation > Testing
|
|
Grey Box Testing
|
In between blackbox and whitebox testing where a tester is able to modify/enhance some technical design and/or code. |
|
| GUI Testing |
|
|
| Hacking |
|
|
|
Inspection
|
A formal Review activity that follows a documented procedure and is used to test out the assumptions and statements in documentation. The outcome of the Inspection is defects raised for correction. |
- Relationship: Review > Black Box > Static > Verification > Testing
|
|
Installation Testing
|
As part of OAT this testing ensures the application can be successfully installed onto the system it will be used on. This includes ensuring the application connects to other applications and services and that users can access and use the application. |
- Relationship: OAT > Acceptance > Functional > Black Box > Dynamic > Validation > Testing
|
|
Integration Testing
|
The Integration testing type follows Component Testing and consists of three integration testing sub-types of Interface, Component Integration and System Integration |
- Relationship: Structural > White Box > Dynamic > Validation > Testing
|
|
Interface Testing
|
After Component Testing has been completed the components that are linked have their interfaces tested to ensure that they can be moved into Component Integration testing. Testing the interfaces after component testing helps ensure that defects observed can be isolated to the interfaces and so more easily fixed. |
- Relationship: Integration > Structural > White Box > Dynamic > Validation > Testing
|
|
Load Testing
|
This sub-type of Performance Testing involves placing significant user load on the hosting infrastructure while monitoring its performance to ensure that the system will function to specification in the live environment. |
- Relationship: Non-Functional > Black Box > Dynamic > Validation > Testing
|
|
Localisation Testing
|
This type of testing is used to ensure the linguistic and cultural changes made to the application are correct for the market the application will be launched in. |
- Relationship: Non-functional > Black Box > Dynamic > Validation > Testing
|
|
Non-Functional Testing:
|
This group of testing types is related to the general characteristics and attributes of the application. These attributes include Security, Accessibility and Performance. |
- Relationship: Black Box > Dynamic > Validation > Testing
|
|
Operational Acceptance Testing (OAT)
|
This testing is part of the Acceptance test type and follows the User Acceptance Testing activity. At this point the application is agreed to be working from the business perspective and the testing now is to ensure it can be deployed and made operationally ready for use as a live application. Forms of OAT include Installation Testing and Disaster Recovery. |
- Relationship: Sub-Type of Acceptance Testing
|
|
Peer Review
|
A type of Review that is conducted against documents and code. The review is carried out with team mates or colleagues of the author or developer within the organisation. As with all inspections the aim is to identify defects at the Verification stage and avoid them migrating to the Validation stage of testing. |
- Relationship: Review > Black Box > Static > Verification > Testing
|
|
Penetration Testing
|
A sub-type of Security testing focused on finding vulnerabilities present in the underlying design of the application and architecture the application is deployed on. This includes exploiting interconnected software systems, networks, access controls and physical security. This is related to User Interface Attacks. |
- Relationship: Security > Non-Functional > Black Box > Dynamic > Validation > Testing
|
|
Performance Testing
|
When conducting the Performance Testing type the aim is to ensure the application and the infrastructure the application will be hosted on can support the demands placed on it. Testing results in the identification of performance bottlenecks. Performance testing involves the Load and Stress testing sub-types. |
- Relationship: Non-Functional > Black Box > Dynamic > Validation > Testing
|
| Rapid Testing |
|
|
|
Recovery Testing
|
This form of testing falls under Stress testing and is conducted after the application has been stressed to failure. The aim of the testing is to ensure that the application can recover gracefully from the failure back to an intended state. |
- Relationship: White Box > Dynamic > Validation > Testing
|
|
Requirements
|
These are statements from the customer as to what they would expect an application to be able to do. They are short descriptions or narratives in non-technical English and don’t specify how the requirements should be realised, this is provided in the Functional Specification document that follows. |
|
|
Review
|
There are several types of Review all of which are aimed at finding defects in documentation and code before components and the application are fully coded. This prevents defects migrating to later stages where they are harder to locate and more costly to fix. The types of review are Inspection, Walkthrough and Peer Review. |
- Relationship: Black Box > Static > Verification > Testing
|
|
Security Testing
|
How well system protected against unauthorized internal/external access. Usually requires sophisticated testing techniques. |
|
|
Static Testing
|
Whenever testing is conducted without running the software it is considered to be static testing. Reviews are the main group of testing types that are carried out and documents and code are the typical subject of the reviews. |
- Relationship: Sub-Division of Verification
|
|
Stress Testing
|
This sub-type of Performance Testing focuses on increasing the load on the hosting infrastructure to breaking point with the aim of defining the finite limits of the system and its Recovery ability. |
- Relationship: Non-Functional > Black Box > Dynamic > Validation > Testing
|
|
Structural Testing
|
Whenever testing is conducted with the intention of exercising the software at the code level and with full visibility of the code the testing types that are used fall under the Structural testing group. The test types include Component and Integration testing. |
- Relationship: White Box > Dynamic > Validation > Testing
|
|
System Integration Testing
|
After all Component Integration Testing has been completed the application will be ready for system integration. This level of testing involves testing the application works with existing system and components and may extend to testing with external components. |
- Relationship: Integration > Structural > White Box > Dynamic > Validation > Testing
|
|
System Testing
|
A level of testing that encompasses all forms of testing under the Functional and Non-Functional test groups. System Testing also include the System Integration Testing sub-type under the Structural test group. |
- Relationship: Dynamic > Validation > Testing
|
|
Test Case
|
A document that describes step-by-step how to test the application by using a wide range of conditions. Contains: Test case ID, AUT/Build, Reference, Environmnt, Business Function, Purpose, Pre-conditions, Test Data, Steps, Expected Output, Actual Output, Pass/Fail, Comments
|
|
| Test Plan |
|
|
| Test Strategy |
|
|
| Unit Testing
See Component Testing
|
|
|
|
Usability Testing
|
This type of testing ensures the application is easy to understood and use. This type of testing is a correlative to Accessibility Testing. |
Relationship: Security > Non-Functional > Dynamic > Black Box > Validation > Testing |
|
User Acceptance Testing (UAT)
|
This testing is part of the Acceptance test type and follows the Beta Testing activity. At this point the application is agreed to be working from a functional perspective and now needs to be validated from the business perspective. UAT is followed by Operational Acceptance Testing. |
- Relationship: Sub-Type of Acceptance Testing
|
|
User Interface Attacks
|
A sub-type of Security testing focused on finding vulnerabilities solely through the UI components of an application. Techniques include Form Field Stressing, Cookie Poisoning, URL Manipulation, Cross Site Scripting and SQL Injection. This is related to Penetration Testing. |
- Relationship: Security > Non-Functional > Dynamic > Black Box > Validation > Testing
|
|
Validation
|
Conducted after Verification this division of the testing domain focuses on the dynamic testing of the application. The applications functionality is directly tested across the main levels of testing that include Component, Integration, System and Acceptance testing.
The object of Validation is to ensure the application has been built in a way that correctly meets the Functional Specification and Functional Design.
|
- Relationship: Testing
|
|
Verification
|
Conducted before Validation this division of the testing domain focuses on review of artefacts such as Requirements, Functional Specifications and Functional Designs, Verification can also include review of code. Verification is a static testing commonly known as ‘desk checks’ as the activities don’t involve the running of the application.
The types of testing to be conducted include Inspections, Walkthroughs and Peer Reviews. The objective of Verification is to ensure the correct solution is specified and designed that will deliver the customer’s requirements.
|
|
|
Walkthrough
|
A type of Review that is conducted by the author of a document or developer of code in order to share their thinking and approach. The aim is to ensure those in the review become familiar with the content and to identify any issues or areas of improvement. |
- Relationship: Review > Black Box > Static > Verification > Testing
|
|
White Box
|
This test types under this category are conducted with knowledge of either the underlying information or code and is used to inform the testing conducted. Examples White Box testing would be Component and Interface testing. |
|
| |
|
|
| |
|
|
| |
|
|
| |
|
|
| |
|
|
| |
|
|
| |
|
|
| |
|
|
| |
|
|
| |
|
|
| |
|
|
| |
|
|
| |
|
|
| |
|
|
| |
|
|
| |
|
|
| |
|
|
| |
|
|
| |
|
|
| |
|
|
| |
|
|
| |
|
|
| |
|
|
| |
|
|
| |
|
|
| |
|
|
| |
|
|
| |
|
|
| |
|
|
| |
|
|
| |
|
|
| |
|
|
| |
|
|
| |
|
|
| |
|
|
| |
|
|
| |
|
|
| |
|
|
| |
|
|
| |
|
|
| |
|
|
| |
|
|
| |
|
|
| |
|
|
| |
|
|
| |
|
|
| |
|
|
| |
|
|
| |
|
|
Comments (0)
You don't have permission to comment on this page.