How does QTP recognize Objects in AUT?

The quick test professional comes with two types of object identification mechanisms unlike winrunner as mentioned below:

1. Usual or the normal object identification mechanism and
2. The smart identification mechanism

What is Usual or Normal Object Identification Mechanism

- In the usual object identification routine, the first step of the quick test professional is to learn the description of the object as provided by the user before the starting of the test. 

- The description of the object provided by the user consists of the properties of the object. 

- All the objects present in the software system or AUT (application under test) are matched one by one with this physical description.

- It is checked that how many properties of the object are matching with the properties mentioned in the description. 

- This method is the easiest  of the two above mentioned object identification routines. 

Now what if this usual object identification mechanism fails to identify the object? 

The alternative here is the second object identification mechanism i.e., the smart identification mechanism. 

Why does a the normal method fails?

- The normal method fails because the value of the object properties starts changing dynamically which makes it difficult for the quick test professional to track the object. 

- Another situation in which the normal identification mechanism can fail is when the quick test professional finds not one but more than one objects in the application under test matching with the properties mentioned in the description. 

- In such a case the quick test professional erases from its memory the learnt description of the object and calls up on the smart identification mechanism for the identification of that particular object. 

Let us see a comparison between the smart identification mechanism and the normal identification mechanism:

1. Smart identification is more complex then the usual one.
2. Smart identification is more flexible then the usual one.

What is Smart Identification Mechanism

- Smart identification mechanism is so reliable that it can work even if the currently provided description of the object fails.

- To get the best out of the smart identification mechanism, one needs to configure it properly in a logical way. 

- Smart identification mechanism is driven by two different sets of properties as described below:

1. Base filter properties: As the name suggests these are the base or the fundamental properties belonging to a particular test object class. The value of these fundamental properties cannot be changed until and unless you make changes in the properties of the original object.
2. Optional filter properties: The leftover properties i.e., all the properties leaving out the base filter properties are grouped under this category i.e., the optional filter properties. These properties unlike the other base filter properties do not change frequently. These properties can some times be ignored i.e., when they do not hold to be applicable and therefore have been named as optional filter properties.

How the smart identification process follows?

- The description given by the user is erased from the memory of the quick test professional and a list of objects called candidate list is created.

- Objects or candidates in this list match at least one property in the property list. 

- Now, the base filter properties are used for cutting down on the list of the object candidates. 

- The list is narrowed down to only one object which has most number of properties matching in the list of properties. 

- Some times it may happen even after reaching this stage the quick test professional may not find a matching object. 

- In such a case the quick test pro makes use of an ordinal identifier in addition with the learnt description. 

Explain the concept of object repository & how QTP recognizes objects?

Just like its Winrunner counterpart, the quick test professional also comes with an object repository which is the first aspect of this article that we are going to discuss in this article and the second aspect to be discussed is regarding the identification of the objects by the quick test professional. 

What is a Object Repository?

- Just like we have a store room and other storage places in our house, the same way the quick test professional consists of a storage place where the information regarding the objects can be stored and this storage place is called the “object repository”. 

- During the process of the identification of the objects, the presence of an interface is necessary between the application under test and test scripts in order for proper identification of the objects. 

- This interface is provided by none other than the object repository itself. 

- An object can be identified as a run time entity with some characteristic properties as well as structure. 

- Few examples of software objects are:

1. Windows
2. Web pages
3. Edit boxes
4. Buttons
5. Check boxes and so on.

What kind of objects QTP recognizes?

Quick test professional recognizes 4 types of objects as mentioned below:

1. Run time objects

These are the objects that are present in the application under test or AUT such as links, check boxes, buttons etc.

2. Test objects

-Run time objects cannot be operated up on directly rather there references are created which are nothing but the test objects such as web button, link, win edit and so on. 

-These test objects are referenced by different names in different environments.

3. Utility Objects

- These are the objects that are reserved by the quick test professional for the purpose of testing as well as test reporting. 

- One such example is the reporter object for displaying the test results.

4. User defined objects (also known as the automation objects)

- In most of the cases objects are required that can perform some specific operations i.e., the user defined operations. 

- Such objects are referred to as the user defined objects.

How QTP recognizes objects?

- For every action that is performed on an object, a local repository is created by the quick test professional automatically while the recording is in progress.

- The local object repository is different from the global object repository in the respect that it cannot be shared among the tests.

- Additional objects can be added to this repository by the user as well as the existing ones can be modified. 

