1. Release testing
1.1. Application
1.1.1. Testing a particular release
1.1.2. Intended for use outside of the development team
1.1.3. To convince the customer of the system that it is good enough for use
1.1.4. Tests are only derived from the system specification
1.2. Types of Release Testing
1.2.1. Requirement-based Testing
1.2.1.1. Involves examining each requirement and developing a test
1.2.1.2. Validation rather than defect testing
1.2.1.3. Demonstrate the system has properly implemented its requirement
1.2.2. Scenario Testing
1.2.2.1. Devise typical scenarios of use and it for develop test cases
1.2.2.2. Should be realistic
1.2.2.3. System users should be able to relate
1.2.3. Performance Testing
1.2.3.1. Involve the emergent properties of a system
1.2.3.1.1. Performance
1.2.3.1.2. Reliability
1.2.3.2. Reflect the profile of use of system
1.2.3.3. Involve planning a series of tests
1.2.3.4. Stress testing
1.2.3.4.1. System deliberately overloaded to test its failure.
2. User testing
2.1. Alpha Testing
2.1.1. WHY?
2.1.1.1. Users of the software work with the development team to test the software at the developer’s site
2.1.2. Pros
2.1.2.1. It gives a better insight in the reliability of the software application.
2.1.2.2. Gains the software team’s confidence before releasing the software application in the market.
2.1.3. Cons
2.1.3.1. Only business requirements are covered in Alpha testing.
2.1.3.2. Time efforts are proportional to cost in an IT project, which in turn increases the project budget.
2.2. Beta Testing
2.2.1. WHY?
2.2.1.1. the software is made available to users to allow them to experiment and to raise problems in the system
2.2.2. Pros
2.2.2.1. It helps in analyzing customer feedback before the release of the product.
2.2.2.2. Testers or developers neglected issues that matter to real customers that are uncovered in beta testing.
2.2.3. Cons
2.2.3.1. It seems a waste of time if the unstable/ under development product is released to the testing team.
2.2.3.2. As receiving feedback from the end-users is important, if no proper feedback is received and no improvements are done.
2.3. Acceptance Testing
2.3.1. WHY?
2.3.1.1. Customers test a system to decide if its ready to be viewed by the system developers
2.3.2. Process
2.3.2.1. 1. Define acceptance criteria
2.3.2.2. 2. Plan acceptance testing.
2.3.2.3. 3. Derive acceptance tests.
2.3.2.4. 4. Run acceptance tests
2.3.2.5. 5. Negotiate test results
2.3.2.6. 6. Accept / Reject the system
2.3.3. Pros
2.3.3.1. User/customer can raise bugs that went undetected during development.
2.3.3.2. Users can track the results or issues, and thus able to make the necessary changes as required.
2.3.4. Cons
2.3.4.1. Will need to develop patches to fix those bugs. Developed patches if mishandled might cause other bugs.
2.3.4.2. If bugs to severe or beyond user expectations, will drop customer satisfaction.
3. Development testing
3.1. Unit testing
3.1.1. Normal operation
3.1.1.1. Process
3.1.1.1.1. 1. Pick an input that's expected to be handled by the unit.
3.1.1.1.2. 2. Observe the output, see whether it's what you expected.
3.1.1.1.3. 3. Repeat with different inputs.
3.1.1.1.4. **Good to include: Single value, different size values, if array, access first middle and last elements, zero length.
3.1.1.2. Pros:
3.1.1.2.1. Demonstrate that the unit is working on expected environment.
3.1.1.3. Cons:
3.1.1.3.1. Does not detect bugs/crashes for abnormal inputs and extreme cases.
3.1.2. Abnormal input
3.1.2.1. Process
3.1.2.1.1. Work under extreme values.
3.1.2.1.2. Generate all errors
3.1.2.2. Pros:
3.1.2.2.1. Can know the limits of the unit.
3.1.2.3. Cons:
3.1.2.3.1. Hard to cover absolutely all possible ways to break a unit.
3.1.2.3.2. Inputs are beyond normal usage, so regular user might never encounter it. (But might does not equals to never!)
3.2. Component testing
3.2.1. Interface testing
3.2.1.1. Process
3.2.1.1.1. 1. Examine the code and identify when they call an external component.
3.2.1.1.2. 2. Identify the limits of the external component. (Extreme ranges for parameters, null pointers, order of execution etc.)
3.2.1.1.3. 3. Try to execute the component so it fails, or is pushed to the extreme.
3.2.1.1.4. 4. Check if the output matches the expected result.
3.2.1.2. Pros
3.2.1.2.1. Detects unwanted behaviour that arises between units.
3.2.1.2.2. Detects units which become defective when interacting with other units.
3.2.1.3. Cons
3.2.1.3.1. Assumes the units are not defective.
3.2.1.3.2. Could be hard to find point of failure.
3.3. System testing
3.3.1. Top-down Integration Testing
3.3.1.1. Process
3.3.1.1.1. 1. Top module tested with stubs.
3.3.1.1.2. 2. Stubs replaced one at a time, "depth first".
3.3.1.1.3. 3. As new modules are integrated, some subset of tests are re-run.
3.3.1.2. Pros
3.3.1.2.1. Systematic testing.
3.3.1.2.2. Ensure top works.
3.3.1.3. Cons
3.3.1.3.1. Top layer might break due to unexpected interaction from bottom layers.
3.3.2. Bottom-up Integration Testing
3.3.2.1. Process
3.3.2.1.1. Worker modules are grouped into builds and integrated.
3.3.2.1.2. Drivers are replaced one at a time, "depth first"
3.3.2.2. Pros
3.3.2.2.1. If something breaks, it's the top layer's problem.
3.3.2.3. Cons
3.3.2.3.1. Have to code placeholder drivers.
3.3.2.3.2. Complicated test designs/implementation.