Software Testing Process and Levels of Testing
In my Software Testing series, I will try to discuss the software testing process and levels of testing. Software testing processes can be developed and changed from company to company and from person to person. I will try to briefly explain the general processes.
The software tester checks whether the product behaves as expected during the testing process. They find the errors in the tests stage and tries to solve them. In this way, the final product becomes free of bugs or includes a minimal number of errors. We can say that the software test improves the quality of the software. Software testing is not just a stage at the end of the software life cycle. Software testing is an iterative process and continues after the software is completed.
For example, after the product is delivered, new features will be added to the product and the product will be improved. Software testing will again be required at this stage.
In summary, software testing is a never ending process.
This is the stage where test planning is performed. The scope of the test is determined, and the risks that are associated with the tests are assessed. The planning stage is the part where the effect of the development is determined, and impact analysis is performed.
Necessary test sources are determined. All materials to be used during the test should be listed. It should be clear when the test starts and ends, and the date ranges are reported to the project leader or team leader. The dates given here are estimates and should be stated as “estimates.”
2. Creation of Scenarios
It is the stage where “expected” and “realized” outputs are prepared according to the content of the project to be tested. In this step, the tester writes the scenarios to be applied. Test scenarios should be considered both simple and diverse. When creating test scenarios, preliminary information from the software developer or product manager is used or design and analysis documents are used.
3. Preparation of Test Environment and Data Creation
This is the preparatory phase for the test. All necessary preparations are made in this step before starting the test. The project to be tested is successfully installed in the test environment.
The data required for the test is provided. After the test environment is prepared, the data to be used is determined and prepared in accordance with the scope of the development. This can be a user, advert or product.
The test environment is checked for the best operation. Not only the area to be tested but also before or after the screen/page is running; if the application is to be tested, the application can be downloaded and connected to the test environment should be checked in advance to minimize the distractions or unexpected issues.
4. Run the Scenarios
This is the stage where the tests are run. Test scenarios that have been written are applied in this step.
The critical thing to note here is that the scenarios created can be applied despite the time pressure. Unfortunately, there is always a “time pressure” on testers. Time pressure is a stressful component, especially in scenarios. Planned scenarios should be fully utilized.
5. Reporting of Results
It is the stage in which the situation that occurs after all specified scenarios are applied is communicated to the person concerned. The report should use as simple a language as possible. Where possible, elements such as screenshots or video showing the error should be used. Then there is the step of tracking the error and reaching the solution in constant communication with the software developer. This step can also be included in reporting errors.
Levels of Testing
When we say testing, we see that there are different types of tests. Categorization is a natural phenomenon that occurs spontaneously over time. Test types are results, not goals.
Test types have a per-category in terms of levels, types and processes. Each type of test can be an article in its own right or even a book. But it is beyond the scope of this manuscript. Therefore, we will focus on the four levels of tests that are most relevant to software developers;
- Unit Testing
- Integration Testing
- System Testing
- Acceptance Testing
The four different test types here have their own definition and each has different purposes and writing methods. Naturally, there may be different means for each. When you feel the need to write a test, you can’t decide what type of test to write if you can’t determine your goal of writing correctly.
If you do not use the correct test type, you will not be able to perform your test writing purpose. It is therefore important to decide the right type of test to achieve your goals.
1. Unit Testing
Unit Testing is a term that goes back to ancient times, although it is not very often heard, as the Smalltalk programming language developed under the leadership of Alan Kay in the 70s. Unit testing in computer science; It is the process of testing whether a block of code (usually method) that calls or uses another block is performing its task correctly by separating it from the other block to which it is associated. Unit tests will fail if the task is not performed correctly. What we call units is usually a method or a function.
The key factor here is; we want to test the smallest piece of code, other parts of the code to be completely isolated by testing. Our aim is to check whether the smallest piece of code does its job correctly. The relationship of this piece of code to other codes is not the subject of the unit test. Therefore, the prerequisite for writing a unit test is; the part of the code to be tested is isolated from other codes.
The part of code we call is usually a method or a function. The relationship of this method with other codes is called coupling. If two different pieces of code are tightly connected it is called highly Coupled, otherwise it is called loosely Coupled. 
Unit tests should be simple and it should probe to see if a very small part is doing the job correctly. Besides, a good unit test should bear the following features;
- It can be automated and easily operated repeatedly.
- It should be easily written.
- Once written, the feature should remain as it is used.
- Anyone should be able to operate.
- Its operation should be as easy as pressing a button.
- It performs checks quickly.
If you cannot answer Yes to all of the following questions, it is probably you did write a unit test:
- Can I run the unit tests I wrote 2 months ago and get the results?
- Can any member of my team run the tests I wrote 2 months ago and get the results?
- Can all the unit tests I have written result in a few minutes?
- Can I run all unit tests at any time with the push of a button?
- Can I write a basic unit test in a few minutes?
If your answer to any of the above questions is No; Despite the fact that what you write is a test, it is certainly not a unit test.
2. Integration Testing
“How can you tell which part needs to be fixed when your car breaks down? The engine consists of a combination of many different parts and all parts work together in harmony. The error may have occurred in any of the parts. All the components come together to produce the real result: the car is moving. You can think of the car as an integration test. If the test is faulty, the association of parts is faulty. If the tests run smoothly, then all parts are running smoothly.
Based on that analogy, a similar process works in software. The tests you perform using the user interface are integration tests. If you do not get the result you expect when you click a button, all the parts that make up the software (as a set) are faulty. The problem is that it is difficult to find out exactly which part is faulty. Because when you press a button there will be dozens or even faces, that will cause errors.
The integration test is, therefore: testing the operation of two or more slave modules as a group. In short, integration testing; checks the combination of codes that can be tested with unit tests. Unit tests only control the operation of the relevant unit independently of the other units.”
For example, suppose that a piece of code that you write unit tests writes the data it generates to disk at some point. When you write a unit test, you test that this method produces the data correctly and tries to write the data to the file, regardless of the file system. However, your file permissions may not be configured correctly. At this point, even if your unit tests run correctly, they may not be able to do the desired job in the real environment. You can test the method as a whole by creating the environment closest to the real environment through integration tests. Therefore, you can find the opportunity to test the collaboration of multiple departments in the integration test, not the unit test.
You may find the error more convenient in unit tests. However, integration tests are more general because they test more code. Therefore, sustainability and operation are more difficult than unit tests. Because it takes time to design the test environment close to the real environment.
3. System Testing
System testing (or end-to-end testing [E2E]). Is a complete system testing. When unit tests and integration tests are testing parts of the system, this one is targeting the system as a whole. This testing is performed by QA testers. For example, testing an entire application from login to checkout and making sure emails are delivered. This is done from the user perspective, and shouldn’t be automated with data mocks or fake requests. This type of testing is the most involved and time-consuming. If a bug was discovered during E2E testing, that means something was missing in unit or integration testing.
4. Acceptance Testing
Acceptance Tests refers to the testing of end-user scenarios. It can also be considered as integration tests but refers to testing a user story.
The purpose of acceptance tests; is to control whether the operations that are necessary for the user group to accept the software as running can be performed. It is used to say, the system cannot perform the operations as expected of it rather than identifying where the system has errors.
Errors will occur in every software that is produced. Testing is needed to minimize errors and produce sustainable software. With this article, I have tried to give a broad picture of the phases of software testing.
I hope this article can help you to gain insight into the testing processes and levels. Thanks for reading!