Perspective on Testing

Software testing… Why do we test the software, can we avoid it?
We test the system for two main reasons First to judge about quality and the efficiency of the system and second to track problems and correct them


The International Software Testing Qualification Board Glossary

Error: People make errors. This is very similar to making a mistake. When people make an error in the code, it's called a bug. Errors from the requirements specification can be magnified during design and amplified during coding.

fault is the result of an error; we could say it is a representation of an error. A fault of commission occurs when we enter something incorrect into// A fault of omission occurs when we fail to enter the correct information. Faults of omission are more difficult to resolve.

Failure A failure occurs when the code corresponding to an error is executed.
Incident is the symptom associated with the failure that is associated with the error that gives users notice of the failure event.

Test is about errors and faults and failures. A test is the examination of software with TEST Cases. The test has two goals of detecting Failures and demonstrating correct execution

Test Case has an identity and is related to the behavior of the program, in addition it has a set of inputs and a set of expected outcomes.

Ιn the development phases, three opportunities arise for errors to be made, resulting in faults that may propagate through the remainder of the development process.The Fault Resolution step is another opportunity for errors (and new faults). When a fix causes formerly correct software to misbehave, the fix is deficient. We will revisit this when we discuss regression testing. The Test Case plays an important role in TESTING

The above diagram is known as the Vmodel. This variation emphasizes the correspondence between testing and design levels and the three levels of definition specification, preliminary design and detailed design correspond to the three levels of testing. 

TEST Fundamental

---

The test has been associated with behaviour, and this behaviour is related to the code base. One view focuses on what the code is, while the behavioural view considers what the code does. There is a debate about whether testers should be programmers so that they can emphasize code over behavioural information.

In the image above, we see a Venn Diagram about Testing, which considers a universe of program behaviours. Given a set S of specified behaviors and a set P of programmed behaviors, we can use this diagram to clearly see the problems that confront a tester. For example, if specified behaviors are not implemented, then these are faults of omission. Similarly, if behaviours are not specified but are implemented, these are faults of the commission. The intersection of S and P represents the correct portion of program behavior that is both specified and implemented. Finally, there may be behaviors that are not tested, programmed behaviors that are tested, and test cases that correspond to behaviors that were not implemented.

Identifying Test cases.

Two fundamental approaches are used to identify test cases, fundamental and structural testing. Functional testing is a function that maps elements of its input space to elements of its output space.

Specification-based Testing is also sometimes called functional testing and is where each program is considered a function that maps values from the input domain to values within its output range. This is sometimes referred to as black box testing and we call it black box testing.  The content of the back box remains unknown and the function of the black box is understood completely in terms of its input. Therefore, the test cases have two distinct advantages they are independent of how the software is implemented and if changed the test cases are still useful 

A code-based test is another approach to test case identification, often referred to as white box testing or clear box testing. In this method, we can see and examine the code, meaning we can look inside the "black box," allowing the tester to identify test scenarios not only functionally but also within the code itself. Code-based testing leads to the use of test coverage metrics. These metrics provide a way to explicitly state the extent to which a software item has been tested, making testing management more meaningful.

Which test is better: code-based or specification-based testing? The goal of both approaches is to identify test cases. Specification-based testing uses only the specification to identify test cases, while code-based testing uses the program's source code implementation as the basis for test case scenarios. Both tests are necessary, and the combination of both provides confidence: specification-based testing ensures the system meets its requirements, while code-based testing provides measurable coverage of the code.