Faulty Assumptions in Quality Engineering

July 1, 2019

---

Introduction :

A software quality is measured by gathering the test results. It is done with the help of quantitative evaluation methods like reliability growth models, that takes into account time as a factor to monitor the quality of the software. This analysis is based on empirical data and model assumptions that describes the way faults are detected and repaired. Another dimension to detecting faults lies in the qualitative approach which is also called probable approximate correctness analysis. This analysis technique generally emphasises on the fact that the quality estimation is accurate.

There are a lot of error prone assumptions that we tend to make in the process of quality analysis, that may sometimes result in an inappropriate outcome. Actually there are few facts that underlies the assumptions. We list the following factors that generally form the basis on which we derive a perception.

• Assumption 1 : Quality requirements dictates the schedule -Fact : Prevailing competition in the market and other market factors govern the schedule.

  The traditional ways of software development proves to be inefficient in the current scenario because the market is dynamic and prone to changes. The present market situation is highly competitive and volatile.

• Assumption 2 : Quality determines reliability -Fact : Reliability is the only parameter for measuring quality.

  It is not true that the software product needs to be 100% reliable. It states that a software product is acceptable and has met the quality criteria if it does not result in a bug. A failure is not considered a bug if it does not create an obstacle in achieving the required results. However security is one aspect other than programming that must not be compromised with. The people involved in software development should be aware of the important aspects and proceed with the development process accordingly.

• Assumption 3 : Users appropriately know their demands - Fact : Users are not very feature specific. This statement stands true for business software products. Due to very unclear or vague feature specifications, the product development often gives rise to a phenomena called feature bloat.

  It is basically the developer's duty to analyse all possible features that could be integrated into the product. A customer may be concerned with the functionality to attain a certain kind of output but they may not be able to break down one feature into sub features.

• Assumption 4 : Comprehending the requirements to be correct -Fact : A very common scenario is that designers try to design an application using the newest technology which is often poorly understood. Therefore flow of the program is generally based on guesses.

  To understand the requirements and design the structure of the entire application demands a great deal of experience, a design cannot be preplanned or there can't be a written document for the same. The idea of how to develop a design as per a user's requirements develops over time.

• Assumption 5 : Users will accept product if it suffices feature and reliability criteria -Fact : To deliver a product that exceeds customer expectations is an aim developers look forward to.

  In order to survive in a generation of high degree of competency, we need to be one step ahead in planning a development strategy. A software should apparently be something that solves the intended purpose in a unique fashion. Simply stating the fact, a user should be in a position to distinguish their own product from its counterparts.

• Assumption 6 : Product maturity is required -Fact : Customer's buying decision is not determined by a product's maturity. Price and availability are the two most important factors that play a crucial role in business scenarios.

  When we talk about maturity of a software product, we must take feature maturity into consideration in contrast to product maturity, as that aspect will ultimately lead to gaining a competitive edge over the competitors. For instance, we may come to realise that there are so many software systems that are available with few features on the internet, free of cost. Whereas the same product's various other features are available at a certain price, if the user wishes to avail the rest of features. But it has been observed that a lot of users are keen on purchasing a given software system to be able to attain their goals with the help of various features. However the users tend to pay for the ones that may not be worthy of a penny for them, as it is of no use to their work. Therefore, it is a matter of concern as to which feature caters to the needs of the end user. That is why, feature maturity is a noteworthy part of the development and deployment process.