Types of system testing.

University project.

Get Started. It's Free
or sign up with your email address
Types of system testing. by Mind Map: Types of system testing.

1. Development testing

1.1. Unit testing

1.1.1. Normal operation Process 1. Pick an input that's expected to be handled by the unit. 2. Observe the output, see whether it's what you expected. 3. Repeat with different inputs. **Good to include: Single value, different size values, if array, access first middle and last elements, zero length. Pros: Demonstrate that the unit is working on expected environment. Cons: Does not detect bugs/crashes for abnormal inputs and extreme cases.

1.1.2. Abnormal input Process Work under extreme values. Generate all errors Pros: Can know the limits of the unit. Cons: Hard to cover absolutely all possible ways to break a unit. Inputs are beyond normal usage, so regular user might never encounter it. (But might does not equals to never!)

1.2. Component testing

1.2.1. Interface testing Process 1. Examine the code and identify when they call an external component. 2. Identify the limits of the external component. (Extreme ranges for parameters, null pointers, order of execution etc.) 3. Try to execute the component so it fails, or is pushed to the extreme. 4. Check if the output matches the expected result. Pros Detects unwanted behaviour that arises between units. Detects units which become defective when interacting with other units. Cons Assumes the units are not defective. Could be hard to find point of failure.

1.3. System testing

1.3.1. Top-down Integration Testing Process 1. Top module tested with stubs. 2. Stubs replaced one at a time, "depth first". 3. As new modules are integrated, some subset of tests are re-run. Pros Systematic testing. Ensure top works. Cons Top layer might break due to unexpected interaction from bottom layers.

1.3.2. Bottom-up Integration Testing Process Worker modules are grouped into builds and integrated. Drivers are replaced one at a time, "depth first" Pros If something breaks, it's the top layer's problem. Cons Have to code placeholder drivers. Complicated test designs/implementation.

2. Release testing

2.1. Application

2.1.1. Testing a particular release

2.1.2. Intended for use outside of the development team

2.1.3. To convince the customer of the system that it is good enough for use

2.1.4. Tests are only derived from the system specification

2.2. Types of Release Testing

2.2.1. Requirement-based Testing Involves examining each requirement and developing a test Validation rather than defect testing Demonstrate the system has properly implemented its requirement

2.2.2. Scenario Testing Devise typical scenarios of use and it for develop test cases Should be realistic System users should be able to relate

2.2.3. Performance Testing Involve the emergent properties of a system Performance Reliability Reflect the profile of use of system Involve planning a series of tests Stress testing System deliberately overloaded to test its failure.

3. User testing

3.1. Alpha Testing

3.1.1. WHY? Users of the software work with the development team to test the software at the developer’s site

3.1.2. Pros It gives a better insight in the reliability of the software application. Gains the software team’s confidence before releasing the software application in the market.

3.1.3. Cons Only business requirements are covered in Alpha testing. Time efforts are proportional to cost in an IT project, which in turn increases the project budget.

3.2. Beta Testing

3.2.1. WHY? the software is made available to users to allow them to experiment and to raise problems in the system

3.2.2. Pros It helps in analyzing customer feedback before the release of the product. Testers or developers neglected issues that matter to real customers that are uncovered in beta testing.

3.2.3. Cons It seems a waste of time if the unstable/ under development product is released to the testing team. As receiving feedback from the end-users is important, if no proper feedback is received and no improvements are done.

3.3. Acceptance Testing

3.3.1. WHY? Customers test a system to decide if its ready to be viewed by the system developers

3.3.2. Process 1. Define acceptance criteria 2. Plan acceptance testing. 3. Derive acceptance tests. 4. Run acceptance tests 5. Negotiate test results 6. Accept / Reject the system

3.3.3. Pros User/customer can raise bugs that went undetected during development. Users can track the results or issues, and thus able to make the necessary changes as required.

3.3.4. Cons Will need to develop patches to fix those bugs. Developed patches if mishandled might cause other bugs. If bugs to severe or beyond user expectations, will drop customer satisfaction.