What is Concurrent Testing?
By: Murali Chemuturi
What is Concurrent Testing?
In these days of web based computing, it is possible that the computer (server) may be simultaneously serving thousands of clients with thousands of processes in execution. In such a scenario, it is possible that the CPU may enter into a dead-lock situation. To refresh your memory, dead-lock is a situation on a computer when one process (say A) locks a dedicated resource (say X) and waits for another dedicated resource (say Y) locked by another process (say B) which is looking for the resource (X) locked by the first process (A) rendering both the processes in an infinite wait for the non-available resource.
Printers causing dead-locks was resolved through SPOOLing (Simultaneous Peripherals Operation On Line), which has become the de-facto standard for driving the printers.
This was happening on the data files frequently. But with the advent of RDBMS and record-level locks being placed automatically, this issue was more or less resolved, but not completely.
Ensuring dead-locks do not occur is referred to as concurrency control. Most of the concurrency control is handled by the system software including the operating system and device drivers, in case of dedicated devices and RDBMS packages in case of data files. There are situations in which programmers need to handle concurrency control and often times, this is forgotten and testers need to uncover such situations.
Now there are two kinds of situations that give rise to concurrency problem.
Take the scenario of a large organization with locations geographically spread across the country or the world which is generating the profit and loss statement. This process involves referring many tables and extracting information to process and generate the required reports. Report writers do handle very predictably with two or three tables but when it comes to 4 or more tables, report writers may not produce predictable results, as setting the correct relations between tables is very difficult. In such cases, it is normal to extract data from all input tables into one or two tables and generate the report using those few tables. These tables are referred to as “report tables” which are emptied and filled on-the-fly when the report generation process is initiated. Report tables are transient and are emptied before filling with data. Report tables are used in many applications. This process of emptying and filling of report tables could take a short duration or a significant amount of time. When more than one user initiates the process that empties and fills the report tables, it is not difficult to imagine the consequences – no report could be reliable.
Another situation is a ticket reservation system. Imagine that there is only one place and two or more users requested for the same place concurrently. It will be shown as available to all users. Let us assume that two or more users have confirmed the purchase and gave credit card details. Now RDBMS is equipped to accept only one and reject the others. So, all except one, confirmations are rejected. Supposing, the credit card transaction is rejected for the accepted request – what happens?
This type of situation arises in warehouse management, online purchases, accounting etc. applications.
Handling such situations is referred to as concurrency control in software development circles. There are many methods for handling concurrency control and detailing them is beyond the scope of this article.
These situations cannot be detected by normal functional testing. This issue needs to be detected using the concurrent testing.
How do we carry out Concurrent Testing?
First we need to establish the need for concurrent testing. We can accomplish this by studying the design documents. See, first, if report tables are used. Every unit that makes use of the report tables needs to be tested for concurrency control. Second we need to see if reservation of tickets or any thing of that nature is involved, if so, we need to carry out concurrent testing.
Once we established the need to carry out concurrent testing, we carry out the testing in the usual manner. We design the test cases. We set up the environment for testing. If it is carried out manually, we set up two individuals to fire the same process simultaneously. They are seated in adjacent seats so that they can consult and ensure that they fire the process as simultaneously as possible.
If the testing is carried using a tool, its parallel testing module can be scripted appropriately to fire the process simultaneously to execute the test cases designed earlier.
The results of concurrent testing either prove or disprove that concurrency control features are built into the software product. When concurrency features are built-in, the software would respond appropriately to both the individuals without generating any errors. If concurrency control features are absent, the software would generate errors.
The result is declared as concurrency control features are present or absent.
Concurrent testing needs to be carried out based on test cases that have to be designed on a case-by-case basis extracting information from the design document. The expected result would depend on the specific functional scenario and is difficult to describe here.
Should every software product be subjected to concurrent testing? The answer is no. But when planning the testing for a product, we need to consider if concurrency control features are needed in the product. If concurrency control is needed, then, we have to include this test in our test plan.
... to read more articles, visit http://sqa.fyicenter.com/art/