Explain the Priority CPU scheduling algorithm

A number of scheduling algorithms are available today and all are appropriate for some different kinds of scheduling environments. In this article we give a brief explanation about the ‘priority CPU scheduling algorithm’. 

For those who are not familiar with this scheduling algorithm, a special case of the priority algorithm is the shortest job first scheduling algorithm (SJF). 

- This algorithm involves associating a priority with each and every thread or process. 

- Out of all the processes, the one with the highest priority is chosen and given to the processor for execution. 

- Thus, it is decided by the priority that which process has to be executed first. 

- There are cases when the two or more processes might have the same priority. 

- In such case FCFS (first come first served) scheduling algorithm is applied. 

- The process first in the queue is then executed first. 

- The SJF is essentially a modification of the priority algorithm. 

- Here, the priority of a process (indicated by p) is simply taken as the inverse of the following CPU burst as predicted. 

- This implies if a process is having a large CPU burst, then its priority will be low accordingly and similarly if the CPU burst is small, the priority will be high. 

- Numbers in some fixed range are used for indicating the priorities such as from 0 to 4095 or from 0 to 7 etc. 

- One thing to be noted is that there has been no general agreement up on whether the number 0 indicates lowest priority or highest priority.

- In some systems the lower priorities are indicated by the low numbers while in some systems low numbers mean higher priorities. 

- The latter case i.e., using low numbers for representing high priorities is more common.

For example, consider the 5 processes P1, P2, P3, P4 and P5 having CPU burst as 10, 1, 2, 1, 5 respectively and priority also respectively as 3, 1, 4, 5, 2. Using the priority scheduling algorithms, the processes will be executed in the following order:

P2, P5, P1, P3, P4

There are two ways of defining the priorities i.e., either externally or internally. This gives two types of priorities:

1. Internally defined priorities: These priorities make use of some quantities that can be measured for computing a process’s priority. These quantities include memory requirements, time limits, ration of the I/O burst and CPU burst, number of files and so on.
2. Externally defined priorities: These priorities are defined by some criteria that are external to the operating system. Such factors include political factors, department leading the work; importance of the process, amount of money paid and so on.

The priority scheduling can be itself divided in to two types namely non – preemptive or preemptive. The priority of the process waiting in the ready queue is compared with that of the executing process.

Ø  Preemptive priority scheduling: Here the CPU is preempted if the waiting process has a priority higher than that of the currently executing process.

Ø  Non – preemptive priority scheduling: Here the new process will be let waiting in the ready queue till the execution of the current process is complete.

Starvation or the indefinite blocking presents a major problem in priority scheduling. A process will be considered blocked if it is ready for execution but has to wait for CPU. It is very likely that the low priority processes will be left waiting indefinitely for CPU. In a system that is heavily loaded most of the time, if the number of high priority processes is large, the low priority processes will be prevented from getting processor. 

What is a Safe State and what is its use in deadlock avoidance?

Safe state plays a great role in avoiding the deadlocks. In this article we discuss in detail the concept of this safe state.
When do we call a state safe?
It is when even if the system allocates resources to all the processes and no deadlock occurs. This allocation is to the maximum limits and can be done in any preferred order. To put it down more formally, we can say that a system is considered to be in a safe state only if a safe sequence exists. This would become clearer from the following example:

Consider the following sequence of processes:

- Now this sequence is considered to be a safe one for the current state of the allocation if the resource requests made by each of the processes Pi can be satisfied by resources that are currently available including the resources held by some another process that precedes Pi.
- In this case, if the resources required by the Pi are not presently available, then it can wait till the preceding process completes its executions and releases the resources.
- Once it finishes, the resources it held, now can be utilized by the Pi for completing the task assigned to it and then it also releases back the resources to be used by succeeding processes.
- It then finally terminates.
- If there exists no sequence like this, then the system is said to be in an unsafe state.
- A deadlock cannot occur in a safe state and so this state cannot be called a deadlocked one. 
- But on the other side, a state is unsafe if it has a deadlock.
- However, it is not necessary that the reason for all states being unsafe is the deadlock.
- An unsafe state can however lead to a deadlock. 
- It is in the safe states, that the operating system is capable of avoiding the deadlocks.
- When the operating system falls in an unsafe state, it is no more in a position to prevent the requests of the processes that would cause a deadlock to occur.
- It is the behavior of the processes by which the unsafe states of the system are controlled.
- Another major difference between the safe and the unsafe states is that in a safe state it is guaranteed by the operating system that the execution of the processes will be completed in expected time but in the case of unsafe states it gives no such guarantee.
- If the concept of the safe state is predefined, then algorithms can be designed that would make sure that no deadlocks occur.
- The idea behind these algorithms would be to ensure the following things:
1. The system does not come out of the safe state.
2. The system is kept in a safe state initially.
3. The system must be able to determine if a resource requested by a process can be allocated immediately to it or it requires waiting.
4. The system grants the request of the process if and only if after finishing it, the system would still be in a safe state.

