A set of activities of pruebas It is usually aimed at checking certain aspects of a software system (or a part of it). Continuing with our previous article on the onion model for Software Testing Levels, and following the guidelines of the ISTQB, we will limit the TTypes of Software Testing depending on the objective on which they are focused.

Software functional tests

First of all we have the Functional Software Testing. Typically we will find the behavior of the system, subsystem or software component described in the specifications of requirements or use cases, although it may also be undocumented ("that works like the system it replaces"). That is, with the functions we establish “what the system does".

These tests are defined from functions or characteristics (as we say, well described in documents or well interpreted by testers) and its interoperability with specific systems, being able to be executed in all test levels (components, integration, system, etc).

Are considered Black Box Testing ("Black-box testing") since we assess the external behavior of the system. The Security Testing or Interoperability Testing between systems or components, they are specialized cases of functional testing.

Non-Functional Software Testing

Second are the Non-Functional Software Testing which include tests of: Performance, Load, Stress, Usability, Maintainability, Reliability or Portability, among other. They therefore focus on software features that state 'how the system works«.

These tests also can run on all test levels. Non-functional characteristics of software can be measured in various ways, for example by response times in the case of performance tests or by maximum number of sessions in stress tests.

Since Non-Functional Software Testing normally considers the external behavior of the system, in most cases Black Box Testing techniques are used.

Structural Software Testing

Next, thirdly, we have the Structural Software Testing. Again they can be executed at all levels of tests (you know: components, integration, system, etc.) and they fit very well if we have used specification techniques of the structure or architecture of the Software. Static code analysis techniques can be applied.

To express the scope with a set of tests ("test suite") that has covered the structure or architecture in question, the concept of Icing ("Coverage"), usually in percentage form.

It is especially common to use support tools for calculating code coverage in the case of Component Testing or Component Integration Testing (for example, tracing the hierarchy of calls between elements). Since we inquire into internal behavior, these tests are also called White Box Testing ("White-box testing").

Software Regression Testing

Finally, the fourth type of evidence presented by the ISTQB are the tests derived from making changes: Regression Software Testing and Retesting.

Once a defect has been corrected, it is time to retest the software to confirm that the defect has been eliminated. They are repeated tests or Re-tests.

Our Regression tests They consist of retesting a component, after it has been modified, to discover any defects introduced, or not previously covered, as a result of the changes. Defects can be found both in the software that has been changed and in some other component. They run when the software or its environment is changed. The criteria for deciding the extent of these Regression Tests is based on the risk of not finding defects in software that was previously working properly.

Regression Tests are carried out on a component already tested, to verify that it does not present new defects when a modification is carried out after said tests.

This type of software testing must be repeatable whether they are to be used for confirmatory (or assurance) and regression tests (such as Availability Probes, for instance). Regression test sets («Regression test suite«) Are usually quite stable so they are very good candidates for software testing automation activities.

It may no longer surprise you that these tests also can be run on all test levels and include test cases of the types seen above: Functional, Non-Functional and Structural Tests.

Conclusions

Now that we have a good picture of the types of software tests that we can incorporate to ensure Software Quality (SQA), it is easier for us to understand that it is an activity that requires a high capacity to adapt to workloads, as well as sufficient specialization. Therefore, in Panel Sistemas we have consolidated our Center of Excellence in Software Quality, Testing and Automation, from where we will be happy to assist you.

 Are you missing some kind of software test?
¡Try us!
: )

Some references on this topic that we propose are:

• Article on Levels of Evidence represented visually with an Onion Layer Model: Software Testing Levels Onion Model
• Learn more about test automation at Zahori.io