Hit or Miss, I guess they never miss huh?

Is testing really that importan? Here is your answer.
A system expecting a 16 bits word received a 64 bits one, causing an overflow which led to the destruction of this machine.

As you would expect from this starting lines, I’m about to write about testing. Once you finish coding, you should test what you did in order to detect any error/failure so you can handle it. Also, you have to check if the software really does what it is meant to; how it fits it, defines the software quality.

This is an OO blog, so, let’s talk about Object-Oriented Systems Testing. This is a continuos activity during development. For the OO branch, testing includes three levels:

Unit Testing

This is somehow an individual test. Typically, is an automated test with associated control data that simulates how the source code to check should behave. checks if the methods and interfaces are error-free and if the attributes are implemented. This kind of testing is the responsibility of the developer who implements the source code of the structure.

Subsystem Testing

This is more complex than unit testing. It involves testing the associations and dependencies within a subsystem and how it interacts with the outside. this one is responsibility of the subsystem leader. This kind of test can be used as a regression for each newly released version of the subsystem.

System testing

This one involves testing everything as a whole. Often, this can be used as regression tests when a new release is assembled. This tests are responsibility of the quality-assurance team.

Testing Techniques

Grey Box Testing

The different types of test cases that can be designed for testing object-oriented programs are called grey box test cases. It is called gray box because the tester has a partial understanding of the internal structure in the system under test; also there is a black box and a white box technique, but this one is the most used. There are a lot of gray box tests, some of the most important are:

  • State model based testing − This encompasses state coverage, state transition coverage, and state transition path coverage.
  • Use case based testing − Each scenario in each use case is tested.
  • Class diagram based testing − Each class, derived class, associations, and aggregations are tested.
  • Sequence diagram based testing − The methods in the messages in the sequence diagrams are tested.

Techniques for Subsystem Testing

  • Thread based testing − All classes that are needed to realize a single use case in a subsystem are integrated and tested.
  • Use based testing − The interfaces and services of the modules at each level of hierarchy are tested. Testing starts from the individual classes to the small modules comprising of classes, gradually to larger modules, and finally all the major subsystems.

Categories/Stages of system testing

  • Alpha testing − This is carried out by the testing team within the organization that develops software.
  • Beta testing − This is carried out by select group of co-operating customers.
  • Acceptance testing − This is carried out by the customer before accepting the deliverables.

Deja un comentario

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google photo

Estás comentando usando tu cuenta de Google. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s

A %d blogueros les gusta esto: