Understanding Software Defects

• User interface errors – the system provides something that is different from Interface.
• Error handling – the way the errors are recognized and treated may be in error .
• Boundary-related errors – the treatment of values at the edges of their ranges may be incorrect .
• Calculation errors – arithmetic and logic calculations may be incorrect .
• Initial and later states – the function fails the first time it is used but not later, or Vice-versa .
• Control flow errors – the choice of what is done next is not appropriate for the current state .
• Errors in handling or interpreting data – passing and converting data between systems (and even separate components of the system) may introduce errors.
• Race conditions – when two events could be processed, one is always accepted prior to the other and things work fine, however eventually the other event may be processed first and unexpected or incorrect results are produced.
• Load conditions – as the system is pushed to maximum limits problems start to occur, e.g. arrays overflow, disks full .
• Hardware – interfacing with devices may not operate correctly under certain conditions, e.g. device unavailable .
• Source and version control - out-of-date programs may be used where correct revisions are available.
• Documentation – the user does not observe operation described in manuals .
• Testing errors – the tester makes mistakes during testing and thinks the system is behaving incorrectly.

Web Testing Challanges

Understanding the Web test process is essential for deciding how to proceed with the selection of a Web test process, automated test tools, and methodologies.

Following are several challenges that need to be considered when deciding on the Web process that is most applicable for your business:

The Web is in a state of constant change. The developer and tester need to understand how changes will affect their development and the Web sitetest process. As technology changes, testers will need to understand how this will affect them and how they will handle their testing responsibilities

When setting up the test scenarios, the tester needs to understand how to implement different scenarios that will meet different types of business requirements. For example, is a tester testing a site with graphic user interface (GUI) buttons and text boxes or testing HyperText MarkupLanguage (HTML) code? Simulating response time by pressing buttons and inputting different values will verify if correct calculations are valid.

The test environment can be a difficult part of the setup for the tester.

You need to be aware of all of the different components that make up the environment; the networking piece can be especially difficult to simulate.

The following several considerations need to be addressed

Multiple server tiers

Firewalls

Databases

Database servers

In the test environment, it is important to know how the different components will interact with each other.

When setting up the Web testing environment, special consideration should be given to how credit card transactions are handled, carried out, and verified. Because testers are responsible for setting up the test scenarios, they will need to be able to simulate the quantity of transactions that are going to be processed on the Web site.

Security is a constant concern for business on the Internet as well as for developers and testers. There are hackers who enjoy breaking the secuiry on a Web site.

Web-based applications Present New Challanges ,Both For Developers and Testers .These challanges include .

1. Short Release Cycle
2. Constant Changing Technology
3. Possible Huge Number Of Users during Initial Website Launch.
4. Inability To control The Users Running Environment.
5. Twenty Four -24 Hour avilability of web site.

web test plan

Understanding Skills

The first and foremost activity of Software Testing is to understand the requirements/ functionalities of the software to be tested. Formal Documents like Software Requirement Specifications, Software Functional Specifications, Use Case Specifications and other Documents like Minutes of Meeting serves as the key references for planning and executing the testing tasks. The testers must have very good understanding skills to read and understand the information written in these documents. Many a times, it is possible to have many interpretations for the information presented in the documents. The testers must be able to identify the duplicate & ambiguous requirements. If the requirements are not clear or ambiguous, the testers must identify the sources of the requirements and get them clarified. The sources of the requirements in most of the project development team should be Business Analysts, Business Users or any other competent authority as identified by the Project Management team. The testers shall analyze and co-relate the information gathered within the perspective of the project.

Listening Skills

Documents are not the only source of reference for the testing activities. The information required for the testing activities may be acquired through offline meetings, seminars, conferences, etc. The minutes of the meetings, conferences, seminars may or may not be recorded in a formal document. The testers must have very good active listening skills in order to collate and co-relate all of that information and refer them for the testing activities. While the requirements or functionalities of the software are discussed over a meeting, many a times, some part of the requirements are missed out. The testers should be able to identify and get them clarified before heading towards the subsequent testing phases.

Test Planning Skills

All software requirements shall be testable. The software shall be designed in such a way that all software requirements shall be testable. The test plan shall be formulated in such a way that paves the way for validating all the software requirements. In the real time scenario, there could be many requirements that are not testable. The tester with his/her test planning skills should be able to find out a workaround to test those non-testable requirements. If there is no way to test them, that shall be communicated clearly to the appropriate authority. There could be many requirements that are very complex to test and the tester should be able to identify the best approach to test them.

Test Design Skills

Software Testing Science preaches many techniques like Equivalence Class Partitioning, Boundary Value Analysis, Orthogonal Array and many more techniques for an effective test design. The testers shall be aware of all those techniques and apply them into their software test designing practice. The tester shall be aware of various formats and templates to author and present the test cases or test procedures in a neat fashion. The tester shall aware of the best practices and the acceptable standards for designing the test cases. The tester shall be aware of the how to write test cases – non-ambiguous, simple, straight to the point.

The test case needs to contain Test Case Description, Test Steps and its corresponding expected results. The tester shall be aware of how to present the content in these three topics effectively in such a way that they can be read without any ambiguity by all the project stakeholders.

Test Execution Skills

Test Execution is nothing but executing the steps that is specified in the test design documents. During the execution, the testers shall capture the actual results and compare against the expected results specified in the test design documents. If there are any deviations between the expected and actual results, the testers shall consider that as a defect. The tester shall analyze the cause of the defect and if it is found and confirmed in the application under test, the same shall be communicated to the developers and it shall get fixed. If the cause of the defect is found with the test case, the same shall be communicated to the test designers and the test cases shall be modified/ amended accordingly. If the testers are not confident about the application functionalities and the test design documents, they may not confidently come to a conclusion about the defect in case of any discrepancies. This will lead to defects being leaked to the next phase and the testers needs to avoid this scenario. The testers shall be confident about the application functionalities and in case of any ambiguity or clarifications; they need to get them sorted out before executing the tests or at least during the test execution.

Defect Reporting Skills

Defect Reports are one of the critical deliverables from a tester. The defect reports are viewed by the development team, business analysts, project managers, technical managers and the quality assurance engineers along with the testers. Hence, the defect reports shall carry enough information about the defect. Steps to reproduce the defect, its expected result and actual result along with other information such as Severity, Priority, Assigned To (developer), Test Environment details are very critical for a defect report without which, the defect report is considered as incomplete. The tester shall be aware of the importance of the defect report and he/she shall create defect report in such a way that it is non-ambiguous. During the course of fixing the defect, the developers may come back to the testing team for more information regarding the defect and the tester shall provide the same without failing.

Test Automation Skills

Test Automation is a wonderful phenomenon by which the testing cost is drastically reduced. The manual test cases upon automation can be executed by running the automated test scripts. This means that the manual effort to run those automated test cases is not necessary and hence the total test effort is reduced drastically. The testers shall be aware of the technique for adopting test automation into the current testing process. Identifying the test automation candidates is very critical for the success of the automation project. Automation candidates shall be identified in such a way that the testing cost towards manual test execution would reduce significantly. This involves lots of thoughts from the financial perspective as well. The testers shall understand the process of do’s & don’ts of automation to make the automation project successful.

Conclusion

The testers shall understand/ learn and be confident about the application functionalities. Test planning, designing, execution and defect reporting are the basic and essential skills that a tester shall possess and develop in his day-to-day career. Professionals who are perfectionist in using these skills are called as “Testing Professionals” or “Testers” or “Testing Engineers”. Hope now, you are a tester…

