Pages

Monday, March 5, 2012

Test Planning Overview

At the end of this session, you will be able to understand:
       Test Strategy – Objective, scope , entry / exit criteria
       Test Plan – Risk Analysis, Roles & Responsibilities , Schedule
       Test Estimation techniques (FTP , TCP)
       Test Specification / Cases
       Sample Test Objective
       Major elements of Test Plan
       Test Planning Tips

What is Test Strategy ?
       Very high-level document showing direction
       Indicates approach and communicate objectives
       Defines responsibilities
       Highlights uniqueness of the system or application to be tested
       Can be defined early in a project
       Is a basis for all other test planning
       The methods, techniques and tools to be used
       Entry and Exit criteria

Key Test Planning components



Test Strategy
Strategy Developers
       Project Managers
       Test Leads
       Test Analysts and Test Engineers
       Users and Customers
When to Start Developing Test Strategy ?
       As early as possible in the project
       Even though requirements are not freeze
       While participating in Hot House or Brainstorming sessions
       While discussing with Stakeholder

Test Strategy
Benefits
       Testing begins early in the project lifecycle
       Clear views of scope, objective & purpose
       Testing is done in organized and planned manner
       Test with correct view and identification of risk
       Arrange for the resources early

Test Strategy
       Test Strategy Components
       Type of project
       Type of Software (GUI, Object Oriented )
       Assumptions
       Purpose of testing
       Testing priority
       Strategy specific to release
       Scope of testing
       Critical success factures
       Phases of testing
       Types of testing
       Development and test tools
       Timelines
       Tester profiles
       Business and operational concerns
       Risks (Business, Technical and project)
       Constrains
       Any other information

Test Strategy
How to Develop ?
       Start early – even before requirements definition, if possible
       Involve representatives from:
      Development
      Testing
      QA
      User groups
      Customers (Internal and/or external)
        Use a standard or template
        Brainstorm the topics in the standard
        Review and discuss the strategy
The Strategy needs to be reviewed for –
      Completeness (Inputs from right people or any gaps ?)
      Level of details
      Accuracy

Test Strategy
       Publish the Test Strategy when reasonably stable and get it approves by senior management, stakeholders
       What if there is need to change Test Strategy?
       Find the changes and the reasons for it
       Understand the impact of testing caused by changes
       Changes should be reflected in updated Test Strategy
       Republish the Test Strategy for the audience after approval

Risks
       Risk is uncertain event which if occurred will have effect on the achievement of the project or business objective
       Types of Risks
                                Business Risk
                                Project Risk
                                General Risk
       Risk / Issue
                ‘That may happen’ implies a probability of less then 100%.
                 If it has a probability of 100% - in other words, it will happen – it is an issue.
                Risks can become issues if they are not addressed effectively.

Risk Management Process



Risk Management
       Risk management – minimize both the frequency and impact associated with risks.
       First part is to understand, identify and determine the magnitude of risks
       Second part is determining risk appetite – amount of loss management is willing to accept for a given risk.
        Two activities associated with Risk Management
                                1) Risk Reduction Methods –
                                Loss Due To Risk = Frequency of occurrence * Estimated Loss in terms of Rs / $ per                occurrence
                                Reduce Opportunity for error – Minimize Loss
                                Identify Error Prior to Loss – Recover Loss
                                2) Contingency Planning – Action plan
        Tester to evaluate the adequacy
        It should be part of the test plan and testing process

Risk Identification
       Risk identification should be undertaken in the project initiation phase and revisited regularly throughout the project lifecycle
       Identify the risks and the risk category, source under which the risks can be grouped.
       PM should refer the Organization Risk database and look at the common risks
       Create a list of identified risks using the Risk Register template
       Some of the risk categories with few examples of risk sources



       Test Manager to identify potential risks that might impact testing:                
                                Not enough Training
                                Us versus Them mentality
                                Lack of Test Tools
                                Lack of Management Understanding / Support of Testing.
                                Lack of Customer and User involvement
                                Not enough time for Testing.
                                Over-reliance on Independent Testers.
                                Rapid change
                                Having to say, “NO”
                                Test Environment
                                New Technology
                                New Development Processes

       Risk Analysis    
