Types of Manual Testing

Introduction

Software testing is an integral part of the Software development life cycle. After the software is developed by the programmers, its testing is done, both manually as well as using automation in which we check whether it meets the requirements of the users, analyze the efficiency of the software, analyze its throughput, and detect and remove errors in the software. Most of us have the misconception that software testing is all about finding errors. Yes, one of the primary goals of testing is to find bugs and errors in the software, and also correct them. However, we can't say that software testing is all about finding errors. 

Manual testing is the testing where a person called a tester manually checks the software and tries to detect and eliminate the errors in the software. In this article, we are going to learn about manual testing, its goals, and most importantly, we are going to focus on the types of manual testing.

What is Manual Testing?

As the name suggests, manual testing is that type of testing in which the test cases are generated by a person called a tester, and the tests are also run manually by the tester. Basically, in manual testing, the errors in the software are detected and amended manually by a person. 

Now, the question arises if we have developed such great technologies, why can't we just test the software application using automated tools only? Why do we need manual testing?

Manual testing helps us find out not only the errors in the code but also the logical errors. Logical errors are those in which there is no error in which the code is written, however, the developer has interpreted the logic incorrectly. This means that a code with a logical error will produce undesired or unexpected outputs. 

Logical errors are difficult to locate using automated testing tools. Manual testing leads to the detection and correction of these errors and can also lead to improving the coding efficiency in terms of time and space as well. 

So, because of such reasons, we can never have 100% automated testing. Hence, manual testing is a must in software development. So, now that we have understood what manual testing is, let us understand how manual testing is done.

The Process of Manual Testing

Manual testing, since it is done by a human and not any automated software, will not have a fixed set of procedures that will be followed. The process of manual testing is flexible from organization to organization, project to project, and in fact, person to person (here person is the tester). The process of manual testing also depends upon the experience of the tester. A more experienced tester will be able to test the applications more efficiently and quickly as compared to a fresher tester. However, apart from all these factors that lead to manual testing not having a fixed set of rules and protocols, there is still a recommended process that is roughly followed by almost every tester and organization. The process of manual testing involves the following 3 steps:

1. Understanding the Requirements and Expectations of the customer:

Whenever software is created, the very first step in the software development life cycle is to know and understand the requirements of the users and what they expect from the final software. On this basis, the software is developed. Now, when a tester has to test the software, he/she should also be familiar with the requirements of the users and expectations from the software so that they can test the software to check whether it fulfils user requirements or not and to check whether it meets its expectations in terms of being error-free, and efficient. 

2. Generation/Creation and Execution of Test Cases: 
What are test cases? Test cases are the set of input and their corresponding output for a particular program/software. The tester has to prepare various test cases so that he/she would be able to test the software efficiently. The test cases should be such that they cover all the situations of working of that particular software including the corner/edge cases.

For example, if there is a calculator software created by a company, the tester must test all the operations available in that calculator with different real numbers covering different situations such as adding negative numbers, dividing a positive and a negative number, etc. In such software, dividing by 0 is an example of a corner test case. What your software should do when we try to divide a number by 0, is something that depends on the user requirements and should be handled according to that only. For example, if the user requirement is to print “INFINITY”, you have to check that your calculator does so, otherwise, if the user requirement is to print that “DIVIDE BY 0 NOT POSSIBLE”, you should print the same.

3. Reporting the Bugs and Errors

Whatever bugs and errors are found while testing, all should be reported to the development team. When the development team fixes those bugs, these 3 steps are repeated until the software becomes production-ready.

Now that we have understood what manual testing is, what are its goals, and how we can perform manual testing, let us now move on to understand different types of manual testing.

Types of Manual Testing

Following are the types of manual testing.

1. Black Box Testing

Black box testing is a behavioural manual testing scheme. What does this mean? We know that the entire software/project is not created in one go. It is divided into different modules and each module is created separately and at the end of the project i.e. after the completion of every module is when the modules are interlinked to each other to form the project as a whole. Now, these modules can be tested separately and independent of each other. This is called unit testing because we test each unit individually. In unit testing, the code is properly checked and the insides matter to the tester. This is also known as white-box testing.

The black-box testing, on the other hand, does not go into the details and just checks the overall project’s behaviour. It does not test modules separately. The entire system as a whole is tested and the tests are majorly focused to see if the functional requirements (that are listed during the requirements gathering phase in the software life cycle) listed by the consumer are fulfilled or not and whether the speed and performance of the software under different conditions is up to the mark or not.

