Overview:
1.Introduction to Software Testing
2.Relevance of Software Testing
3.Testing Process Overview/Software Testing Life Cycle STLC
4.The V model
5.Verification & Validation
6.Test Levels/Types of Testing
7.Career Path and Test Engineer Capabilities
8.Test plan
9.Test case
10.Defect management
1. Introduction to Software Testing
1.1. Definition of Software Testing :
Testing is the process of identifying defects, where a defect is any variance between actual and expected results.
Testing is process of trying to discover every conceivable fault or weakness in a work product.
Software testing is operating the software under controlled conditions,
(1) to verify that it behaves “as specified”;
(2) to detect errors, and
(3) to validate that what has been specified is what the user actually wanted.
2. Relevance of Software Testing
2.1. The Purpose of Testing :
The purpose of testing is verification, validation and error detection in order to find problems and the purpose of finding those problems is to get them fixed.
The product/project should meet the Requirements.
To ensure a quality product, which is reasonably bug free.
To satisfy the End-User.
2.2 Why need Testing?
3. Testing Process Overview
3.1 Software Testing Life Cycle (STLC) :
3.2 Requirement Analysis:
During this phase, test team studies the requirements from a testing point of view to identify the testable requirements.
The QA team may interact with various stakeholders (Client, Business Analyst, Technical Leads, System Architects etc) to understand the requirements in detail.
Requirements could be either Functional (defining what the software must do) or Non Functional (defining system performance /security availability ) .Automation feasibility for the given testing project is also done in this stage.
Activities:
Identify types of tests to be performed.
Gather details about testing priorities and focus.
Automation feasibility analysis (if required).
Prepare Requirement Traceability Matrix (RTM).
Identify test environment details where testing is supposed to be carried out.
3.3 Test Planning:
This phase is also called Test Strategy phase. Typically , in this stage, a Senior QA manager will determine effort and cost estimates for the project and would prepare and finalize the Test Plan.
Activities:
Preparation of test plan/strategy document for various types of testing
Test tool selection
Test effort estimation
Resource planning and determining roles and responsibilities.
Training requirement
3.4 Test Case Development:
This phase involves creation, verification and rework of test cases & test scripts. Test data , is identified/created and is reviewed and then reworked as well.
Activities:
Create test cases, automation scripts (if applicable)
Review and baseline test cases and scripts
Create test data (If Test Environment is available)
3.5 Test Environment Setup:
Test environment decides the software and hardware conditions under which a work product is tested. Test environment set-up is one of the critical aspects of testing process and can be done in parallel with Test Case Development Stage. Test team may not be involved in this activity if the customer/development team provides the test environment in which case the test team is required to do a readiness check (smoke testing) of the given environment.
Activities:
Understand the required architecture, environment set-up and prepare hardware and software requirement list for the Test Environment.
Setup test Environment and test data
Perform smoke test on the build
3.6 Test Execution:
During this phase test team will carry out the testing based on the test plans and the test cases prepared. Defects will be reported back to the development team for correction and retesting will be performed.
Activities:
Execute tests as per plan
Document test results, and log defects for failed cases
Map defects to test cases in RTM
Retest the defect fixes
Track the defects to closure
3.7 Test Cycle Closure :
Testing team will meet , discuss and analyze testing artifacts to identify strategies that have to be implemented in future, taking lessons from the current test cycle. The idea is to remove the process bottlenecks for future test cycles and share best practices for any similar projects in future.
Activities:
Evaluate cycle completion criteria based on Time, Test coverage, Cost, Software, Critical Business Objectives , Quality
Document the learning out of the project
Prepare Test closure report
Qualitative and quantitative reporting of quality of the work product to the customer.
Test result analysis to find out the defect distribution by type and severity.
4. The V Model
5. Verification & Validation
5.1 Verification:
Verification is the checking or testing of items, including software, for conformance and consistency by evaluating the results against pre-specified requirements.
[Verification: Are we building the system right?]
5.2 Validation :
Validation looks at the system correctness – i.e. is the process of checking that what has been specified is what the user actually wanted.
[Validation: Are we building the right system?]
5.3 Verification vs Validation :
Verification: Are we building the system right?
Validation: Are we building the right system?
In other words, validation checks to see if we are building what the customer wants/needs, and verification checks to see if we are building that system correctly.
6.1 Types of Testing:
Major types of testing:
Unit Testing
Integration Testing
System testing
Regression testing
Acceptance testing
6.2 Description Types of Testing:
5.2.1 Unit Testing:
Testing the functionality of a specific section of code, usually at the function level. These types of tests are usually executed by developers as they work on code (white-box style), to ensure that the specific function is working as expected. Unit testing is also called component testing.
6.2.2 Integration Testing:
Testing two or more modules or functions together with the intent of finding interface defects between integrated components (modules).
There two approaches to integration testing
Top-down approach
Bottom - up approach
6.2.2.1 Top-down approach:
Start from the top level module and integrate individual components and stub the rest of the system
6.2.2.2 Bottom - up approach:
Integrate individual components from lower level module until whole system is integrated.
6.2.3 System Testing:
System testing is typically “Black Box “ testing where the system is taken as black –box and tested based only on its functionality
Test cases are based on the overall system requirement specification
It is critical part of the testing process as the system is verified as a whole
6.2.4 Regression Testing:
Re-testing after fixes or modifications of the software or its environment.
It can be difficult to determine how much re-testing is needed, especially near the end of the development cycle.
Automated testing tools can be especially useful for this type of testing.
6.2.5 Acceptance Testing:
User Acceptance Testing (UAT) is a process of obtaining confirmation that a system meets mutually agreed-upon requirements.
Final testing based on specifications of the end-user or customer, or based on use by end-users/customers over some limited period of time.
6.2.6 Performance testing :
Performance testing is in general testing performed to determine how a system performs in terms of responsiveness and stability under a particular workload.
It can also serve to investigate, measure, validate or verify other quality attributes of the system, such as scalability, reliability and resource usage.
Performance Testing Types:
Load testing
Stress testing
Endurance testing (soak testing)
Spike testing
Configuration testing
6.2.7 Security testing :
Security testing is a process to determine that an information system protects data and maintains functionality as intended.
The six basic security concepts that need to be covered by security testing are:
Confidentiality,
Integrity,
Authentication,
Availability,
Authorization and
Non-repudiation
7. Career Path and Test Engineer Capabilities
8. Test Plan
8.1 Test Plan:
A document that defines the overall testing approach is called Test Plan.
Introduction
Project ID
Project Name
Module / Application Name
Revision History
Testing Details
Module to be tested (Based on Priority)
Features to be tested in this time
Features not to be tested
Test Approach (Strategy)
Test Type
Test Team
Test Objective
Test Environment
Test Methodology
Entry and Exit Criteria
Suspension and Resumption criteria
Acceptance Test
Acceptance Test Scope
Out of Scope
Acceptance Test Criteria and Procedures
Test Execution
Open Issues
Test Schedule
Traceability to Requirement
Test Case
Maintenance of Test plan
9. Test Case
9.1 Test Case:
A set of test inputs, execution conditions, and expected results developed for a particular objective
A test case is a document that describes an input, action, or event and an expected response, to determine if a feature of an application is working correctly
A test case should contain particulars such as test case identifier, test case name, objective, test conditions/setup, input data requirements, steps, and expected results
Elements of a Test Case with example:
Module Name : DS-Payroll
Component Name : Payroll
Test Type : System Test
Test Case ID : DS-PROLL-001
Use Case No : UC-001
Test Condition: 1. Request to the system for 'Company Information' entry screen.
2. After appear 'Company Information' entry screen insert all the necessary information and request system to save the data.
3. Without insert any value try to add information.
4. Try to add same information again.
Expected Output:1. System will provide 'Company Information‘ entry screen successfully.
2. Inserted information will be saved successfully and it will be notify by a user friendly message.
3. System will asking for the required field the values.
4. System will not permit to add same information again and will notify about the existing information.
10. Defect Management
10.1 Definition of defect:
A flaw in a system or system component that causes the system or component to fail to perform its required function. - SEI
A defect, if encountered during execution, may cause a failure of the system.
The purpose of finding defects:
The purpose of finding defects is to get them fixed
The prime benefit of testing is that it results in improved quality. Bugs get fixed
10.2 Why do defects occurs:
There are various reasons for the occurrence of the faults; it may be due to
Poor documentation
Ambiguous or unclear requirements
Lack of programming skills
Due to increase in work pressure and assigned deadlines
10.3 Defect Types:
1.Introduction to Software Testing
2.Relevance of Software Testing
3.Testing Process Overview/Software Testing Life Cycle STLC
4.The V model
5.Verification & Validation
6.Test Levels/Types of Testing
7.Career Path and Test Engineer Capabilities
8.Test plan
9.Test case
10.Defect management
1. Introduction to Software Testing
1.1. Definition of Software Testing :
Testing is the process of identifying defects, where a defect is any variance between actual and expected results.
Testing is process of trying to discover every conceivable fault or weakness in a work product.
Software testing is operating the software under controlled conditions,
(1) to verify that it behaves “as specified”;
(2) to detect errors, and
(3) to validate that what has been specified is what the user actually wanted.
2. Relevance of Software Testing
2.1. The Purpose of Testing :
The purpose of testing is verification, validation and error detection in order to find problems and the purpose of finding those problems is to get them fixed.
The product/project should meet the Requirements.
To ensure a quality product, which is reasonably bug free.
To satisfy the End-User.
2.2 Why need Testing?
3. Testing Process Overview
3.1 Software Testing Life Cycle (STLC) :
3.2 Requirement Analysis:
During this phase, test team studies the requirements from a testing point of view to identify the testable requirements.
The QA team may interact with various stakeholders (Client, Business Analyst, Technical Leads, System Architects etc) to understand the requirements in detail.
Requirements could be either Functional (defining what the software must do) or Non Functional (defining system performance /security availability ) .Automation feasibility for the given testing project is also done in this stage.
Activities:
Identify types of tests to be performed.
Gather details about testing priorities and focus.
Automation feasibility analysis (if required).
Prepare Requirement Traceability Matrix (RTM).
Identify test environment details where testing is supposed to be carried out.
3.3 Test Planning:
This phase is also called Test Strategy phase. Typically , in this stage, a Senior QA manager will determine effort and cost estimates for the project and would prepare and finalize the Test Plan.
Activities:
Preparation of test plan/strategy document for various types of testing
Test tool selection
Test effort estimation
Resource planning and determining roles and responsibilities.
Training requirement
3.4 Test Case Development:
This phase involves creation, verification and rework of test cases & test scripts. Test data , is identified/created and is reviewed and then reworked as well.
Activities:
Create test cases, automation scripts (if applicable)
Review and baseline test cases and scripts
Create test data (If Test Environment is available)
3.5 Test Environment Setup:
Test environment decides the software and hardware conditions under which a work product is tested. Test environment set-up is one of the critical aspects of testing process and can be done in parallel with Test Case Development Stage. Test team may not be involved in this activity if the customer/development team provides the test environment in which case the test team is required to do a readiness check (smoke testing) of the given environment.
Activities:
Understand the required architecture, environment set-up and prepare hardware and software requirement list for the Test Environment.
Setup test Environment and test data
Perform smoke test on the build
3.6 Test Execution:
During this phase test team will carry out the testing based on the test plans and the test cases prepared. Defects will be reported back to the development team for correction and retesting will be performed.
Activities:
Execute tests as per plan
Document test results, and log defects for failed cases
Map defects to test cases in RTM
Retest the defect fixes
Track the defects to closure
3.7 Test Cycle Closure :
Testing team will meet , discuss and analyze testing artifacts to identify strategies that have to be implemented in future, taking lessons from the current test cycle. The idea is to remove the process bottlenecks for future test cycles and share best practices for any similar projects in future.
Activities:
Evaluate cycle completion criteria based on Time, Test coverage, Cost, Software, Critical Business Objectives , Quality
Document the learning out of the project
Prepare Test closure report
Qualitative and quantitative reporting of quality of the work product to the customer.
Test result analysis to find out the defect distribution by type and severity.
4. The V Model
5. Verification & Validation
5.1 Verification:
Verification is the checking or testing of items, including software, for conformance and consistency by evaluating the results against pre-specified requirements.
[Verification: Are we building the system right?]
5.2 Validation :
Validation looks at the system correctness – i.e. is the process of checking that what has been specified is what the user actually wanted.
[Validation: Are we building the right system?]
5.3 Verification vs Validation :
Verification: Are we building the system right?
Validation: Are we building the right system?
In other words, validation checks to see if we are building what the customer wants/needs, and verification checks to see if we are building that system correctly.
6.1 Types of Testing:
Major types of testing:
Unit Testing
Integration Testing
System testing
Regression testing
Acceptance testing
6.2 Description Types of Testing:
5.2.1 Unit Testing:
Testing the functionality of a specific section of code, usually at the function level. These types of tests are usually executed by developers as they work on code (white-box style), to ensure that the specific function is working as expected. Unit testing is also called component testing.
6.2.2 Integration Testing:
Testing two or more modules or functions together with the intent of finding interface defects between integrated components (modules).
There two approaches to integration testing
Top-down approach
Bottom - up approach
6.2.2.1 Top-down approach:
Start from the top level module and integrate individual components and stub the rest of the system
6.2.2.2 Bottom - up approach:
Integrate individual components from lower level module until whole system is integrated.
6.2.3 System Testing:
System testing is typically “Black Box “ testing where the system is taken as black –box and tested based only on its functionality
Test cases are based on the overall system requirement specification
It is critical part of the testing process as the system is verified as a whole
6.2.4 Regression Testing:
Re-testing after fixes or modifications of the software or its environment.
It can be difficult to determine how much re-testing is needed, especially near the end of the development cycle.
Automated testing tools can be especially useful for this type of testing.
6.2.5 Acceptance Testing:
User Acceptance Testing (UAT) is a process of obtaining confirmation that a system meets mutually agreed-upon requirements.
Final testing based on specifications of the end-user or customer, or based on use by end-users/customers over some limited period of time.
6.2.6 Performance testing :
Performance testing is in general testing performed to determine how a system performs in terms of responsiveness and stability under a particular workload.
It can also serve to investigate, measure, validate or verify other quality attributes of the system, such as scalability, reliability and resource usage.
Performance Testing Types:
Load testing
Stress testing
Endurance testing (soak testing)
Spike testing
Configuration testing
6.2.7 Security testing :
Security testing is a process to determine that an information system protects data and maintains functionality as intended.
The six basic security concepts that need to be covered by security testing are:
Confidentiality,
Integrity,
Authentication,
Availability,
Authorization and
Non-repudiation
7. Career Path and Test Engineer Capabilities
8. Test Plan
8.1 Test Plan:
A document that defines the overall testing approach is called Test Plan.
Introduction
Project ID
Project Name
Module / Application Name
Revision History
Testing Details
Module to be tested (Based on Priority)
Features to be tested in this time
Features not to be tested
Test Approach (Strategy)
Test Type
Test Team
Test Objective
Test Environment
Test Methodology
Entry and Exit Criteria
Suspension and Resumption criteria
Acceptance Test
Acceptance Test Scope
Out of Scope
Acceptance Test Criteria and Procedures
Test Execution
Open Issues
Test Schedule
Traceability to Requirement
Test Case
Maintenance of Test plan
9. Test Case
9.1 Test Case:
A set of test inputs, execution conditions, and expected results developed for a particular objective
A test case is a document that describes an input, action, or event and an expected response, to determine if a feature of an application is working correctly
A test case should contain particulars such as test case identifier, test case name, objective, test conditions/setup, input data requirements, steps, and expected results
Elements of a Test Case with example:
Module Name : DS-Payroll
Component Name : Payroll
Test Type : System Test
Test Case ID : DS-PROLL-001
Use Case No : UC-001
Test Condition: 1. Request to the system for 'Company Information' entry screen.
2. After appear 'Company Information' entry screen insert all the necessary information and request system to save the data.
3. Without insert any value try to add information.
4. Try to add same information again.
Expected Output:1. System will provide 'Company Information‘ entry screen successfully.
2. Inserted information will be saved successfully and it will be notify by a user friendly message.
3. System will asking for the required field the values.
4. System will not permit to add same information again and will notify about the existing information.
10. Defect Management
10.1 Definition of defect:
A flaw in a system or system component that causes the system or component to fail to perform its required function. - SEI
A defect, if encountered during execution, may cause a failure of the system.
The purpose of finding defects:
The purpose of finding defects is to get them fixed
The prime benefit of testing is that it results in improved quality. Bugs get fixed
10.2 Why do defects occurs:
There are various reasons for the occurrence of the faults; it may be due to
Poor documentation
Ambiguous or unclear requirements
Lack of programming skills
Due to increase in work pressure and assigned deadlines
10.3 Defect Types:
No comments:
Post a Comment