What is the difference between Hard and Soft real-time systems?

- Real time operating systems are the systems that have been developed for serving to the real time requests of the applications. 

- They are readily capable of processing the data as it is inputted. 

- They do not make any delays in buffering. 

- Thus, the time taken for processing is quite less.

- The scheduling algorithms used by the real time operating systems are quite advance and dedicate themselves to a small set of applications. 

- Minimal thread switching latency and interrupt latency are two key factors of these kinds of operating systems. 

- For these systems the amount of time they take for responding matters more than amount of work they do.

- These systems are used to maintaining consistency in producing the output. 

The real – time operating systems can be divided in to two categories namely:

1. The hard – real time operating system and
2. The soft – real time operating system

In this article we discuss about these two systems and the common differences between them.

1. The hard real time operating systems produce less jitter while producing the desired outputs. On the other hand, the jitter produced by the soft real time operating system is quite more when compared to its hard real time counterpart.
2. The thing that distinguishes them is not the main goal but rather the type of performance it gathers i.e., whether hard or soft.
3. The soft real time operating systems have been designed as such that they can usually meet the deadlines whereas, the hard real time operating systems are designed in such a way so as to meet the deadlines deterministic-ally.
4. The hard – real time systems are also called as the immediate real time systems. They are bound to work within the confined strict deadlines. If in case, the application is unable to complete its task in the allotted time, then it is said to have failed. Some examples of the hard – real time operating systems are: anti-lock brakes, aircraft control systems and the pacemakers.
5. Hard real time operating system are bound to adhere to the deadlines assigned to them. Missing a deadline can incur a great loss. As for the soft real time operating systems, it is acceptable if the deadline is missed such as in the case of the online databases.

There is also a third category of the real – time operating systems that is not so known. It is called the ‘firm RTOS’. They also need to keep up to the deadline since missing it won’t cause any catastrophic effect but may give results that are undesirable.

More about Real time Operating System

- The embedded systems have evolved all of a sudden and now they are present all around us in digital homes, cell phones, air conditioners, cars and so on. 

- We very rarely recognize the extent to which they have eased our day to day life. 

- Safety is another aspect of our lives for which we depend on these embedded systems. 

- The thing that controls these systems is the operating systems. 

- Real time operating system is what that is used by most of these gadgets. 

- The tasks that are assigned to a real – time OS always have deadlines. 

- The OS adheres to this while completing it. 

- If these systems miss the deadline the results can be very dangerous and even catastrophic. 

- With each passing day the complexity of these systems is increasing and so our dependence on them.

- Some examples of real – time operating systems are:

Ø  OSE

Ø  RTLinux

Ø  Windows CE

Ø  LynxOS

Ø  QNX

Ø  VxWorks

- The RTOS know well not to compromise with the deadlines. 

Explain Jubula - Web Functional/Regression Test Tool

Today we have around 100 tools available for functional and regression testing of the web based applications. Jubula is one among such tools and will be discussed here in detail. 

About Jubala

- This is an open source tool that is available both as a standalone application and as a part of the eclipse package.  

- The former comes with an installer that is quite easy to use and the latter one can be downloaded from an update site. 

- Jubula client can be used for viewing the actual and the expected results and also it can be used for viewing the current as well as the previous results. 

- Here, you can easily the automatic screenshots whenever an error occurs. 

- Jubula supports many applications such as:

1. Html
2. Swing
3. SWT/ RCP/ GEF and so on.

- Some features of Jubula tool have been listed below:

1. Heuristic object recognition
2. Command line client
3. Context sensitive help in client
4. Multi – user database for storing projects
5. Portability
6. Version control

- Command line has been included in this tool so as to facilitate continuous integration.

- Version control is achieved via the exports in XML format. 

- The contribution in this regard was made by BREDEX GmbH (also the developer of GUI dancer). 

- The GUIdancer was actually built up on the lines of Jubula core and offer some more features. 

- Jubula is not dependent on any platform windows, unix, linux or MAC. 

- A project by the name of ‘jubula functional testing tool’ was created as an open source project. 

- This project was a part of the eclipse technology project. 

- Other functional testing tools work up on the thing that the saving and management of the scripts is done through coding. 

Now depending up on the testing approach you are following, your test automation process may involve steps like recording, generation or straightaway writing of the code. 