- One disadvantage of such algorithms is low resource utilization. It is because the process would still have to wait for the resource even if it is available.
- A deadlock occurs when two or more processes that are competing with one another to wait for each other to finish and neither of them do so.
- The deadlock which involves only two processes is called a deadly embrace.
- This may also occur if one process is waiting for the other to finish which in turn is waiting for some other process to finish and so on.

What is Context Switch?

- The context switch refers to the process that involves storing and restoring of the context or the state of the process. 

- This makes it possible to resume the execution of the process from that same saved point in the future. 

- This is very important as it has enabled the various processes for sharing one CPU and therefore it represents one of the essential features of an operating system that is capable of multi – tasking. 

- It is the operating system and the processors which decide what will constitute the context. 

- One of the major characteristic of the context switches is that they are computationally very intensive.

- Most of the designing of the operating systems is concerned with the optimization of the use of these switches. 

- A finite amount of time is required for switching from one process to another one. 

- This time is spent in the administration of the process which includes saving and loading of the memory maps, registers etc. plus the various lists and tables are updated. 

- A context switch may mean either of the following:

Ø  A register context switch

Ø  A task context switch

Ø  A thread context switch

Ø  A process context switch

Potential Triggers for a Context Switch

There are three potential triggers for a context switch. A switch can be triggered in any of the three conditions:

1. Multi-tasking: 

- It is common that one process has to be switched out of the processor so as to execute another process. 

- This is done by the use of some scheduling scheme. 

- Here, if the process makes itself un-executable, then it can trigger this context switch. 

- The process can do this by waiting for synchronization or an I/O operation to finish. 

- On a multitasking system that uses pre-emptive scheduling, the processes that are still executable might be switched out by the scheduler. 

- A timer interrupt is employed by some of the preemptive schedulers to avoid process starving of the CPU time.

- This interrupt gets triggered when the time slice is exceeded by the process. - Furthermore, this interrupt makes sure that the scheduler will be able to gain control for switching.

2. Interrupt handling: 

- Modern architectures are driven by the interrupts. 

- This implies that the CPU can issue the request while continuing with some other execution and without waiting for the current read/ write operation to get over. 

- When the currently executing operation is over, the interrupt fires and presents the result to the CPU. 

- Interrupt handler is used for handling the interrupts. 

- The interrupts are handled by this program directly from the disk. 

- A part of the context is automatically switched by the hardware up on the occurrence of an interrupt. 

- This context is enough for the handling program to go back to the code that raised the interrupt.

- The additional context might be saved by the handler as per the details of both the software and hardware designs. 

- Usually, only a required small context’s part is changed so as to keep the amount of time required for handling as minimum as possible. 

- Kernel does not take part in scheduling a process that would handle the interrupts.

3. User and kernel mode switching: 

- A context switch is not required for making a transition between the kernel mode and the user mode in an operating system.

- A mode transition in itself cannot be considered to be a context switch. 

- But, it depends on the OS whether or not the context switch will take place. 

Explain Janova - Web Functional/Regression Test Tool

About Janova Testing Tool

- Janova is another tool in the class of the web testing tools but certainly better since it is automated. 

- The major characteristic feature that sets this testing tool apart from the others is its capability of running the tests in the cloud with security and reliability. 

- Janova can be configured using the project structures of features such as pages, test scripts and flows for accessing the web – based applications and defining its requirements in natural language such as English. 

How the application is supposed to work is described by its features.

- Firstly, the feature is created, verification elements are defined by the user that is supposed to be on that particular web page. 

- The tool also provides the detailed result reports concerning the tests performed. 

- Janova is all about automated testing in cloud which is powerful, effective and simple. 

- Using Janova, you can write tests in simple English. 

- Therefore, the need for coding is eliminated. 

- The tests are executed via the power of the cloud. 

