Facebook Badge
Blogroll
Saturday, November 12, 2011
History of Testing
Being a Software Test Professional, you must know a brief history of Software Engineering. Software Testing comes into picture in every phase of Software Engineering.
The software industry has evolved through 4 eras, 50’s –60’s, mid 60’s –late 70’s, mid 70’s- mid 80’s, and mid 80’s-present. Each era has its own distinctive characteristics, but over the years the software’s have increased in size and complexity. Several problems are common to almost all of the eras and are discussed below.
The Software Crisis dates back to the 1960’s when the primary reasons for this situation were less than acceptable software engineering practices. In the early stages of software there was a lot of interest in computers, a lot of code written but no established standards. Then in early 70’s a lot of computer programs started failing and people lost confidence and thus an industry crisis was declared. Various reasons leading to the crisis included:
- Hardware advances outpacing the ability to build software for this hardware.
- The ability to build in pace with the demands.
- Increasing dependency on software’s
- Struggle to build reliable and high quality software
- Poor design and inadequate resources.
This crisis though identified in the early years, exists to date and we have examples of software failures around the world. Software is basically considered a failure if the project is terminated because of costs or overrun schedules, if the project has experienced overruns in excess of 50% of the original or if the software results in client lawsuits. Some examples of failures include failure of Air traffic control systems, failure of medical software, and failure in telecommunication software. The primary reason for these failures other than those mentioned above is due to bad software engineering practices adopted. Some of the worst software practices include:
- No historical software-measurement data.
- Rejection of accurate cost estimates.
- Failure to use automated estimating and planning tools.
- Excessive, irrational schedule pressure and creep in user requirements.
- Failure to monitor progress and to perform risk management.
- Failure to use design reviews and code inspections.
To avoid these failures and thus improve the record, what is needed is a better understanding of the process, better estimation techniques for cost time and quality measures. But the question is, what is a process? Process transform inputs to outputs i.e. a product. A software process is a set of activities, methods and practices involving transformation that people use to develop and maintain software.
At present a large number of problems exist due to a chaotic software process and the occasional success depends on individual efforts. Therefore to be able to deliver successful software projects, a focus on the process is essential since a focus on the product alone is likely to miss the scalability issues, and improvements in the existing system. This focus would help in the predictability of outcomes, project trends, and project characteristics.
The process that has been defined and adopted needs to be managed well and thus process management comes into play. Process management is concerned with the knowledge and management of the software process, its technical aspects and also ensures that the processes are being followed as expected and improvements are shown.
From this we conclude that a set of defined processes can possibly save us from software project failures. But it is nonetheless important to note that the process alone cannot help us avoid all the problems, because with varying circumstances the need varies and the process has to be adaptive to these varying needs. Importance needs to be given to the human aspect of software development since that alone can have a lot of impact on the results, and effective cost and time estimations may go totally waste if the human resources are not planned and managed effectively. Secondly, the reasons mentioned related to the software engineering principles may be resolved when the needs are correctly identified. Correct identification would then make it easier to identify the best practices that can be applied because one process that might be suitable for one organization may not be most suitable for another.
Therefore to make a successful product a combination of Process and Technicalities will be required under the umbrella of a well-defined process.
Having talked about the Software process overall, it is important to identify and relate the role software testing plays not only in producing quality software but also maneuvering the overall process.
The computer society defines testing as follows: “Testing -- A verification method that applies a controlled set of conditions and stimuli for the purpose of finding errors. This is the most desirable method of verifying the functional and performance requirements. Test results are documented proof that requirements were met and can be repeated. The resulting data can be reviewed by all concerned for confirmation of capabilities.”
There may be many definitions of software testing and many which appeal to us from time to time, but its best to start by defining testing and then move on depending on the requirements or needs.
The software industry has evolved through 4 eras, 50’s –60’s, mid 60’s –late 70’s, mid 70’s- mid 80’s, and mid 80’s-present. Each era has its own distinctive characteristics, but over the years the software’s have increased in size and complexity. Several problems are common to almost all of the eras and are discussed below.
The Software Crisis dates back to the 1960’s when the primary reasons for this situation were less than acceptable software engineering practices. In the early stages of software there was a lot of interest in computers, a lot of code written but no established standards. Then in early 70’s a lot of computer programs started failing and people lost confidence and thus an industry crisis was declared. Various reasons leading to the crisis included:
- Hardware advances outpacing the ability to build software for this hardware.
- The ability to build in pace with the demands.
- Increasing dependency on software’s
- Struggle to build reliable and high quality software
- Poor design and inadequate resources.
This crisis though identified in the early years, exists to date and we have examples of software failures around the world. Software is basically considered a failure if the project is terminated because of costs or overrun schedules, if the project has experienced overruns in excess of 50% of the original or if the software results in client lawsuits. Some examples of failures include failure of Air traffic control systems, failure of medical software, and failure in telecommunication software. The primary reason for these failures other than those mentioned above is due to bad software engineering practices adopted. Some of the worst software practices include:
- No historical software-measurement data.
- Rejection of accurate cost estimates.
- Failure to use automated estimating and planning tools.
- Excessive, irrational schedule pressure and creep in user requirements.
- Failure to monitor progress and to perform risk management.
- Failure to use design reviews and code inspections.
To avoid these failures and thus improve the record, what is needed is a better understanding of the process, better estimation techniques for cost time and quality measures. But the question is, what is a process? Process transform inputs to outputs i.e. a product. A software process is a set of activities, methods and practices involving transformation that people use to develop and maintain software.
At present a large number of problems exist due to a chaotic software process and the occasional success depends on individual efforts. Therefore to be able to deliver successful software projects, a focus on the process is essential since a focus on the product alone is likely to miss the scalability issues, and improvements in the existing system. This focus would help in the predictability of outcomes, project trends, and project characteristics.
The process that has been defined and adopted needs to be managed well and thus process management comes into play. Process management is concerned with the knowledge and management of the software process, its technical aspects and also ensures that the processes are being followed as expected and improvements are shown.
From this we conclude that a set of defined processes can possibly save us from software project failures. But it is nonetheless important to note that the process alone cannot help us avoid all the problems, because with varying circumstances the need varies and the process has to be adaptive to these varying needs. Importance needs to be given to the human aspect of software development since that alone can have a lot of impact on the results, and effective cost and time estimations may go totally waste if the human resources are not planned and managed effectively. Secondly, the reasons mentioned related to the software engineering principles may be resolved when the needs are correctly identified. Correct identification would then make it easier to identify the best practices that can be applied because one process that might be suitable for one organization may not be most suitable for another.
Therefore to make a successful product a combination of Process and Technicalities will be required under the umbrella of a well-defined process.
Having talked about the Software process overall, it is important to identify and relate the role software testing plays not only in producing quality software but also maneuvering the overall process.
The computer society defines testing as follows: “Testing -- A verification method that applies a controlled set of conditions and stimuli for the purpose of finding errors. This is the most desirable method of verifying the functional and performance requirements. Test results are documented proof that requirements were met and can be repeated. The resulting data can be reviewed by all concerned for confirmation of capabilities.”
There may be many definitions of software testing and many which appeal to us from time to time, but its best to start by defining testing and then move on depending on the requirements or needs.
When we stop testing?
stop testing these are the main factors.
1. Reduce in defects.
2. Increase in Testing cost.
3. Delivary dates.
We need to check that
1) Whether all the Bugs which were Assigned to developers
have been fixed .
2) All the documents pertaining to testing have been
prepared.
3) all the bugs which were in Previous releases have been
retested .Product Based Testing versus Project Based Testing
Product Based Testing versus Project Based Testing
Before we delve into the differences, for a better clarity, I would like
to explain what is a software product and a software project.
Software product: A software application that is developed by a company
with its own budget. The requirements are driven by market surveys. The
developed product is then sold to different customers with licenses.
Example for software products: Tally (by TCS), Acrobat reader/writer
(Adobe), Internet Explorer (MS), Finnacle (Infosys), Windows (MS), QTP
(HP) etc.
Software project: A software application that is developed by a company
with the budget from a customer. In fact, the customer gives order to
develop some software that helps him in his business. Here, the
requirements come from the customer.
Example for software projects: A separate application ordered by a
manufacturing company to maintain its office inventory etc. This
application is used only by this company and no one else.
With the above insights, we will now discuss the differences.
As an end tester, there will not be much difference in testing either a
product or a project. It is test scenarios and test cases, and
requirements everywhere. However, here below are some differences
between a product and a project, and differences from a testing
perspective:
01. For a project, test plan is a must. All the
documents related to that are to be prepared. For a product, test plan
would have been made long time back. It is at max updated.
02. In project, client has to approve the test plan and test cases, and sign them off. In product it is not necessary.
03. In project, tester directly interacts with the client. In a product, tester interacts with the FD team or business analysts.
04. In project, the deadlines are not flexible. In product testing, deadlines are flexible.
05. In project client hold the authority on the developed code. In product, client doesn't hold the ultimate authority on the code.
06. The budget for development of the project is given by the customer in case of project development. In case of product, the budget is given by the own company.
07. The features in a project are always new. However, in Product, the basic features remain same, and only a few new features will be added, or few existing features will be modified.
08. Because of point #6, more regression testing needs to be done in case of a product, and less in case of a project.
09. Since a product runs for years, test automation saves lot of effort, where as in case of projects, it depends on the duration of the project.
10. Usually, a project complies to a small environment, as specified by the client. So, testing only on the specified environment is sufficient. A product can be installed on a number of OS and other environment parameters, depending on the end user. So, usually, more compatibility testing needs to be done in case of product.
11. A project is used by the specific client for the specific purpose only. Hence tester needs to test only in that end user’s perspective. In case of a product, the same product can be used by a variety of clients. (For example, the same Enterprise Incentive Management application can be used by Pharma clients, Insurance clients etc). So, tester needs to consider all types of potential users and their usage and needs to test accordingly.
12. Licensing comes into picture in case of a product. Thus scenarios related types of license, their registration and expiry etc needs to be tested for a product. Licensing does not exist for a project.
13. Test planning depends on the software development life cycle. Usually, it will be different for a project and a product.
14. Chances are very high to get onsite opportunities for the tester working in a project. Chances are very less in case of a tester working on a product.
15. Economic recession badly hits a software project. The customer may halt or stop the project, in which case, the test engineer may lose the job sometimes. In case of a product, a short term (0-1year) recession may not hit the engineer, as the company keeps adding the new requirements. In fact, the test engineer may get more work, if the company tries to add some innovative requirements to lure the customers into buying their product.
16. In case of a project, competitors do not come into picture, except at the senior level management. In case of a product, the tester also should consider the competitive products while testing. Sometimes, the tester needs to evaluate the performance against competitors' products. Behavior of the product with the competitors' products coexisting on the same machine needs to be considered. Also, tester needs to check any violation of the copyrights.
02. In project, client has to approve the test plan and test cases, and sign them off. In product it is not necessary.
03. In project, tester directly interacts with the client. In a product, tester interacts with the FD team or business analysts.
04. In project, the deadlines are not flexible. In product testing, deadlines are flexible.
05. In project client hold the authority on the developed code. In product, client doesn't hold the ultimate authority on the code.
06. The budget for development of the project is given by the customer in case of project development. In case of product, the budget is given by the own company.
07. The features in a project are always new. However, in Product, the basic features remain same, and only a few new features will be added, or few existing features will be modified.
08. Because of point #6, more regression testing needs to be done in case of a product, and less in case of a project.
09. Since a product runs for years, test automation saves lot of effort, where as in case of projects, it depends on the duration of the project.
10. Usually, a project complies to a small environment, as specified by the client. So, testing only on the specified environment is sufficient. A product can be installed on a number of OS and other environment parameters, depending on the end user. So, usually, more compatibility testing needs to be done in case of product.
11. A project is used by the specific client for the specific purpose only. Hence tester needs to test only in that end user’s perspective. In case of a product, the same product can be used by a variety of clients. (For example, the same Enterprise Incentive Management application can be used by Pharma clients, Insurance clients etc). So, tester needs to consider all types of potential users and their usage and needs to test accordingly.
12. Licensing comes into picture in case of a product. Thus scenarios related types of license, their registration and expiry etc needs to be tested for a product. Licensing does not exist for a project.
13. Test planning depends on the software development life cycle. Usually, it will be different for a project and a product.
14. Chances are very high to get onsite opportunities for the tester working in a project. Chances are very less in case of a tester working on a product.
15. Economic recession badly hits a software project. The customer may halt or stop the project, in which case, the test engineer may lose the job sometimes. In case of a product, a short term (0-1year) recession may not hit the engineer, as the company keeps adding the new requirements. In fact, the test engineer may get more work, if the company tries to add some innovative requirements to lure the customers into buying their product.
16. In case of a project, competitors do not come into picture, except at the senior level management. In case of a product, the tester also should consider the competitive products while testing. Sometimes, the tester needs to evaluate the performance against competitors' products. Behavior of the product with the competitors' products coexisting on the same machine needs to be considered. Also, tester needs to check any violation of the copyrights.
Performance Testing
Performance testing is the process of determining the speed or effectiveness of a computer, network, software program
or device. This process can involve quantitative tests done in a lab, such as measuring the response time or
the number of MIPS (millions
of instructions per second) at which a system functions. Qualitative attributes such as reliability, scalability and
interoperability
may also be evaluated. Performance testing is often done in conjunction with stress
testing.
Performance testing can verify that a system meets the specifications claimed by its manufacturer or vendor. The process can compare two or more devices or programs in terms of parameters such as speed, data transfer rate, bandwidth, throughput,, efficiency or reliability.
Performance testing can also be used as a diagnostic aid in locating communications bottlenecks. Often a system will work much better if a problem is resolved at a single point or in a single component. For example, even the fastest computer will function poorly on today's Web if the connection occurs at only 40 to 50 Kbps (kilobits per second).
Slow data transfer rate may be inherent in hardware but can also result from software-related problems, such as:
Performance testing can verify that a system meets the specifications claimed by its manufacturer or vendor. The process can compare two or more devices or programs in terms of parameters such as speed, data transfer rate, bandwidth, throughput,, efficiency or reliability.
Performance testing can also be used as a diagnostic aid in locating communications bottlenecks. Often a system will work much better if a problem is resolved at a single point or in a single component. For example, even the fastest computer will function poorly on today's Web if the connection occurs at only 40 to 50 Kbps (kilobits per second).
Slow data transfer rate may be inherent in hardware but can also result from software-related problems, such as:
- Too many applications running at the same time
- A corrupted file in a Web browser
- A security exploit
- Heavy-handed antivirus software
- The existence of active malware on the hard disk.
| To explore how performance testing is used in the enterprise, here are some additional resources for learning about performance testing: |
| What is performance testing? Determining what exactly performance testing is proves to be more difficult than you'd expect. Testing expert Scott Barber attempts to pinpoint a definition while recognizing that it may be impossible for the industry to settle on one set explanation. |
| Software testing fundamentals: Performance testing: Software performance testing is crucial to software development and very easy to mess up. These tips and expert opinions illustrate how to conduct performance tests effectively. |
| Three tips for successful application performance testing: Testing database-backed applications for performance can be a daunting task. But you can make it easier on yourself if you follow these three tips. |
Friday, November 11, 2011
QC(Quality Control)
Quality control (QC) is a procedure or set of procedures intended to ensure that a manufactured product or performed service adheres to a defined set of quality criteria or meets the requirements of the client or customer. QC is similar to, but not identical with, quality assurance (QA). QA is defined as a procedure or set of procedures intended to ensure that a product or service under development (before work is complete, as opposed to afterwards) meets specified requirements. QA is sometimes expressed together with QC as a single expression, quality assurance and control (QA/QC).
In order to implement an effective QC program, an enterprise must first decide which specific standards the product or service must meet. Then the extent of QC actions must be determined (for example, the percentage of units to be tested from each lot). Next, real-world data must be collected (for example, the percentage of units that fail) and the results reported to management personnel. After this, corrective action must be decided upon and taken (for example, defective units must be repaired or rejected and poor service repeated at no charge until the customer is satisfied). If too many unit failures or instances of poor service occur, a plan must be devised to improve the production or service process and then that plan must be put into action. Finally, the QC process must be ongoing to ensure that remedial efforts, if required, have produced satisfactory results and to immediately detect recurrences or new instances of trouble.
Something about QTP
1.0 INTRODUCTION
Mercury Quick Test Professional 8.0 provides the industry’s best solution for functional test and regression test automation - addressing every major software application and environment. This next-generation automated testing solution deploys the concept of Keyword-driven testing to radically simplify test creation and maintenance. Unique to Quick Test Professional’s Keyword-driven approach, test automation experts have full access to the underlying test and object properties, via an integrated scripting and debugging environment that is round-trip synchronized with the Keyword View.
Quick Test Professional 8.0 satisfies the needs of both technical and non-technical users. It enables you to deploy higher-quality applications faster, cheaper, and with less risk. It empowers the entire testing team to create sophisticated test suites with minimal training.
Advantages:
• Empower the entire team to create sophisticated test suites with minimal training
• Ensure correct functionality across all environments, data sets, and business processes
• Fully document and replicate defects for developers, enabling them to fix defects faster and meet production deadlines
• Easily regression-test ever-changing applications and environments
• Become a key player in enabling the organization to deliver quality products and services, and improve revenues and profitability
New Features in QTP 8.0
FEATURE USE
Keyword View Lets you easily build and maintain tests without writing VBScripts
Auto-Documentation Provides improved test clarity and the ability to view test steps in plain English
Step Generator Allows you to quickly insert custom-built functions into your tests
Enhanced Expert View Provides greater efficiency when generalizing test components
Action Parameters Allows you to generalize testing actions for greater reusability
Custom Reports Enables you to create custom reports for your unique needs
Unicode Support Lets you test global deployments of your enterprise applications
2.0 RECORDING A SESSION
QuickTest records the operations we perform, displays them as steps in the Keyword View, and generates scripts in the expert view. Each test in Quick test includes a single action. Multiple actions can be included when needed.
• Before recording a test see to that all other browsers are closed. Choose how to open the application. This can be done as follows:
Go to Test->Record & Run Settings->web.
If the page is already open select the ‘Record and run on any open web browser’ option. If you want to open the page automatically select the ‘Open the following browser when record and run session begins’ option and set the Url of the page you want to record.
• Click the Record button or choose Test > Record.
• Navigate through the application or Web site. QuickTest records each step performed and displays it in the Keyword View and Expert View.
• When you complete your recording, click the Stop button or choose Test > Stop.
• Click the Save button to save the test.
Example:
While recording the home page of Google the following code is
generated.
Browser("Google").Page("Google").WebEdit("Search").Set "QTP "
Browser("Google ").Page("Google").WebEdit("Search").Submit
Browser("Google").Page("GoogleSearch: QTP").Link("QTP").Click
Browser("Google ").Page("QTP").Sync
RECORDING MODES
Quick test supports the following recording modes:
a. Normal: recognizes the objects in the application irrespective of their location in the screen.
b. Analog: records the exact keyboard and mouse operations with respect to the screen coordinates or the application window.
c. Low level: records any object irrespective of support from QTP. Recognizes all run time objects as windows objects. It is used when an object is not identified by Quick test.
By default the normal recording mode is enabled.
3.0 RUNNING A SESSION
When you run a test, QuickTest performs the steps you recorded on the application.
• The Run option can be used to run the test from start to end.
• The Run from Step option in the Test menu is used to run the test from a selected step to the end of the current action, if running from the Expert View, or to the end of the test , if running from the Keyword View. Thus it enables us to check a specific part of the application or to confirm that a certain part of the test runs correctly.
• The Update Run option in the Test menu is used to update the Active screens, Checkpoints and the test object descriptions. While recording, Quick Test saves the snapshots of the application as Active screens which can be used later to set Checkpoints and output values.
• The Pause option in the Debug menu is used to temporarily suspend the run. To resume running a paused test, click the Run button.
• The StepInto(F11) option in the Debug menu is used to run the current line of the test.
• The Insert\Remove Breakpoint(F9) option in the Debug menu is used to stop a test run at a pre-determined place in a test. A breakpoint is indicated by a red-colored hand in the left margin of the test window. The test run is paused when it reaches the breakpoint, before executing the step. You can examine the effects of the test run up to the breakpoint, make any necessary changes, and then continue running the test from the breakpoint.
• The DebugViewer option in the View menu is used to view, set, or modify the current value of objects or variables in the test,when a test stops at a breakpoint.
After a test run, the results are displayed in the Test Results window.If the window is not already open choose Test->Results.The Test result tree can be collapsed and expanded. Iterations, actions, and steps that contain checkpoints are marked Passed or Failed in the bottom right part of the Test Results window and are identified by the icon or in the tree pane.
To add details in the Test results window Reporter event is used. The following line of code can be used.
Reporter.ReportEvent 0, Search, “Search Successful"
The first argument (0 or 1) represents the Event status.0 and 1 represent pass and fail respectively. The second argument indicates the step name and the third gives details about the executed test.
4.0 ACTIONS
A test is composed of actions or logical sections. The steps we add to the test are added within the test’s actions. By default, each test begins with a single action. Dividing a test into actions helps us to streamline the testing process. When we run a test with multiple actions, the Test Results are divided by actions so that we can view the detailed results for each action individually. Each action has its own sheet in the Data Table so that we can insert data that applies only to that action.
Actions can be of three types:
• Non-re-usable: Action can be used in the local test, only once.
• Reusable: Action can be used in the local test, multiple times.
• External: These are reusable actions created in another test. This can be of two types. If a call to an external action is used the action is read only in the calling test. But, any existing action can be inserted as a copy of the original action. In this case, we can modify this copy of the external action in the calling test.
Actions on Quick Test Window (Keyword View)
Actions Tool Bar contains buttons and a list of actions, enabling us to view the details of an individual action or the entire test flow. The test flow displays the overall flow of the test with all the actions in the test.
There are two buttons on the Actions Tool Bar, i.e. BACK and SHOW, as shown below.
Actions List Back Show
The Action Tool Bar will be visible, only when, we have one or more external/reusable actions in our test. If it is invisible, use View Tool Bars Action to display it.
4.1 Creating a new action
1) Click the step after which you want to insert the new action.
2) Choose Insert > New Action or click the New Action
button. The Insert New Action dialog box opens. (In QTP 8.0, Insert Call to New Action)
3) Type a new action name or accept the default name.
4) Add a description of the action.
5) Select Reusable Action to make it reusable. This can be
modified at a later time in the Action properties dialog box.
6) To insert a new action at the end of the test, check the At the end of the test checkbox. To insert the new action within the action of the currently selected step, select After the current step.
7) Click OK.
4.2 Inserting an existing action
We can insert an existing action by inserting a copy of the action, or by inserting a call to the original action.
a) Inserting calls to an action makes it easier to maintain tests, because when an object or procedure in the application changes, it needs to be updated only once, in the original action.
b) When we insert a copy of an action into a test, the action is copied in its entirety, including checkpoints, parameterization, and the corresponding action tab in the Data Table. The action is inserted into the test as an independent, non-reusable action (even if the original action was reusable). Once the action is copied into the test, we can add to, delete from, or modify the action. Any changes we make to this action after inserting it affect only this action, and changes to the original action do not affect the inserted action. We can insert copies of both reusable and non-reusable actions.
Select an existing action, and choose:
InsertCall to Copy of an action / Call to Existing Action as required Use the Browse button to choose the action select the location Click OK.
4.3 Nesting Actions
Running an Action within an action is nesting. The following are the uses of nesting actions.
• Helps maintaining the modularity of the test
• Help running one action or another based on the results of a conditional statement
• To insert a nested action, follow the same procedure for inserting a new Action, with, select after the current step as 6th step.
4.4 Splitting Actions
To split an existing action:
1) Select the step with which the new action should begin.
2) Choose StepSplit Action. The following window appears:
• If we select ‘Independent of each other’ option: it creates 2 independent actions, with second action beginning with the selected step.
• If we select ‘Nested’ option: It creates two actions, with first one calling the second. (A Parent-Child relationship).
3) We can also change the Names and Descriptions of these actions.
4.5 Exiting an Action
There are three types of Exit Action statements:
• ExitAction - Exits the current action, regardless of its iteration attributes.
• ExitActionIteration - Exits the current iteration of the action.
• ExitRun - Exits the test, regardless of its iteration attributes.
• ExitGlobalIteration - Exits the current global iteration.
5.0 OBJECT MANAGEMENT
Quick Test identifies objects of two types
• Test Objects: Objects in the test that represent objects in the application or website that are created and maintained by QTP.
• Run Time Objects: Objects in the application that are created and maintained by the Browser.
Three object management tools are available to maintain both the test and runtime objects in the test.
5.1 Object Identification
It is used to set the properties used to identify an object. Each object has mandatory and assistive properties which are used to identify them. For example, from the figure below, the mandatory properties used to identify an ActiveX button object are caption and progid. Thus an ActiveX button is always identified using these two properties. In case these properties are not enough for identifying the object Quick Test uses the assistive properties to do the same. We can modify these properties using the Add\Remove button. Smart Identification is used to identify the object if the learned properties are not sufficient.
5.2 Object Repository
All objects recorded for the test are stored in the repository. The Object Repository displays all objects in the current action or the entire test. The Object Repository can be used to view or modify the properties of any object in the reposirory or to add new objects to the repository. An object in the application can be highlighted using the Highlight option. A temporary frame appears around the object causing it to flash. But the application must be open and the object should be visible in the page. The object spy can also be accessed from the Repository.
Set the object repository path from Test->Settings->Resource Tab. Select the repository file with the extension .tsr. If the repository file is not available create a file with extension .tsr. The repository path must be set before starting recording.
The Object Repository can be Per Action or Shared.
• The shared repository can be used by multiple actions of the same test or by actions from different tests. Test object properties are prone to frequent updation. While adding existing actions, we can copy an action using the same Object Repository and Call actions using the same Object Repository, or Object Repository per action mode
• Per Action object repository is used by one or very few tests.Test object properties are modified less frequently.While adding existing actions, if we are using different object repositories for different actions (One repository per action) then we can copy or call actions from tests using Object Repository per Action mode.
5.3 Object Spy
It can be used to view the properties and values of an object in any open application. Click the pointing hand to select the object in the application. The object’s properties (Test object properties and Run-Time object properties) and methods can be identified. The object’s hierarchy tree is also displayed. To perform other events such as mouse clicks or window focus hold the CTRL key.
6.0 CHECKPOINTS
A checkpoint is a verification point that compares a current value for a specified property with the expected value for that property. Thus it ensures proper functionality of the objects in the application. When you add a checkpoint for an object a statement containing Check Checkpoint is added in the Expert view. Checkpoints can be added in the following ways.
• During Recording: In the Keyword View or Expert View, choose Insert
->Checkpoint option to select a type of checkpoint and select the object for which the checkpoint is to be added.
• During Editing: Right click the object in the Active screen and select the type of checkpoint to be added.
After selecting the object, add the property that is to be checked. For example, for a standard checkpoint on a radio button for the property ‘selected’ checks whether the radio button is selected or not. Checkpoints can also be placed in the Keyword view. Right click the object in the keyword view and insert the required checkpoint.
Example:
Consider inserting a checkpoint for the Search textbox in the Home page of Google. The following code is generated.
Browser ("Google").Page ("Google").WebEdit ("Search").Check CheckPoint ("Search")
If you want to retrieve value from the checkpoint, use parenthesis around the checkpoint argument.
TYPES OF CHECKPOINT
TYPES DESCRIPTION
Standard CheckPoint
It checks the property value of an object in your application or Web page. It checks a variety of objects such as buttons, radio buttons, combo boxes, lists, etc.
Image CheckPoint
It checks the value of an image in the application. We can create an image checkPoint by inserting a standard checkPoint on the image object.
Bitmap CheckPoint
It checks an area of the application as a bitmap.To create a bitmap checkpoint of multiple objects, select the highest level object that includes all the objects to include in the bitmap checkpoint.
Text CheckPoint
It checks whether the text string is displayed in the appropriate place in your application or on a Web page
Text Area CheckPoint
It checks whether the text string is displayed within the defined area in the application. If the area defined is associated with more than one object, the Object Selection-Text Area Checkpoint Properties dialog box opens.
Table CheckPoint
It checks the information within a table or the table itself. The row or column values can also be checked.
Accessibility CheckPoint
It identifies areas of the Web site that do not conform to the World Wide Web Consortium (W3C) Web Content Accessibility Guidelines.
Page CheckPoint
It checks whether the page is displayed correctly and gives information like number of links, number of images and load time of the page
Database CheckPoint
It checks the contents of a database accessed by the application
XML CheckPoint
It checks the data content of XML documents in XML documents in the application
7.0 OUTPUT VALUES
Output Value is used to retrieve the current value of any object in the application and stores it in a specified location. Output values can be added in the following ways
• During Recording: In the Keyword View or Expert View, choose Insert -> Output Value and select the type of output value and the object for which the value is to be outputted.
• During Editing: Right click the object in the Active screen and select the type of output value to be added.If the location clicked is associated with more than one object, then the Object Selection - Output Value Properties dialog box opens. From here select the required object.
Types of Output values
We can create the following categories of output values:
• Standard Output Values: to output the property values of most objects like editbox,button,radio button,list box,etc.
• Text Output Values: to output text strings displayed in the application. When creating a text output value, we can output a part of the object's text. The text before and after the output text can also specified.
• Text Area Output Values: to output text strings displayed within a defined area of the application. We can also output a part of the object’s test.
• Database Output Values: to output the contents of database cells, based on the results of a query on the database. We can create output values from the entire contents of the result set, or from a part of it.
• XML Output Values: to output the values of XML elements and attributes in XML documents.
Example
Browser("Google").Page("Google").WebEdit("Search").Set "QTP"
Browser("Google").Page("Google").WebEdit("Search").Output CheckPoint("Search")
Browser("Google").Page("Google").WebEdit("Search").Submit
Browser("Google ").Page("Google Search: QTP").Link("QTP").Click
Browser("Google ").Page("QTP").Sync
8.0 PARAMETERIZATION
A parameter is a variable that is assigned a value from an external data source at run time. We use parameterization when we want to change the value of properties at run time. Parameterization can be done in three ways using Quick Test.
• Datatable
• Environment variables
• Random numbers
A property of an object can be parameterised from the object repository.Select the property to be parameterised and check the Parameter option from the configure vlue frame and enter the value in the datatable column.
8.1 DataTable Parameters
The test runs once for each line of data in the DataTable. Each iteration takes a different value from the datatable. To run selected rows in the datatable choose the Run tab from Test-Settings and specify an option in the Datatable iterations frame.
Example
Consider parameterising the search string in the home page of Google.Each time you want to search for a different string. Enter the search string in the datatable and change the code as follows
Browser("Google").Page("Google").WebEdit("Search").Set
Datatable.Value("SearchString")
Browser("Google").Page("Google").WebEdit("Search").Submit
The datatable contains the searchstrings for search. The datatable has two rows and thus the test runs for two iterations.We can import data for the datatable from an external source such as Excel. Choose the resources tab from Test->Settings and select Other location in the Datatable frame and specify the path of the Excel file.
8.2 Environment variable Parameters
The Environment variables can have Quick Test generated values or values supplied from external files. We can add environment variables from Test->Settings->Environment tab. Choose User-defined from the variable type. Click New to create your own internal variables or Click Export to retrieve values from external sources.
8.3 Random number Parameters
It enables us to use random numbers as values in the test. We can specify the range from which the random number is generated. By default, the random number range is between 0 and 100.
Subscribe to:
Posts (Atom)
Popular Posts
-
Story of how a hang becomes a crash (because testers love reporting crashes) I am doing my first exploratory testing workshop for...
-
Java Test Tools Arquillian - Arquillian from JBoss enables you to test Java business logic in a remote or embedded container. Alternatively...