What is Test Case? How to write a good test case?

Test Cases are the implementation of a test case design which will help the software tester to detect defects in the application or the system being tested. This should be the primary goal of any test case or set of test cases. When I write a test case, I think of both types of test cases, positive test cases and negative test cases. Positive test cases are those which execute the happy path in the application and make sure that the happy path is working fine. Negative test cases as the name suggests are destructive test cases which are documented with some out-of-box thinking to break the system.
A Test Case should be documented in a manner that is useful for the current test cycle and any future test cycles. At a bare minimum each test case should contain: Sr No, Summary or Title, Description, Steps to reproduce, Expected Results, Actual Results and Status of the test case or remarks.

Test Case Summary or Title

The Summary or title should contain the essence of the test case including the functional area and purpose of the test. Using a common naming convention that groups test cases encourages reuse and help prevents duplicate test cases from occurring.

Test Case Description

The description should clearly state what sequence of events to be executed by the test case. The Test Case description can apply to one or more test cases; it will often take more than one test case to fully test an area of the application.

Test Case Steps to reproduce

Each test case step should clearly state the navigation, test data, and events required to accomplish the step. Using a common descriptive approach encourages reuse and conformity.

Expected Results of Test Case

The expected behavior of the system after any test case step that requires verification / validation - this could include: screen pop-ups, data updates, display changes, or any other discernable event or transaction on the system that is expected to occur when the test case step is executed.

Status or Remarks

The operational status of the test case - Executed or not executed etc.

The following tools are provide automated functional testing and performance testing for environments including Dot Net, Java, CORBA, WWW, WAP, client/server, UNIX, and Windows & Etc …

1 .Segue Software delivers the industry’s premier e-business reliability products and solutions to help you address the risks and complexities that can affect the performance and quality of your e-business system.

• SilkTest - Automated functional and regression testing
• SilkPerformer - Automated load and performance testing
• SilkMonitor - 24×7 monitoring and reporting of Web, application and database servers
• SilkPilot - Unit testing of CORBA objects
• SilkObserver - End-to-end transaction management and monitoring for CORBA applications
• SilkMeter - Access control and usage metering
• SilkRealizer - Scenario testing and system monitoring
• SilkRadar - Automated defect tracking

2. Mercury offers a suite of solutions that automate testing and quality assurance for client/server software and systems, e-business applications, and enterprise resource planning applications.

• QuickTest Professional^TM - E-business functional testing
• LoadRunner® - Enterprise load testing
• TestDirector^TM - Integrated test management
• WinRunner® - Test automation for the enterprise

What are Recover Scenarios?

While executing your scripts you may get some UNEXPECTED/UNPREDICTABLE errors. (like printer out of paper). To “recover” the test (and continue running) from these unexpected errors you use Recovery Scenarios.

Next question arises,

When to use “on error resume next” or programmatic handling of errors VS Recovery Scenarios ?

If you can predict that a certain event may happen at a specific point in your test or component, it is recommended to handle that event directly within your test or component by adding steps such as If statements or optional steps or “on error resume next”, rather than depending on a recovery scenario. Using Recovery Scenarios may result in unusually slow performance of your tests.They are designed to handle a more generic set of unpredictable events which CANNOT be handled programmatically.

For Example:

A recovery scenario can handle a printer error by clicking the default button in the Printer Error message box.

You cannot handle this error directly in your test or component, since you cannot know at what point the network will return the printer error. You could try to handle this event in your test or component by adding an If statement immediately after the step that sent a file to the printer, but if the network takes time to return the printer error, your test or component may have progressed several steps before the error is displayed. Therefore, for this type of event, only a recovery scenario can handle it.

I would not go into details of how to create files and how to define them since they are fully covered in QTP Documentation. Mercury QuickTest Professional User’s Guide > Working with Advanced Testing Features > Defining and Using Recovery Scenarios >

What constitute Recovery Scenarios?

A recovery scenario consists of the following:

• Trigger Event. The event that interrupts your run session. For example, a window that may pop up on screen, or a QTP run error.
• Recovery Operations. The operations to perform to enable QTP to continue running the test after the trigger event interrupts the run session. For example, clicking an OK button in a pop-up window, or restarting Microsoft Windows.
• Post-Recovery Test Run Option. The instructions on how QTP should proceed after the recovery operations have been performed, and from which point in the test QTP should continue, if at all. For example, you may want to restart a test from the beginning, or skip a step entirely and continue with the next step in the test.

Recovery scenarios are saved in recovery scenario files having the extension .rs. A recovery scenario file is a logical collection of recovery scenarios, grouped according to your own specific requirements.

Is there a method to programmatically call them?

By default, QTP checks for recovery triggers when an error is returned during the run session. You can use the Recovery object’s method to force QTP to check for triggers after a specific step in the run session.

For a complete list go to QTP Documentation > Quick Test Advanced References > Quick Test Automation > Recovery Object

The limitations listed below are specifically for QTP 8.2:

Maximum worksheet size—65,536 rows by 256 columns
Column width—0 to 255 characters
Text length—16,383 characters
Formula length—1024 characters
Number precision—15 digits
Largest positive number—9.99999999999999E307
Largest negative number— -9.99999999999999E307
Smallest positive number—1E-307
Smallest negative number— -1E-307
Maximum number of names per workbook—Limited by available memory
Maximum length of name—255
Maximum length of format string—255
Maximum number of tables (workbooks)—Limited by system resources (windows and memory)

We Sharing some of the useful tips on quick test professional. I used while working and found from gds. I urge the readers to share their experiences/tips they have used while working on QTP. You can use the comments section to do the same.

1) How to add a constant number in a datatable?
This is more to do with MS excel then QTP!! but useful to know because at times it becomes frustrating to the novices.
Just append ‘ to the number
Ex: if you wish to enter 1234567 in datatable then write it as ‘1234567

2) How can i check if a parameter exists in DataTable or not?
The best way would be to use the below code:
on error resume next
val=DataTable(”ParamName”,dtGlobalSheet)
if err.number<> 0 then
‘Parameter does not exist
else
‘Parameter exists
end if

3) How can i check if a checkpoint passes or not?
chk_PassFail = Browser(…).Page(…).WebEdit(…).Check (Checkpoint(”Check1″))
if chk_PassFail then
MsgBox “Check Point passed”
else MsgBox “Check Point failed”
end if

4) My test fails due to checkpoint failing, Can i validate a checkpoint without my test failing due to checpoint failure?
Reporter.Filter = rfDisableAll ‘Disables all the reporting stuff
chk_PassFail = Browser(…).Page(…).WebEdit(…).Check (Checkpoint(”Check1″))
Reporter.Filter = rfEnableAll ‘Enable all the reporting stuff
if chk_PassFail then
MsgBox “Check Point passed”
else
MsgBox “Check Point failed”
end if

5) What is the difference between an Action and a function?
Action is a thing specific to QTP while functions are a generic thing which is a feature of VB Scripting. Action can have a object repository associated with it while a function can’t. A function is just lines of code with some/none parameters and a single return value while an action can have more than one output parameters.

