I was speechless when a colleague said, in all seriousness, it would shed most of their regression testing, and that it had found errors. Having regained composure - and my voice - I asked him what he was thinking such a thing, which certainly responded, "Well, so and so says the tests found no problems that are not worth it."
As it happens, the claim turns out to be crazy from the first and most commonly quoted definition of software testing. The Art of Software Testing, the definition states: "The purpose of the test is detecting errors. The test is the process of trying to discover every design error or weakness in a work product.
Based on this concept set, I see that my colleague and his informant had the idea that the tests found no errors have no value. I can also see why the testers could compete with dentists to higher depression and suicide rates in all professions.
Proving a negative-
Not enough to find bugs is an acceptable goal for software testing. The approach requires testers to prove a negative - that there are no errors found. To demonstrate this, they must know how many mistakes you have to start and where are the errors. If we knew that we would not need to test, should only correct errors.
Also, if you do not know how many errors there are, how to know when to end testing? How can you measure the effectiveness of testing? Does this mean that as contributing to the improvement of software development process, its effectiveness decreases as a tester too?
The proof of the Pointless-
Another reason for this "no errors" no value "definition is dangerous is that it gives credence to the idea of all software errors are created equal. It is assumed that finding an error, regardless of what or where it is, is valuable. This belief leads testers spend valuable time and resources for creating dark situations, random and meaningless, in hopes of "catching" the programmer unable to adapt to changes. At the same time, the evaluators were fleeing the most basic and obvious evidence, assuming that they will work. But what if they do not?
Ironically, the true meaning of the term "regression testing" is the search functionality of the software used to work but no longer does, i.e., the program has "fallen". But in the definition of Myers's no point in managing a test that has found no errors, so that once a software feature works that are immune to further testing. However, the functionality that no longer works after a regression test poses the greatest risk, because it is still in use. The new functionality does not work can be irritating, but is unlikely to be devastating.
Demonstrate progress-
To give credit where credit is due, more recent authors have improved in the absence of errors; there is no definite evidence of value. As Software Test Automation, the purpose of testing the software is to "give greater confidence in the product areas that work and to document issues with the product areas that do not work". Notice that this terminology is introduced to establish the value of what works and what does not.
Similarly, the glossary of the latest standards of the British Computer Society Specialist Interest Group in Software Testing (BCS SIGIST) defines the test as "the process of exercising software to verify compliance with specified requirements and detect errors.” Ah, now we're getting somewhere. The concept of needs - you know, the reason that developed the software in the first place - is finally part of the definition.
While it may seem academic to obsess about how to define the software test, the impact is very handy. Well-meaning experts - who adhere to the definitions that evaluators have to discard the evidence of that work - are setting the testers (and their companies) for failure. If the software has not been shown to a basic, which cares if it does the dark?
0 comments:
Post a Comment