Agile Testing, like Traditional Testing, must encompass all Test Levels, including Unit Testing, Integration Testing, System Testing, and User Acceptance Testing.
Component Tests (Unit Tests):
• 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
Supporting Development (Support Programming) − Support Programming Tests are used by Programmers to determine the code necessary to achieve a desired behavior from a System. These Tests also help to ensure that new Code does not interfere with the existing behaviors of the System. Verification only (Critique Product) − Critique Product Tests are used to identify any flaws in the completed Product. These Tests help to identify any issues that may have been overlooked during development.
Business Facing and Technology Facing Tests
In order to determine which tests should be performed when, it must be determined if the test is a Business Facing test or Technology Facing test.
Business Facing Tests
A Business Facing Test is one that answers questions from the business domain, which are understood by business experts and are relevant to the real-time scenario in order to explain the behavior of the system.
Technology Facing Tests
A Technology Facing Test is one that answers questions from the technology domain, which are understood by the programmers and help them clarify what needs to be implemented. Both types of tests can be seen using the Agile Testing Quadrants defined by Brian Marick.
Agile Testing Quadrants
The Agile Testing Quadrants, created by Brian Marick, provide a helpful taxonomy to help teams identify, plan and execute the testing needed. These quadrants are:
Quadrant Q1: Unit Level, Technology Facing. This quadrant supports the developers and unit tests belong here. These tests can be automated.
Quadrant Q2: System level, Business Facing. This quadrant focuses on product behavior, and functional tests belong here. These tests can be manual or automated.
Quadrant Q3: System or User Acceptance Level, Business Facing. This quadrant focuses on real-time scenarios, and user acceptance tests belong here. These tests are manual.
Quadrant Q4: System or Operational Acceptance Level, Technology Facing. This quadrant focuses on performance, load, stress, maintainability, and scalability tests. Special tools and automation testing can be used here.
