Common types of software testing tester need to know
“Test” – only two words but it is actually very large and complex. Depending on the specific needs and purposes, we will have different types of testing. In this article you will understand the types of software testing, the purpose of each type, and their value.
1. Installation testing
Installation testing, as the name implies, usually revolves around installing and removing applications on different environments.
Installation testing plays a very, very, very important role. Why? Because if your product needs to be installed in order to work and if the user cannot install (or have an error in the installation), then the result is … no one can use your product.
When to use installation testing?
You should begin installation testing as soon as possible, and if your product requires installation, you should focus more on this section.
Questions during installation test:
Can the application be installed successfully on [you enter your test environment such as PC (Windows, Linux), Mobile (Android, iOS)]? Are the installation / dismantling steps easy to make? Can the product be successfully uninstalled on [you enter your test environment like PC (Windows, Linux), Mobile (Android, iOS)]? Can the product be installed in different directories? Are there any leftover files or folders after the product? Can the product be installed from CD / DVD? Can users update and upgrade installed applications?
2. “Smoke test”
The term smoke test was started in electronics and hardware. This is the first test operation that needs to be done when an engineer turns on a switch or plugs in a power source to see if there is “smoke rising.” If there is no smoke (meaning the product is ok for further testing), if there is smoke (the product is dead), they must be repaired immediately.
Similarly, in software development, smoke test is a type of test to evaluate whether a product or build built by a developer has any serious errors so that it can continue with other activities.
This type of testing is only for a preliminary evaluation of whether the build is ok for further testing. The reason we have to use smoke test is that early detection of important bugs will help to avoid wasting when we spend time on other testing activities.
Smoke tests (some can be called sanity tests, build validation tests, build acceptance tests) are usually a simple test set and contain some basic test cases going through the most important features of the product. As you work with the product you will have to know which features are most important (ie those features are the original value, vital for the product or company). If you still do not know, it is best to find out or ask immediately.
When should the “smoke” test be used?
When the dev assigns a build to the test team, the first task is to execute this smoke test. The smoke test set is usually small, so it usually takes about 1-2 hours to execute. If the build fails, immediately notify your boss, developer or other stakeholders to assess the situation. Return the build and should not test other features.
3. Compatibility test
This type of testing aims to evaluate application compatibility with different environments and platforms. This type of testing is important because there are more and more different platforms, operating systems, browsers, and users expect their products to work well in these different environments.
Compatibility tests generally apply to:
Different web browsers such as Chrome, FireFox, Safari and different versions of each type Different operating systems such as Windows, Linux, Mac OS and different versions of each type Different platforms such as PC, Mobile , Desktop, Laptop Of course, depending on the characteristics of the application, there are specific types of compatibility tests such as compatibility tests for different telecommunications networks, compatibility tests for switch languages, testing compatible for different types of users, etc. It is advisable to learn about the end users of the product such as tastes, habits, and environment to determine the corresponding compatibility test.
However, compatibility testing also has its own difficulties, of which the two are notably:
Preparing for the test environment: Having to test on many different test environments will make preparation, setup difficult in terms of cost, time, and techniques. The solution is to be able to use virtual machines to support faster environmental preparation or services that provide built-in browsers. Test coverage is very large. Suppose you have 500 test cases that need to be executed and you have to run 500 test cases on Chrome, FireFox, Safari, IE and each version has different versions. You multiply and can see that the test case volume that needs to run is “huge”. The solution is to reduce the number of test environments or increase the workforce or also automate the test suite to reduce execution time.
4. Regression test
This can be considered the most common type of test and most testers know about this type of test.
Regression testing aims to test whether changes in a build in a feature (such as adding a new feature, changing a feature, fixing bugs) do not affect other features or create new bugs. .
This type of testing is important and nearly indispensable in testing because we cannot (or have difficulty) predicting whether even the smallest change can affect other modules. Of course some changes are predictable, some are not. Regression therefore is considered to be the safest solution.
Regression testing is performed as follows:
Suppose you have 1000 test cases for your entire product, after the developer introduces a new build, you must execute all of these 1000 test cases on the new buiild and every time you build a new build you will have to execute it again. 1000 test cases.
What are the common difficulties encountered with this type of test? Because a large number of test cases must be executed after each build, regression testing is often costly (time, manpower) and “boring”. The solution to this problem is that the regression testing is usually automated to increase coverage, either to reduce the number of test cases (select only the critical ones) or to increase manpower. It depends on different conditions to decide which solution is suitable.
5. Acceptance test
Acceptance testing is a type of test conducted by a customer or product owner to assess the quality of a product whether or not to accept a product. This type of testing is often found in outsource projects.
The acceptance test set usually contains important basic test cases of the product and is usually carried out independently by the customer or a third party. In fact, in some projects, acceptance test is often used. Use as a smoke test to evaluate a build from the developer to see if it is acceptable for further testing.
6. Performance testing
Performance testing is a type of testing to evaluate the performance of the system as well as the stability of the system. There are two basic types of tests in performance testing:
Stress test: A form of performance test in which the system is pushed to the highest threshold until the system “die” only. The goal is to find the threshold of the system. Load test: The load test is a test to assess whether the system can operate when operating under a certain load (usually the number of users accessing) This type of test is extremely important because it helps them. We assess the load capacity of our system to have plans to upgrade and repair promptly. This type of testing is often used on systems that require large data loads or a large amount of access to which slow loading, glitches, or stalling can affect product survival. This type of test is usually applied to websites or e-commerce applications, news, etc.
Some tools that support this type of testing are LoadUI, JMeter, and LoadComplete.