User:Shitalkumar sh/sandbox

= Software Testing Fundamentals =

Software Development models

 * Sequential
 * Waterfall Model
 * V- Model


 * Iterative

Test Levels

 * Component Testing/ Unit Testing
 * Integration Testing
 * System Testing
 * Acceptance Testing

Requirement Analysis
Its starting phase of Software Development process
 * Client Requirements : Clients expectation of the product (A Requirement Specification Document)
 * System Requirements : System related requirements (A Functional Specification Document)

Component Testing/ Unit Testing

 * It starts along with 'Module design' i.e. 'Detailed design of the product'
 * Module is tested by its own developer or developer of another module
 * No formal records are maintained
 * Developer fix errors as soon as he/she detect them
 * Test approach involves repetition of three steps
 * Create test cases - (Unit Test cases)
 * Develop code
 * Run tests

Levels of Integration Testing

 *  Component Integration Testing 
 * Comes after Component testing
 * Test components/modules interaction
 * Tested by developers or integrators


 *  System Integration Testing 
 * Comes after System testing
 * Test interaction of product with other systems
 * Tested by system testers

Methods of Integration Testing

 * Big-bang Integration Testing
 * Incremental Integration Testing (Preferable)
 * Top-Down Incremental Testing : External to Internal components
 * Bottom-Up Incremental Testing : Internal to External components

System Testing

 * To ensure following things in the application in the simulated environment


 * Meets the requirements identified during initial phase
 * Can optimally utilize system resources
 * Can interact with the OS it supports
 * Can withstand potential risks (e.g. hacker, virus attack etc.)

Functional requirements

 * Step 1 - Black-box testing : To test external functions of the application
 * Step 2 - White-box/ Structure-based testing : To test each internal component of the application

Nonfunctional requirements

 * application perform as intended
 * withstand adverse conditions such as invalid inputs
 * error-free installation and modifications
 * compatibility with supported hardware and software
 * ease of navigation

Acceptance Testing

 * To determine whether an application


 * meets all the specified requirements
 * is ready to be deployed
 * adversely affect existing application and business operation.

Types of Acceptance testing

 * User Acceptance testing
 * Operational Acceptance testing
 * Contract Acceptance testing
 * Regulation Acceptance testing

Alpha and Beta testing
These are two types of acceptance testing of an application produced for mass use e.g. commercial-off-the-shelf (COTS) application

Alpha testing
Its done
 * By a team and a group of prospective customers.
 * At site of organization that developing the application

Beta testing
Its done
 * After successful completion of Alpha testing
 * By another set of prospective customers

Acceptance testing at different levels

 * During Component testing - to verify its usability
 * During Integration testing - while installing it or integrating with another application
 * Before System testing - when new feature is added to existing application

Different types of Software Testing
There are different Test types:
 * Functional Testing - tests the functionality of a selected component
 * Non-functional Testing - tests the behavioral or the quantified characteristic of the system and software
 * Structural Testing - tests the structural aspects of the component
 * Regression Testing - tests modified software to ensure that none of the existing functionality was altered unintentionally
 * Maintenance Testing - tests changes and the impact of a modified operational system on existing environment

Set of characteristics under functional software testing
Based on the International organization for Standardization (ISO) quality standard 9216 that regulates testing (ISO/IEC 9216), Functional testing is performed for various characteristic, such as
 * Suitability - Tests if the product perform according to specifications
 * Accuracy - Tests to ensure that the faulty products are not passed to users
 * Interoperability - Tests if the product can work on multiple systems
 * Security - Tests if the product is sheltered from threaten, such as viruses and other malicious software
 * Functionality Compliance - Tests to determine whether the system adheres to certain specified criteria, such as standards, conventions, regulations, or laws

Two perspectives of functionality testing

 * Requirement-based testing
 * Business-process-based testing

Types of non-functional testing
It comprises various types of testing Tests the degree to which a system fulfills its specified functions within given constrains Measures the behavior of a system by increasing its load Evaluates the system at and beyond the boundaries of its specified requirements Tests how easily a user can perform a specific task Tests how easily a product can be modified in the future Tests how reliably a product perform over a given period of time Tests how easily a system can be transferred from one platform to another
 * Performance Testing
 * Load Testing
 * Stress testing
 * Usability Testing
 * Maintainability Testing
 * Reliability Testing
 * Portability Testing

Set of characteristics under non-functional software testing
ISO/IEC 9216 states following characteristics of non-functional testing
 * Reliability
 * Maturity
 * Fault Tolerance
 * Recover-ability
 * Reliability Compliance
 * Usability
 * Understandability
 * Learnability
 * Operability
 * Attractiveness
 * Usability Compliance
 * Efficiency
 * Time Behavior
 * Resource Utilization
 * Efficiency Compliance
 * Maintainability
 * Analyzability
 * Changeability
 * Stability
 * Testability
 * Maintainability Compliance
 * Portability
 * Adaptability
 * Installability
 * Co-Existence
 * Replaceability
 * Portability Compliance

Structural Software testing
After functional testing, we perform structural testing It complements functional testing by measuring amount of and the thoroughness with which the functional tests were executed. These tests are based on the logic of the application, regardless of the requirements and specifications. Structural testing is also known as 'White-box' or 'Glass-box' Testing Can be carried out at all test levels.

Structural testing at various levels
Structure is that of code itself such as statements or decisions Structures could be call tree where one module calls other Structures may be a menu structure, a business process or a web page structure
 * Component level (based on the structural aspects of the program such as code in the program)
 * Component integration level (based on the architecture of the system, such as a calling hierarchy)
 * System testing ''(based on structure of system after integration of all the components)

Test Suite
It is a set of several test cases, where the post-condition of one test case serves as the precondition of the next test.

Test Coverage
Structural tests measure amount of testing done by checking coverage items ''(set of structural elements). For adequate testing, one need to execute all the elements such as statements, branches, conditions, decisions, and paths in the code one by one. The coverage is expressed as a percentage of the items being covered. It determines the depth of usage of test suite

Code coverage
It determines parts of coverage that are tested or omitted

Structure-based/ White-box techniques
Used to implement structural testing They are based on an analysis of a component or a system Examples of code-related testing at the component level :
 * Control-flow testing
 * Data-flow testing

Regression Software Testing
But confirmations testing itself doesn't guarantee a quality of the product, because after defect is fixed or debugged the new version of software is said to have regressed with respect to former version.
 * Confirmation Testing : During product development, whenever ant defect is discovered and fixed or debugged, one have to retest that debugged component by re-executing the test cases that failed last time. This type of retesting is called Confirmation testing.
 * Regression Testing : A set of Regression tests are designed to test regressed software that confirms the system works as expected. And the testing is called as Regression testing

Types of Regression

 * Local Regression - a change or a bug fix in the existing software creates a new bug
 * Exposed Regression - a change or a bug fix in the existing software reveals an existing bug
 * Remote Regression - any change or a bug fix in one area triggers an error in another area of the system

Regression Test Suite

 * A set of test cases where post-conditions of one test case is used as preconditions of next one. These test cases perform an overall testing of each of the most important functions in a system. As same set of test cases are used every time, the test cases can be used for automation.
 * It is important to maintain the test suite so it stays updated with latest software. So whenever new functionality added to software, new regression tests should also be added and older and irrelevant tests should be removed.

Strategies to capture defects in the regressed software
 * Repeating all tests - if have sufficient time and resource. automation helps here
 * Repeating some of the tests - if its not possible to repeat all tests
 * Using Cross-functional tests - to capture accidental regression
 * Releasing the product in various phases - by releasing updates on the product in phases
 * Having other users testing the product (Beta testing) -

Techniques for strategy of repeating tests

 * Traceability (to select tests based on technical risks)
 * Change analysis (to select tests based on technical risks)
 * Quality risk analysis (to select tests based on business risks)

Maintenance Software Testing
For a product, which is deployed and in use for number of the years, maintenance work to be carried out on its components. This maintenance work may be to correct defects, to improve performance or to adapt the product to a modified environment. Maintenance testing is a type of retesting carried out to confirm that this modified product is defect free once again.

Main reasons for using Maintenance testing

 * Modification
 * Migration
 * Retirement of the system

Classification of modifications (from testing point of view)

 * Planned modifications
 * Perfective planned modifications
 * Adaptive planned modifications
 * Corrective planned modifications


 * Ad-hoc corrective modifications

Tests carried out during Maintenance testing
Ideally maintenance testing should test all the changes made to the system and the working of the entire system itself. But to reduce amount of regression testing one should always determine the parts of the system that could be affected. Analyzing the impact of the changes on the system is called as Impact analysis Activities aimed at reducing the time taken for regression testing are,
 * Confirmations tests
 * Regression tests
 * Performing risk analysis
 * Checking for the product's original test specifications

Differences between Maintenance testing and regular testing
There are some specific differences between maintenance testing and regular testing for new product. These differences are due to some factors, such as Maintainability testing is different from Maintenance testing. It determines ease of maintenance of the system.
 * Test types
 * Test triggers
 * Issues faced
 * Test Oracle : It helps determine the expected output results for the software.

Softeware Testing Terminologies

 * Smoke Testing and Sanity Testing


 * Ad hoc/Monkey/Peer Testing


 * Partitioned Testing

Adding some known defects in order to estimate the efficiency of tester,then it is called Be bugging or Defect Seeding or Defect Feeding
 * Be bugging/ Defect Seeding/ Defect Feeding
 * Rattle Testing/ Build verification Testing

The standard deliverables provided as part of testing are: Test Trace-ability Matrix Test Plan Testing Strategy Test Cases (for functional testing) Test Scenarios (for non-functional testing) Test Scripts Test Data Test Results Test Summary Report Release Notes Tested Build
 * Test Design Phase Deliverable
 * Coverage Management


 * Test Coverage criteria


 * Configuration Management System


 * Test Scenario/ Test Script/ Test Run


 * Test Approach for an application


 * Kick off Phase


 * Master Test Plan


 * What is 'Deferred' in Testing


 * Defect Density


 * Test Estimation


 * Transmittal Report


 * Quality Assurance


 * Quality Center


 * Test control action


 * Smoke/Sanity Testing
 * System Testing/ User Acceptance Testing
 * Usability Testing/ User Acceptance Testing
 * Black Box/White Box Testing
 * Transmittal Report
 * Partitioned Testing
 * Test Case/ Test Suite/
 * Test Scenario/ Test Script/ Test Run
 * Be bugging
 * Alpha/Beta Testing
 * Rattle Testing/ Build verification Testing
 * Quality Center
 * What is 'Deferred' in Testing
 * Defect Density
 * Test Design Phase Deliverable
 * Kick off phase
 * Ad hoc/Monkey/Peer Testing
 * Test Estimation
 * Master Test Plan
 * Test control action
 * Coverage Management
 * Configuration Management System
 * Test Coverage criteria
 * Test Approach for an application

General Awareness
HISTORY WORLD ECONOMICS POLITICS SPORT ENTERTAINMENT LITERATURE