6) Where to use function or action?
Well answer depends on the scenario. If you want to use the OR feature then you have to go for Action only. If the functionality is not about any automation script i.e. a function like getting a string between to specific characters, now this is something not specific to QTP and can be done on pure VB Script, so this should be done in a function and not an action. Code specific to QTP can also be put into an function using DP. Decision of using function/action depends on what any one would be comfortable using in a given situation.

7) When to use a Recovery Scenario and when to us on error resume next?
Recovery scenarios are used when you cannot predict at what step the error can occur or when you know that error won’t occur in your QTP script but could occur in the world outside QTP, again the example would be “out of paper”, as this error is caused by printer device driver. “On error resume next” should be used when you know if an error is expected and dont want to raise it, you may want to have different actions depending upon the error that occurred. Use err.number & err.description to get more details about the error.

How to use environment variable?
A simple defintion could be… it is a variable which can be used across the reusable actions and is not limited to one reusable action.
There are two types of environment variables:
1. User-defined
2. Built-in
We can retrieve the value of any environment variable. But we can set the value of only user-defined environment variables.

To set the value of a user-defined environment variable:
Environment (VariableName) = NewValue

To retrieve the value of a loaded environment variable:
CurrValue = Environment (VariableName)

Example
The following example creates a new internal user-defined variable named MyVariable with a value of 10, and then retrieves the variable value and stores it in the MyValue variable.

Environment.Value(”MyVariable“)=10
MyValue=Environment.Value(”MyVariable“)

9) What are the files and subfolders of a QuickTest Professional test?
The files and folders hold binary and text data that are required for the test to run successfully.
The following table provides a description, the type, and comments regarding the files that make up a QuickTest Professional test.

Files within Action folder:

There are few more files extensions like

.MTB Batch File
.LCK Locked

10) How to rename a checkpoint (QTP 9.0)?
Example:
Window(”Notepad”).WinEditor(”Edit”).Check CheckPoint(”Edit”)
In the above example, the user would like to change the name of the CheckPoint object from “Edit” to something more meaningful.
Note:
This functionality is new to QuickTest Professional 9.0.This is not available for QTP 8.2 and below.
1. Right-click on the Checkpoint step in the Keyword View or on the Checkpoint object in Expert View.
2. Select “Checkpoint Properties” from the pop-up menu.
3. In the Name field, enter the new checkpoint name.
4. Click . The name of the checkpoint object will be updated within the script.
Example:
Window(”Notepad”).WinEditor(”Edit”).Check CheckPoint(”NewCheckPointName”)
Note:
You must use the QuickTest Professional user interface to change the name of the checkpoint. If you manually change the name of the checkpoint in the script, QuickTest Professional will generate an error during replay. The error message will be similar to the following:

“The “” CheckPoint object was not found in the Object Repository. Check the Object Repository to confirm that the object exists or to find the correct name for the object.”

The CheckPoint object is not a visible object within the object repository, so if you manually modify the name, you may need to recreate the checkpoint to resolve the error.

11) Does QuickTest Professional support Internet Explorer 7.0?
QuickTest Professional 9.1
QuickTest Professional 9.1 supports Microsoft Internet Explorer 7.0 Beta 3. Internet Explorer version 7.0 is now certified to work and to be tested with QuickTest Professional version 9.1.
QuickTest Professional 9.0
QuickTest Professional 9.0 supports Internet Explorer 7.0 Beta 2.
QuickTest Professional 8.2 and below
QuickTest Professional 8.2 and below do not include support for Internet Explorer 7.0.

Does QuickTest Professional support Firefox?
QuickTest Professional 9.1 and 9.2
QuickTest Professional 9.1 provides replay support for Mozilla Firefox 1.5 and Mozilla Firefox 2.0 Alpha 3 (Alpha-level support for Bon Echo 2.0a3).
Notes:

QuickTest Professional 9.1 will not record on FireFox. You can record a test on Microsoft Internet Explorer and run it on any other supported browser, such as FireFox.

The .Object property for web objects is not supported in FireFox.

QuickTest Professional 9.0
QuickTest Professional 9.0 provides replay support for Mozilla FireFox 1.5.
Notes:

QuickTest Professional 9.0 will not record on FireFox. You can record a test on Microsoft Internet Explorer and run it on any other supported browser, such as FireFox.

The .Object property for web objects is not supported in FireFox.

QuickTest Professional 8.2 and below

QuickTest Professional 8.2 and below do not have support for Firefox.

12) Problem
After Quick Test Professional is started, Windows Media will not start. It returns the error message “wmplayer.exe has generated errors and will be closed by Windows. You will need to restart the program. An error log is being created.”

If you start Window’s Media Player first, it will continue to work normally after starting QuickTest Professional.

Solution:

Include the Windows Media Player’s executable in the NoBBTApps section of the mic.ini file

1. Close QuickTest Professional.
2. Go to \bin\mic.ini.
3. Include wmplayer.exe in the NoBBTApps section of mic.ini file.

Example:
[NoBBTApps]
wmplayer.exe=rek

4. Save the mic.ini file and restart QuickTest Professional.

13) What is the lservrc file in QTP?

The lservrc file contains the license codes that have been installed

The lservrc file contains the license codes that have been installed. Whenever a new license is created, the license code is automatically added to this file. The lservrc file is a text file, with no extension.

File Location:

1) For a Concurrent (Floating) license installation:

“#server installation directory#\#language#”

Example:
C:\Program Files\XYZ Technologies\ABC Server\English\lservrc

2) For a Seat (Stand-alone) license installation:

#AQT/QTP installation directory#\bin”

Example:
C:\Program Files\Mercury Interactive\QuickTest Professional\Bin\lservrc

14) What to do if you are not able to run QTP from quality center?
This is for especially for newbies with QTP.
Check that you have selected Allow other mercury products to run tests and components from Tools–> Options–> Run Tab.

15) Does QuickTest Professional support Macintosh operating systems?
No, QTP is not expected to run on this OS.

Regression Testing

As some one has said, changes are the only thing constant in this world. It holds true for software also, existing software are either being changed or removed from the shelves. These changes could be due to any reason. There could be some critical defects which need to be fixed; there could be some enhancements which have to happen in order to remain in the competition. 

Regression testing is done to ensure that enhancement, defect fixes or any other changes made to the software have not broken any existing functionality.

Regression testing is very important, because in most places these days iterative development is used. In iterative development, shorter cycle is used with some functionality added in every cycle. In this scenario, it makes sense to have regression testing for every cycle to make sure that new features are not breaking any existing functionality.

Whenever there are any changes in the system, regression testing is performed. Regression testing can be performed for the complete product or it can be selective. Normally, full regression cycle is executed during the end of testing cycle and partial regression cycle is executed between the test cycles. During the regression cycle it becomes very important to select the proper test cases to get the maximum benefits. Test cases for regression testing should be selected based on the knowledge of 

• What defect fixes, enhancement or changes have gone into the system?
• What is the impact of these changes on the other aspect of system?

Focus of the regression testing is always on the impact of the changes in the system. In most of the organizations, priority of the regression defect is always very high. It is normally included in the exit criteria of the product that it should have zero regression defects. 

Regression testing should always happen after the sanity or smoke testing. Sanity/Smoke can be defined as the type of testing which make sure that software is in testable state. Normally, sanity test suite will contain very basic and core test cases. These test cases decide the quality of the build and any failure in the sanity test suite should result in the rejection of build by the test team.

Regression testing is a continuous process and it happens after every release. Test cases are added to the regression suite after every release and repetitively executed for every release. 