- The detailed reports help you to understand the results of your test. 

- The plain English business rules are turned in to the tests by Janova. 

- Since the tests are run in the cloud, the need for keeping the software up to date and disparate files is reduced.

- Also, you don’t need to spend thousands of dollars on the maintenance of the software testing equipment.

- For producing the code – free business requirements the features, flows and pages. 

- These requirements then become the automated tests that can be executed in the cloud at a speed that is 20 times faster than the usual web testing tools. 

How Janova actually works?

- Janova offers such an automated testing solution that lets you test an application across various environments. 

- You can use the power of the cloud for multiplying the effective workload and at the same time can track the progress of your development team. 

- Janova has been designed in such a way that the brittleness that other testing solutions have can be avoided.

- If the business requirements undergo any changes, they are automatically reflected in the tests since the tests are requirements and requirements are tests. 

- Therefore, changes made in one are reflected in the other.

- Using just plain English you can create a test in very less time that would be capable of creating and updating the variables automatically.

- It would also link the variable through the system of features, steps, scenarios, and pages.

-The tests are defined at a very high level allowing you to implicitly understand the desired outcome of the test. 

- Once you are done with the creation of the features and scenarios, you can define the variables by right – clicking on the ‘inspect element’ option with any tools preferred by the developer and moving that info in to the page files. 

What if you encounter an error in the page files? 

- Janova provides solution for this also. 

- You can edit it here and the changes will be retroactively be updated within the tests. 

- The application under test goes through the following stages:

1. Janova application
2. Broker
3. Workers
4. Secure access
5. Results

- Janova operates through the cloud – based system of workers.

- It scales and delegates the processing power automatically ensuring that you get results for your tests as fast as possible.

- The plain language syntax is converted in to a testing script. 

- This script is then distributed throughout the cloud.

- Janova has partnered with GoodData (which is a business intelligence provider) in order to provide it users with a more powerful analytic suite.

What are the main features of TOSCA? What are its benefits and limitations?

About TOSCA

- TOSCA test suite was developed as a tool for automated execution for regression and functional testing by TRICENTIS technology and consulting GmbH.

- TOSCA is a wise combination of an application programming interface, a graphical user interface, integrated test management and a command line interface. 

- In the year of 2011, TOSCA became the second most widely used software test automation tool. 

- Since then, it has received a number of awards for its web and customer support.  

- The architecture of TOSCA comprises the following components:

Ø  TOSCA commander

Ø  TOSCA wizard

Ø  TOSCA executor

Ø  TOSCA exchange portal

Ø  TOSCA test repository

- This test automation tool follows a model driven approach so that the whole test can be made dynamic in nature. 
- The modules can be dragged and dropped for creating new tests.  
- This in turn makes it possible for having a business – based description of the test cases.
- With such a description it becomes for the non – technical users to design and automate the test cases.

Features of TOSCA

- Main features of TOSCA include:

Ø  Generation of dynamic test data

Ø  Generation of synthetic test data

Ø  Business dynamic steering of test case generation that is highly automated

Ø  Unified handling as well as execution of the automated and manual test cases.

Ø  Unified handling and execution of the non – GUI and GUI test cases.

- In addition to all these above mentioned features, another feature of TOSCA is that it weighs the test cases as per their importance in proper execution of the business processes. 
- This also enables the TOSCA to provide detailed reports about the impact that the existing technical weakness have on the fulfillment of the requirements.
- A software called Fecher uses TOSCA for the development of data base and application migration projects.

Limitations of TOSCA

TOSCA has two major limitations when compared with the other software test automation tools:

Ø  Using it one cannot perform any load testing and stress testing.

Ø  It hasn’t got any active X components.

Below mentioned extensions are provided with TOSCA:

Ø  Requirements: This extension lets the requirements to be imported, edited, exported and administrated the risk associated with the requirements can be weighted. These requirements are then linked to the tests after they have been designed.

Ø  Test case – design workbench: This extension defines the tests cases that are required for providing coverage to specific test objects on the basis of the requirements. The test cases are then generated by employing all the combinations in the following ways:

1.    Pairwise

2.    Orthogonal array

3.    Linear expansion

Ø  Reporting: This extension lets you collect, analyze and present the test results. Either crystal reports can be used for creating the test reports or they can be exported as an XML or PDF file.

Ø  TOSCA easy entrance: This extension lets you create the entities that can be reused via drag and drop feature.

