| Every software development company
| |
| | Performance Levels
|
| focuses on developing quality software.
| |
| | Data Structures/Elements Safety
|
| The only way to track the software
| |
| | Reliability
|
| quality isevaluating it at every stage of
| |
| | Security/Privacy
|
| its development. It requires some kind of
| |
| | Quality
|
| metrics, which is obtained through
| |
| | Constraints & limitations
|
| effectivetesting methods. Each stage of
| |
| | Next comes the updating of the crucial
|
| software testing is effectively monitored
| |
| | requirement trace-ability matrix or RTM,
|
| for the software QA.
| |
| | which determines the number and types
|
| 1. Software measurements are used for:
| |
| | oftests.
|
| 2. Deriving basis for estimates
| |
| | While measuring the mapping of test
|
| 3. Tracking project progress
| |
| | cases, the number and priority of
|
| 4. Determining (relative) complexity
| |
| | requirement it tests, its execution
|
| 5. Understanding the stage of desired
| |
| | effort andrequirement coverage must be
|
| quality
| |
| | determined.
|
| 6. Analyzing defects
| |
| | The Requirement compliance factor (RCF)
|
| 7. Validating best practices
| |
| | measures the coverage provided by the
|
| experimentally
| |
| | test cases to one or set of
|
| Here, some software testing metrics are
| |
| | requirement(s).
|
| proposed for black box testing that has
| |
| | Mathematically,
|
| real world applications. It discusses:
| |
| | RCFj=∑(Pi*Xi)
|
| Importance of software testing
| |
| | (maxXi)*(∑Pi)i=1
|
| measurement
| |
| | Where,j is a set of requirements and
|
| Different techniques/processes for
| |
| | (j=1-m);
|
| measuring software testing
| |
| | Xi=2, if the test case (say Tj) tests
|
| Metrics for analyzing testing
| |
| | requirements Ri completely,
|
| Methods for measuring/computing the
| |
| | =1, if it tests partially,
|
| metrics
| |
| | =0, if otherwise.
|
| Advantages of implementing these metrics
| |
| | Effectiveness=RCFj/Ej where Ej=Time
|
| These metrics helps in understanding the
| |
| | required for executing a test case
|
| inadequacies in different software QA
| |
| | 4. Evaluating estimation accuracy
|
| stages and finding better
| |
| | Relative error=(A-E)/A where E is
|
| correctingpractices.
| |
| | estimate of a value and A is actual
|
| What is measurement and why it is
| |
| | value.
|
| required?
| |
| | For a collection of estimates, the mean
|
| The process of assigning numbers or
| |
| | RE for n projects is
|
| symbols to attributes of real world
| |
| | __ n
|
| entities for describing them according to
| |
| | RE=1/n∑REii=1
|
| definedrules is called measurement.
| |
| | For a set of n projects, the mean
|
| For developing quality software, several
| |
| | magnitude of RE (MRE) is
|
| characteristics like requirements, time
| |
| | ___ n
|
| and effort, infrastructural
| |
| | MRE=1/n∑MREii=1
|
| cost,requirement testability, system
| |
| | Of a set of n projects, an acceptable
|
| faults, and improvements for more
| |
| | level for MRE is less than 0.25.
|
| productive resources should be measured.
| |
| | If K is the number of projects whose mean
|
| Measuring software testing is required:
| |
| | magnitude of relative error is less than
|
| 1. If the available test cases cover all
| |
| | or equal to q,then the prediction quality
|
| the system's aspects
| |
| | pred(q)=K/n
|
| 2. For tracking problems
| |
| | 5. Measurement of Efficiency in testing
|
| 3. For quantifying testing
| |
| | process
|
| Choose the suitable metrics
| |
| | In software testing, we must keep tabs on
|
| Several metrics can measure
| |
| | what we had planned and what we have
|
| software-testing process.
| |
| | actually achieved for measuring
|
| Here, the following types of metrics are
| |
| | efficiency.
|
| identified:
| |
| | Here, the following attributes play major
|
| Base metrics:
| |
| | roles: -
|
| These raw data are collected in a testing
| |
| | Cost: The Cost Variance (CV) factor
|
| effort and applied in formulae used to
| |
| | measures the risk associated with cost.
|
| derive Calculated Metrics.
| |
| | CV=100*(AC - PC)/PC, AC=Actual Cost,
|
| The Test Metrics comprise of the Number
| |
| | PC=Planned/Budgeted Cost.
|
| of
| |
| | Effort: Effort Variance (EV) measures
|
| Test Cases Passed, Failed, Under
| |
| | effort.
|
| Investigation, Blocked, Re-executed and
| |
| | EV=100*(AE - PE)/PE
|
| Test Execution Time.
| |
| | (AE=Actual Effort, PE=Planned Effort)
|
| Calculated metrics:
| |
| | Schedule: Schedule Variance (SV) is
|
| They convert the Base Metrics data into
| |
| | important for project scheduling.
|
| useful information. Every test efforts
| |
| | SV=100*(AD-PD)/PD where AD=Actual
|
| must implement the following Calculated
| |
| | duration and PD=Planned duration.
|
| Metrics:
| |
| | Cost of quality: It indicates the total
|
| % Complete
| |
| | effort expended on prevention, appraisal
|
| % Defects Corrected
| |
| | and rework/failure activities versus
|
| % Test Coverage
| |
| | allproject activities.
|
| % Rework
| |
| | Prevention Effort=Effort expended on
|
| % Test Cases Passed & Blocked
| |
| | planning, training and defect prevention.
|
| % Test Effectiveness & Efficiency
| |
| | Appraisal Effort=Effort expended on
|
| % 1st Run Failures
| |
| | quality control activities.
|
| % Failures
| |
| | Failure effort=Effort expended on rework,
|
| Defect Discovery Rate
| |
| | idle time etc.
|
| Defect Removal Cost
| |
| | COQ=100*(PE + AE + FE)/Total project
|
| Measurements for Software Testing
| |
| | effort.
|
| The corresponding software testing
| |
| | Product -
|
| process in software development measures
| |
| | Size variance: It is the degree of
|
| each step for ensuring quality product
| |
| | variation between estimated and actual
|
| delivery.
| |
| | sizes.
|
| 1. Software Size:
| |
| | Size Variance=100*(Actual Software
|
| The amount of functionality of an
| |
| | Size-Initial Estimated Software Size)
|
| application determines this and is
| |
| | Initial Estimated Software Size
|
| calculated by
| |
| | Defect density: It is the total number of
|
| Function Point Analysis
| |
| | defects in software with respect to its
|
| Task Complexity Estimation Methodology
| |
| | size.
|
| 2. Requirements review:
| |
| | Defect density=Total number of defects
|
| Before software development, the Software
| |
| | detected/software size
|
| requirement specifications (SRS) from the
| |
| | Mean Time Between Failures: MTBF is the
|
| client are obtained. It must be:
| |
| | mean time between two critical system
|
| Complete
| |
| | failures or breakdowns.
|
| Consistent
| |
| | MTBF=Total time of software system
|
| Correct
| |
| | operation/Number of critical software
|
| Structured
| |
| | system failures.
|
| Ranked
| |
| | Defects: Defects are measured through:
|
| Testable
| |
| | Defect distribution: It indicates the
|
| Traceable
| |
| | distribution of total project defects.
|
| Unambiguous
| |
| | Defect Distribution=100*Total number of
|
| Validate
| |
| | defects attributed to the specific phase
|
| Verified
| |
| | Total number of defects.
|
| The Review Efficiency is a metric that
| |
| | Defect removal effectiveness: Adding the
|
| offers insight on the review quality and
| |
| | number of defects removed during the
|
| testing.
| |
| | phase to the number of defects found
|
| Review efficiency=100*Total number of
| |
| | laterapproximates this.
|
| defects found by reviews/Total number of
| |
| | Benefits of implementing metrics in
|
| project defects
| |
| | software testing:
|
| 3. Effectiveness of testing requirements:
| |
| | Improves project planning.
|
| It is measured by maintaining Requirement
| |
| | Understanding the desired quality
|
| Trace-ability matrix and specification of
| |
| | achieved.
|
| requirements, which should have:
| |
| | Helps in improving the processes
|
| SRS Objective, purpose
| |
| | followed.
|
| Interfaces
| |
| | Analyzing the associated risks.
|
| Functional Capabilities
| |
| | Improving defect removal efficiency.
|
