Test Level – Test types

Tram Ho

1. Test level

1.1. Unit Testing

Unit Testing ( unit testing ) is a level of software testing that aims to verify that each unit of software is developed as designed. Unit testing is the smallest test level of any software. Functions, procedures, classes, or methods can all be considered units. It usually has one or several inputs but the output is unique.

Unit testing is done by the developer and is white box testing. This is done as soon as possible during the coding phase and throughout the software development process.

Purpose :

  • Increase security when code changes
  • The code is easy to use, easy to understand and reusable
  • Repair costs are lower than the following periods
  • Easier to correct errors

1.2. Integration Testing

Integration Testing ( integration testing ) is performing testing integrating a group of individual modules together. A software system consists of many modules coded by different people. Integrated testing focused on data transfer between modules.

  • Integration tests are performed to detect interface failures or during interactions between integrated systems or components.
  • Component integration test: check the interaction between components provided that the components passed in the previous component test.
  • System integration test: check the interaction between different subsystems and the systems have passed the previous test.
  • This is done by a developer, a specialized test team, or an integrated developer / tester group, including non-functional testing, and is performed after Unit Testing and before System Testing.

Some integrated testing methods :


Figure 1.1. Bigbang Integration Testing

This is an integrated testing method where all or most of the units are combined and tested together. This method is implemented when the test team receives the entire software.

Advantages : suitable for small projects

Disadvantages : can bypass small interface bugs in the process of finding bugs, it takes time for system integration, so there is no time for testing.

TOP DOWN Figure 1.2. Top Down Testing

Testing is done from top to bottom. The highest unit is tested first, the lower unit is then tested sequentially.

Advantages : easier bug reduction, critical modules that are tested first for bugs in large designs can be found and fixed first.

Disadvantages : modules at lower level will be tested incompletely


Figure 1.3. Bottom up Testing

Testing is done from bottom to top. The lowest unit is tested first, the higher unit is tested later.

Advantages : reducing bugs is easier, does not take time to wait for the modules to be integrated.

Disadvantages : the system’s important module may be faulty, unable to keep the original prototype of the system.


Figure 1.4. Sandwich Testing

Sandwich is an approach to integration testing, which is a combination of Top Down and Bottom Up methods.

1.3. System Testing

System testing is testing a system that has been fully integrated to ensure it works properly.

System testing is a black box test and is focused on the function of the system. Test the functions and interfaces, the behavior of the system completely to meet the requirements.

The purpose of this stage is to evaluate whether the system’s performance is in accordance with the specification document and performed by the tester.

1.4. Acceptance Testing

Official acceptance test relates to business requirements and processes to determine whether the system meets the acceptance criteria and allows users, customers or other authorized organizations to determine whether to accept receive the system or not.

Acceptance test is the fourth level conducted after the system test is completed and before the product is put into official use. With the purpose of ensuring the software meets customers’ requirements. Products received acceptance from customers / end users.

Acceptance test is divided into 2 different levels

  • Alpha testing: conducted at a software development site by people in the organization but not involved in software development.
  • Beta testing: performed by customer / end user at end user’s location.

2. Test type

2.1 Smoke test

Smoke Testing is a process to check whether the build has been implemented stably or not? To confirm whether the QA team can continue with further testing? Smoke Testing is a set of minimum tests that run on each build.

Smoke Testing is the process by which the build software has been deployed to the QA environment and has been tested for application stability. It is also called “build verification testing”.

Smoke testing covers most of the software’s major functions but none of them are deep. The results of this test are used to decide whether or not to conduct further testing. If this test passes, it will continue with the functional test. If that fails, pause the next test and ask for a new build with the required fixes. If an application is badly broken, detailed testing can be a waste of time and effort.

Smoke Testing is performed whenever new software functions are developed and integrated with the current build that are implemented in the QA / staging environment. It ensures that all important functions are working correctly or not.

