What is Polling?

- Polling is often referred to as the polled operation.

- When the statuses of the external devices are actively sampled by a client program just like a synchronous activity is referred to as the polling. 

- The common use of the polling is in the input and output operations. 

- In rare cases, polling is also called as the software driven I/O or just simply as polled I/O. 

- As and when required, polling is also carried out with the busy waiting synonymous. 

- Polling is then referred to as the busy–wait polling. 

- In this case whenever it is required to carry out an input/ output operation, the system just checks the status of the device required for fulfilling this operation until it is idle. 

- When it becomes idle it is accessed by the I/O operation. 

- Such polling may also refer to a state in which the status of the device is checked again and again for accessing it if idle. 

- If the device is occupied, the system is forced to return to some other pending task. 

- In this case the CPU time is wasted less when compared to what happens in busy waiting. 

- However, this is not a better alternative to interrupt driven I/O polling. 

- In single purpose systems that are too simple, using busy-wait polling is perfectly fine if the system cannot take any action until the I/O device has been accessed. 

- But traditionally, the polling was thought to be a consequence of the operating systems and simple hardware that do not support multitasking. 

- The polling works intimately with the low level hardware usually. 

- For example, a parallel printer port can be polled for checking whether or not it is ready for printing another character. 

- This involves just the examination of a bit. 

- The bit to be examined represents the high or low voltage stage of the single wire in the cable of the printer during the time of reading. 

- The I/O instruction by which this byte is read is also responsible for transferring the voltage state directly to the eight flip flops or circuits. 

- These 8 flip flops together constitute one byte of a register of CPU. 

Polling also has a number of disadvantages. 

- One is that there is limited time for servicing the I/O devices. 

- Polling has to be done within this time period only. 

- But in some cases there are many devices to be checked which cause the polling time to exceed the given limit. 

- The host keeps on hitting the busy bit until the device becomes idle or clear. 

- When the device is idle, the state is written in to the command register and also in the data out register. 

- The command ready bit is set to 1. 

- The controller sets the busy bit once it knows that the command ready bit has been set.  

- After reading from the command register, the controller carries out the required I/O operation on the device. 

- On the other hand, if the read bit has been set to one, the controller loads the device data in to the data in register. 

- This data is further read by the host. 

- Once the whole action has been completed, the command ready bit is cleared by the controller. 

- The error bit is also cleared for showing that the operation has been completed successfully. 

- At the end the busy bit is also set.

- Polling can be seen in the terms of master slave scenario where the master sends inquiring about the working status slave devices i.e., whether they are clear or engaged. 

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. 

What are some common tools for installation testing?

Introducing a new student to the rest of the class gives us a practical example of the installation testing. The new student should be properly introduced to the rest of the class so that he/ she feel comfortable. Same holds true for software systems and applications. The effectiveness of any testing however also depends up on the type of the testing tools used. In this article we shall be discussing about some common tools for installation testing. 

If the installation of your software product fails, what impression it will make of you on the customer? Obviously it will cost you your reputation. How can you avoid such pathetic and embarrassing conditions? "Answer is by testing the software system’s or application’s installer with an appropriate combination of both the automated and manual processes on different machines and with different configurations". 

The factor of which you should be most concerned is nothing but “time” since installation testing eats up a lot of time, so you got to be wise and use testing tools that can save up your time. Execution of even a single test case takes a lot of time in installation testing. Now imagine if you are going to perform installation testing on a big software system or application? How much it is going to cost you? Before you start installation testing you need to decide on how many systems and configurations you are going to install the application software. Prepare a basic hard disk drive for this purpose with some other basic necessary components.

Role of Installation Testing Tools

- There are testing tools available that will help you in making sets of each of the configurations like file format and operating system that are used in the further installation testing.

- There are many other tools that can be used to automate the whole installation testing process.

- This involves setting out some systems for creating basic images of the base configuration. This can be done by using testing tools like Norton ghost which can create exact image of the operating systems very accurately and quickly.

- This step is guaranteed to save a huge amount of your time for each test case.

- Creating images takes only 5- 10 minutes whereas installing one Operating System with basic configuration takes up to one hour.

- There are some other tools that allow you to use one operating system with multiple attempts of installation.

- But in this case you will need to uninstall the application again and again and prepare the base state for the next installation.

- Apart from all the other testing tools, use flow diagrams also serve as a great aid for performing the installation testing.

- Use flow diagrams simplify the whole task so amicably.

- These flow diagrams can be further used for automating the test efforts since very easily these diagrams can be converted in to the automated scripts.

- Some test tools have been developed that test the installer scripts which are further used to check the disk space required for the installation.

