- Level: University Degree
- Subject: Mathematical and Computer Sciences
- Word count: 1173
Critique: An Approach to Software Product Testing (CarlosMunoz) Submitted by: - Abhishek Das (2003002) During the development of a software,with a special look at the always growing complexity of the softwares, themanagement of the quality of the s...
Extracts from this document...
Introduction
Critique: An Approach to Software Product Testing (Carlos Munoz)
Submitted by: - Abhishek Das (2003002)
During the development of a software, with a special look at the always growing complexity of the softwares, the management of the quality of the softwares gets an always bigger role. The key element of the software quality management is the product testing. This paper takes us through an ingenious approach suggested by the author. The author bases the paper on the presence of test case generators for generation of random test cases. The author tries to drive in the point of the effectiveness of correctness measurement by way of some hypothetical tables and by comparing it to other approaches. The article also talks about the defect detection and identification using two methods stating the situations in which both are used (viz. extensive & adaptive). The article also suggests that the product testing and productivity of the software are interconnected and cannot be dealt in isolation.
The article clearly suggests the futility of assurance offered by various testing methods. Since 100%
Middle
The author however brings out the defects in this method by saying,” Sometimes the test case content is challenged as not being representative of usage” and “What to count for test and failure units are the other correctness measurement problems”.
To the first problem the author suggests the use of increasingly difficult test. This however seems to be a rather juvenile effort at dealing with the difficulty. The complexity of test cases will only create further problems at the time of maintenance and service. Morover it is not always that the person or organisation making the software also periodically checks for errors. They may be employees of the customers company who may only be intrigued by the complexity and will eventually be dissatisfied with the performance. Thus my point of view is to keep things simple as far as possible.
The difficulty wit identifying failure units is that there may not be any sanguine answer to the question of where exactly the defect lies and until it is found and corrected the program is still uncertain. Herein the marketing perspective of management comes in.
Conclusion
The article also points to the statement made by Ackerman and Musa in “When to stop Testing”. He says” If one does nor find new defects at a cost effective rate one should stop extensive testingbecause it is not worth the money being spent.”
While discussing productivity the author stresses on the need of computers for test case generations suggesting the futility of hand written test cases. My take on this would be that we should exactly know when to use the generators and when to use human intellect for generating cases but taking into consideration the CPU time cost and the complexity. With the increase in complexity the cost of using the test case generators comes down and that of hand written test cases go up. The graph below demonstrates the fact.
Cost
Complexity
In conclusion I believe that the bearing of human intellect is too high on test case generation and hence they cannot be removed from the process.
This student written piece of work is one of many that can be found in our University Degree Software Engineering section.
Found what you're looking for?
- Start learning 29% faster today
- 150,000+ documents available
- Just £6.99 a month