Because test cases of regression suite are executed for every release, they are perfect candidate for the automation. Test automation is discussed separately in the Test Automation section of this website.

Performance Testing Strategies

The basic purpose of this document is to give a high level introduction to Software Load and Performance testing methodologies and strategies. This document is intended to facilitate Software test Managers, Project Managers, Software Engineers, Test Leads, Test engineers, and QA leads — anyone who is responsible for planning and/or implementation of a successful and cost effective performance testing program.
 

Scope

the scope of all the conceptualization mentioned in this document is only in the Test Execution in Automation Context.

In this context the attributes of Load & Performance testing covered are as follows,

Load / Performance Test Planning

Load / Performance Tool Evaluation / Selection

Load Test Process / Methodology and Test Strategy

Load / Performance Test Start/Stop Criteria

Test Environmental Setup and Pre-Requisites

Test Scenarios Definition including Load Scenario, Data Volume, Virtual Users Ramp Rates and Scripting Guidelines etc.

Pass / Fail / Exit Criteria

Analysis and Report Generation
 
 
2       Load / Performance Test Planning 

To make any operation/mission successive planning plays the most vital role and according to the 80-20 theory, 80% of the time should be spent in planning and 20% in real time plan execution/implementation. In the similar fashion, Software performance test planning is very crucial as well.
Any Software Performance Test Plan should have the minimal contents such as,
Performance Test Strategy and Scope Definitions.

-Test Process and Methodologies to follow in different test phases.

-Test Tool Details (Tool Evaluation, Selection, Configuration, Addins, Third Party Utilities Integration, Os Configurations etc)

-Test Cases Details including Scripting, Library Development and Script Maintenance Mechanisms to be used in Every Performance Test Phases.

-Resource Allocations and Responsibilities for Test Participants.

-Test Life Cycle Tasks Management and Communication Media.

-Risk Management Definitions.

-Test Start /Stop Criteria along with Pass/Fail Criteria Definitions.

-Test Environment Setup Requirements. (Hardware Setup, Software Setup, Os Configurations, Third Party Utilities Setup etc.)

-Multi-Platform Performance Test Strategies.

-Application Deployment Setup Requirements for Load Test.

-Virtual Users, Load (Iterations Vs Users), Volume Load Definitions for Different Load/Performance Test Phases.

-Results Analysis Algorithms and Reporting Format Definitions.

3       Load / Performance Tool Evaluation & Selection
Tool Evaluation are yet another important task in Performance Test Automation wherein there are several things to be considered. In cases wherein the tool evaluation and selection is completely done by the Client then readers may skip this Topic and proceed to next. 

While selecting any tool for Load or/and Performance testing the following things should be analyzed such as, 

-Test Budget Vs Available Load/Performance tools in the market mapping to the Budget.

-Protocols, Development & Deployment Technologies, Platforms, Middle-Ware tools / Servers, Third-Party Integrations of the Application Under test Vs Support for these factors in the available tools with prioritization of the availability in the tool for the Scope of expected test.

-Complexity of the Tool Usage Vs Availability of the tool experts along with the timeline requirements for the tool scripting / load scenario creation / tool configuration with respect to Man-hours and Other Resource Requirements.

-Tools Limitations and Work-Around factor mapping with the current scope of testing.

-Tool’s Integration / Portability Factors with Other Tools used to Monitoring, Analyzing and Test Management.

-On Evaluation and Selection of Base tool, third party monitors / tools to be used in Integration with Main Load Testing Tool should be defined.

(Third Party Monitors / Tools like ‘Optimize IT’, ‘Web logic’, ‘Oracle Tools’, ‘Spotlight On Oracle’, ‘Fog-Light’ and Test Management Tools like Mercury-Test Director, Segue-Silk Plan Pro, Compuare-QA Center etc.)
  

4       Test Process / Methodology and Test Strategy 

Test Process, Methodology and Strategy for any Load / Performance testing will definitely vary for every project based on the Client Requirements / Company Process Implementations but still here we are going to put some light on the common generic performance test process, methodologies and strategies followed in the industry.

By using a methodology a project can make sure that resources are applied to the problem effectively and that the people involved approach the work in a structured way. In Performance testing Process there are couple of classifications as mentioned below,
Benchmark Testing

This task tests the newly coded performance features to assert that they do actually improve the performance of the application. There is always a danger that a new performance feature decreases the performance of the application instead of increasing it. Tests should be constructed so that they executed a standard benchmark style test with the feature switched on and with the feature switched off.

      The first time this particular task is performed the task becomes developing the benchmark tests. When this task is performed in later iterations it becomes re-running the benchmark tests with the new version of the code in order to track whether or not the code is improving.

 
Analysis Testing

      Benchmark tests are good for a basic understanding of what is happening and are very useful for tracking improvements over time but they are not so good at isolating the reasons of the next major performance problem. Analysis Testing refers to designing tests that attempt to isolate the next major performance problem. These kinds of tests may do something completely different to the benchmark tests in order to explore what is happening in the target application. The tests are designed to explore theories as to where the next performance problem may be.

      This is also where supplementary tools are used most often. Additional tools such as method-level profilers and operating system performance monitors can be useful in working out where a problem might be occurring.

Long Running Tests

It is important to include some tests that run for long periods of time. There are a number of problems that may occur only after the target application has been running for more than a day or even after a week. Memory leaks in particular may take many hours before they become measurable. The length of these tests should be related to how often you plan to run the target application before restarting. If you plan to restart the target application every day then the test length should simulate one day’s worth of work but if you plan to restart the target application only once a week then the test length should simulate a week’s worth of work.

      This type of testing involves long periods of time and this causes problems such as,

1.      Since the tests take so long you are not typically able to perform as many of them.

2.      These tests take so long that they tie up resources for long periods of time.

                  One thing that you can do to be compact the work performed over one day into a short period time by making use of how normally a server machine is not run at one hundred percent of CPU for the whole day. By creating a sustained workload for a shorter period of time you can usually simulate on days worth of work in a shorter period. For problems like memory leaks it doesn’t normally matter how long the test takes what is important is how much work the test does. A quick half-hour test may not exercise the application for long enough but a sustained high-workload test that simulates one days worth of work in six hours should hopefully identify any problems.

      For example a typical interactive application that services internal users might look like the following chart with peaks at around 11am in the morning and 2pm in the afternoon.

By making the CPU do more work in less time you can compact the overall length of the test into a shorter period and so perform long running tests more easily.

Due to the hassle and restrictions involved in this kind of testing it should be done after the application is behaving reasonably well with shorter testing periods. But also it shouldn’t be left too late either since it takes so long to run these tests it is a good idea to get started with them before the end of the time allocated to performance testing.

Distributed Testing 