- These tools make sure that only the required amount of space is utilized and not more than that otherwise an error is flagged. You should be careful with the fact that the space required is different for different file system formats.

- Another tool that can help you a big deal with installation testing is “distributed testing environment”.

- Adopting this methodology you can very effectively handle all the different test cases from just one machine and it saves you a lot of time.  

What are different characteristics of stability testing?

Stability testing in the context of software testing and engineering as it itself
indicates, refers to the many attempts to determine if an application will crash.

- Stability testing seeks to find a fault, an error, a bug or a reason that can render the software system or the application as non working or which can make the application lame.
- The main objective of the stability testing is to determine if there are any grounds on the basis of which the software system or application should be kept void of certification and it also aims at finding some positive point on the basis of which the software system or the application can be granted the certification.

- For a software system or application to be certified, it should be in functional state and basically stable.
- This can only be done by applying specific and suitable criteria and tests for testing functionality and stability. This is nothing but the stability testing.

There are several criteria available for stability testing. Few have been discussed below in detail:

1. Pass or fail criteria
- Each primary function tested and then the results are recorded.
- Each and every individual function is operated or executed in a way that is apparently consistent with its objective or the purpose regardless of the degree of correctness of its result or output.
- The observations are recorded for analysis.
- It is certain that out of so many functions, at least one or two primary functions will prove incapable of operating in a way that it apparently consistent to their aim or purpose.

2. Functional ability of a software system or the application
- There is for sure some impairment in any software system.
- But that does not necessarily mean that the software system is not fit for normal use.
- Any software product or application is said to work abnormally in a way that it seriously impairs it for the normal usage.

3.Disruption criteria
- The software system or the application is observed to disrupt the normal functioning of the operating system.

4.Criteria of in-operability
- No primary function of the software system or application is observed to get obstructed and become inoperable and non functional during the course of the testing.
- There is at least one primary function of the software system or application is observed to get obstructed and become inoperable and non functional during the course of the testing.

5. The software system or the application is observed to crash, fail, loose data and hang.

Some Important Points:
- Stability can be defined as the ability of a software system or application to continue functioning in the case of over time and over its full range of functionalities without crashing, failing or hanging and loss of data.

- For a tester to know whether the software system is seriously unfit for normal and regular use, he /she is required to have a knowledge of how that software system or application works in a normal environment i.e., normal user and normal usage.

- In order to carry out the stability test, the tester requires knowing the types of data values which software system or application can effectively and efficiently process.

- To test for the instability of a software system, the tester needs to use his knowledge in order to give some challenging inputs to the system to fail the system.

What is meant by Use-case oriented metrics?

Using the use case method is not dependent on the programming language. Typically, you can use use cases as another method of generating the size of the application; the value of use cases is in most cases to the lines of code (LOC) and also to the number of test cases that will have to be written for comprehensive testing of the application. Like many other estimation techniques, the use case method is used early in the software life cycle, before design, development and testing happens.

A use case is written to capture user interactions and functions that describe a system. Many users try to work out what a standard size for a use case is, but use cases can exist at different levels of abstraction. As a result, though there are many attempts to use the use case method as a instrument of trying to measure the effort required for building the application, the inability to define a size and coverage of the use case, means that not many people have been successfully able to do this.

Estimation through use case method is not a simple one; there are multiple steps required such as determining technical factors, determining environmental factors, determining use case points, determining product factors, and then overall, putting all these factors together to get use case points which translate into man-days or man-weeks.

Flow Oriented Modeling - Creating a Data Flow Model

Flow models focus on the flow of data objects as they are transformed by processing functions. Derived from structured analysis,flow models use the data flow diagram, a modeling notation that depicts how input is transformed into output as data objects move through the system. Each software function that transforms data is described by a process specification or narrative. In addition to data flow, this modeling element also depicts control flow.

Data flow oriented modeling is the most widely used analysis notation. Flow oriented modeling focuses on structured analysis and design, follows a top to down methodology and uses a graphical technique depicting information flows and the transformations that are applied as data moves from input to output.

The modeling tools that are used to build a data flow oriented model include context diagrams, data flow diagrams, entity relationship diagram, control flow diagram, state transition diagram, data dictionary, process specification and control specification.

Steps to create a data flow model
- Diagram 0: develop a context diagram.
- Decompose the Process into high level processes.
- In parallel to this, develop data flow diagrams, entity relationship diagrams and state transition diagrams.
- Define data stores which includes normalization.
- Develop data dictionary.
- Finalize data flow diagrams, entity relationship diagram and state transition diagrams.
- Develop process specifications which includes PDL, decision tables or trees.
- Perform transformational analysis which includes developing structure charts.
Information flow continuity must be maintained as each data flow diagram level is refined. This means that input and output at one level must be the same as input and output at a refined level.

