Testing

Is a testing procedure used to verify whether the system being tested meets the given Requirements.

• Test cases are designed to see if the Requirements are meet

• Determine if the application is “fit for purpose,”

• in case of delivery to a customer, the positive testing process is likely to be a important aspect of contractual acceptance

demonstrates that the system does NOT do what it is not supposed to do.

• Test cases are designed to investigate the behavior outside the strict scope of the requirements specification

• Often used to test aspects that have not been documented or that have been poorly or incompletely documented in the specification

Coffee mashine:

system contains of 4 states —> (ON/OFF, Standby, produce beverage)

positive tesing:

verifing if requirements are meet.

• If currently in OFF state and the ON/OFF button pressed —> indicator light and display should turn on; mashine should start heating up, after if no other input is made for longer time mashine should go into standby mode.

• If currently in On mode and produce baverage is pressed —> mashine should produce baverage

• After bevarage is produced the ON/OFF button gets pressed again —> mashine should turn off; indicated by indicator light and display turns off

negative testing:

demonstrating that mashine is not doing what it shouldn`t do.

• What happens if the coffee machine is producing a coffee and the On/Off button is pressed?

• What happens if the coffee machine is ON and the produce beverage button is pressed without a water, coffee beans… in the coffee machine?

• What happens if the coffee machine is ON and the produce beverage button is pressed and the water temperature is to low?

Guidelines to be considered when testing or even implementing tast cases.

1. Define the expected result of a test case

2. A programmer should avoid attempting to test his or her own program

3. Any testing process should include a careful inspection of the results of each test

4. Test cases must be written for input conditions that are valid and unexpected, as well as for those that are valid and expected

5. Examining a program to see if it does not do what it is supposed to do is only half the battle; the other half is seeing wheter the program does what it is not supposed to do

6. Do not plan a testing effort under the tacit assumption that no errors will be found

7. The probability of existence of more errors in a section of a program is proportional to the number of errors already found in that section

Equivalence partitioning is a way to test a function by grouping similar inputs together that are expected to produce similar behavior/output based on the functionality being tested.

This technique helps to reduce the number of test cases needed to test the function thoroughly by selecting representative test cases for each group of inputs. For instance, if a function requires numerical input, it can be divided into groups such as negative numbers, zero, and positive numbers. Instead of testing every possible numerical input, representative test cases are selected for each group to save time and resources while ensuring comprehensive testing.

The principal assumption of this technique is that testing one instance of the class is equivalent to testing all of them

The V-Model is a software development and testing model that emphasizes the relationship between the software development process and testing activities. The model consists of a series of stages on the left-hand side representing the development process and a corresponding testing stage on the right-hand side. The outputs of each development stage are verified and validated by the corresponding testing stage. The V-Model is often used in safety-critical systems and other industries where thorough testing and documentation are crucial to ensure that all aspects of the software are thoroughly tested and defects are caught early.

• Unit test

  unit testing is a software testing technique that involves testing individual units or components of a software application in isolation to ensure they are reliable, functional, and meet their requirements. The primary goal of unit testing is to identify errors in program logic, and it is typically performed by the software engineer or programmer who developed the unit. Unit testing is also known as component testing and aims to catch errors and defects early in the software development process.

• Integration Testing

  Sure, integration testing is a software testing technique that checks if different modules or components of an application, which have passed unit testing, work correctly when combined or integrated. The goal of integration testing is to demonstrate that the modules interface and interact with each other correctly, stably, and coherently before system testing. Modules can be functions, procedures, objects, windows, sub-windows, or reusable components that perform a well-defined service within the application under test. Communication between modules occurs via strictly defined interfaces. Integration testing helps identify and fix issues that arise during module interaction.

• System Testing

  Sure, system testing is a software testing technique that verifies whether the application under test (AUT) is acceptable to its users and operators and whether it passes acceptance tests. The objective of system testing is to demonstrate the functional and structural stability of the system, including non-functional requirements like performance and reliability. The technique employs black box testing and focuses on high-level requirements of the system without considering implementation details of component modules. System testing is performed on the entire system, including its interfaces with other systems, and aims to ensure that the AUT meets requirements and expectations.

• Acceptance testing

  is a software testing technique that aims to ensure that the application under test meets its business requirements and is usable before it is delivered to end-users. The objective is to provide confidence that the system works correctly and meets the needs of users.

  During user acceptance testing, one or more user representatives, along with the test team, test the AUT by performing typical tasks users would perform during normal usage of the system. This testing process should also address system documentation to ensure that it is clear, complete, and understandable to the end-users.

  The main goal of acceptance testing is to ensure that the application under test meets the business requirements and is usable by end-users, making it the final step in the testing process before delivery.

Difference between System and Acceptance testing:

while system testing focuses on the functional and structural stability of the system, acceptance testing focuses on whether the system meets the business requirements and is usable by the end-users. The testing team performs system testing, while user representatives perform acceptance testing.

identify errors and defects at the boundary of input values or parameters.

The technique involves testing the values that are at the edge of the input domain, including the minimum and maximum values, and the values just above and below those boundaries.

For example, if a function takes an input of a number between 1 and 100, boundary value analysis would test the function using the minimum value of 1, the maximum value of 100, and values just above and below those boundaries, such as 2, 99, and 101.

The goal of boundary value analysis is to identify errors that may occur when the input values are at the edge of the input domain.

is used for automatically generating test cases

• a generator produces random combinations of valid input values

• The results generated by each input are logged and the inputs and their respective results can be inspected following testing for defects

+ Straightforward process to automate the process of providing inputs

+ Highly effective in identifying obscure defects

‐ but it is difficult to automate the process of checking the

outputs

- difficult to reproduce the results of random tests

intrusive testing requires the AUT to be modified i.e. you display certain values for debugging and testing that will not be in the end product given to the client.

Problematic:

• What you deliver after testing is not what you actually tested!

• Systems that have been released containing changes

  introduced during intrusive testing

State transition testing is a type of functional testing that is used to test the behavior of a system or application in response to various input conditions and events. It is particularly useful for testing systems or applications that exhibit different behaviors depending on their current state.

In state transition testing, the system or application is modeled as a finite state machine, where the different states represent the various conditions that the system or application can be in. Test cases are then designed to cover the different state transitions that can occur in the system or application, along with the associated input conditions and events.

For example, suppose you are testing a system that has two states: "idle" and "active". You might design test cases to cover the following state transitions:

1. Transition from idle to active when a specific input is received

2. Transition from active to idle when a specific input is received

3. Transition from active to active when a specific input is received

4. Transition from active to active when a specific event occurs

By designing test cases that cover these different state transitions, you can ensure that the system or application is behaving correctly under different conditions and events, and that it is transitioning between states in the expected manner.

• Positive and negative testing

• White box and black box testing

  White box tests are designed with the knowledge of how the system under test is constructed. Also be termed glass box testing

  Black box tests are based on an analysis of the specification of the component without reference to its internal workings. The test cases are derived from a knowledge of the external behavior only

• Experience based testing or error guessing

  not a real technique —> testers test the AUT based on expirience and knowledge of the systems behaviour; mostly try and error

• Automated software testing

  Test automation tools used to created reusable tests based on recording the expected behavior of the AUT under its typical operation