Thinking about software quality-what is quality?

Thinking about software quality-what is quality?

When choosing a product, one of the words we often put on our lips is "quality", which is an important indicator that affects our choices. In this article we will discuss what is the quality of the software. Of course, are some of the individual views, do not agree to be able to shoot bricks or to discuss.

The word quality is too common to confuse, sometimes it means quality, sometimes it implies good quality. and inevitably, good quality is often associated with its negative side, as if the previous "Quality Miles", or now 3.15, listed are quality problems, it seems that very little to promote quality products. So most of the time, we look at the quality from the opposite side (defects, or poor quality) to see. We will also use either positive or inverse examples when discussing the following. While the quality of the software is being explored, it may also give examples of other products for ease of understanding.

In the previous article also mentioned, in the traditional definition of software defects, is to see whether the actual product is consistent with the specification (spec), if inconsistent that is defect or commonly known as a bug. If only from this extent, the definition itself is not a problem, because if it is not what we want, it is certainly not. So here we come to the first aspect of quality.

Quality scope #1: realizes the function on the instruction manual

For example you downloaded a movie player, it claims to support MP4, MOV, RMVB, AVI format, then it must be able to play these formats correctly. This is a very basic requirement, just like a washing machine to be able to wash clothes. If the implementation of such basic skills can occur, then the user will be very angry, feel that the quality is too poor, simply can not be used, directly uninstall, or request a return (commercial products).

This is because of the serious consequences, so in the test, for such a basic function we will be repeatedly verified.

OK, if the specification said that the function has been achieved, then is a good quality products? This may not actually be the case. So where is the difference?

Quality scope #2: Some self-explanatory requirements

Why is that self-evident? For example, or a washing machine, a customer might say, "I want to buy a washing machine." Then he bought one, and the price was good. When I went back, I found that I could do the laundry (the basic skills mentioned above), but there was a problem, the washing machine took 3 hours to wash, and the noise was very loud when it was washed.

Washing machines are a common commodity, and users may not ask how long or how loud the noise will be when they start buying. This does not mean that he does not have the standard, but "self-evident". If not stated beforehand, this may lead to some disputes, but the final manufacturer of such a washing machine must be the victim of these problems. Because we all know this brand of laundry is very slow, and the noise is big. And if only according to the requirements of the first scope, it may be a very good product, and perhaps the clothes are very clean, passed the QA test.

I believe that this kind of example can also cite many

Notebook: Heat is relatively small, not too hot

Anti-virus software: take up system resources not too much, machine start will not become very slow

Online Shopping System: Response time can not be too long

There are many requirements for this, including safety, performance,stability,impact to other software ...

Because this kind of request is "self-evident", so the development time is easy to be neglected. Of course, it may be deliberately overlooked, because of the technical and cost reasons, many Shanzhai products are so.

It is good practice to make a clear list of the needs of these areas and quantify them as much as possible. For example, the time and noise involved in the previous example, if there are clear requirements in the internal design document, the final product will not have such a big problem.

There are several features of this type of demand.

1. The requirements in this regard are not easily identified and are not easily evaluated or validated.

For example, performance, more complex than a simple function point, and sometimes even what is performance good enough or very good is difficult to define. So it also requires product design and developers to have a more input understanding of the needs of products and users, and not just do it.

2. Product characteristics In this regard are difficult to be copied.

Domestic cottage capacity Presumably everyone has seen, many products come out soon have a very similar function of imitation. Small to mobile phone, big to the car. The Shanzhai version of the iphone looks very much like Oh, and can also be touched in full screen, multi-touch, and less than 1000 pieces. There are two-ring SUV, a bit farther to see is the BMW X5, before an American colleague to see a car also deliberately took out a mobile phone photo nostalgia, because he is X5 owner. In reality, the iphone is still hot in China, X5 is still a lot of people dream car. Because there are a lot of unseen features (such as performance) that make a clear distinction between them and the copycat, the quality stands out. Of course, the difference is not just this, but others, such as branding.

Well, if our products even consider these self-explanatory requirements, would it be considered to be of good quality? Not necessarily.

Quality scope #3: Designed to meet user needs

At the scope #1中, we mention that the minimum condition for good quality is the realization of the declared function. So the other question is, is the design itself justified?

If we position developer as the person who realizes the required function, and the QA is positioned to verify that these functions are correctly implemented, then the quality of this department is not covered. Because if this is the position, people will not think, this is reasonable? is the user want to do it? will users like it? Anyway, we just have to follow the spec to make it good.

There are many examples of this, such as

1. By design, we only support IE browser. But we found that many users are using Firefox and Chrome.

2. Our mail history lookup is only supported by the recipient, in reality there are many users who need to find by sender

3. If the user reinstall the system, it is necessary to reconfigure the policy that was previously configured on the old system, including the white list and black list.

4. If the network is broken, the user in front of the things to enter the next network to re-input.