Another issue that often comes up is where the clients are located to do their testing. If the clients are located near where the server is running then the test may not adequately simulate the eventual production configuration. If the eventual production configuration is to have the client processes distributed nation-wide over a company’s private network then some testing should be done to simulate this otherwise if there is a problem with the network then testing with the client processes near to the server may not uncover this.

      There are generally practical problems with doing this kind of testing. There may be many different sites from where the clients may be executed and managing the load testing clients out on all of these sites can be a hassle. Due to these sorts of problems not all of the performance testing has to be done in a distributed way but some of it should be. Also like the long running tests this sort of testing should be done after the application is behaving reasonably well in a non-distributed way. This way the methodologies can be implemented based on the scope of testing requirements at a particular phase of performance testing.

      If we talk about the Test Process in general practice, once the Benchmark attributes like Load Scenario with load (Iterations / Scenario / Script), Virtual users with ramp-up rates, Business Transactions Definitions, Finalization of Tools for testing, Hardware Environment, SW-Environment like OS configuration, DB, Data Dependencies, Tool configurations, Application under test deployment details are finalized and documented the initial base benchmark test can be conducted in a normal circumstances to make sure that the application is in a stable state to go through the heavy load test. If any issues found during this test, then release cycles may be repeated till application reaches enough stability to start heavy Load / Performance test.

      The next task at the end of Baseline Performance test can be to start the Load Test. Load testing is an important task accomplished through Stress and Data Volume testing. This methodology of testing is used to establish an initial sound structure upon which the product is developed. A load test is meant to exercise the design of the application and reveal weaknesses in the targeted product before “General Availability”. By revealing problems during the development we do not only prepare for a successful deployment, but also a long prosperous product life cycle.

      Load testing comprises of Individual Module testing run on Iterative basis. Load tests are conducted against the Application under Test using a varying number of virtual users whose results are used for developers/architects to validate/tune the code / design /configurations for optimizing the product performance. The metrics established from the load test will be compared against the baseline to identify performance discrepancies.

      The cycles of such load tests and tuning can be repeated till the product stability reaches enough to go to production OR stability as defined by the client.

      Along with load testing, Stress testing is implemented as a sub-set of load testing. The stress is nothing but applying the load in the ramp-up of virtual users in the groups at the pre-defined rates. (I.e. Group1 – Users will ramp at rate of 5 users/scenario – 5, 10, 15, 20). There are cases when Client expects to benchmark the bottlenecks for specific application functionalities commonly used/accessed by all users the most and that too at a time. For such cases, we can put rendezvous points at appropriate transaction actions wherein all the users will ramp up at the pre-defined rate but when it comes the time to execute the action of rendezvous action, users will wait till all Virtual Users reach till that point and perform that action at a time. So in such a scenario bottlenecks can be easily located. Basically Stress tests are intended to be modular in design so each functional script can be run independently.

      In the performance testing process, there are cases in which some part of application is data volume dependant like Search Screens wherein the Queries / Stored Procedures Performance based on amount of data volume existing in the database, then for such cases before starting the test, the dump of some huge amount of data should be inserted in the database through some SQL Scripts or Automation Scripts etc. so that the results of such screens can help in database tuning / optimization.

      At the end of all such tests, the results from the load testing tool, monitoring tools give a bright idea about the tuning requirements in the system like CPU, Memory, OS, HW, SW, Code, Application Configuration, Middle-tier servers etc. and such Load Test and Results Analysis Vs tuning cycles can be repeated till the application reaches stability as expected by the client.

 
5       Load / Performance Test Start/Stop Criteria 

In case of any performance testing there should be a defined / documented Start and End Criteria to avoid the adhoc process resulting in weird outputs. This start / end criteria should be well defined in the Performance Test Plan along with all the risk management factors.

The start of any Performance or load testing should be done for any application or any module of the application only when the Design, Database Structure and Application Development platform is finalized and there will be no major changes at any layers of the application, which affect directly or indirectly to the Performance Factor.  It really again depends on the scope of testing such that the test is going to be conducted for a specific Module or the whole System.

Once the Load or Performance Test is conducted, results are collected and analyzed the cycles of tuning will carry on but yes definitely the end criteria should be well defined to Stop this Performance Testing and Tuning Cycles based on various factors like product GA release timelines (Project Deadlines) and Client Requirements in terms of System Stability, Scalability and reliability under load and Performance Tolerance Criterions.

In some projects the end criteria is defined based on the Client Performance Measures Requirements defined for each section of the application so if product reaches to that expected level then that might be considered as the end criteria for Performance Testing.

6       Test Environmental Setup and Pre-Requisites 

In the performance testing, by the term test environment here, it’s composed of hardware environment (Machine, Memory, Virtual Memory, Number of CPU’s etc), Software environment like Os, Os configuration, Files System Settings, Free Space for logs, Application Configuration along with Middle Tier Server and associated Configurations, Database, Network etc.

Among all of the above environmental variables defined few or all might be used for setup based on the Deployment Setup Client / Customer expects to have in production.

This setup also involves the Automation Tools installation, configurations, Agent Installations and setup in Load Clients, Third Party Monitors on Clients / Servers etc.

      There may or may not be any pre-requisites if all of the above variables setup is all set before starting the test but some pre-requisites like Reference Data, Test Input Data in the database Insertion etc.

Also System Settings at Os Level, Tier-Level, and Server Level etc. should be listed in a document as Checklists and should be verified before starting any Performance Test.

7       Test Scenarios 

Test Scenarios Definition includes various tasks like Business Scenarios Definitions, Writing Automation Scripts for Test Cases Corresponding to defined Business / Functional Scenarios, expected Data Volume for Test mapping to Virtual Users Ramp Rates and Scripting Guidelines etc.

       In the test scenario development, the scripts written can be made data driven to facilitate Iterative testing in Load Test Scenarios. Once these details are well defined in Test Automation Plan, then Virtual User Test Scripts can be written to simulate User Client Actions / Client - Server Request-Response Hits etc. On completion of baseline scripting, based on data-drive requirements the test scripts can be parameterized to make them compatible to execute the same functionality / User Actions for different set of Test Data on Iterative basis.

In some typical cases in few scenarios wherein the performance of some sections of the application is based on the volume of the data residing in the database then Data Volume Based Performance Test is a must. In such cases, the data insertion SQL Scripts can be written and executed before the execution of Load Test and Data-Volume based Test Scripts should be mapped to this data.

Also along with these factors definitely the number of Virtual Users, amount of load (i.e. Preset Number of Iterations/script) should be predefined from the Customer Production load Volume in peak and non-peak hours. Also in the Stress test which is a part of load test itself, the Virtual Users need to be set in Ramp Up by the pre-defined rates like 5,10,15,20,25 Users etc. Along with the Stress Ramping Rate setting of the Virtual Users in the load scenario, there are cases wherein if the requirement is to perform a particular Action/Operation by all the virtual users at a time for finding out the bottle neck points, Test Scripts should have rendezvous points for such actions so that whenever all the virtual users are performing different operations for different test cases, they will wait till all Virtual Users get to the rendezvous points and execute that action at a time and at the end of that action then again the Ramp-up of  Virtual Users is re-started.

 
8       Analysis and Report Generation 

Once the results are ready, analysis is the most important job in the whole performance test if the requirements of load or performance test are not defined.

In the analysis, the main criteria for analysis should be to find out the bottle neck points wherein we should be able to track out the transactions / users / hits creating the highest level of performance reduction. The main factors to be consideration are,         

Request / Response Timings to-fro from Client to Server
-Transaction Timings Vs Users
-Transaction Timings Vs Load
-Transaction Timings Vs CPU Utilization
-Server Memory Utilization
-Database Server Performance using DB Server Monitors
-Web / Application Server Performance
-Paging Rate Ratios
-Open Cursor Factors in Database
-Load Balancer Factors
-Network Delays
-Bean Performance Factors using Monitors like Optimize IT for Java Based Applications
-Other Monitors like Application Server (e.g. Web-logic) Monitors etc.

