Skip to main content

Development

Make the quality measurable

This blog briefly talks about the situations which may lead to the difficulty of measuring a product’s quality.

Most of time, when producing a product such as an iPad, there are very detailed metrics that can be used to determine the product’s quality. For a project generating a software system, there should also be such detailed quality metrics in place when the project starts. Unfortunately, this is not always the case on some projects.

 

There are several possible situations where the quality cannot be measured effectively:

  • The Business Analyst hasn’t gathered the requirement completely

On a recent project, our GDC team was required to work on an independent performance testing project. Prior to the start of the project, we asked for any specific performance expectations from customer such as resource usage, response time, user load, etc. We were told that the customer didn’t specify that. As a result, we had to use test results of first time test execution as the benchmark. Typically, the benchmark should come from an existing live system provided by customer. In this case, the customer may forget to mention that but the BA should remind the customer to provide such data.

  • The project startup plan was not well planned

Usually, when planning a project, we need to think about one question: when should we stop testing? The answer to the question will lead to the quality gate of acceptance testing which can be further broken down into measurable quality metrics. However, there are situations where this has not been well defined for the project, which leads to a situation that the team has no idea when the testing should stop.

  • The triage bar is not defined

The missing of triage bar may also result in a situation where quality may not be measured properly. A typically project may define the pass of user acceptance testing as “no major or above defect”. However, if the triage bar (the description of blocker/critical/major/minor/trivial) has not been defined properly and shared within the team the quality of the product may not be fairly measured as well.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Diego Zhong

More from this Author

Follow Us