So, based on the above 2 main points that are focused majorly on black-box testing, it can be divided into 2 parts:

  • Functional Testing: As the name suggests, it is the black-box testing in which the main goal is to see that the project fulfils all the functional requirements that it is expected to fulfil. This type of black-box testing can further be divided into 3 categories:
    • Smoke Testing: This is the first phase of functional black-box testing. It comes into the picture when the software is deployed in the testing environment. This testing is not actually for the complete testing of the project. The testing in this phase is done to ensure that the software is ready for the testing phase. For instance, a smoke test for User authentication and login is performed on software. If the login test fails, this means that the software is not ready for testing at that time. Hence, the feedback is sent to the development team. If the software passes the login test, this means that it is ready to be tested further. 
    • Regression Testing: Now, say the software has already been deployed in the testing environment and a new feature is pushed. So, we want to make sure that adding this feature does not change the previous functionalities in any unexpected or unwanted manner and also, we want to make sure that the new functionality added is working fine. So, this type of testing is called regression testing.
    • User-Acceptance Testing: Every large-scale software organization has a group of non-technical people who give unbiased reviews of the product. They are just like the users in the market that will use our product and don’t have much technical background, but they (users) are the ones for whom the software is developed. They can give feedback on what they like, and what they don’t apart from finding any technical glitches in the software by using it over some time before the software is deployed publically. This helps in correcting any minor/major technical faults in the software if there are any even after multiple phases of testing. Even if there is no such error and the software is deployed publically after this phase, this testing phase gives an idea to the developers about what they can release and improve in the further builds/versions of the software.
  • Non-functional Testing: As already discussed, in this type of testing the main objective is to check the speed and performance of the software and the related issues. Two types of non-functional testing are:
    • Usability Testing: Here, the testing aims to check how easy and quick it is for the user to use the software. It is again based on customer feedback.
    • Localization Testing: Let us say that there is a software that is a global scaled software. This means this is available for use in multiple countries around the globe. Hence, the localization of this software is important. For instance, the Amazon app is available in the Hindi Language for Indian users. For localization testing, people from the targeted audience are employed to check the correctness and ease of understanding and usage of the product.

2. Exploratory Testing: The name suggests that this type of testing would be based on exploration. The question is, however, who explores what? Many times in the software industry, the software is needed but the requirements are not very clear to the customer. So, the requirements are not well elaborated and the developers have to understand the rest for themselves. In such a case, a tester has to explore the functionality of the created software and think about scenarios and real-life situations for the software himself/herself. The test cases are prepared by exploring different possibilities of use and result by the tester himself/herself. Hence, it is called exploratory testing. 

Note: This is quite a good example of a situation where automated testing is not much in use. This is because the automated tools cannot explore and imagine different situations of using themselves, without the proper input data, which in this case, is not available (requirements are not properly listed).

3. Integration Testing

The software is usually created by dividing it into different modules. When these modules are integrated to form a system as a whole and testing is performed upon it, it is called integration testing. There are 2 kinds of approaches that are followed for integration testing. They are: 

  • Bottom-Up Approach: As the name suggests we will start from the module that is at the bottom and reach the module at the top of the hierarchy of the system. Since we start from the bottom module to the top module in the hierarchy, the system as a whole is tested.
  • Top-Down Approach: This approach is the opposite of the Bottom-Up Approach. Here, we start from the topmost module of the hierarchy. This module is tested independently. Now, its child modules are integrated with it and this partial system (of topmost and its child modules) is now tested. In the same way, we keep on adding/integrating the modules and testing the system. When we reach the bottom, we have the entire system as a whole.

4. System Testing

In System Testing, the entire system as a whole is tested. So, what is the difference between integration testing and system testing? System testing is a destructive method of testing. This means that instead of checking if everything is working fine or not, we try to create certain situations in which the system/software has a chance of failing. By doing so, we can identify the potential points of failure in the software. The two main branches of System testing are:

  • Installability Testing: When the customers give the requirements of the software, they also specify certain specifications for the software to work. For instance, a desktop app might work for Windows 10 and above only. So, it should not be able to install on Windows 7. So, the test of whether the application/software installs on the specified platforms and does not install on others comes under this testing.
  • Recovery Testing: If there is a power cut or if the application/software uses the internet, then on the loss of internet connection, the software should be able to recover the user data. This test comes under-recovery testing.

5. GUI Testing

GUI stands for Graphical User Interface. This is nothing but what you see on your screen. If there is software that you do not like to see, it does not matter how good its functionalities are, you will never use it. Hence, GUI is a very important factor and GUI testing becomes even more important. The GUI testing is of 2 types:

  • UI Testing: The user interface and how the user feels about the look of the software is tested here. Basically, in this testing phase, the alignment of the content, the buttons, checkboxes, size of text and other elements on the screen, color contrast, and combination, are all tested. 
  • Functionality Testing: Say there is a button on the screen and when you tap it or click it, it does not do anything. This will irritate you as a user and is a major fault in GUI. Hence, the GUI Functional testing involves testing the functionalities of elements present in the UI. 

So, these were some of the major types of manual testing in software engineering.

Conclusion

From the above discussion, we can conclude that testing is a very important phase in the software development life cycle. Also, manual testing has its advantages over automated testing and there are various situations in which we can’t even use automated testing (for example exploratory testing). 

So, we hope that you have understood the different types of manual testing completely. Keep learning and keep growing. 

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章