Thus now after consolidating all the results for the above points, the statistical analysis should be done and the Performance Test Report should be created such that the Development, Design-Architecture, Database / IT, PMG group can get a clear idea about the Application Performance and all the factors affecting it.

After Analysis then based on the scope the corresponding tuning like Os tuning, Database Tuning, Memory Up-gradations, CPU counts in Multi-CPU machine, Code-Tuning, Application Server Cache tuning or any other tuning as per the scope can be done and same tests executed earlier should be repeated in the tuned environment to make out the differences in the results before and after tuning. These tuning cycles can be repeated until the pre-defined required Performance is achieved. In the next version of this document we will be placing the examples for each type of Performance Analysis with the corresponding graph with all the algorithms used for analysis.

 
9       Pass / Fail  / Exit Criteria 

At the end of the Load / Performance Test execution, we can find the number of failed users, failed transactions or failed scripts but the Pass / Fail Criteria for a particular test should be well defined before execution of the test as basically this criteria entirely depends on the scope of testing and the environment. For e.g. in some cases few transaction steps failed which has some workarounds or the reasons for failing the transactions or virtual users are due to unusual attributes behavior which is not related to the application then the results, or few times the tests / scripts / virtual users / transactions failure might happen due to Load Tool Configuration or Load Tool Defects also so its very important to analyze and make a precise differentiation of the Defect occurred in the test and then finalize whether the test was pass or fail.

Also based on the failed Items due to any of the performance test parameters the Failed Item Details should be included in the Applications Limitations List. By doing so, the limitations list can give a clear picture about the Applications Scalability / Load or Performance Limitations with respect to corresponding Load Parameters which in turn will give inputs for the tuning / enhancements for the Application.

Based on the Test Results tuning cycles will be driven and test phases will as well be repeated but the exit criteria should be pre-defined to avoid hazardous tuning life cycle.

Test Case : Test case is a document that describes an input, action or event and an expected response to determine if a feature of an application is working correctly and meets the user requirements.A Good test case is the one that has high probability of finding as yet undiscovered error.

The Test case document contains the following fields:

Testing Life Cycle – Roles and Responsibilities

Test Manager

• Single point contact between on site and offshore team
• prepare the project plan.
• Test management
• Test planning
• Interact with onsite lead, Client QA manager.
• Team Management.
• Work Allocation to the team.
• Test coverage analysis.
• Co-ordination with onsite for issue resolution.
• Monitoring the deliverables.
• Verify readiness of the product for release through release review.
• Obtain customer acceptance on the deliverables
• Performing risk analysis when required
• Reviews and status reporting.
• Authorize intermediate deliverables and patch release to customer.

Test Lead

• Resolves technical issues for the product group
• Provide direction to the team member.
• Perform activities to the respective product group.
• Review and approve of test plan.
• Review test script/code.
• Approve completion of the integration testing.
• Conduct system/regression test.
• Ensure tests are conducted as per plan.
• Reports status to the offshore test manager.

Test Engineer

• Development of the test cases and scripts
• Test execution
• Result capturing and analysis
• Defects reporting and status reporting.

Win Runner Navigation

Using Rapid Test Script wizard

• Start->Program Files->Winrunner->winruner
• Select the Rapid Test Script Wizard (or) create->Rapid Test Script wizard
• Click Next button of welcome to script wizard
• Select hand icon and click on Application window and Cilck Next button
• Select the tests and click Next button
• Select Navigation controls and Click Next button
• Set the Learning Flow(Express or Comprehensive) and click Learn button
• Select start application YES or NO, then click Next button
• Save the Startup script and GUI map files, click Next button
• Save the selected tests, click Next button
• Click Ok button
• Script will be generated.then run the scripts.
• Run->Run from top Find results of each script and select tools->text report in Winrunner test results

Using GUI-Map Configuration Tool:

• Open an application.
• Select Tools-GUI Map Configuration; Windows pops-up.
• Click ADD button; Click on hand icon.
• Click on the object, which is to be configured. A user-defined class for that object is added to list.
• Select User-defined class you added and press ‘Configure’ button.
• Mapped to Class;(Select a corresponding standard class from the combo box).
• You can move the properties from available properties to Learned Properties. By selecting Insert button .
• Select the Selector and recording methods.
• Click Ok button
• Now, you will observe Win runner identifying the configured objects.

Using Record-ContextSensitive mode:

• Create->Record context Sensitive
• Select start->program files->Accessories->Calculator
• Do some action on the application.
• Stop recording
• Run from Top; Press ‘OK’.

Using Record-Analog Mode:

• Create->Insert Function->from function generator
• Function name:(select ‘invoke_application’ from combo box).
• Click Args button; File: mspaint.
• Click on ‘paste’ button; Click on ‘Execute’ button to open the application; Finally click on ‘Close’.
• Create->Record-Analog .
• Draw some picture in the paintbrush file.
• Stop Recording
• Run->Run from Top; Press ‘OK’.

GUI CHECK POINTS-Single Property Check:

• Create->Insert function->Function Generator-> (Function name:Invoke_application; File :Flight 1a)
• Click on’paste’ and click on’execute’ & close the window.
• Create->Record Context sensitive.
• Do some operations & stop recording.
• Create->GUI Check Point->For single Property.
• Click on some button whose property to be checked.
• Click on paste.
• Now close the Flight1a application; Run->Run from top.
• Press ‘OK’ it displays results window.
• Double click on the result statement. It shows the expected value & actual value window.

GUI CHECK POINTS-For Object/Window Property:

• Create->Insert function->Function Generator-> (Function name:Invoke_application; File :Flight 1a)
• Click on’paste’ and click on’execute’ & close the window.
• Create->Record Context sensitive.
• Do some operations & stop recording.
• Create->GUI Check Point->Object/Window Property.
• Click on some button whose property to be checked.
• Click on paste.
• 40Now close the Flight 1a application; Run->Run from top.
• Press ‘OK’ it displays results window.
• Double click on the result statement. It shows the expected value & actual value window.

GUI CHECK POINTS-For Object/Window Property:

• Create->Insert function->Function Generator-> (Function name:Invoke_application; File :Flight 1a)
• Click on’paste’ and click on’execute’ & close the window.
• Create->Record Context sensitive.
• Do some operations & stop recording.
• Create->GUI Check Point->For Multiple Object.
• Click on some button whose property to be checked.
• Click on Add button.
• Click on few objects & Right click to quit.
• Select each object & select corresponding properties to be checked for that object: click ‘OK’.
• Run->Run from Top. It displys the results.

BITMAP CHECK POINT:For object/window.

• Create->Insert function->Function Generator-> (Function name:Invoke_application; File :Flight 1a)
• Click on’paste’ and click on’execute’ & close the window.
• Create->Record Context sensitive.
• Enter the Username, Password & click ‘OK’ button
• Open the Order in Flight Reservation Application
• Select File->Fax Order& enter Fax Number, Signature
• Press ‘Cancel’ button.
• Create->Stop Recording.
• Then open Fax Order in Flight Reservation Application
• Create->Bitmap Check->For obj.window;
• Run->run from top.
• The test fails and you can see the difference.

For Screen Area:

• Open new Paint Brush file;
• Create->Bitmapcheck point->from screen area.
• Paint file pops up; select an image with cross hair pointer.
• Do slight modification in the paint file(you can also run on the same paint file);
• Run->Run from Top.
• The test fails and you can see the difference of images.