Smoke Testing is performed by QA / QA lead engineers. Whenever there is a new build, the QA team determines the main function in the application to perform Smoke Testing. The QA team checks the relevant categories within the application that is being tested. The tests are performed in the dev environment on the code to ensure the accuracy of the application before releasing the build to QA.

Smoke Testing is usually done manually, although it can be done similarly through automation.

Manual Smoke Testing : In general, Smoke Testing is done manually. When the build is released to QA, test cases of high-priority functions are executed and tested to find important errors in the system. If the tests pass, we will continue with functional testing. If the tests fail, the build will be canceled and sent back to the dev team for editing. Smoke Testing is done on new builds and will be integrated with older builds to maintain the accuracy of the system. Before implementing Smoke Testing, the QA team will check the accuracy of the build versions.

Automation Smoke Testing : Instead of having to manually repeat tests when a new software build is deployed, the recorded smoke test cases are repeated with the build. It determines whether the main functions are still working properly. If the test fails, then they can edit the build and deploy it immediately. This way we can save time and ensure build quality to the QA environment.

Figure 2.1. Smoke Testing process

Advantages of Smoke Testing :

  • Critical errors are detected early in the process to minimize the risk and cost of repairing the error.
  • Improve system quality and optimize the efficiency of test time.

2.2. Functional Testing

Functional testing is a kind of black box test and its test case is based on the specification of the software application / component being tested. Functions are tested by inputting and checking output, with little regard for the internal structure of the application.

Functional testing is one of the four main types of tests that fall into the second level of testing integration.

Purpose of Functional Testing : Functional testing indicates that the program is not compatible with its external specifications.

The benefits of functional testing : avoid redundant testing and prevent over-paying attention to too many types of bugs at a time.

Techniques in functional testing :

Equivalent partitioning technique Decision-making technique Border value analysis technique Guess the error

Functional testing consists of 5 steps :

  • Determine the functions that the desired software will perform.
  • Generate input data based on specification document of functions
  • Determine outputs based on specification documents of the functions.
  • Carry out test cases.
  • Compare actual results and desired results.

2.3. Usability Testing

Usability Testing is a black box testing technique to determine if your product is user-friendly. Usability testing is usually done in System Testing and Acceptance Testing.

Usability testing consists of 5 main parts :

● Learnability: How quickly can you learn how to use the software?

● Efficiency: How fast can you get the job you want?

● Memorability: How fast can you remember how to use the software?

● Errors: How often do you encounter errors in the software?

● Satisfaction: How much do you like using the software?

After identifying the 5 main components, you can fully identify:

● What is the feature to include in the product?

● How to make use of features easier and more comfortable for users?

● What is a useful feature?

Who conducts Usability Testing?

Test participants should be representatives of those who plan to use your product or who have behaviors, skills, knowledge related to the product you are developing. To answer the question “Who will perform usability testing?” You need to answer the following questions:

● Related: Is your app relevant to test users?

● Frequency of use: Does this user regularly use your application in the work that person does?

● Demographics: Cultural differences are an important factor for the user experience. Focus on location, age, gender when selecting sample users.

● Income level: Are these users willing to pay to use your application / service? Including financial ability and shopping habits.

When should Usability Testing be implemented?

Usability testing is recommended for early use – right from the earliest stages of the software development model and implemented throughout later stages.

Advantages :

● Help to detect early usability problems before the product is marketed.

● Improve user satisfaction.

● Help make the end user feel comfortable when using the product. Thanks to that the product is more appreciated.

● Help gather feedback from the right target audience that will use your product, not the random user.

Disadvantages : quite expensive resources (time, manpower …) and cost to implement.

2.4. Security Testing

Security testing is an extension of negative testing. It focuses on invalid input values ​​and whether these inputs are capable of producing significant failures related to certain requirements of the product being tested. We need to provide sufficient evidence to prove to customers that their systems and system information are safe and secure before invalid input is a very important part of testing. security.

