Release judgment criteria・The fifth type of test is confirmation of past defects
The fifth type of test is the confirmation status of past defects.
This series of articles introduces the types of tests from the perspective of what kind of test you are doing when determining the quality of the test. Up to the version upgrade function introduced in the previous article , the viewpoint was whether the function and stability of the software could be confirmed, but the fifth is to make use of the experience in other software development so far. This is the status of confirmation of past defects from the perspective of .
This is literal and easy to understand. Do you test to see if your product has been on the market in the past and software-related issues aren’t happening with this product? It is a confirmation. Depending on the company, past problems may be abbreviated as past questions, or past troubles may be abbreviated as past tigers, but the same thing is said, it is a reproduction test of problems that have occurred once in the past .
Is it useful to check past defects in other products?
By the way, is it effective to do such a thing? Is it really the same potential problem lurking in another product? In the first place, all software is a single item . The structure of the software, the OS used, the middleware used, the hardware that runs, and even the development language used differ from product to product. Even though there are big differences in the products, is it effective to confirm that the product that is going to be shipped is being tested to reproduce the defects that occurred in the past products ? Everyone is wondering.
Certainly, software is one item and no one is the same. There are some common parts that are the basis of derivative development and remodeling development, but the parts that have been remodeled are different. It seems unlikely that a bug of the same cause is lurking.
But all software has something very important in common . The point is that people make software . Software design, implementation, and testing are brain tasks that can only be done by maximizing one’s thinking ability and maintaining high concentration. And unfortunately people always make mistakes.
I’ve already made your mistake …
And strangely, everyone makes the same mistakes . If you live in the world of software development for a long time, you will come across many situations where the mistakes you made are the same as the mistakes I made in the past. Of course, this is the first mistake for the technician who caused this problem , but most of the time , other people have made similar mistakes before .
Well, to put it more simply, there are some parts of embedded software that you have to be careful about when designing and implementing, and it seems like a pitfall that most software engineers who design and implement such parts for the first time make mistakes. There is a certain part. Exclusive control deadlock , flash memory access timeout , state transition design transition impossible state , dynamic resource leak or double release , priority inversion , etc. to Gabe storage collection or was, imperceptibly data in the flash memory disappear and are living in the world of was or ,,, many years embedded system software, you come across again and again in the same kind of bug. I will introduce the points to note about the design and implementation in this area little by little in the bug nest article.
And bugs caused by similar design and implementation mistakes are often found in similar tests. As a result, we often see new bugs that look like bugs we’ve seen in the past . This means that bugs that have occurred in other products in the past have a relatively high risk of similar bugs being latent in this product.
Well, it 's a theory that the tub shop is profitable if the wind blows, so it 's not convincing. Since the test of confirming defects similar to past defects is efficient in finding potential bugs from experience, it is one of the confirmation items of test quality whether or not Gutara’s father is conducting a confirmation test of past problems. bottom.
The type of test, next is the confirmation status of past defects
When judging whether the test quality is good or bad, we look at the types of tests performed, but next to the test of the version upgrade function is the status of checking past defects in the test. Please see the following article if you are interested.