What differentiates Jubala from other testing tools?

- It considers the importance of the automated acceptance tests as same as that of the project code. 

- According to Jubula, same best practices (reusability, modularity, readability etc.) should be used for creating these tests as well without requirement of any extra code. 

- Thus, the power of testing is given in the hands of the software testers and at the same time for the customers the access improves for monitoring the tests. 

- This results in a code free approach that minimizes the need for test maintenance, thus allowing the users to write the tests from their perspective. 

- If the team focuses on the software from the viewpoint of the user, it can gains a whole lot of quality info which often goes un-utilized when only JUnit tests are run.

- Jubula comes with a library of actions which is used for creating the tests. 

- You can combine the actions contained in the library using drag and drop.

- This library contains all the necessary actions that one may require for writing the tests. 

- This library is also independent of platform and application which implies that you can start writing the tests before the software is actually made available to you. 

- When you work with Jubula, you save on time since as soon as the code is committed the tests can be executed. 

- The time between the introduction of an error and catching it is reduced.

Objectives of Jubala

Jubula has got the following objectives:

1. Providing tooling for carrying out automated GUI testing on html and java based applications.
2. Specifying and maintaining a model specifications and requirements of the tests.
3. Providing API for projects so that the test scenarios can be generated, test can be executed and results can be obtained. 

How to run a test automatically in Test Director?

The whole testing process revolves around the execution of the tests. As the changes are introduced in to the software system or application, running tests either manually or automatically becomes mandatory so that the defects can be located and quality can be assessed. 

How are tests run?

- One starts the testing process with the creation of the tests and adding these tests to a test set. 

- Tests are grouped into test sets by the test director so that some specific goals can be achieved. 

- Execution process of the tests can be controlled via the various controls provided by the test director. 

- Along with these controls, there are certain conditions and settings which need to be configured for the execution of the tests as desired by the tester. 

- The date and time can also be scheduled when the tests will be executed. 

- Once the tests have been defined the tester can begin with the execution of the tests. 

- Whenever the tests are executed manually, it is basically the test steps that were defined earlier during the test planning which are executed one by one. 

- The steps are passed or failed by the tester depending up on whether there is a match between the expected results and the actual results. 

- For the automatic run of a test, the selected tool is directly opened by the test director and the test is run. 

- The result hence obtained is exported to the test director. 

- Setting conditions and specifying date and time for the execution of a test both can be done with the help of the execution flow tab.

- In the execution, one thing should be noticed which is that the condition is always dependent on the result of some other specified test in the same flow. 

- Also, the sequence in which the tests are to be executed can be specified. 

In this article we shall see how the test execution can be automated. The tool selected for the execution of the tests is opened directly by the test director and the tests are run on either local or remote machine. It is either choice if you want to run all the tests or some specified ones. 

For running the tests automatically one of the following tools must be installed on the system:

a)   Astra quick test

b)   Quick test professional

c)   Winrunnner

Follow the below mentioned steps:

1. Clicking on the test lab tab will display the test lab module. This is a must for the automation of the tests.
2. The test set you want to execute automatically should be displayed in the execution grid. For doing this click on the execution grid tab and select the required test from the test sets tree.
3. Select a test. For running the winrunner test select the required test or if you want to run an astra quick test or QTP test select the required one. Next clicking on the run button will open up the execution dialog box and the test will be displayed.
4. Configure the test run settings and select the ‘run all tests locally’ option for running the tests on the local machine.
5. For running the tests click on run tests and the tool will be opened automatically by the test director and the tests will be run. The execution progress can be viewed in the status column.
6. Once the execution of the test is complete close the execution dialog box by clicking on the exit option.
7. Also the summary of the test results can be viewed in the execution grid.

What issues should be considered when deciding whether to automate a test? How to generate an automated test script?est Scripts, Scripts

Execution of the test sets lies at the center of any testing process. As the software system or application encounters changes, the defects are located by running both manual as well as automated tests in the project. Also, the quality of the tests is assessed by running the tests itself. 

Issues considered when deciding to go for automation?

- Deciding which all tests have to be automated is a part of the test planning process. 

- Two options namely manual and automated are available for the execution of the tests. 