- Global object repository is more commonly known as the shared repository. 

Now let us focus up on the second aspect of the quick test professional i.e., the identification of the objects. 

- Quick test professional has got two major mechanisms for accomplishing this task as stated below:

1. Usual object identification mechanism

- In this mechanism, the learned description of the object i.e., the one provided by user is followed throughout the identification process for identifying the object. 

2. The smart identification mechanism

- This mechanism is smarter than the former one, more flexible but far complex. 

- It comes into play when the first one fails. 

- It rejects the description that was used in the first mechanism and prepares a list of objects that resembles properties defined by the quick test professional. - For the smart identification process to work properly it is required that it should be configured properly. 

What are different control flow defects?

Flow of control is the dynamic aspect of any program. Whenever there is a flow of control in a program, the program is said to be active or responsive. The execution of a software program, system or application depends pretty much on the flow of control and data. Flow of control is needed to maintain data links between the different components of the software system or application.

The control flow makes use of some predefined special codes. These codes are transmitted via a band over the communications channel preferably primary. These codes are of 2 types namely:


1. XON: it stands for “transmit on” and
2. XOFF: it stands for “transmit off”.

Because of these two codes, the flow of control is sometimes referred to as the “XON/ XOFF control flow”.

NOTE : Flow of control in a software system or application is totally different from the flow of control in the hardware system. Like any other process, the flow of control also experiences some defects.

MECHANISM OF CONTROL FLOW
In order to understand these defects it is necessary that you understand the mechanism of this process.
- One of the ends of the data link sends the code XON to the other end if this end is ready to intake data.
- If this end is not able to receive data it sends off the XOFF code to the other end.
- The other on getting this code immediately stops the data transmission and resumes once again when the other end is ready to accept the data and sends a XON code.

DIFFERENT CONTROL FLOW DEFECTS
- The ends of the data links sometimes become unresponsive to the intake or transmission of data.
- These kinds of problems are an indication of the defects in data linkage.

To make you understand the control flow defects let us see a detailed example:

- Say you connect your computer to printer whose performance speed is relatively slow when compared to the speed of the computer.
- When you want to take out a print, the computer starts by sending the data to be printed to the printer.
- Since the speed of the printer is slower than the computer, it lags behind i.e., it is unable to handle the incoming volume of data from the computer.

- Ultimately it reaches a stage where it memory is overflowing with the data.
- Now what the printer will do in such a situation? It sends a XOFF code to the computer to stop this data transmission.
- It again sends a XON code to the computer once it has received the whole previously transmitted data and is ready to receive the data again.
- XON and XOFF have a specialty that they can be used by the data links in both the directions.
- In some cases it happens that the data links are not able to employ these codes from either direction.
- This is again a defect in the control flow.
- The flow control is usually used for devices having old technology i.e., the devices which are not compatible with the modern software.
- The devices are unable to accept any more incoming data because their output rate is limited.

REMOVAL OF DEFECTS
- Removal of defects in the flow of control is very necessary.
- It is important since the flow of control is very crucial for the well execution of the software system or application.
- Tests should be undertaken to identify these defects.
- Once the defects have been identified, they should be assigned priority on the basis of the severity they can cause.
- The defects should be validated and resolves as soon as possible.

What are the different fault injection methods?

In the context of software engineering, fault injection is a technique or methodology meant for improving the test coverage. This is usually done by introducing faults in the program source code in order to test the code paths. In particular it is done to test the error handling test paths that might otherwise be left un- followed and thus, untested. Fault injection technique is often used in combination with the stress testing.

Fault injection technique is considered to be one of the most important parts of developing robust software. To add to your knowledge, robustness testing or syntax testing or fuzz testing is also a kind of fault injection methodology which is commonly used to detect the potential vulnerabilities of the communication interfaces such as application programming interfaces, command line parameters and protocols.

The injected fault goes through a well defined cycle before it becomes an observable failure. After the fault is injected, the program or the application is executed. Upon execution, the injected fault may cause an error which is to be considered as an invalid state within the boundaries of the system. This error may cause many further errors within the boundaries of the system. In this way each error acts as an injected fault and propagates to the system boundaries and comes to observance. When the states of the errors are observed at the boundaries of the system they are known as failures. This whole mechanism is known as “fault – error – failure – cycle”.

