As in the case of Traditional Testing, Agile Testing also need to cover all the Test Levels.
- Unit Testing
- Integration Testing
- System Testing
- User Acceptance Testing
Unit Testing
- Done along with Coding, by Developer
- Supported by Tester who writes Test Cases ensuring 100% Design Coverage
- Unit Test Cases and Unit Testing results need to be reviewed
- Unresolved major defects (as per priority and severity) are not left
- All Unit Tests are automated
Integration Testing
- Done along with Continuous Integration as the Sprints progress
- Done at the end after all the Sprints are completed
- All Functional Requirements are tested
- All Interfaces between Units are tested
- All the Defects are Reported
- Tests are automated where possible
System Testing
- Done as the Development progresses
- Users Stories, Features and Functions are Tested
- Testing done in Production Environment
- Quality Tests are executed (Performance, Reliability, etc.)
- Defects are reported
- Tests are automated where possible
User Acceptance Testing
- Done at the end of each Sprint and at the end of the project
- Done by the Customer. Feedback is taken by the Team
- Feedback will be an input to subsequent Sprints
- User Stories in a Sprint are pre-verified to be testable and are with defined Acceptance Criteria
Test Types
- Component Tests (Unit Tests)
- Functional Tests (User Stories Tests)
- Non-functional Tests (Performance, Load, Stress, etc.)
- Acceptance Tests
Tests can be fully Manual, fully Automated, Combination of Manual and Automated or Manual supported by Tools.
Support Programming and Critique Product Tests
Tests can be for −
- Supporting Development (Support Programming) − Support Programming Tests are used by the Programmers.
- To decide on what code they need to write to accomplish a certain behavior of a System
- What Tests need to be run after Coding to ensure the new Code does not hamper the rest of the behaviors of the System
- Verification only (Critique Product) − Critique Product Tests are used for discovering inadequacies in the finished Product
Business Facing and Technology Facing Tests
To decide on what tests to be performed when, you need to determine whether a test is −
- Business Facing, or
- Technology Facing
Business Facing Tests
A Test is a business-facing test if it answers the questions framed with words from business domain. These are understood by the business experts and would interest them so that behavior of the system can be explained in the real time scenario.
Technology Facing Tests
A Test is a technology-facing test if it answers the questions framed with words from technology domain. The programmers understand what needs to be implemented based on the clarifications on technology.
These two aspects of test types can be viewed using the Agile Testing Quadrants defined by Brian Marick.
Agile Testing Quadrants
Combining the two aspects of Testing Types, the following Agile Testing Quadrants are derived by Brian Marick −
The Agile Testing Quadrants provide a helpful taxonomy to help teams identify, plan and execute the testing needed.
- Quadrant Q1 − Unit Level, Technology Facing, and supports the developers. Unit tests belong to this Quadrant. These tests can be Automated tests.
- Quadrant Q2 − System level, business facing, and conform product behavior. Functional tests belong to this quadrant. These tests are either manual or automated.
- Quadrant Q3 − System or User Acceptance Level, Business Facing and focus on real time scenarios. User Acceptance Tests belong to this quadrant. These tests are manual.
- Quadrant Q4 − System or Operational Acceptance Level, Technology Facing and Focus on Performance, Load, Stress, Maintainability, Scalability Tests. Special tools can be used for these tests along with automation testing.
Combining these, the Agile Testing Quadrants that reflect What-Testing-When can be visualized as follows −