- If you go with the manual execution of the tests, you can begin with the execution just after you finish defining the test steps. 

- If you go for automating the tests, the test scripts need to be generated and completed. 

- Below we state the issues that should be considered when deciding to go for automation:

1. Do Automate: Only the tests which are data driven or which make use of multiple data values for the same operation, which run with every new version of the application as a measure to check its functionality i.e., regression testing, which are for stress testing i.e., run many times and tests that facilitate the checking of a server system or multi-user client system (load testing) must always be automated.
2. Do not automate: The tests which are meant for a single execution, need to be executed immediately, check for the usability of the tests and whose result cannot be predicted should not be automated.

Steps for generating Automated Test Scripts

Below mentioned steps can be followed for the generation of the automated test scripts:

1. First, click on the test plan tab in order to enable the display of the test plan module.
2. Locate the manual test that you want to automate by selecting the subject folder available at the root of the test plan tree. There click on the find button and the find folder/ test dialog box will open up.
3. Type the name of the test to be searched for in the ‘value to find’ field of the box. Check the ‘include tests’ check box so that the test director can be instructed to look for folders and tests. Finally click on find option. ‘Search results’ dialog box will pop up thus displaying all the possible matches. Click on go to button and the test will be highlighted in the test plan tree. Close this dialog box.
4. Click on the design steps tab in order to display the design steps tab.
5. For generating a test script click on the generate script button. You can choose either of the following options:

a) QUICKTEST_ TEST: For generating an astra quicktest test or quick test professional test.

b)   WR – AUTOMATED: For generating a winrunner test.

The above two options will be available if the corresponding add ins have been installed. Once the test has been automated, the manual test symbol ‘M’ will be replaced by automated test icon.

6. For viewing the test script click on the test script lab. Click on the launch button for displaying and modifying the test script in the testing tool where it was created.

Whenever an automated test is run, the testing tool selected by the tester is opened by the test director automatically and the test is run on either the remote hosts or local machines. The tests can be run either from the execution flow tab or the execution grid tab.

How to design and copy test cases in test director?

Application testing process is not the one that can be completed in a jiffy. It demands constant input in form of efforts, organization and maintenance. Well, all this becomes easy when you are assisted by mercury interactive’s test management tool.
Test director saves you a great deal of efforts for tasks such as requirements analysis, test planning, test execution, defect tracking etc. here in this article we are going to tell you how you can design as well as copy the test cases in test director. After the tests created for all the subjects have been added to the test plan tree and the basic test information has been defined, the test cases or the test steps are defined.
By defining them we mean that more details or step by step instructions are provided for how that particular test case is to be executed. Each step of a test case consists of two things namely:
1. Actions to be performed on the application under testing or AUT and
2. The expected results.

Test steps can be created either for manual tests or automated tests using test director. For manual testing it is said to be complete when you are done with the designing of the tests.
Then, the test execution can be straightaway be started by using the test plan tree. But in the case of the automated testing, an addition step is to create automated test scripts using any other mercury interactive tool such as Winrunner or some other third party tool.

Steps for designing test cases

Below mentioned are the steps that one can follow for designing a test case:
1. It has to be made sure that the test plan module is on display and if it is not click on the test plan tab to turn it on.
2. The test case for which you are about to design the test steps also needs to be displayed. You can do this by simply clicking on the name of that particular test.
3. Next you need to launch the design step editor by clicking on the ‘design steps lab’.
4. In the design step editor dialog box clicking on the new step button you will get a new step dialog box which will ask you enter a step name which is by default a sequential number.
5. Now for defining that step you require to fill up the following fields and click OK:
         a) Step name
         b) Description
         c) Expected result
6. Last step is to click OK which will close the design step editor and display the design steps.

How to copy the test cases?

In test director you get the option of copying the test cases either from the same project or from some other. Follow the below mentioned steps:
1. You need to turn on the design steps tab and select that particular test case from the test plan tree which you want to be copied.
2. Next step involves selecting the steps of the test cases which you want to be copied. You will observe a gray sidebar, position the mouse pointer there and you will see that the pointer changes to  ->. Now hold down the shift and select the steps you want to be copied.
3. By using the copy steps copy down all the selected steps.
4. Next paste the steps where you want them to be copied in the test plan tree by using the paste steps button in the design steps tab.