Four Step Process
       Form the Risk Analysis Team
       Identify Risks
       Estimate the magnitude of the Risk
       Select Testing priorities

       Risk Planning   
       Identify the approach to handle the risk. It could be one or more of the following:
                                To Eliminate risks (Avoid, Transfer)
                                To Mitigate risks
                                To Accept the risk and develop contingency plans
       Based on the approach, plan the alternative sets of actions that can be taken and the ownership for executing them.
       Define the events/ triggers or the periodicity at which the risk exposure will be reviewed and recalculated if necessary,
       Define the threshold (Impact*Probability) beyond which to initiate action
       Define the various possible actions that would be initiated

       Risk Tracking and Control            
       Risk tracking monitors the status of specific risks and the progress in their respective action plans.
       Risk tracking also includes monitoring the probability, impact, exposure, and other measures of risk for changes that could alter priority or risk plans and project features, resources, or schedule.
       Risk tracking also includes Risk Reporting to ensure that all the relevant stakeholders are aware of the status of project/program risks and the plans to manage them.
       Risks are used to decide where to test more thus reducing the impact

Risk Register



       Managing Schedule
       The project schedule is the core of the project plan.
       The project schedule is a calendar that links the tasks to be done with the resources that will do them.
       Before a project schedule can be created, the project manager must have a work breakdown structure (WBS), an effort estimate for each task, and a resource list with availability for each resource.
       A WBS is a fundamental technique for organizing the scope of a project, using a hierarchical tree structure.

       Scheduling Process
       Create WBS
       Allocate Resources to the Tasks
       Identify Dependencies
Create the Schedule

       Estimation
       Estimates can be difficult for the reason is that estimates are often asked early in a project that might not know enough information to provide a close to accurate estimate
       Some golden rules for estimates –
                                Estimation shall be always based on the software requirements
                                It should be based on expert judgment
                                Reference previous projects
                                Metrics based
                                Should be supported with tools

       Estimation
Why wrong null?
                Lack of clarity of requirements
                Nonavailability of baseline for estimations
                Lack of experience in estimation
                Lack of knowledge of scientific and standard estimation techniques
                Lack of time for estimation
                Working towards a suggested value
                Not knowing what an estimation methodology includes and what it excludes
                Lack of application knowledge (many know the theoretical aspect)

       Basic Estimation Components




       Top null Approach
       Bottom null Approach

Commonly used estimation techniques
       Function Point Analysis (FPA)
       Complexity-based estimation
       Estimation by analogy
       Activity based estimation
       Wideband Delphi
       Test Case Point (TCP)
       Use Case Point (UCP)
       User Story Point (USP)
       Function Test Point (FTP)

Maximizing ROI – Testing

Risk Factors and Quality Attributes
       How testing adds value?
                The value of testing derives from identifying problems that would have a cost or other adverse impact on an organization if they remained in a system at implementation time.
       By starting early
                testing should begin at the ideas or user requirements stage in a project, rather than waiting for early code development. It is generally accepted that the cost of detection for a fault is lower at the start of the development life cycle than it is at the end.
       A reduction in software project costs (i.e., an increase in productivity) either directly or through reducing rework.
       The delivery of higher quality software and consequently reducing the customer's cost of ownership

Risk Factors and Quality Attributes
       Losses from Defects
                Lot of re-work efforts are spent to fix the defects as a result cost of low quality can by              
               high
                In some cases, estimates of re-work may take more than half of the development cost
                More resources are put in fixing work which will result in not addressing other       
               demanding customers
               Quality and profitability relationship is complex. If quality is kept improving           
               relentlessly, it may not necessarily mean profits will increase indefinitely. Fine balance         
               should be obtained between the two

Risk Minimization Approaches
       Risk Minimization and ROI
       Find the most important defects
       Find the defects in early stages
       Find the defects that require most re-work time first
       Efficient use of resources
       Accurate quality advice/suggestions
       Arriving at method for determining when an application/product can be released
       Use variations in testing techniques to find more bugs
       It requires that we understand standards as they relate to how our clients value the product
       Exploratory testing is a useful approach for analyzing risk and Scripted testing is better suited for tracking known risk.

No comments:

Post a Comment