This mechanism forms a key mechanism in the context of dependability. In 19s the fault injection technique was used to introduce faults at the level of hardware system. This type of fault injection method is known as HWIFI or hardware implemented fault injection. It tends to simulate failures within a hardware system. Soon after that it was found that faults could also be introduced in the software system and it could be helpful in accessing the software system more appropriately.

These fault injection techniques are collectively known as SWIFI or software implemented fault injection. Techniques for software implemented fault injection can be classified into two major categories namely:

Compile time injection:
This can be defined as an injection technique in which the source code is modified so that the simulated faults can be injected into the system. One popular method for doing this is “mutation testing” in which the existing code is changed so as to induce faults. The other technique is “code mutation” in which the faults produced are very similar to those added unintentionally by the programmers. Another technique which is modification of code mutation technique known as code insertion fault injection adds code rather than modifying the existing piece of code. This is done with the use of simple functions which take an existing value and perturb it using some logic into another value. Such functions are called perturbation functions.

Run time injection:
This technique can be defined as the technique which makes use of a software trigger to inject fault in the system which is executing. Using this technique faults can be injected in a variety of ways such as those listed below:

- Time based triggers
An interrupt is generated when the timer reaches a specified time. The interrupt handler associated with the timer will inject the fault.

- Interrupt based triggers
Software trap mechanisms and hardware exceptions are effectively used to generate a fault in the code of the system at a particular point. This gives instant access to a specific memory location.

- Corruption of memory space
- Syscall interposition techniques
- Network level fault injection

What do you understand by gray box testing?

Grey box testing or gray box testing can be defined as a combination of both white box testing as well as black box testing. Therefore, we can say grey box testing requires the full knowledge of algorithms and internal structure of the software system for the designing and production of test cases at the level of white box testing but, testing the software system at the level of black box testing.

It is not necessary for the person who is testing the software system to have full knowledge about the internal structure, source code and algorithms of the program.

Grey box testing according to one misconception is not only about modifying the input data values and modifying output information values because the system has to be tested as per the conditions of black box testing.

One needs to understand this when integrating two modules of the software system which have been written by two different programmers and whose thinking differ a lot. The two programmers only know about the interfaces of the both modules under test.

In contrast to this, the modification of a data repository is well considered as grey box testing because in this case only the internal data is modified and the external data remains unaffected. Apart from integration testing, grey box testing also includes reverse engineering.It is required to determine error messages and the boundary values for data.

Grey box testing includes the benefits from both sides i.e., it has the advantages of both white box testing and black box testing. This may seem confusing but it can be clarified with the following example. A person who knows the concepts of software mechanism and its internal structures as well as he/ she knows how the system should work and can determine the output, will design better test cases while externally testing the software system. However, a person with only the knowledge of black box testing won’t be able to make better test cases as compared to the former.

Despite all the added advantages, grey box testing is limited to intelligent test cases and the testing is to be performed with limited information, exception and data type handling etc. grey box testing is implemented to find flaws in the design and implementation of the software system.

The developer who uses grey box testing is well versed with the knowledge of system design and system implementation and designs test cases based on that knowledge itself.

The test strategy in grey box testing is based on the limited knowledge of internal structure of the software system. The best examples of this can be architectural model, UML design model and state model.

Grey box testing techniques are the best techniques for applications related to internet and web. It is ideal for modules that are connected through well defined user interfaces or which are loosely integrated. A major part of grey box testing is under white box testing and only a minor part follows the black box testing.

During grey box testing, initially the tester implements a limited number of test cases to test the internal structure of that particular software system. Later the tester follows black box testing techniques and feeds inputs to the test cases and checks whether the output is obtained as expected or not. In this kind of testing, inspection of internal structure is fully allowed but, the extent of modification is limited.

In addition to all the benefits of grey box testing, this testing methodology is a great time saver. It’s very useful especially when you have a shortage of time to test the software system.

How a task network is defined for a software engineering project?

The task network is a useful mechanism for depicting inter task dependencies and determining the critical path. When more people are working on a software engineering project, tasks and sub-tasks have their own inter-dependencies and also as the number of people increases, the development activities and tasks are performed in parallel. These concurrent tasks must be coordinated so that so that they will be complete when later tasks require their work products.

What is a task network?
It is also known as activity network. It is a graphic representation of how the tasks are flowing in a software engineering project. There is a pattern and a sequence that is followed by tasks. This task network can be used as a mechanism or a way to know this sequence and pattern of the tasks that can act as an input to an automated project scheduling tool.