How do u do batch testing in WinRunner & Is it possible to do in QTP, if so explain?

WinRunner provides you the facility of executing a certain batch of the unattended tests. This feature of the winrunner has proved to be quite useful especially in the situations when a large groups of tests have to be run over night i.e., an over night run. 

How to do batch testing in WinRunner?

- A batch test can be viewed as a test consisting of a test script which holds the calls to the other tests. 

- Such call statements execute each and every test called in the list and also save the result up on execution.

- A batch test may consist of n number of tests depending up on the need and requirement of the user. 

- A batch as such just seems like a normal test but with an unusual large number of calls. 

- A batch test can be run by using the option “run in batch mode”. 

- This option is available in the run category of the general dialog box which gets invoke just before the start of the execution of the test. 

- Whenever a test is run in batch mode, all of the messages that may be displayed during the test run are suppressed by the winrunner. 

- This is done so that the winrunner is able to run a batch test unattended. 

- The execution of the batch tests is therefore different from the regular, interactive test runs where you may come across several messages popping up on the screen. 

- In batch tests, this thing is not there and so a lot of time is saved. 

- The current chain of all the called tests can be viewed at a break point in the call chain pane available for viewing in the debug viewer window. 

- After the completion of the batch test run the winrunner makes the results available in the test results window. 

- Winrunner provides you the facility of running the batch test via command line.

Is it possible to do batch testing through QTP?

- The quick test professional is the successor of the winrunner and is quite advanced and efficient in many respects as compared to the winrunner. 

- Batch testing is possible in quick test professional. 

Difference lies in the way in which the batch testing is carried out here. 

- The quick test professional facilitates the batch testing service with the help of a separate built-in tool called the test batch runner or QTP batch testing tool. 

- With this tool you can group the tests in to a number of batches which are then executed. 

- The result of this batch test run is made available in the test result viewer. 

- In quick test professional, batch wise viewing of the result is not possible. 

- Results for individual tests have to be viewed. 

- For the execution of a test batch you need to open the path of the test batch and give the run command. 

- In quick test professional, other mercury products for batch testing can also be installed and used if one is not comfortable with the in built tool of the quick test professional i.e., the test batch runner. 

- For doing this you need to follow the below mentioned sequence:

Tools menu à options à run à check the check box “allow other mercury products” à apply à ok

- Even a partial batch test is also possible! 

- You just need to deselect the tests that you want to be executed. 

- MTM or multi test manager is another mercury product using which one can carry out batch testing. 

What is a Run-Time Data Table? Where can I find and view this table?

The quick test professional always makes it a point to produce a run time data table at the end of every run session so that the user can have a live view of the data table that is currently associated with the test being carried out at that time. 

What is a Run-Time Data Table?

- While the run session is still in progress, the run time data table is displayed in the data table pane of the quick test professional window. 

- This is to make it easy for the user to view any changes that are constantly made to data during the run session.

- At the end of the run session, this run time data table is closed and in the data table pane the stored design time data table is displayed again in the place of the run time data table. 

- In some of the cases the data which entered in to the run time data table during the run session is not saved along with the test.

- At the end of the run session the data in the table is finalized and is displayed is run time data table column of the results window of the test. 

- The name of the run time data table was derived from the fact that it is generated during the run time. 

- With every script or component there is an associated run time data table which serves the purpose of displaying the data.  

- One run time data table has the property to access the data from some other data table during the run time. 

After a particular test has been executed with either of the following:

1. Data table parameters and
2. Data table output value steps

The following are displayed by the run time data table:

1. Parameterized values that were used during the testing and automation and
2. Output values that were saved in the data table during the run session.

Certain data table methods are provided by the quick test professional with the help of which the user can alter the data table as required and these are:

1. Add sheet: This data table method can be used to add sheets in to the pre existing run time data table. Syntax used is:

Datatable.addsheet (name of the sheet)

2. Delete sheet: This data table method as obvious from its name is used for deletion of the already added sheets in a run time data table. However at one time only one sheet can be deleted. Syntax used is:

Datatable. Deletesheet (“ID of the sheet”)

3. Get sheet count: This data table method gives you the number of sheets that you have in your run time data table. Syntax used is:

Datatable. Getsheet count