Ø  User management: This extension lets you integrate the multiple user concept with check in and out mechanisms as well as versioning.

Ø  Web Access: This extension works for providing remote access.

Ø  SAP solution manager ready: This extension lets you integrate TOSCA with SAP.

Because of its various features TOSCA is so famous among the testers.  A total of 300 customers have been recorded worldwide. The software is being used in numerous tasks such as:

1. Banks
2. Insurance
3. Telecommunication
4. Industrial companies and so on.

It makes use of third generation model that uses plain English for the creation of tests.  

Explain Cucumber Testing Tool?

A need was felt for a tool that could create and run automated acceptance tests that were developed in so called BDD or behavior driven development style. Thus, cucumber testing tool came in to existence. 

About Cucumber Testing Tool

- The software for this tool has been developed in ruby programming language. 

- However, the cucumber testing tool does work for the projects beyond the ruby level. 

- For some ruby, cucumber testing tool is like a bridge to go to the target language. 

- For other, gherkin parser still continues to be relevant while they use the target language for the implementation purpose.

- There are certain feature documentations that are created in business – facing text and these can also be executed with the help of cucumber testing tool. 

- Features might be defined using one or more than one scenarios. 

- These are executed using the ruby definition of the test implicit comprising of few steps. 

- For the ruby tool box, the cucumber testing tool proved to be the most popular testing frame work in the month of January 2012. 

- The leading frame work was RSpec. 

- In the same year in the month of April, the cucumber testing tool was moved to a category of the acceptance test frameworks. 

- A survey was carried out which revealed that cucumber testing tool stands 5^th in the ranking of the popular testing frameworks being used by the startup companies.

- Cucumber is just an implementation of the behavior driven development based up on ruby.

- Using it, the user can describe how the system behaves with some natural language comprising of some specific keywords. 

- Firstly, a feature file is created explaining a feature of the software system or application as well as certain scenarios pertaining to a number of different test situations. 

- Secondly, step definitions are written in ruby programming language that explains the purpose of that particular step. 

- Writing those definitions in ruby language provides flexibility in the execution of the test cases. 

- The testing tool comes with definitions for an acceptance testing tool called webrat. 

- This tool can be used for simulation of the browser not having javascript support. 

- It also provides option for making a combination with water that is a web automation frame work and is used for implementing the web automation tests based up on web browser.

- Using cucumber, with this combination counts as a traditional way of using it but anyways it works quite well. 

- In testing using cucumber, a feature is tested against a number of test scenarios that might describe several operations. 

- The step definitions part needs to be explained so that the tool knows what it has to do next. 

- In some of the cases, water is used with water – web driver gem and Rspec gem. 

- Constants can be defined as a reference to the browser and for web.

- Hash PAGES is not required in every case but proves to be beneficial when there are a number of pages involved. 

- The tests thus developed can be executed either when the full web site is ready or during the implementation phase itself. 

- Even if you decide to go with the second option, you will have to run the test one more time when the next release goes out. 

- You have a third option i.e., for using the test as a stand – alone set for the web site. 

- Another plus point of the cucumber testing tool is that it displays in quite a formatted way that displays steps that were both successful and failure. 

- Green color is used for displaying successful steps and red is used for the failed ones. 

- All that has been described for the cucumber implies for the water web testing frame work also. 

How is test management done by the test director?

If you are familiar with all the concepts of the test director you can apply them to your software systems or applications since you know how it works.

The test director implements the test management via four major phases as mentioned below:

1. Specification of the requirements
2. Planning the tests
3. Execution of the tests
4. Tracking the defects

Throughout each of the phases the date can be analyzed by the detailed reports and graphs generated earlier. Firstly, you need to analyze your software system or application and determine all of your testing requirements. 

Phase I - specification of Requirements

The first phase of the test director test management process involves the following steps:

1. Examination of the documentation of the software system or application for the determining the testing scope i.e., test goals, strategies, objectives etc.
2. Building of a requirements tree for defining overall testing requirements.
3. Creation of a list of detailed testing requirements for each topic mentioned in the requirements tree.
4. Writing a description for each requirement, assigning a priority level to it and adding attachments if required.
5. Generation of the reports and graphs for providing assistance in the analyzation of the testing requirements.
6. Carrying out a review of the requirements to check if they meet the specifications.

Phase II - Planning the Tests

The second phase involves the following tasks:

