Software Quality Assurance - Testing Tools

To deliver quality software product, quality has to be assured in each and every phase of the development process. In many organizations, there will be a separate Software Quality Assurance (SQA) team that audits the work of the various development teams to ensure that the process definitions are followed strictly. In small organizations, the development engineers themselves need to do the quality assurance work. Whatever be the organizational structure, the most important point is that the output of each phase should be of very high quality. The SQA team is responsible to ensure that all the development teams follow the processes. The output of a phase should not be described on qualitative terms—we should have quantitative measures. These quantitative measures or "metrics" will be discussed in the next section.

Metrics in Software Development

In every engineering discipline, measurement is an important activity. Just as we quantify weight, height etc. and use units such as gram, centimeter, to represent various parameters; in software engineering, measures (or metrics) are used to quantify various parameters. The software metrics help in

  • Estimation of size and complexity of the project.
  • Tracking the progress of the project.
  • Analyzing the effectiveness of the software process and taking corrective action if necessary.
  • Measuring the productivity of the people.

In software industry, it is said that you cannot manage what you cannot measure. For an effective management of the software projects, the metrics are very important. Some important software metrics are described in this section.

The Person Month

The effort required for execution of a project is measured in Person Months (PMs). If a person works for one month, the effort is one PM. If 6 people work on a project for one year, the effort is 72 PMs. Though the exact time a person works in a month may vary, on an average, 154 hours can be assumed. (22 days at the rate of 7 hours per day, excluding one hour for social formalities, gossip, tea breaks etc.) If the complexity of the project is estimated in terms of PMs, it is easy to calculate the cost in terms of dollars, if the rate per person hour is known (or assumed).

Product Metrics

To estimate the size of a project is very difficult task. One accepted method of estimating the product size is using the metric KDSI (Kilo or Thousand Delivered Source Instructions) or Kilo Lines of Code (KLOC)—how many thousands of lines of code are required for the project excluding the comments.

Based on the KDSI, a project can be categorized as small, intermediate, medium, large or very large:

Small <= 2 KDSI Intermediate >2 and <= 8 KDSI Medium > 8 and <= 32 KDSI Large > 32 and <= 128 KDSI Very large > 128 KDSI

In database management system (DBMS) projects, the project size can be measured in terms of number of tables, forms, and reports.

Productivity Metrics

The number of lines that can be written by a programmer in one hour can be used as a metric for measuring the productivity of the programmer i.e., the Delivered Source Instructions (DSI) per hour. Using the size of the project in KDSI and the average productivity of the programmer, the time required to execute a project can be calculated as below.

Time required for execution of a project (in hours) = Total KDSI of the project / (average KDSI per hour)

Another metric used for productivity is the number of defects removed per hour by a programmer.

However, it needs to be mentioned that organizations should not judge the performance of individuals based on these metrics. These metrics must be used only to estimate the time required for the execution of the project or time required to remove the defects etc.

Quality Metrics

To measure the quality of the product, the following metrics can be used: Number of defects found per KDSI (known as defect density) Number of changes requested by the customer after the software is delivered. MTBF (Mean Time Between Failures) i.e., the average time between failures.MTTR (Mean Time to Repair) i.e., the average time required to remove a defect after it is detected.

To measure the quality of the output of a development phase, the SQA.team has to define the metrics. For instance, during the requirements engineering phase, SRS document is written. Then design, implementation, and testing are done. While doing the design or implementation or while carrying out the testing, the SRS document may have to be changed. The number of changes made to the SRS document can be a metric to measure the quality of the requirements engineering process. Similar measures can be worked out for the design, implementation, and testing phases as well. The SQA team has to define and measure the software metrics at every stage of software development.

Note: The product quality metrics are different from process quality metrics. The product quality metrics reflect the quality of the product whereas the process quality metrics reflect how well the process isdefined.

Documentation

Many engineers dislike documentation work. However, the SQA team has to ensure that enough documentation is available at each stage of the project. The documents delivered at important milestones of a project are known as Work Products. Some important work products that need to be made available at various stages are:

  • Project proposal
  • Project agreement
  • Project plan document
  • Software requirements specification document
  • Design document
  • Configuration management document
  • Test plan
  • Quality assurance plan
  • User manual
  • Source code with enough on-line comments
  • Test reports
  • Maintenance manual

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

Testing Tools Topics