software testing

Software Testing

process of evaluating a software solution to ensure that it behaves as expected and meets the specified requirements.

involves:

1. executing the software under controlled conditions

2. assessing its behavior to identify any defects or bugs

Bugs

is an erroneous software or hardware element of a system that can cause the system to fail

why do we test

1. Finding defects: Software testing helps identify defects or bugs in the software

2. Ensuring quality: Testing ensures that the software meets the quality standards and fulfills the requirements specified by stakeholders.

3. Validating requirements: Testing verifies that the software behaves according to the specified requirements,

4. Improving user experience: By identifying and fixing defects, testing helps improve the overall user experience of the softwar

Edsger W. Dijkstra

testing shows the presence, not the absence, of bugs

Test-Driven Development

software development approach in which tests are written before the actual implementation code.

Core principles of TDD

1. Every step in the development process must start with a plan of how to verify that the result meets a goal

2. The developer should not create a software artifact (a system requirement, a UML diagram, or source code) unless they know how it will be tested

TDD Steps: Red-Green-Refactor

1. Red: Write a failing test(no implementation code yet, the test case will fail initially.)

2. Green: Write the minimal implementation code to pass the test

3. Refactor: refactor the code to improve its design, readability, and maintainability while keeping all tests passing.

Benefits of TDD

1. Improved code quality

2. Reduced bugs

3. Faster feedback loop

4. Better documentation

White-box testing

exploits structure within the program (assumes program code available)

→ internal workings of the system are transparent to whoever is testing

Examples:

1. control-flow testing

2. state-based testing

Black-box testing

explores input space of functionality defined by an interface specification (end-user perspective)

→Internal workings of the system are hidden from the tester

example:

1. equivalence testing

1. boundary testing

test case

particular choice of input data to be used in testing a program and the expected output or behavior

test

finite collection of test cases

Why testing is hard

1. Any nontrivial system cannot be completely tested

2. In practice, we have to run many “unsuccessful” test cases that do not expose any faults

3. Our goal is to find faults as cheaply and quickly as possible.

Acceptance Tests

Form of black box testing

Unit Testing

smallest possible part of a system – called a unit – is tested individually and independently

Integration Testing

tests how components of a system interact with each other

System Testing (end-to-end)

tests an entire system

Tests included in end-to-end(system testing)

1. Functional Testing – tests the functional requirements of a system

2. Quality Testing – tests the non-functional requirements of a system e.g. security, performance, usability, scalability, etc.

3. Acceptance Testing – customer verifies that the requirements have been met

4. Installation Testing – tests that the system works as intended when deployed to the end-user’s device

Coverage

measures the degree to which the specification or code of a software program has been exercised by tests

Types of covearge tests

1. Test Coverage AKA (Big picture): Specification testing focuses on the coverage of the input space, without necessarily testing each part of the software

2. Code Coverage (Implementation details): Code coverage measures the degree to which the elements of the program source code have been tested

Equivalence testing

black-box testing method that divides the space of all possible inputs into equivalence groups/classes such that the program is expected to “behave the same” on each input from the same group

Steps to equivalence testing

1. partition the input values into equivalence classes

2. test one or more inputs from each equivalence class

Boundary Testing

a special case of equivalence testing that focuses on the boundary values of input parameters

Control-flow Testing

organises testing based on the control flow of the software

covaerge tests in control flow

1. Statement coverage – every statement executed at least once by some test case

2. Edge coverage – every branch of the control flow is traversed at least once by some test case

3. Condition coverage – every condition takes TRUE and FALSE conditions at least once in some test case

4. Path coverage – every distinct path through the program has been traversed at least once in some test case

State-based testing

defines a set of abstract states that a software unit (object) can take and tests the unit’s behavior by comparing its actual states to the expected states

State-based testing components

1. State – a constraint on the values of an object’s attributes

2. Event – an input given to the system

3. Action – the result, output or operation that follows an event

4. Transition – a change of state caused by an event

5. Guard – a condition associated with an event which determines whether a transition is triggered or not

Types of state-based coverage

1. EVENT COVERAGE :EVERY EVENT IS TESTED

2. STATE COVERAGE: EVERY STATE IS VISITED

3. ACTION COVERAGE: EVERY ACTION IS TRIGGERED

Common control faults

1. Missing transition – nothing happens with an event

2. Incorrect transition – resulting state is incorrect

3. Incorrect State Handling - Extra, missing or corrupt state

4. Sneak path – event is accepted when it shouldn’t be