There are four main focus areas to be considered in security testing (Especially for websites / apps):

  • Network security: This involves finding vulnerabilities in network infrastructure (resources and policies).
  • System software security: This involves assessing weaknesses in various software (operating systems, database systems and other software) on which the application depends. to enter.
  • Client-side application security: This involves making sure that the client (browser or any such tool) cannot be manipulated.
  • Server-side application security: This involves ensuring that the server code and its technologies are strong enough to resist any intrusions.

2.5. Performance Testing

Performance Testing is a type of test aimed at determining the responsiveness, bandwidth, reliability and / or scalability of a system under a certain work / access volume.

Performance Testing is commonly used to:

  • Assess the readiness of the product
  • Judging based on performance criteria
  • Comparison between performance characteristics of multiple systems or system configurations
  • Find the source of performance problems
  • Support system adjustment
  • Find bandwidth levels

Why do Performance Testing need to be done?

  • Release readiness evaluation: Allows you to predict or estimate the performance characteristics of an application in production and evaluate whether or not to perform performance tests based on those predictions. These predictions are also valuable for stakeholders to make decisions about whether an application is ready for release or the ability to handle future growth, or whether it needs to improve performance / performance. Hard before releasing.
  • Provide data showing the ability of users not satisfied with the performance of the system. Provide data to assist in predicting revenue losses or brand reputation due to scalability, stability, or user dissatisfaction with application response time.

Infrastructure evaluation:

  • Assess the suitability of current performance
  • Determination of stability
  • Identify the capacity of the application’s infrastructure, as well as identify future resources needed to provide acceptable performance.

Compare the configurations of different systems to determine the best performance for applications and businesses

Verify the application of the desired performance characteristics in the resource budget constraint.

Full evaluation of software performance:

  • Determine the desired performance characteristics of the software before and after the change.
  • Provides comparisons between current performance characteristics and desired applications.

Improve operational efficiency:

  • Analyze application behavior at different load levels.
  • Identify problems in the application.
  • Provides information regarding speed, scalability and stability of the product before its release, thus allowing you to make decisions about when to adjust the system.

Some types of performance testing :

Load test : A performance test is performed to evaluate the behavior of a system when increasing the workload.

Stress test : A type of performance test that is performed to assess the behavior of a system at or beyond its intended workload limit.

Endurance testing : The goal is to ensure the software can handle the expected load over a long period of time.

Spike testing : The goal is to test the software’s response to sudden changes in user-generated loads.

2.6. Regression Testing

Upgraded software, there will be newer versions than the current version, new added features, extended features, etc. However, over time this may lead to loss. stability of the application.

During the regression test, new test cases are not created but previously created test cases are repeated.

Regression testing can be performed at any level of testing (Unit, Integration, System or Acceptance) but is mainly involved in system testing. Complete regression testing is not possible so focus only regression testing on the main functions of the system.

  • Based on the following factors to determine the level of Regression Testing:
  • Based on experience and understanding with the application.
  • Discussions with developers.

The places where the change is made.

For example, if the change is made on the home page, then more attention should be paid to those with fewer visits.

Based on the situation (the time and resources available), the severity of the change (the degree of its influence), the input … will be more effective when you choose the right test suite. with the whole test:

  • Unit regression means that you only need to perform a retest for changes to a module or area of ​​the application.
  • Partial regression means that you will perform a retest of changes to modules that interact with it.
  • Full regression is that you will have to retest the entire application, regardless of the location of the change.


This article only hopes to help you understand the basics of Test level, Test Types. You need to learn more to be able to better understand the Test level, Test Types and apply it to the work you are doing. You can refer to the Website at the reference link below to learn and find out the best way!

Reference: https://reqtest.com/testing-blog/different-levels-of-testing/ https://www.softwaretestinghelp.com/types-of-software-testing/

Chia sẻ bài viết ngay

Nguồn bài viết : Viblo