4. Get sheet: This methods returns the sheet specified from the run time data table by the user. Syntax used is:

Datatable. Getsheet( ID of the sheet)

5. Get row count: Returns the number of rows present in a particular sheet of the run time data table. Syntax used is:  datatable. Getrowcount
6. Value: This data table method serves two purposes i.e., using it you can either obtain value of a specified cell or you can modify the value of the cell. Syntax for both the cases is:

Variable = datatable. Value( name of the parameter, name of the sheet)

Variable = datatable. Value( name of the parameter, name of the sheet) = value

  There are some other data table methods also like:

1. Set current row
2. Set next row
3. Set previous row
4. Import
5. Export and so on.

What is a QTP batch testing tool?

Under the context of quick test professional the term given for the execution or running of multiple tests or a series of tests at the same time is “batch testing” or sometimes it is also called “batch execution”. 

However, this batch testing cannot be performed normally like the other applications, a special tool is needed. Quick test professional provides such a tool and it is called “batch testing tool” or the “test batch runner”. 

The batch testing process follows the below mentioned process:

1. Creation of individual tests.
2. Execution of the individual tests created in the first step.
3. Formation of batches using the batch testing tool.
4. Execution of the batch tests on tests from batch testing tool.
5. Observation of result via test result viewer.

Here one thing to be noted is that the provision of viewing batch wise result is not available in quick testing professional for the batch testing sessions. 

Creating a Test Batch

- For creating a test batch, you need to hog down to the tools menu in the menu bar of the quick test professional window.

- Then select test batch runner, then batch, then add option, then specify the path of the test to be added, then save it with appropriate extension like MTB or module test batch and  finally close the test batch runner. 

Execution of Test Batch

- For the execution of a test batch you again need to open the batch testing tool i.e., the “test batch runner” by following the same sequence of steps as discussed for the creation of a test batch. 

- But instead of the add option you need to select the run option. 

- When you do this, the test batch runner is launched and the tests are executed one by one. 

Here if you don’t want to use test batch runner or if you are facing issues with it, you can go for batch testing using other mercury products by checking the “allow other mercury products” check box and clicking OK. 

- In some cases it may be required to run only some specific tests and not all.

- This is also possible in quick test professional via test batch runner. 

- For doing this, you just need to open the test batch runner like always and go to option “open test batch”, then select or deselect from the lists of the tests and go for run test batch. 

- The selected tests are kept in waiting mode till they are all executed one by one. 

- Another mercury product that serves the same purpose as the test batch runner is the “multi test manager”. 

- After the execution of the scripts is complete via test batch runner you can open up that particular test script, then go to automation, then results option and here you have the results. 

- When your test batch is set to batch mode, the entire results cannot be viewed at a time. 

- This whole program can be scheduled if you want it to be scheduled by going to the scheduled tasks option in the control panel. 

- There are some known issues with the quick test professional’s batch testing tool like consolidated test results cannot be viewed and if by chance the batch test execution stops in the mid way, the batch cannot be executed again. 

- The batch runner window should be closed and opened again. 

- Whenever a test is completed, the QTP window comes in the front and the AUT window goes back, the next is opened and executed. 

- For multi test manager the same steps are followed as for the quick test professional. 

Explain Quick Test Professional (QTP) Testing process?

The quick test professional is a software package that facilitates both the test automation as well as the software testing. To be an expert in quick test professional it is important that you understand both the test automation and software testing using the quick test professional. 

When the software testing process is carried out using the quick test professional it is referred to as the quick test professional test process. By now you must have got it that the emphasis of this article is on the same testing process. 

To say the quick test professional testing process constitutes of the following steps as mentioned below:

1. Configuring of the record and run settings
2. Creating an object repository (this step is optional is many cases)
3. Creating the basic automation scripts
4. Editing or enhancing the script
5. Executing the script
6. Debugging the script
7. Analyzing the results
8. Summarizing the results (this includes tracking the discovered defects and generating the report)

Major stages of the QTP testing process

1. Analyzation of the application

- This is the first test and is aimed at finding your testing needs. 

- This phase involves the type determination of the development environment of your application i.e., whether it is a web application or a windows application. 

- In either of the cases, you will need to load your quick test professional software with appropriate add ins. 