DATABASE CHECK POINTSUsing Default check(for MS-Access only)

• Create->Database Check Point->Default check
• Select the Specify SQL Statement check box
• Click Next button
• Click Create button
• Type New DSN name and Click New button
• Then select a driver for which you want to set up a database & double clcik that driver
• Then select Browse button and retype same DSN name and Click save button.
• Click Next button & click Finish button
• Select database button & set path of the your database name
• Click ‘OK’ button & then Click the your DSN window ‘OK’ button
• Type the SQL query in SQL box
• The click Finish button Note : same process will be Custom Check Point

Runtime Record Check Point.

• Repeat above 10 steps.
• Type query of two related tables in SQL box Ex: select Orders.Order_Number, Flights.Flight_Number from Orders, Flights where Flight.Flight_Number=Orders.Flight_Number.
• Select Finish Button
• Select hand Icon button& select Order No in your Application
• Click Next button.
• Select hand Icon button& select Filght No in your Application
• Click Next button
• Select any one of the following check box 1. One match record 2. One or more match records. 3. No match record
• select Finish button the script will be generated

Synchronization PointFor Obj/Win Properties:

• Open start->Programs->Win Runner->Sample applications->Flight1A.
• Open winrunner window
• Create->RecordContext Sensitive
• Insert information for new Order &click on “insert Order” button
• After inserting click on “delete” button
• Stop recording& save the file.
• Run->Run from top: Gives your results.

Without Synchronization:

• settings->General Options->Click on “Run” tab. “Timeout for checkpoints& Cs statements’ value:10000 follow 1 to 7->the test display on “Error Message” that “delete” button is disabled.

With Synchronization:

• Keep Timeout value:1000 only
• Go to the Test Script file, insert pointed after “Insert Order” button, press statement.
• Create->Synchronization->For Obj/Window Property
• Click on”Delete Order” button & select enable property; click on “paste”.
• It inserts the Synch statement.

For Obj/Win Bitmap:

• Create-> Record Context Sensitive.
• Insert information for new order & click on “Insert order” button
• Stop recording & save the file.
• Go to the TSL Script, just before inserting of data into “date of flight” insert pointer.
• Create->Synchronization->For Obj/Win Bitmap is selected.
• (Make sure Flight Reservation is empty) click on “data of flight” text box
• Run->Run from Top; results are displayed. Note:(Keep “Timeout value” :1000)

Get Text: From Screen Area: (Note: Checking whether Order no is increasing when ever Order is created)

• Open Flight1A; Analysis->graphs(Keep it open)
• Create->get text->from screen area
• Capture the No of tickets sold; right clcik &close the graph
• Now , insert new order, open the graph(Analysis->graphs)
• Go to Winrunner window, create->get text->from screen area
• Capture the No of tickets sold and right click; close the graph
• Save the script file
• Add the followinf script; If(text2==text1) tl_step(”text comparision”,0,”updateed”); else tl_step(”text comparision”,1,”update property”);
• Run->Run from top to see the results.

Get Text: For Object/Window:

• Open a “Calc” application in two windows (Assuming two are two versions)
• Create->get text->for Obj/Window
• Click on some button in one window
• Stop recording
• Repeat 1 to 4 for Capture the text of same object from another “Calc” application.
• Add the following TSL(Note:Change “text” to text1 & text2 for each statement) if(text1==text2) report_msg(”correct” text1); Else report_msg(”incorrect” text2);
• Run & see the results

Using GUI-Spy:

Using the GUI Spy, you can view and verify the properties of any GUI object on selected application

• Tools->Gui Spy…
• Select Spy On ( select Object or Window)
• Select Hand icon Button
• Point the Object or window & Press Ctrl_L + F3.
• You can view and verify the properties.

Using Virtual Object Wizard:

Using the Virtual Object wizard, you can assign a bitmap to a standard object class, define the coordinates of that object, and assign it a logical name

• Tools->Virtual Object Wizard.
• Click Next Button
• Select standard class object for the virtual object Ex: class:Push_button
• Click Next button
• Click Mark Object button
• Drag the cursor to mark the area of the virtual object.
• Click Next button
• Assign the Logical Name, This name will appear in the test script when you record object.
• Select Yes or No check box
• Click Finish button
• Go to winrunner window & Create->Start Recording.
• Do some operations
• Stop Recording

Using Gui Map Editor:

Using the GUI Map Editor, you can view and modify the properties of any GUI object on selected application. To modify an object’s logical name in a GUI map file

• Tools->GUI Map Editor
• Select Learn button
• Select the Application A winrunner message box informs “do you want to learn all objects within the window” & select ‘yes’’ button.
• Select perticular object and select Modify Button
• Change the Logical Name& click ‘OK’ Button
• Save the File

To find an object in a GUI map file:

• Choose Tools > GUI Map Editor.
• Choose View > GUI Files.
• Choose File > Open to load the GUI map file.
• Click Find. The mouse pointer turns into a pointing hand.
• Click the object in the application being tested. The object is highlighted in the GUI map file.

To highlight an object in a Application:

• Choose Tools > GUI Map Editor.
• Choose View > GUI Files.
• Choose File > Open to load the GUI map file.
• Select the object in the GUI map file
• Click Show. The object is highlighted in the Application.

Data Driver Wizard

• Start->Programs->Wirunner->Sample applications->Flight 1A
• Open Flight Reservation Application
• Go to Winrunner window
• Create->Start recording
• Select file->new order, insert the fields; Click the Insert Order
• Tools->Data Table; Enter different Customer names in one row and Tickets in another row.
• Default that two column names are Noname1 and Noname2.
• Tools->Data Driver Wizard
• Click Next button &select the Data Table
• Select Parameterize the test; select Line by Line check box
• Click Next Button
• Parameterize each specific values with column names of tables;Repeat for all
• Final Click finish button.
• Run->Run from top;
• View the results.

Merge the GUI Files:

Manual Merge

• Tools->Merge GUI Map Files A WinRunner message box informs you that all open GUI maps will be closed and all unsaved changes will be discarded & click ‘OK’ button.
• Select the Manual Merge. Manual Merge enables you to manually add GUI objects from the source to target files.
• To specify the Target GUI map file click the browse button& select GUI map file
• To specify the Source GUI map file. Click the add button& select source GUI map file.
• Click ‘OK’ button
• GUI Map File Manual Merge Tool Opens Select Objects and move Source File to Target File
• Close the GUI Map File Manual Merge Tool

Auto Merge

• Tools->Merge GUI Map Files A WinRunner message box informs you that all open GUI maps will be closed and all unsaved changes will be discarded & click ‘OK’ button.
• Select the Auto Merge in Merge Type. If you chose Auto Merge and the source GUI map files are merged successfully without conflicts,
• To specify the Target GUI map file click the browse button& select GUI map file
• To specify the Source GUI map file.
• Click the add button& select source GUI map file.
• Click ‘OK’ button A message confirms the merge.

Manually Retrive the Records form Database