Component Level Design - Designing Class based Components - Cohesion

Cohesion in context with component level design refers that a component or class encapsulates only attributes and operations that are closely related to each other and to the class or component itself.

TYPES OF COHESION

Functional
It is exhibited mainly by operations. This type of cohesion occurs when a module performs one and only one computation and then returns a result.
Layer
It is exhibited by packages, components, and classes. This type of cohesion occurs when a higher layer accesses the services of a lower layer, but lower layers do not access higher layers.
Temporal
Operations that are performed to reflect a specific behavior or state.
Procedural
Components and operations are grouped together. It allows one to be invoked immediately after preceding one was invoked. It is done even if there is no data is passed between them.
Communicational
Operation on same data are defined in one class. Classes and components that exhibit functional, layer, and communicational cohesion are easy to implement, test and maintain.
Sequential
Components and operations are grouped in such a manner that the first one provides input to the second one and so on.
Utility
Components, classes, or operations exist in the same category but are otherwise unrelated are grouped together. This type is less used.

What are Test Case Documents and how to design good test cases?

Designing good test cases is a complex art. The complexity comes from three sources:
- Test cases help us discover information. Different types of tests are more effective for different classes of information.
- Test cases can be good in a variety of ways. No test case will be good in all of them.
- People tend to create test cases according to certain testing styles, such as domain testing or risk based testing. Good domain tests are different from good risk based tests.
A test case specifies the pretest state of the IUT and its environment, the test inputs or conditions, and the expected result. The expected result specifies what the IUT should produce from the test inputs. The specification includes messages generated by the IUT, exceptions, returned values, and resultant state of the IUT and its environment. Test cases may also specify initial and resulting conditions for other objects that constitute the IUT and its environment.

A scenario is a hypothetical story, used to help a person think through a complex problem or system.

Characteristics of Good Scenarios

A scenario test has five key characteristics:
a story that is motivating, credible, complex and easy to evaluate.The primary objective of test case design is to derive a set of tests that have the highest attitude of discovering defects in the software. Test cases are designed based on the analysis of requirements. use cases, and technical specifications, and they should be developed in parallel with the software development effort.

A test case describes a set of actions to be performed and the results that are expected. A test case should target specific functionality or aim to exercise a valid path through a use case. This should include invalid user actions and illegal inputs that are not necessarily listed in the use case. A test case is described depends on several factors, e.g. the number of test cases, the frequency with which they change, the level of automation employed, the skill of the testers, the selected testing methodology, staff turnover, and risk.

Overview Of Process

A process is an activity which takes place over time and which has a precise aim regarding the result to be achieved. The concept of a process is hierarchical which means that a process may consist of a partially ordered set of sub-processes. A process is rather abstract. It describes the essentials of the purpose, structure, rationale, roles and timing, leaving plenty of implementation freedom. The power of a process is its abstraction, which enables its application in a wide range of applications, by tailoring its implementation to the specific application. A process can be tailored and elaborated in one or more procedures, which describe cookbook-like what need to be done when and by whom.
The process has been given many definitions for instance :
* A program in Execution.
* An asynchronous activity.
* The 'animated sprit' of a procedure in execution.
* The entity to which processors are assigned.
* The 'dispatchable' unit.
In Process model, all software on the computer is organized into a number of sequential processes. A process includes PC, registers, and variables. Conceptually, each process has its own virtual CPU. In reality, the CPU switches back and forth among processes.
A process goes through a series of discrete process states :
* New State: The process being created.
* Running State: A process is said to be running if it has the CPU, that is, process actually using the CPU at that particular instant.
* Blocked (or waiting) State: A process is said to be blocked if it is waiting for some event to happen such that as an I/O completion before it can proceed. Note that a process is unable to run until some external event happens.
* Ready State: A process is said to be ready if it use a CPU if one were available. A ready state process is runable but temporarily stopped running to let another process run.
* Terminated state: The process has finished execution.

A process in an operating system is represented by a data structure known as a process control block (PCB) or process descriptor. The PCB contains important information about the specific process including :
* The current state of the process i.e., whether it is ready, running, waiting, or whatever.
* Unique identification of the process in order to track "which is which" information. * A pointer to parent process.
* Similarly, a pointer to child process (if it exists).
* The priority of process (a part of CPU scheduling information).
* Pointers to locate memory of processes.
* A register save area.
* The processor it is running on.