- There are available separated add – ins for both the web type and windows type applications. 

- These add – ins are required since they only give the power to quick test professional to identify as well work with the objects present in the application. - Next thing to determine are the business processes and functionality required. 

- For determining these two things you need to think about what your customer will do with the application. 

- The required business processes are then divided in to smaller groups or units and the actions based on these units are created. 

- This is done so because with smaller modular actions it becomes easy to read, follow and maintain the tests in the long term.

2. Preparation of the testing infrastructure: 

- Based on the needs that you determined in the first phase, the resources required are determined in this second phase. 

- The resources are either obtained or created as required. 

- The resources may include the following:

      a)   Object repositories along with the test objects.

      b)   Function libraries along with the functions that add to functionality of the quick test professional and so on.

- Also in this phase the settings of the quick test professional are configured as per the tasks need to be performed.

3. Building of the tests and addition of the steps to them: 

- By now the testing infrastructure is complete and now you can start developing your tests. 

- Any number of empty tests can be created and actions can be added to them so as to form the testing skeletons. 

- Relevant actions can be associated with the corresponding object repositories.

- Relevant tests can be associated with the function libraries. 

- Steps can be inserted with the help of key words and test preferences are also considered.

4. Enhancement of the test: 

- This phase includes insertion of the checkpoints so that you can easily search for a specific value of object, page or text etc and know whether or not your application is functioning properly.

5. Debugging, execution and analyzation of the test: 

- This phase ensures that the application is working without encountering any interruption. 

- Only if a test is running properly, it can correctly check the behavior of the application.

6. Reporting of the defects: 

- The defects discovered can be reported to the quality center if you have it installed on your machine. 

What is a Test Fusion Report in QTP?

This article gives a detailed description of what a test fusion report is. Once a test has been executed, all the aspects of that particular test report are displayed by a certain report that has been termed as the test fusion report. 

What are Test Fusion Reports?

Basically the below mentioned aspects of a test run are displayed by the test fusion report:

1. A high level overview of the results.
2. Tree view of that particular test specifying the exact point where the application software actually encountered failure and this tree view is expandable.
3. The data that was used during the test run.
4. The screen shots of the steps of the test run where the application software showed some discrepancy.
5. Explanation of each check point in high detail along with the fail and pass criteria.

- These test fusion reports can be combined along with the quick test professional. 

- The main advantage of this is that on combining these reports with the quick test professional, they can be shared among the whole development and quality assurance team. 

- The test fusion report displays at what all exact points the application software failed. 

- The test fusion report consists of a data table. 

- This data table gives a record of the whole test data. 

- A screen view is also presented in the test fusion report which provides one with the actual screen view. 

- With the aid of the test fusion report, even the success or failure of the check points can be determined. 

- The test fusion report proves to be quite a handy tool while the developer has to report to its client or customer. 

- There are some other components of the test fusion report as mentioned below:

1. Name of the test
2. Test case
3. Start of the test run
4. End of the test run
5. Name of the result
6. Iteration
7. Status

- A different aspect of the test run is displayed by the test fusion report and can also be considered to be a kind of compilation of the whole application testing process. 

- The screen shots provided by the test fusion report provides a solid support for any inconsistencies that are present within a software application. 

- The test fusion report is represented in the tree format and displays all the aspects of the test run in the same format. 

- You can find detail for each and every step of the iterations here in the test fusion report. 

- All the results of a test are collected by the test fusion report. 

- Test fusion report can also be categorized under the instances of the collecting parameter return. 

- There is a big difference between the errors and the failures which is distinguished by the test frame work. 

- Anticipated problems are called failures whereas the un- anticipated ones are the errors. 

- All these are listed by the test fusion report. 

- The results of the testing have to be reported at various stages like unit testing, integration testing and system testing and so on. 

- The test fusion report provides the state of the software product that is under development through different angles. 

- Producing this test fusion report takes around 5 – 10 percent of the total development effort. 

- This percent though being quite less is of great significance, after all an organization cannot give a certification about the readiness of the software product in just one line. 

- Producing a test fusion report becomes much more important especially when the software encounters some problem.

- There are several other aspects of the software system or application that the customer would like to know apart from the functional requirements like a few mentioned below:

1. platform
2. dependence
3. performance and so on.