1. Examination of the application, testing resources and system requirement for determining the test goals.
2. Division of the application in to modules to be tested and building of a test plan tree to divide the application in to testing units hierarchically.
3. Determination of the type of tests that are required for each module and adding a basic definition of each test to the test plan tree.
4. Linking each test to the corresponding testing requirement.
5. Developing manual tests where each test step describes the test operations and expected outcome. Deciding which tests are to be automated.
6. Creation of the test scripts for the tests that are to be automated using a custom testing tool such as mercury interactive testing tools.
7. Generation of the graphs and reports for the analyzation of the test planning data.
8. Reviewing the tests for determining their suitability to the testing goals.

Phase III - Execution of tests

Third phase involves the following activities:

1. Defining the tests in to groups so as to meet various testing goals of the project. This may involve testing a new version of the application or a specific function in it.
2. Deciding which all tests are to be included in the test set.
3. Scheduling the execution of the tests and assigning tasks to different application testers.
4. Execution of the tests either manually or automatically.
5. Viewing the results of the test runs for determining if a detect was detected in the application under test and generation of the reports and graphs for analyzation of the results.

Phase IV - Tracking the Defects

The last phase of the test management i.e., defect tracking involves the following activities:

1. Submitting new defects detected in the software system or application. Defects can be added during any phase by QA testers, project managers and developers etc.
2. Carrying out a review of the new defects and determining which ones are to be fixed.
3. Correcting the defects that were decided to be fixed.
4. Testing the new build of the software system or application and repeating the whole process until all the defects are fixed.
5. Generation of the graphs and reports to provide assistance in the analyzation of the progress of the defect fixes and determining the date when the application is to be released. 

How do you schedule and run tests in Test Director?

In this article we shall see how the tests can be scheduled and run. 

By configuring the conditions the test director can be instructed to postpone the run of the current test till the completion of some other specified tests is over. For example, the test b is scheduled to be run only after the test a finishes with the execution and there is one more test c which is scheduled to run only if the test b passes.

Also, the tests a and b can be scheduled to be executed a day prior to the execution of the test c. the tests and their conditions are displayed by the execution flow in the form of a diagram. 

Steps to schedule tests in test Director

Follow the below mentioned steps to schedule a test run:

1. Firstly, make sure that the test module is in the view mode and if it is  not then first enable it.
2. Second step involves creation of a new test. Click on the execution flow tab in the test lab module. Choose a folder in the test sets tree and click on the ‘new test set’ option. You will get a ‘new test set’ dialog box. Type in the following details:

a)   Test set name

b)   Description

Once you are done click OK and the test set will be added to the test sets tree in the left pane by the test director.

3. Add a test that you want to add to the test set created in the previous step. Using the ‘select tests’ button  to make the test director display the test plan tree in the right pane. Then, type the name of the test to be searched for in the find box in the test plan tree and click find button. Select the searched test and add it to the test set using the ‘add tests to test set’ button.
4. Any number of tests can be added to the test set. To add the tests to the execution flow either simply drag them in to the execution flow area or double click on them.
5. Add conditions using conditions tab. When you will click on the new button a ‘new execution condition’ dialog box will pop up. Select the required test and then passed option. This will instruct the test director to execute the next test only after the successful execution of the previous test. Click OK once done with this and the condition will be added to the run schedule of by the test director in the test dialog box.
6. You can even add a dependency condition to the tests by clicking on the time dependency tab. You will get a field titled ‘run at specified time’, in that specify the date of execution and click OK. Clicking on OK will close the run schedule. The conditions will be displayed by the test director in the execution flow area.
7. Further, if required, some execution condition can also be added to the tests.
8. For rearranging the tests in a hierarchical way, click on the perform layout option. You can then view the dependencies between the tests clearly.  

How the tests are run in Test Director?

We get two options form the test director namely:

a)   Running tests manually and

b)   Automating the tests.

Follow the steps below for the manual execution of a test:

1. Click on the test lab module to display the test lab module.
2. From the test sets select the required test set.
3. From the execution grid select the required test.
4. Clicking on the run will open up a manual runner dialog box.
5. To begin the test run click on the test run. Parameter values dialog box will open up.
6. Assign the parameter values for the test.
7. Click OK and test director will show up the manual runner. The step details dialog box will open up. Perform the execution process step by step.
8. After running all the steps return to the default manual runner display. End the test run by clicking on the end of run button. 

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.