Module 5 Test Management

By K.N.Sasidhar

Test Management
• • • • • • Test Organisation Test Planning and Estimation Test monitoring and control Configuration management Risk and Testing Incident Management

Test Organisation:

• Organisational structures for testing • Test Team composition

Organisational structures for Testing:
There are many different organisational structures within IT for testing Testing can be the responsibility of: • The Developers • The development team(‘buddy’ testing) • One person within the team • A dedicated test team • Internal test consultant • A separate Organisation

Test Team Composition:
• • • • • • • • • • • • The Client – The Project sponsor The Project Manager The User The Business Analyst The System Analyst The Technical designer The Developer / Programmer The Test manager The Independent tester The auditor The trainer The Technical Writer

• The support and help teams

Configuration Management(CM)
• • • • • • What is configuration management Symptoms of Poor Configuration management Configuration Identification Configuration Control Status Accounting Configuration Auditing

CM – Definition: “A disciplined approach in the management of software and the associated design, development ,testing,operations and maintenance of testing” • Change management and Configuration management – both are not quite the same. • Change management manages the changes made to items and configuration management manages all the items and the status of all the items of the system as a whole.

Symptoms of poor CM:
• Unable to match the program source code and object code • Unable to identify source code changes for a particular version of software • More than one person changing the same source code at the same time for different reasons • Source documentation changes made without developers being aware • Source documentation changes made without saving the previous version • Unable to determine what testing was performed for a release of software

Symptoms of poor CM: • Which can lead to:
– Error-prone code – Missed deadlines – Applications that do not reflect(changed) requirements – Applications that are difficult to maintain

CM Activities:
• • • • Configuration Identification Configuration control Status accounting Configuration auditing

“Configuration Identification is the process of identifying all the items within a project that are going to be subject to version control”. All details of the items need to be recorded including the status and version.

Configuration control:
• The maintenance of configuration Items over time • A process where by configuration Items are - Requested for check out - Checked out - Requested for check-in - Approved or disapproved for check-in - Checked in

Status Accounting • Recording and reporting on the status of configuration items • Includes initial approved versions,status of requested changes and implementation status of approved changes • Gives the ability to see the current state of a configuration item

Configuration Auditing • The Verification that the configuration management process is being adhered to • The verification that configuration items reflect their defined physical and functional characteristics.

Test Estimation,Monitoring and Control
• Test Estimation – why,what, and how ? • Test Monitoring – why and how ? • Test Control

Test Estimation - Why ? • To determine how long activities are likely to take • To determine resource requirements • To understand task dependencies • To determine overall project timescales • Always remember contingency!!

Test Estimation - What ? • • • • • • Reviews Planning Specification Execution Recording Checking

Test Estimation - How ?

• Metrics Database • Completed plans from previous projects • Experience

Test Monitoring – Why ? • To determine Progress - Are our test plans complete? - Are our test cases complete? - What have we tested ? - What has tested and passed ? - What has tested and failed? - What have we still got to test ? - ……

• Test Monitoring – Why ? -…… - To determine deviations from estimations - To make adjustment to estimates if required. - To enable the management of product and project risks - To enable management reporting

Test Monitoring – How ?

• • • •

Percentage of test executed Pass/fail rate of tests Number of defects found / resolved. Business process ‘fit for purpose’.

Test control
• • • • • To control we must monitor Understand the current position of testing Recognize problem areas Increase or divert resources if necessary De-scope or delay if we have to

Incident Management We will cover… What is an incident ? Incidents and the test process Incident Logging Beiger grading of incidents Tracking and Analysis

Incident Management What is an Incident ? • A problem or a query arising during the testing process • An incident is typically when the expected results and actual results of a test differ • Incidents can also be raised against system documentation • An incident can be raised at any point during the SDLC

Incidents and the Test Process

• Can assist managers in determining testing progress • Incidents statistics can help improve the testing process

Incident Logging • • • • • • • • • • • • Incident Identification Date incident raised Classification System reference Status code Priority code Incident description Software release Who raised the incident Who the incident is assigned to Departments involved Closure date

Beizer Grading of Incidents:
• • • • • • • • • • Mild Moderate Annoying Disturbing Serious Very Serious Extreme Intolerable Catastrophic Infectious

Incident Tracking and analysis Incidents should be tracked from inception through to resolution • • • • What is its current status? Who currently own this incident? How long have they had it? Closure version etc…

All information entered about an incident should be retained.

Incident Tracking and analysis Incident data provides the ‘raw material’ for testing and analysis • Ho many incidents are outstanding? • How many high priority incidents are there? • Where are most incidents occurred? • What is the turn around time for fixing incidents?

Standards for Testing
• QA standards Specify testing to be done : ex-ISO 9000 • Industry specific standards Specify the level of testing to be done(how much) ex: FAA • Testing standards Specify ho the tests should be done BS 7925-1,BS 7925-2

Risk and Testing
Risk can be defined as the chance of an event,hazard,threat or situation occurring and its undesirable consequences,a potential problem. The level of risk will be determined by the likelihood of an adverse event happening and the impact (the harm resulting from the event) Risks are used to decide where to test more thus reducing the impact… A risk based approach to testing provides proactive opportunities to reduce the levels of product risks.

Project risks Project risks are the risks that surround the project’s capability to deliver its objectives,such as • Supplier issues: - failure of a third party • Organisational factors: - Skill and staff shortages - Personal and training issues - Political issues ( occurs in reviews or not following up wrt project issues) - improper attitude towards testing • Technical issues: - the quality of design, not defining the right requirements, code etc

Product Risks Potential failure areas in the software or system are known as product risks, as they are a risk to the quality of the product,such as: - Error-prone software delivered - the potential that the software/hardware could cause harm to an individual or company - poor software characteristics - software that does not perform its intended functions

Sign up to vote on this title
UsefulNot useful