Manual testing is a part of the testing process over the quality control step in the process of software development. It is produced without the use of tester software to check the program website or by user interaction modeling. Any regular users can do this with informing the developers about the bugs.
Such users usually provide random, spontaneous revisions when just sitting in front of computers and testing different things. The tester may or may not have a checkup plan or checklist. This person thinks to click here and there trying different scenarios, values and thinking, "What happens if I do like this." All the ideas and actions of the tester are not documented and are spontaneous. A few scenarios can not be replayed later.
This situation usually happens when a development project is running out of time. For such a situation there's a typical lack of specifications. Requirements are still in development and are always changing, and the PM says: "No time for scribbling, just do it." The work in this project is not particularly excellent and deserves sympathy.
Often, the automation of this type of testing is as follows:
It's hard to think of many advantages of a spontaneous test. The only argument that is worth mentioning is that it saves time (because we do not spend the time on planning, testing the design, we are just beginning the checkup). This approach is always more expensive on long-term developments (and in most developing and testing cases).
Disadvantages of Manual Testing:
The decision to automate this test depends on the decision of the tester. This means that the tester must have the necessary knowledge to produce a real checkup. Otherwise, it depends on the individual design and implementation of tests without any independent verification of the control quality. The way how manual testing is done influences the work of QA team in the future. Some companies come to the conclusion that they have to hire more and more testers while others just use the outsource QA services.
Can you Do Stress Testing Manually?
Stress testing lets you to control how applications and systems, in general, are efficient regarding stress and also to evaluate the system's ability to regenerate, i.e. to return to a normal state after discontinuation of the effects of stress.
Stress in this context may be increasing the intensity of the operations to very high values, or change the alarm server configuration. One of the objectives of stress testing may be the performance degradation assessment. Thus the goal of stress testing may interfere with performance test objectives.
Stress testing is a critical stage of software assessment, during which analyzes the performance of the system at different loads. Stress testing is an automated process, as to realize the terminal degree of the system is quite difficult to load regarding manual testing. So the answer is No, it should be done using automation.
How is a stress test done?
Stress tests of the system are based on application features, allowing qualitatively to determine the stability of the work in normal conditions and under the system overload. Unlike load testing, a stress test aims to make it work at peak load. Stress tests are used to identify those segments of code that need improvement. Also, they play a crucial role in the detection of errors related to the management of resources. Stress checkups indicate the obvious gaps in the synchronization code that affect the stable workflow of the system.
At the end of the test, the expert assesses the ability of the system to recover from the load limit. In this case, the limit load of the system can be detected in the testing phase of the application. Typically, in the perfect case, the system must independently "rehabilitated" after exposure to the maximum load. Also, it is also important how long the system is able to withstand such pressure.
Despite some similarities with load testing, stress testing of the system has its own characteristics. First, stress testing is based on the sequential increase of the pressure to find the system performance limits. Load test involves checking the application in the normal mode to ensure the correctness of the system and its components.
Examples of Stress Tests
Stress testing can be used for stand-alone applications and distributed systems with a client-server architecture. The simplest example of stress testing of a separate application may be opening a 50 MB file with Notepad, included into the Windows package. In general, as the conditions for the stress testing can be used a linear increase in the expected load.
How is a stress test done? In the case of multi-distributed systems, testing must take into account not only the actual amount of the load, consisting of a variety of elements but their proportions in the total volume. For example, there's a Web Service for processing and displaying user-created pages, each of which can consist of plain text and some dynamic controls.
It is known that a user creates one page per day, which contains an average of 1,000 text characters and one form. It is also known that the system is one request to display the original page per minute. At the same time the speed of page display is a critical business process.
Using the above model, the users' behavior with the system, it is easy to simulate the dynamics of change in the load. A stress test, which is taken as a basis for such a load model does not address the risks associated with the fact that the system will no longer satisfy the performance requirements of the changing scenario of its use. For example, the display speed of the page may be significantly reduced if people add dozens of forms to it instead of one.