• db_connect(query1,DSN=Flight32);
• db_execute_query(query1,select * from Orders,rec);
• db_get_field_value(query1,#0,#0);
• db_get_headers(query1, field_num,headers);
• db_get_row(query1,5,row_con);
• db_write_records(query1,,c:\\str.txt,TRUE,10);

46. High severity, low priority bug?

A: — A page is rarely accessed, or some activity is performed rarely but that thing outputs some important Data incorrectly, or corrupts the data, this will be a bug of H severity L priority

47. If project wants to release in 3 months what type of Risk analysis u do in Test plan?

A:– Use risk analysis to determine where testing should be focused. Since it’s rarely possible to test every possible aspect of an application, every possible combination of events, every dependency, or everything that could go wrong, risk analysis is appropriate to most software development projects. This requires judgment skills, common sense, and experience. (If warranted, formal methods are also available.) Considerations can include:

• Which functionality is most important to the project’s intended purpose?
• Which functionality is most visible to the user?
• Which functionality has the largest safety impact?
• Which functionality has the largest financial impact on users?
• Which aspects of the application are most important to the customer?
• Which aspects of the application can be tested early in the development cycle?
• Which parts of the code are most complex, and thus most subject to errors?
• Which parts of the application were developed in rush or panic mode?
• Which aspects of similar/related previous projects caused problems?
• Which aspects of similar/related previous projects had large maintenance expenses?
• Which parts of the requirements and design are unclear or poorly thought out?
• What do the developers think are the highest-risk aspects of the application?
• What kinds of problems would cause the worst publicity?
• What kinds of problems would cause the most customer service complaints?
• What kinds of tests could easily cover multiple functionalities?
• Which tests will have the best high-risk-coverage to time-required ratio

48. Test cases for IE 6.0 ?

A:– Test cases for IE 6.0 i.e Internet Explorer 6.0:—
1)First I go for the Installation side, means that –
+ is it working with all versions of Windows ,Netscape or other softwares in other words we can say that IE must check with all hardware and software parts.
2) Secondly go for the Text Part means that all the Text part appears in frequent and smooth manner.
3) Thirdly go for the Images Part means that all the Images appears in frequent and smooth manner.
4) URL must run in a better way.
5) Suppose Some other language used on it then URL take the Other Characters, Other than Normal Characters.
6)Is it working with Cookies frequently or not.
7) Is it Concerning with different script like JScript and VBScript.
HTML Code work on that or not.
9) Troubleshooting works or not.
10) All the Tool bars are work with it or not.
11) If Page has Some Links, than how much is the Max and Min Limit for that.
12) Test for Installing Internet Explorer 6 with Norton Protected Recycle Bin enabled .
13) Is it working with the Uninstallation Process.
14) Last but not the least test for the Security System for the IE 6.0

49. Where you involve in testing life cycle ,what type of test you perform ?

A:– Generally test engineers involved from entire test life cycle i.e, test plan, test case preparation, execution, reporting. Generally system testing, regression testing, adhoc testing
etc.

50. what is Testing environment in your company ,means hwo testing process start ?

A:– testing process is going as follows
quality assurance unit
quality assurance manager
testlead
test engineer

51. who prepares the use cases?

A:– In Any company except the small company Business analyst prepares the use cases
But in small company Business analyst prepares along with team lead

52. What methodologies have you used to develop test cases?

A:– generally test engineers uses 4 types of methodologies
1. Boundary value analysis
2.Equivalence partition
3.Error guessing
4.cause effect graphing

53. Why we call it as a regression test nor retest?

A:– If we test whether defect is closed or not i.e Retesting But here we are checking the impact also regression means repeated times

54. Is automated testing better than manual testing. If so, why?

A:– Automated testing and manual testing have advantages as well as disadvantages
Advantages: It increase the efficiency of testing process speed in process
reliable
Flexible
disadvantage’s
Tools should have compatibility with our development or deployment tools needs lot of time initially If the requirements are changing continuously Automation is not suitable
Manual: If the requirements are changing continuously Manual is suitable Once the build is stable with manual testing then only we go 4 automation
Disadvantages:
It needs lot of time
We can not do some type of testing manually
E.g Performances

55. what is the exact difference between a product and a project.give an example ?

A:– Project Developed for particular client requirements are defined by client Product developed for market Requirements are defined by company itself by conducting market survey
Example
Project: the shirt which we are interested stitching with tailor as per our specifications is project
Product: Example is “Ready made Shirt” where the particular company will imagine particular measurements they made the product
Mainframes is a product
Product has many mo of versions
but project has fewer versions i.e depends upon change request and enhancements

56. Define Brain Stromming and Cause Effect Graphing? With Eg?

A:– BS:
A learning technique involving open group discussion intended to expand the range of available ideas
OR
A meeting to generate creative ideas. At PEPSI Advertising, daily, weekly and bi-monthly brainstorming sessions are held by various work groups within the firm. Our monthly I-
Power brainstorming meeting is attended by the entire agency staff.
OR
Brainstorming is a highly structured process to help generate ideas. It is based on the principle that you cannot generate and evaluate ideas at the same time. To use brainstorming, you must first gain agreement from the group to try brainstorming for a fixed interval (eg six minutes).

CEG :
A testing technique that aids in selecting, in a systematic way, a high-yield set of test cases that logically relates causes to effects to produce test cases. It has a beneficial side effect in pointing out incompleteness and ambiguities in specifications.

57. Actually by using severity u should know which one u need to solve so what is the need of priority?

A:– I guess severity reflects the seriousness of the bug where as priority refers to which bug should rectify first. of course if the severity is high the same case is with priority in normal.

severity decided by the tester where as priority decided by developers. which one need to solve first knows through priority not with severity. how serious of the bug knows through
severity.

severity is nothing impact of that bug on the application. Priority is nothing but importance to resolve the bug yeah of course by looking severity we can judge but sometimes high severity bug doesn’t have high priority At the same time High priority bug don’t have high severity
So we need both severity and priority

58. What do u do if the bug that u found is not accepted by the developer and he is saying its not reproducible. Note:The developer is in the on site location ?

A:– once again we will check that condition with all reasons. then we will attach screen shots with strong reasons. then we will explain to the project manager and also explain to the client when they contact us

Sometimes bug is not reproducible it is because of different environment suppose development team using other environment and you are using different environment at this situation there is chance of bug not reproducing. At this situation please check the environment in the base line documents that is functional documents if the environment which we r using is correct we will raise it as defect We will take screen shots and sends them with test procedure also

59. what is the difference between three tier and two tier application?

A:– Client server is a 2-tier application. In this, front end or client is connected to
‘Data base server’ through ‘Data Source Name’,front end is the monitoring level.

Web based architecture is a 3-tier application. In this, browser is connected to web server through TCP/IP and web server is connected to Data base server,browser is the monitoring level. In general, Black box testers are concentrating on monitoring level of any type of application.

All the client server applications are 2 tier architectures.
Here in these architecture, all the “Business Logic” is stored in clients and “Data” is stored in Servers. So if user request anything, business logic will b performed at client, and the data is retrieved from Server(DB Server). Here the problem is, if any business logic changes, then we
need to change the logic at each any every client. The best ex: is take a super market, i have branches in the city. At each branch i have clients, so business logic is stored in clients, but the actual data is store in servers.If assume i want to give some discount on some items, so i
need to change the business logic. For this i need to goto each branch and need to change the business logic at each client. This the disadvantage of Client/Server architecture.

So 3-tier architecture came into picture:

Here Business Logic is stored in one Server, and all the clients are dumb terminals. If user requests anything the request first sent to server, the server will bring the data from DB Sever and send it to clients. This is the flow for 3-tier architecture.

Assume for the above. Ex. if i want to give some discount, all my business logic is there in Server. So i need to change at one place, not at each client. This is the main advantage of 3-tier architecture.