What are different Recording Modes in QTP?

There are three basic Recording modes in QTP:

1) Normal recording in QTP:

It is used for recording the operations perform at different contacts on the standard GUI objects. During this all actions are recorded with Objects details in Object repository. It will generate the corresponding test script statement for every user action. It will also store the required related information in the object repository.

QTP records in Normal mode by default and takes full advantage of QTP Object Model , recognizing application objects regardless of their location on screen.

2) Analog Recording in QTP

           It is used for recording the continuous operations. This is useful for the cases where we need to record exact mouse or Keyboard operation in relation to Screen or application. This is useful when Normal reocrding does ot work for you. E.g.- It will be helpful where we want to record mouse drag operation.

3) Low-level Recording in QTP

           It is special recording mode provided by QTP, which is used for recording the minimum operations   on  the Non-Supported environments also.





This mode records at object level and records all run-time objects as windows or winobject test objects. You can also use this recording mode in case exact coordinates are important for your testing.

What is the basic difference between Structural and Functional Testing?

Different people use different Software terminologies as per their convenience  and here are two more which are used in Software Industry, specifically among Quality Prfessionals.

Structural testing is about comparing software behavior against the apparent intention of the source code wirtten to execute it. Many testers call it White-Box Testing or Glass-Box Testing :) Structural testing is also called path testing since you choose test cases that cause paths to be taken through the structure of the program.


Other the other side, functional testing is about comparing workflows behavior in the application against user requirements specification. This is also called as Black-Box Testing.

Structural testing verifies how the program works by considering possible pitfalls in the structure and logic. In Functional testing, nobody is bothered about the internals. It simply focuses on the end results and way they are delivered to users.

What is Code Coverage and how does it impact Software Quality?

I would like to take second question first: Code coverage is considered as an extended step towards ensuring good quality of the software by indirect means. Why I explained it in this way?

In my opinion Code coverage is more about assuring quality of test-cases and finding redundant code, not about quality of actual product we are developing. Realistically its very difficult to do Code coverage exceises with actual testing. So normally teams Quality Engineers try to find out the cases they need to add and test-cases which does not help in improving the coverage.

You may not agree, as its my personal opinion.

Now lets come to first question about what it is?

Code Coverage is methodology to:

1.  Find different program areas not excercised by Testers through pre-identified set of Test cases.
2. Add new test cases to increase coverage in terms of Functional/Statement/Decision/Conditional-coverages
3.  Identify overall gap between the actual coverage and targetted coverage. Its more about statistics which helps a Quality engineering team to know about the other quality measures of a Software.
4. To identify redundant test-cases which have 0% contribution in coverage increase.

Most of the times last point is not considered but we should not forget that its also a wastage of resources/time when we run redundant test-cases which adds no value.

What is winDBG???

WinDbg is a multipurpose debugger for Microsoft Windows, distributed on the web by Microsoft. It can be used to debug user mode applications, drivers, and the operating system itself in kernel mode. It is a GUI application, but has little in common with the more well-known, but less powerful, Visual Studio Debugger.

WinDbg can be used for debugging kernel-mode memory dumps, created after what is commonly called the Blue Screen of Death which occurs when a bug check is issued. It can also be used to debug user-mode crash dumps. This is known as Post-mortem debugging.

WinDbg also has the ability to automatically load debugging symbol files (e.g., PDB files) from a server by matching various criteria (e.g., timestamp, CRC, single or multiprocessor version). This is a very helpful and time saving alternative to creating a symbol tree for a debugging target environment. If a private symbol server is configured, the symbols can be correlated with the source code for the binary. This eases the burden of debugging problems that have various versions of binaries installed on the debugging target by eliminating the need for finding and installing specific symbols version on the debug host. Microsoft has a public symbol server that has most of the public symbols for Windows 2000 and later versions of Windows (including service packs).

Recent versions of WinDbg have been distributed as part of the free Debugging Tools for Windows suite, which shares a common debugging engine between WinDbg. This means that most commands will work in all alternative versions without modification, allowing users to use the style of interface with which they are most comfortable.

What is BoudsChecker : Memory Leak Testing Tool

BoundsChecker is a memory checking tool used for C++ software development with Microsoft Visual C++. It is part of the DevPartner for Visual C++ BoundsChecker Suite. Comparable tools are Purify, Insure++ and Valgrind.

BoundsChecker can be run in two modes: ActiveCheck, which does not instrument the application, and FinalCheck, which does.

ActiveCheck performs a less intrusive analysis and monitors all calls by the application to the C Runtime Library, Windows API and calls to COM objects. By monitoring memory allocations and releases, it can detect memory leaks and overruns. Monitoring API and COM calls enables ActiveCheck to check parameters, returns and exceptions and report exceptions when they occur. Thread deadlocks can also be detected by monitoring of the synchronization objects and calls giving actual and potential deadlock detection.

FinalCheck requires an instrumented build and gives a much deeper but more intrusive analysis. It provides all of the detection features of ActiveCheck plus the ability to detect buffer overflows (read and write) and uninitialized memory accesses. It monitors every scope change, pointer and memory usage.