We can also cite a number of similar examples. What do these problems have in common, that is, users will complain that our system quality is not good enough, will give the after-Sales service department to bring a case to come up with their reasonable (from their point of view is really) requirements.

If our software testing only stays at the point of view of the verification function, these problems are not a problem, because we are excluded from the scope of the work directly. But eventually these problems will be encountered by users, and the impression is that our product quality is not good enough, especially when the competitor can do it. This will form a gap, our internal testing when the quality is very good and stable, but the user is not satisfied.

To solve this problem, there may be two requirements

1. Testers (and developers, in fact) should consider the issue more from the user's perspective. It is often said that the customer insight, from this point of view we are not completely passive according to Spec walk, but can challenge it, why to do so, at least to know why.

2. Testers need to go ahead of the development process, not just wait until the product is made and then install it for verification. That's too late, and the cost of the modification is much higher than it was earlier. Testers should be involved in the design of the product at the outset and give their opinions from the user's point of view. Of course, this part also relies on domain knowledge and personal experience.

The above two aspects, for testers, is a challenge, because the requirements are higher, but also the opportunity, because the work more value.

So far, it seems that our quality range has been more complete? Not yet.

Quality scope #4: Ability to handle exceptional situations

Speaking of which, let's give an example. Many people may be impressed with the anti-fall ability of their Nokia phone, or they have met or listened to a friend. The common plot is this, accidentally from the table, or from the stairs to the mobile phone fell down, and then the lid fell open, even the battery fell out, when the heart pulled cool, but holding the luck to put them back together, press the power button, everything is OK, and then very happy. The follow-up to this story is a lot of people so the second time, the third time is called the Nordson user. Because they think their cell phone quality is very good.

The interesting part of the story is that the instructions never write our cell phones fall off the stairs will not be a problem, manufacturers estimate generally do not dare to write. From the stairs to drop the phone is definitely an abnormal situation, is not a product against the scene, strictly speaking after the fall is normal. But conversely, if there is no problem in this abnormal situation, it will make people feel good quality. So it's a place of quality plus and branding build up. Like you Can (formerly?) Accidentally pour water on a ThinkPad keyboard, or you can kick your MacBook's power cord.

From the software point of view, there are also many anomalies, such as

1. Sudden power outage

2. Hardware failure

3. Operating system failure

4. Unexpected network connection interruption

5. System resources (memory, hard disk, network port, etc.) exhausted

6. User's error operation

Normally, none of this happens, but it still happens (Murphy's Law). If it is just a PC playing MP3 software, encountered above the situation is a problem, and even can not restore the need to reload, perhaps it is acceptable, after all, is not very important task, and it does not happen often. But if it is a very important software system, and has important data, can not restore the problem is big.

For this part, we should all consider, whether it is development or testing. In the process of testing, we should also try to verify.

In fact, there are many aspects of quality, such as.

Quality scope #5: Ease of Use

This is a very important and often overlooked aspect. Most of the time we develop products people will feel that their products are very useful, but users do not feel. I think one of the important reasons is that we are very familiar with the field, and the various functions of the product, and even their internal connection is very clear, and because of the work of the reasons we have used dozens of times. The ease of doing so is of course not a problem. But we cannot ask our users to do so, because users do not (many products should not) spend a lot of time studying our products, they buy our products provide the function, is to more efficient and efficient completion of his work. If the user has to modify a lot of places in order to complete a common job, such as modifying a small setting, and there is no hint to tell him to modify the corresponding place, then this is the problem of our product.

Many times the user wrong or misuse of our product features, in addition to the user's own knowledge and lack of experience, we should also reflect on whether our products do not work well, the process and interface design is too confusing.

Ease-of-use is not just a product's UI that looks better, but also includes the product's process and interface design. This is a very large area, and it is confined to its own understanding and space is not detailed. Most basic, we can think of ourselves as a limited product understanding of the initial user, a lot of problems are easy to expose, or there is a way to find a less understanding of the person, give him some tasks, let him go to operate, and then to observe, listen to his feelings.

Quality scope #6: maintainability

The purpose of maintenance is many, such as product upgrade, function upgrade, patching and so on. This is a common task for a formal and long-term system, especially for server software. The quality of these aspects is often very easy to affect the user's judgment and impression of the product. Common problems include

1. Product upgrades cannot be directed to future versions of data, or data errors

2. Incompatible after upgrade or high hardware requirements

3. Can I roll back if I get a problem after patching or upgrading?

4. The user reported the problem, if collecting information location problem

Software quality is actually a very complex thing, the above mentioned in fact is only a few aspects of the work often encountered (even so, many are often ignored), such as the user's view of product quality will also be affected by emotional factors, such as product UI, and customer service personnel communication process, as well as the company and product brands and so on.

From the point of view of software testing, we also have different types of testing activities to ensure the different aspects of quality, such as design review, and various types of tests, functional,stability,performance,deployment, Migration,usability,stress,compatibility and so on.

Read the original reading the1 Complaints

Thinking about software quality-what is quality?