On a macroscopic view, task network depicts the software engineering tasks. On a microscopic view, each and every task in the task network is expanded. For a concept development project, task network includes the following tasks:
- Concept Scoping
- Concept Planning
- Technology and Risk Assessment (It constitutes three tasks).
- Proof of Concept
- Concept Implementation (It constitutes three tasks).
- Integrate the three tasks which constitutes concept implementation.
- Customer Reaction

Software engineering activities are concurrent in nature. This nature leads to scheduling requirements. The project manager should keep in mind the following points to ensure continuous progress:
- He should determine the inter-task dependencies.
- He should be aware of tasks that lie on critical path which means the tasks that should be completed on schedule if project has to completed on schedule.

User Interface Analysis and Design - Testing Interface Mechanisms

There are interface mechanisms through which the interaction between the user and the web application occurs. There are some testing interface mechanisms described below:
- Links are tested to ensure that proper content object or function is reached. External link testing should occur throughout the life of the web application. Links within content object are also tested. Part of a support strategy should be regularly scheduled link tests.

- Client side scripting should be repeated whenever a new version of a popular browser is released. Compatibility testing should be done to ensure that the scripting language that is chosen is working properly in environmental configuration that support the web application.

- Forms testing is done at two levels:
At macroscopic level, tests ensure that labels correctly identify fields within the form; server is receiving the information that is contained within the form; defaults are used when user is not selecting from pull down menu or set of buttons; browser functions do not corrupt data and error checking script is working properly.
At targeted level, tests ensure that form fields are of proper width and data types; appropriate pull-down menus option are specified; tab key is performing in the right manner and browser auto fill features do not lead to data input errors.

- Dynamic HTML in web applications are tested to ensure that the dynamic display is working fine.

- Pop up windows are tested to ensure that a pop up window is properly positioned and sized; the design of pop up window is consistent with the aesthetic design of interface; scroll bars are working properly.

- Streaming Content is tested to ensure that they are up to date, properly displayed and restarted without difficulty.

- Cookies are tested at both server and client side. On server side, tests are conducted to ensure cookie is properly constructed and transmitted to client side. Proper persistence of cookie is tested to ensure that the expiration date is correct. On client side, tests are conducted to ensure whether web applications properly attaches existing cookies to specific request.

WebApp Interface Design - Interface Control Mechanisms and Interface Design Workflow

INTERFACE CONTROL MECHANISM
The objectives of Web application interface are:
- establishing a consistent window into content and functionality provided by interface.
- guiding the users through interactions with web application.
- organizing the content and navigation options.

A metaphor is drawn that guides the user interaction and enables the user to gain understanding of the interface. Some interaction mechanisms available to web application designers are
- navigation menus that list key content and or functionality.
- graphic icons that enable user to select some property or specify a design.
- graphic images that implements a link to content object or the functionality of web application.

INTERFACE DESIGN WORKFLOW
It includes the following tasks:
- The information contained in analysis model is reviewed and refined.
- A rough sketch of web application interface layout is developed.
- The user objectives are mapped to specific interface actions.
- Set of user tasks associated with each action are defined.
- For each interface action, storyboard screen images are developed.
- Input from aesthetic design can be used to refine interface layout.
- User interface objects required to implement interface are identified.
- A procedural representation of user's interaction is developed.
- A behavioral representation is developed.
- Interface layout is described.
- Interface design model is refined and reviewed.

Introduction to Pattern-based design in software design?

Pattern based design is a technique that reuses the design elements. Each architectural pattern, design pattern, or idiom is cataloged, thoroughly documented and carefully considered as it is assessed for inclusion in a specific application.

A description of design pattern may consider a set of design forces. Design forces are those characteristics of the problem and attributes of the solution that constrain the way in which the design is developed. These design forces also describe the environment and conditions that must exist to make design pattern applicable.

Types of design patterns available are:
- Architectural patterns
The overall structure of software, relationship among subsystems and software components and rules are defined for relationship among elements of architecture.
- Design patterns
It addresses a specific element of design to solve some design problem, relationships among components or mechanisms for good communication among components.
- Idioms
These are language specific patterns. They implement the algorithmic element of a component. They can act as a specific interface protocol or a mechanism for communication among components.

What are different testing mechanisms used to test the sofware?

After deciding the inputs and outputs for the test cases, another issue that comes into picture is writing the code that actually tests the software. Following mechanisms can be used to write codes:

