Blog

All articles

Software testing. Part 3. Types of testing and approaches to it

We continue to study the subject of software testing, what it is and how it works. This part of the topic is devoted to the types of testing and approaches to it.

Types of testing

Functional types of testing

  • Functional testing
  • GUI Testing
  • Security and Access Control Testing
  • Interoperability Testing

Non-functional types of testing

  • All types of performance testing:

o Performance and Load Testing

o Stress Testing

o Stability / Reliability Testing

o Volume testing

  • Installation testing
  • Usability Testing
  • Failover and Recovery Testing
  • Configuration Testing

Change-Related Types of Testing

  • Smoke Testing
  • Regression testing
  • Re-testing
  • Build Verification Test
  • Sanity Testing

Functional testing considers the predefined behavior and is based on an analysis of the specification of the functionality of the component or the system as a whole.

GUI Testing – functional testing of the interface for compliance with the requirements – size, font, color, consistent behavior.

Security testing is a testing strategy used to test the security of a system, as well as to analyze the risks associated with providing a holistic approach to application security, hacker attacks, viruses, and unauthorized access to sensitive data.

Interoperability Testing is a functional test that verifies the ability of an application to interact with one or more components or systems and includes compatibility testing and integration testing

Load testing is an automated test that mimics the work of a certain number of business users on a shared resource.

Stress Testing allows you to check whether the application and the system as a whole are able to work under stress and also assess the ability of the system to regenerate, i.e. to return to normal after the cessation of stress. Stress in this context can be an increase in the intensity of operations to very high values ​​or an emergency change in the configuration of the server. Also, one of the tasks in stress testing can be the evaluation of performance degradation, so stress testing goals may overlap with performance testing objectives.

Volume Testing. The task of volume testing is to obtain a performance estimate when you increase the amount of data in the application database.

Stability / Reliability Testing. The task of testing stability (reliability) is to test the performance of the application for long (many hours) testing with an average load level.

Testing the installation is aimed at checking the successful installation and configuration, as well as updating or uninstalling the software.

Usability testing is a testing method aimed at establishing the degree of ease of use, learning, understanding and attractiveness for users of the developed product in the context of given conditions. It also includes:

User eXperience (UX) is the experience experienced by the user during the use of the digital product, while the User interface is a tool that allows the user-to-web resource interaction.

Failover and Recovery Testing tests the tested product in terms of its ability to resist and successfully recover from possible failures due to software errors, hardware failures, or communication problems (for example, network failure). The purpose of this type of testing is to check the recovery systems (or duplicating the main functionality of the systems), which, in case of failures, will ensure the integrity and integrity of the data of the tested product.

Configuration Testing is a special type of testing aimed at testing the operation of the software under various system configurations (declared platforms, supported drivers, various computer configurations, etc.)

Smoke testing is considered as a short cycle of tests, performed to confirm that after the code is assembled (new or patched), the installed application starts and performs the basic functions.

Regression testing is a type of testing aimed at checking changes made in an application or the environment (fixing a defect, merging code, migrating to another operating system, database, web server or application server) to confirm the fact that the existing functionality works, as before. Regression can be both functional and non-functional tests.

Re-testing is testing, during which test scenarios that detect errors during the last run are executed to confirm the success of correcting these errors.

What is the difference between regression testing and re-testing?

Re-testing checks for bug fixes

In Regression testing, it is checked whether the bug fixes affected on other software modules and whether new bugs were caused, as well as any changes in application code.

Build Verification Test is testing aimed at determining the compliance, the released version, the quality criteria for the start of testing. For its purposes it is analogous to Smoke Testing, aimed at accepting a new version for further testing or operation. In depth, it can penetrate further, depending on the requirements for the quality of the released version.

Sanitary testing is a narrowly targeted test sufficient to prove that a particular function works according to the requirements stated in the specification. It is a subset of regression testing. It is used to determine the operability of a certain part of the application after the changes made in it or the environment. It is usually done manually.

Approaches to integration testing:

  • Bottom Up Integration

All low-level modules, procedures, or functions are assembled and then tested. After that, the next level of modules is assembled for integration testing. This approach is considered useful if all or almost all modules of the developed level are ready. Also, this approach helps to determine the level of availability of the application based on the test results.

  • Top Down Integration

Initially, all high-level modules are tested, and gradually low-level ones are added one by one. All lower-level modules are simulated with plugs with similar functionality, then they are replaced with real active components as they become available. So we are testing from top to bottom.

  • “Big Bang” Integration

All or almost all the developed modules are assembled together as a complete system or its main part, and then integration tests are conducted. This approach is very good for saving time. However, if the test cases and their results are not recorded correctly, the integration process itself will be greatly complicated, which will become an obstacle for the testing team when achieving the main goal of integration testing.

In the final article you will learn about the principles of testing and the life cycle of the bug. Stay tuned!