Software Testing Methods

Original author: STEN PITTET
  • Transfer
Hello! Next week we are launching a new thread on the course "Automation Web Testing" . This will be the subject of today's material.

This article discusses various methods of software testing, such as unit testing, integration testing, functional testing, acceptance testing, etc.



There are many different types of tests that you can apply to make sure that changes to your code are scripted. Not all types of testing are identical, although here we look at how the main testing practices differ from each other.

Testing: manual or automated?

First you need to understand the differences between manual and automated tests. Manual testing is carried out directly by a person who clicks on buttons in the application or interacts with software or API with the necessary tools. This is quite expensive, as it requires the tester to install the development environment and run the tests manually. There is a likelihood of error due to a human factor, such as a typo or skipping steps in a test case.

Automated tests, on the other hand, are performed by a machine that runs a test script that was written in advance. Such tests can vary greatly depending on complexity, from testing a single method in a class to working out a sequence of complex actions in a UI to make sure that it works correctly. This method is considered more reliable, but its performance still depends on how well the script for testing was well written.

Automated tests are a key component of Continuous Integration and continuous delivery.), as well as a good way to scale your QA process while adding new functionality to your application. However, manual testing still has its own value. Therefore, in the article we will definitely talk about exploratory testing.

Different types of tests

Unit tests

Unit tests are considered low-level tests that are close to the source code of your application. They are aimed at testing individual methods and functions within classes, testing the components and modules used by your program. Unit tests in general do not require special automation costs and can work out extremely quickly if you use a continuous integration server.

Integration tests

Integration tests check if the services and modules used by your application work well together. For example, they can test integration with a database or make sure that microservices interact correctly with each other. These tests run at greater cost since they need many parts of the application to work simultaneously.

Functional tests

Functional tests are based on the business requirements of the application. They only check the output after the action is performed and do not check the intermediate states of the system during the reproduction of the action.

Sometimes there are contradictions between integration tests and functional tests, as they both request multiple components that interact with each other. The difference is that integration tests can just make sure that the database is accessible, while a functional test wants to get a certain value from the database to check one of the requirements for the final product.

End-to-end tests

End-to-end testing simulates user behavior when interacting with software. It checks how accurately different users follow the intended scenario of the application and can be quite simple, for example, look like loading a web page or entering a website or, in a more complicated case, confirming an e-mail address, online payments, etc.

End-to-end tests are extremely useful, but producing them is expensive, and it can be difficult to automate. Several cross-cutting tests are recommended, but still rely more on low-level testing (unit and integration tests) to be able to quickly recognize major changes.

Acceptance testing

Acceptance tests are formal tests that are conducted to make sure that the system meets business needs. They require the application to run and run, and mimic user actions. Acceptance testing can go further and measure system performance and reject recent changes if the ultimate development goals have not been achieved.

Performance Tests Performance

tests test the behavior of a system when it is under significant load. These tests are non-functional and can take many forms to test platform reliability, stability and availability. For example, it can be monitoring the response time when performing a large number of requests or observing how the system behaves when interacting with big data.

Performance tests are inherently expensive to conduct, but they can help you understand what external factors can drop your system.

Smoke testing

Smoke testing is a basic test that tests the basic functionality of an application. They work out quickly enough and their goal is to make it clear that the main functions of the system work as they should and nothing more. Such testing is aimed at identifying obvious errors.

Smoke tests can be useful immediately after building a new build to check whether you can run more expensive tests, or immediately after deployment, to make sure that the application works fine in the new environment.

How to automate tests

A tester can carry out all the tests mentioned above manually, but this will be extremely costly and unproductive. Because people have limited ability to perform a large number of repetitive actions while still testing reliably. However, the machine can easily reproduce the same actions and check, for example, that the username / password combination will work for the hundredth time without any complaints.

To automate testing, you first have to write them in some of the programming languages ​​using a testing framework that is suitable for your application. PHPUnit , Mocha , RSpecAre examples of test frameworks that you can use for PHP, Javascript, and Ruby, respectively. They have many features for each language, so you should work out a little research yourself and consult with the developer communities to figure out which framework is best for you.

If your tests can be run using scripts from the terminal, you can automate them using a continuous integration server like Bamboo or the Bitbucket Pipelines cloud server. These tools will monitor your repositories and run test suites as soon as new changes are pushed into the main repository.



If you are new to testing, check out our continuous tutorial.integration to create your first test suite.

Research testing

The more features and improvements are added to your code, the greater the need for testing increases, because at each stage you need to make sure that the system works correctly. Also, it will be needed every time you fix a bug, since it would not be superfluous to make sure that it does not return again after several releases. Automation is the key to making this possible; writing tests sooner or later will become part of your developer practice.

The question is, is it necessary to conduct manual testing at all in this case? The short answer is yes, and it should be focused on what is called exploratory testing, which helps identify subtle errors.

A research testing session should not exceed two hours and should have a clearly defined scope to help testers focus on a specific area of ​​the software. After informing all testers about the limits of the testing, it remains at their discretion the actions that they will take to check how the system behaves. Such testing is expensive in nature, but very useful for identifying problems with the user interface or verifying the health of complex workflows for users. It is important to conduct such testing whenever a radically new function is added to the application in order to understand how it will behave in borderline conditions.

Testing Note

Before finishing this article, I want to talk about the purpose of testing. On the one hand, it is very important to make sure that users can use your application (“I can’t log in”, “I can’t save data”, etc.), but on the other hand, it’s equally important to verify that your system Does not break when entering incorrect data or unexpected actions. You need to anticipate what will happen when a user makes a typo, tries to save an incomplete form, or uses the wrong API. You need to check whether one of the users can easily compromise the data, gain access to a particular resource to which he should not have access. A good set of tests should try to break your application and help to understand the limit of its capabilities.

And finally, tests are code too! So do not forget about them during the code review, as they may be the last step before releasing the product to the consumer market.

According to the established tradition, we are waiting for your comments and invite everyone to the open door day , which will be held on March 18 by our teacher, the leading test automation engineer at Group-IB, Mikhail Samoilov .

Also popular now: