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