Software Testing and Debugging

SOFTWARE TESTING

Testing can only show the presence of errors, not their absence. The goal of testing is confidence.

• Validation: Are we building the right product? What does the customer need?
• Verification: Are we building the product right? Functional/Non-Functional requirements.

SOFTWARE INSPECTION VS. SOFTWARE TESTING

While inspection will go through the code without running the program, testing will run the program and look at the results. Incomplete programs can only be inspected, not tested. Inspections can control aspects of good software (maintainability…), not just the results.

TEST CASE:

• Requirements
• Data/Input
• Actions
• Expected Results

TEST CASE PRINCIPLES:

• A test tries to find flaws in a program.
• A good test case will show a possible defect with a high probability.
• A successful testcase has uncovered a previously unknown flaw.
• The setup of a testcase can vary depending on the object to be tested.
• Each definition of a testcase includes an expected result.
• A good testcase controls what the program does, but also what it does not do.
• Programs should be tested by other programmers.
• Plan enough time to correct flaws, (there will always be flaws!).

TESTING CLASSIFICATION

• Subject: What is the basis, the software or the specification? Classification: Blackbox/Whitebox testing.
• Subject: How detailed is the test described and how strict does it have to be followed? Classification: Formal (high level of detail) vs. not formal (random tests).
• Subject: Is the system running while being tested? Classification: Dynamic (running program) static (programming code).

BLACK BOX TESTING: EQUIVALENCE PARTITIONING

Usually there are different inputs possible for a program --> difficult to test all! Input data falls into different categories (e.g., positive, negative, 0) with similar behaviour. It is considered enough to test each category or partition (or class) a few times check for problematic behaviour.

BOUNDARY VALUE APPROACH

Special form of equivalence class testing. Each class boundary has to be tested from both sides ]10-20[ (test nº10 and nº20). I’m using the boundaries of each E.C. (Equivalent Class) because there is where problems usually appear.

ALTERNATIVE TO BOUNDARY VALUE APPROACH

Input values based on experience à “Zero”, “null”, “200k1”, Your Age:”2099”,? ß Ä Ü Ö @; Data types for variables play an important role in these cases…

DIFFERENT LEVELS OF BUGS

• Fatal bug (Show Stopper): System cannot be used as required. Everything is on hold until the problem is fixed.
• High priority bug: Limited functionality is available. Extra resources are allocated to fix this problem.
• Medium priority bug: Functions cannot be used appropriately, but a workaround exists. The problem will be fixed within the next couple of cycles.
• Low priority bug: The flaw in the program is mainly cosmetical nature. Bug-fixing is optional and depending on the available resources.

WHITE BOX TESTING

1. All programming paths will have to be examined and checked for all variants and possibilities.
2. Even then, it is not guaranteed, that there is a path missing. All necessary functions are implemented correctly. Data – Tests (wrong input) may not be discovered.
3. The program has to be understood in all its detail!!!

ALGORITHMS

A process or set of rules to be followed in calculations or other problem-solving operations, especially by a computer. Like a receipt.

PSEUDOCODE

Is an informal high-level description of the operating principle of a computer program or other algorithm. It uses the structural conventions of a normal programming language, but is intended for human reading rather than machine reading. (Buzz, Fizz).

CONTROL STRUCTURES

1. Sequence Structure: Sequence of statements (do this, print this…)
2. Selection structure: Decision between two possibilities (If (condition){ statement;} Then, else…
3. Loop structure: Execute statement multiple times (while (condition) {statement) ;} or Repeat {statement;} until (condition);