- TEST DRIVERS
The lower level modules can be tested by using a test driver program. Approach that is used is to write a program that passes input data to the unit under test and comparing the output to truth. Input is selected from uniform testing, Monte Carlo testing, selected input conditions or from manufactured data. Output is compared against trusted results using an inverse function or a file containing correct data.

- WHITE BOX TESTING
Test drivers can also be used to test several modules at once to save time if you are doing white box testing. White box testing taken advantage of the internal working of the module under test. This approach saves time but disadvantages include while testing several things together, you may get a right answer indicating that everything is right but if you do not get the right answer then you are not sure what went wrong.

- BLACK BOX TESTING
This testing does not depend on the internal working of the module unde test. It only depends on the inputs and outputs of the system.

- TEST STUBS
Test Drivers are high level routines that call lower level subprograms, test stubs can be used to test higher levels of program. Stub is a simple routine that takes the place of real routine. It may be a null procedure or it may have a simple message. There is no need for test stubs to be limited to fixed data or user supplied data. Stubs need not be just input stimulators. Stubs also display or record data sent to them.

- TEST AND DEMO PROGRAMS
A test program usually does not involve much operator intervention. A demo program is a quick confidence check.

What are different activities that comprise Software Quality Assurance?

To build a quality software, software quality assurance comprise of different activities. People involved are development team and software quality assurance team. The team of software quality assurance is responsible for quality assurance planning, overseeing, analyzing, record keeping, defects analysis and rework.

The activities encompassing software quality assurance are:
- Software Quality Assurance Plan is prepared by SQA team. They identify the evaluation to be performed, audits and reviews to be performed, standards that are applicable, procedures for error reporting and tracking, documents to be produced and amount of feedback required.
- SQA team checks if the selected software development process conform to the organizational policy and quality standards.
- SQA team monitor and track deviations from the software development process. It reviews software engineering activities.
- SQA team reviews, monitor and track defects found with each work products. Documentations are done to ensure that corrections have been made.
- The SQA team ensures that deviations in the software activities and work products are handled based on defined standard operating procedures.
- The SQA team reports deviations and non-compliance to standards to the senior management or stakeholders.

Software quality assurance plans saves time, money, increases productivity, enhances training, provides extra support.

What is Software Quality Assurance (SQA)? What are characteristics of a well-engineered software?

Software Quality Assurance(SQA) is a function of software quality that assures that the standards, processes, and procedures are appropriate for the project and are correctly implemented.
- It is a subset of software engineering that ensures that all deliverables and work products are meet, and they comply with user requirements and standards.
- Its goal is to detect defects before the software isdelivered as a final product to the end-users.
- It includes quality management approach.
- It includes effective methods and tools.
- It includes formal technical reviews.
- It includes a multi-tiered testing strategy.
- It includes control of software documentation.
- It includes a procedure to assure compliance with software development standards, and measuring and reporting mechanism.

How do we say that the software is well-engineered?

- A software should be easy to use by the user.
- A software should have the capability to be able to execute on different platforms.
- A software should be able to transfer from one system to another.
- A software should be able to evolve and adapt to changes over time.
- A software should be reliable, secure and safe.
- A software should be capable of using resources efficiently.

A software has quality if it is fit for use, i.e., it is working properly. It should conform to explicitly stated user's external characteristics, explicitly documented quality standards and implicit characteristics.

User Interface Testing - Interface testing strategy

The user interface model is reviewed to ensure that it conforms to customer requirements and to other elements of analysis model. During testing, focus is shifted towards application specific aspects of user interaction as they are manifested by interface syntax and semantics.

The goal of interface testing is to:
- uncover errors related to specific interface mechanism.
- uncover errors in the way interface implements semantics of navigation, web application functionality or content display.

Objectives that should be achieved are:
- Interface features are tested to ensure that design rules, aesthetics, and related visual content are available for user without error.
- Individual interface mechanisms are tested in a manner that is analogous to unit testing.
- Each interface mechanism is tested within the context of a use case or navigation semantic units for a specific user category.
- The complete interface is tested against selected use cases and navigation semantic units to uncover errors in the semantics of the interface.
- The interface is tested within a variety of environments to ensure that it will be compatible.

Usability testing evaluates the degree to which users can interact effectively with the web application and the degree to which the web application guides user actions, provides meaningful feedback, and enforces a consistent interaction approach. Usability tests are designed by a web engineering team, but the tests themselves are conducted by end users.

Steps to be followed are :
- define a set of usability testing categories and identify goals for each.
- design tests that will enable each goal to be evaluated.