It all started with a conversation … As a programmer, sometimes I was wondering what types of tests can be used to efficiently test software. I started at the beginning of the course with unit tests and automated tests, and then at various events I had the opportunity to meet people who are professionally concerned with software testing. I knew at the start of the idea of unit testing and integration testing, but those really are not all. Though I am not a tester, I understand that most of the tests, however, should be written by the person who produces the software. I began to raise questions about the methods and application testing methodologies. I started to show people your articles on the InfoSec Institute website. And then the same people started coming to me and they were much more willing to share their knowledge with me. This article is unusual even for me. On the basis of conversations with people I classified the problems that they encounter in their daily work and this sparked the idea of a series of articles on software testing. After many hours of conversations over coffee we were able to extract all the major software testing divisions and put them in these articles. After classifying the materials and subsequent conversations with specialists, we were able to develop a way to present the whole subject. I put it below:
Part 1 and 2 will be the theoretical introduction to software testing.
In Part 3, you will know all the frameworks which are used to test the software.
In the fourth part with frameworks we write several tests, including unit testing, integration and automatic.
In the fifth part I’ll show you how to use integration tests to prepare documentation for penetration testing for clients.
Everybody ready? Here is the first part of our discussion. Introduction to Software Testing Software testing is really a collection of activities, whose job is to capture as many errors as possible. You could say that it is quality control software for each emerging at the stage of its creation. The main objective of testing each application is actually checking whether the application is correct and to detect all possible errors, which is a direct translation of the application code development costs, the cost of changes to the code and the subsequent costs of taking care of the code. In fact, the process of testing should be subjected to all applications, whether they are small desktops that are built to individual recipients as well as the huge application domain and dedicated systems that are created for the giant corporations. In an ideal world, no programmer should send anything to the version control system as a release, which he was not clad in 100% of the tests, both integration and unit. Unfortunately, there is no perfect world. Introduction to the process of software testing Basically, the process of testing the application has two main objectives:
The purpose of the first of each software development process is actually its verification. It is based on the fact that checks if the software produced by us is in accordance with the technical specifications and client specifications. The second objective of each of the testing processes is to verify the software, or to check whether the produced software is actually in line with the expectations of the user. And it’s not just about the user experience, resulting from the service interface, but also to verify if the software produced is free from defects and does not leak during normal use of it.
In addition, the application testing processes are related to other issues. First of all is the question of fault, error and failure. What do they really mean in business? Error is any event initiated by humans or the environment, which means that the code produces an unexpected result. Then we are talking about the code that generates a result inconsistent with its specification. Occasionally, however, the program can not use one of its features. And then we can talk about the crash. However, the defect in the program is a mistake committed in a period of life of the program. This may be a mistake or an architectural programming flaw. As programming errors are fairly easy to spot at any stage of testing the application, an architectural mistake is to assume that they will not reveal themselves for some time, when you least expect it and you will have to live with it for some or all sprints. So let us, therefore, institute order. Every error you commit, revealed by a software failure, is caused by a defect in the action of man. Division of testing processes due to the adopted concept testing As I mentioned testing applications is today a widely developed process. We are also still developing new types of tests. Most developers also write their own tools for testing applications. Really writing tools for work is very addictive and one of the most interesting intellectual challenges. Theory of testing processes is distinguished by two completely opposite concepts: ascensional-synthetic methodology and top down-analytical methodology. In theory, never use only methods resulting from only one of the methods. Most of the methods used are a combination of these two methodologies, because you cannot really determine which method of testing is not really the best. It all depends on the project, the language in which it is written, project size and complexity of the system. Now let’s look at them one by one:
The first is to test the bottom-up methodology. It depends essentially on writing and testing all parts of the program from the bottom up. At the very beginning of the software development and test writes all modules at the lowest level. Immediately after they repeat the same process for the modules in the higher layer lying directly above the layer you wrote. The testing process for this methodology finishes only when the system is completed with the module located on the top of the hierarchy and the program will not be fully tested.
This is called incremental programming and testing. For this approach to application testing, it is not required or necessary to complete the project describing the system architecture. This has the advantage that the test can proceed relatively rapidly, in the stage when the project is only created. But there is one crucial disadvantage. Later, when you write and add more layers, there may appear very serious errors of the entire project, and then I realized the only way out is to change the concept of our program right at the very end of the project. And that means not only the costs for the customer, but also for the company that the software provides. Testing is based on bottom-up methodology of software development.
The second test is testing methodologies coming down. This methodology is based on checking and connecting modules in order from top to bottom. It works perfectly with the architectural approach, which in short is called “from the particular to the general.” It does not require writing all the lower-level modules but only the skeleton structure sub-modules. A particular advantage of this methodology is that we do not need to create special programs as we are able to test and verify the composition of the entire program.
The only drawback to this solution which brings me to start with is a situation in which we give some input to the system, which does not really have any direct effect on the data that are transmitted by the layers or modules. So to put it to our program, we may not be able to call a particular method or function with all the data sets that interest us.
Another of the methods with which I often do is called modified top-down testing. The main task of this testing methodology is to combine the advantages of these two methodologies of software testing. This method is, in my opinion, very similar to the top-down testing, but in contrast to that method it requires a thorough test any new functionality, and each new module before being incorporated into the software release.
The advantage of this approach is primarily a test of all possible logical structures of the program inside the modules. We know that it is sometimes useful. The main drawback of this solution is something else. It takes some time to prepare the software for testing and the creation of substitutes for each module in the program. A program for testing is usually a short program that allows you to test the functionality of the selected module or using specific input and allows you to call all procedures module or functionality, and full observation of the results provided by them. Return to this theme by the way of integration tests.
Another interesting method of testing is to test mixed. Again, here we are in fact dealing with a compromise between the methods of ascending and descending tests. This is a very interesting methodology. Testing begins descending from the top layer, I get to test. Testing begins ascending from the lowest level of software modules, known as basic modules. Finally, these two methods are to meet somewhere in the middle of the program. The meeting place of the two methodologies is set just before the pre-test, after learning the structure of the software provided by the developer or client. The main disadvantage of this approach is the inability to test the software, namely a portion of the testing module downlink.
But this solution has more advantages than disadvantages. The main advantages of this approach are a quick merge all of the modules making up the skeleton, and we obtained a rapidly running program. In addition, this type of approach partially neutralizes the disadvantages of the two main methodologies for testing, while fully preserving their advantages.
Another testing methodology is a modified mixed. It is a combination of ascending and descending modified methodologies. It is based on the fact that the lower layers of the test are on the way upstream, just as it leads us to this methodology. Modules of higher levels, however, are first tested separately from one another, and then they merge with each other through downlink testing methodology. Using this approach allows you to get rid of disadvantages of mixed testing methodology. Another interesting method of testing is to test the methodology using bing-bang. This is actually the easiest of the possible methods to merge modules. At the beginning of the test we have the individual modules and the application layer, which is in complete isolation from the rest of the program. They are then merged with each other and the program is re-tested.
This method gives really great results in the case of small and well-designed programs, but really, it has more disadvantages than advantages. We must always work to write the control modules, and at least a skeleton of the other modules. Only then we move to merge the program and this is done in a very late stage of software testing. We meet also with great difficulty in the case when we have to determine where the creation of a defect in the software is. Summary of the first What we learned here is mainly to test the application and then eat them. Therefore we already know what it is. So as always mastered new knowledge and we can be proud of ourselves. In the next section we will look at division tests. And then we will learn a lot of practical knowledge in the field of software testing. Thank you.
