Software Testing FAQS

Q: What is verification?
A: Verification ensures the product is designed to deliver all functionality to the customer. It typically involves reviews and meetings to evaluate documents, plans, code, requirements, and specifications. This can be done with checklists, issues lists, walkthroughs and inspection meetings.

Q: What is validation?
A: Validation ensures that functionality, as defined in requirements, is the intended behavior of the product; validation typically involves actual testing and takes place after verifications are completed. Validation takes place during or at the end of the development process.

Q: What is the difference between verification and validation?
A: 1. Verification takes place before validation, and not vice versa.
2. Verification evaluates documents, plans, code, requirements, and specifications. Validation, on the other hand, evaluates the product itself.
3. The inputs of verification are checklists, issues lists, walkthroughs and inspection meetings, reviews and meetings. The input of validation, on the other hand, is the actual testing of an actual product.
4. The output of verification is a nearly perfect set of documents, plans, specifications, and requirements document. The output of validation, on the other hand, is a nearly perfect actual product.

Q: What is a walkthrough?
A: A walkthrough is an informal meeting for evaluation or informational purposes. A walkthrough is also a process at an abstract level. It’s the process of inspecting software code by following paths through the code (as determined by input conditions and choices made along the way). The purpose of code walkthroughs is to ensure the code fits the purpose. Walkthroughs also offer opportunities to assess an individual’s or team’s competency. A walkthrough is a static analysis technique in which a programmer leads participants through a segment of documentation or code, and the participants ask questions, and make comments about possible errors, violations of development standards, and other issues.

Q: Software QA: What is an inspection?
A: In software QA, an inspection is a formal meeting, more formalized than a walkthrough and typically consists of 3-10 people including a moderator, reader (the author of whatever is being reviewed) and a recorder (to make notes in the document). The subject of the inspection is typically a document, such as a requirements document or a test plan. The purpose of an inspection is to find problems and see what is missing, not to fix anything. The result of the meeting should be documented in a written report. Attendees should prepare for this type of meeting by reading through the document, before the meeting starts; most problems are found during this preparation. Preparation for inspections is difficult, but is one of the most cost-effective methods of ensuring quality, since bug prevention (in software development) is more cost effective than bug detection.

Q: Software QA: What is quality?
A: Quality software is software that is reasonably bug-free, delivered on time and within budget, meets requirements and expectations and is maintainable. However, quality is a subjective term. Quality depends on who the customer is and their overall influence in the scheme of things. Customers of a software development project include end-users, customer acceptance test engineers, testers, customer contract officers, customer management, the development organization’s management, test engineers, testers, salespeople, software engineers, stockholders and accountants. Each type of customer will have his or her own slant on quality. The accounting department might define quality in terms of profits, while an end-user might define quality as user friendly and bug free.

Q: What is quality assurance (QA)?
A: Quality Assurance (QA) ensures all parties concerned with the project adhere to the process and procedures, standards and templates and test readiness reviews. QA depends on clients and projects, team leads or managers, feedback to developers and communication among customers, managers, developers’ test engineers and testers.

Q: What is software quality assurance?
A: Software Quality Assurance, is oriented to *prevention*. It involves the entire software development process. Prevention is monitoring and improving the process, making sure any agreed-upon standards and procedures are followed and ensuring problems are found and dealt with. Software Testing, is also oriented to *detection*. Testing involves the operation of a system or application under controlled conditions and evaluating the results. Organizations vary considerably in how they assign responsibility for QA and testing. Sometimes they’re the combined responsibility of one group or individual. Also common are project teams, which include a mix of test engineers, testers and developers who work closely together, with overall QA processes monitored by project managers. It depends on what best fits your organization’s size and business structure.

Q: What is good code?
A: A good code is code that works, is free of bugs and is readable and maintainable. Organizations usually have coding standards all developers should adhere to, but every programmer and software engineer has different ideas about what is best and what are too many or too few rules. We need to keep in mind that excessive use of rules can stifle both productivity and creativity. Peer reviews and code analysis tools can be used to check for problems and enforce standards.

Q: What is good design?
A: Design could mean to many things, but often refers to functional design or internal design. Good functional design is indicated by software functionality can be traced back to customer and end-user requirements. Good internal design is indicated by software code whose overall structure is clear, understandable, easily modifiable and maintainable; is robust with sufficient error handling and status logging capability; and works correctly when implemented.

Q: What makes a good test engineer?
A: Good test engineers have a “test to break” attitude. We, good test engineers, take the point of view of the customer, have a strong desire for quality and an attention to detail. Tact and diplomacy are useful in maintaining a cooperative relationship with developers and an ability to communicate with both technical and non-technical people. Previous software development experience is also helpful as it provides a deeper understanding of the software development process, gives the test engineer an appreciation for the developers’ point of view and reduces the learning curve in automated test tool programming.

Q: What is software life cycle?
A: Software life cycle begins when a software product is first conceived and ends when it is no longer in use. It includes phases like initial concept, requirements analysis, functional design, internal design, documentation planning, test planning, coding, document preparation, integration, testing, maintenance, updates, re-testing and phase-out.

Q: How do you introduce a new software QA process?
A: It depends on the size of the organization and the risks involved. For large organizations with high-risk projects, a serious management buy-in is required and a formalized QA process is necessary. For medium size organizations with lower risk projects, management and organizational buy-in and a slower, step-by-step process is required. Generally speaking, QA processes should be balanced with productivity, in order to keep any bureaucracy from getting out of hand. For smaller groups or projects, an ad-hoc process is more appropriate. A lot depends on team leads and managers, feedback to developers and good communication is essential among customers, managers, developers, test engineers and testers. Regardless the size of the company, the greatest value for effort is in managing requirement processes, where the goal is requirements that are clear, complete and testable.

Q: Why are there so many software bugs?
A: Generally speaking, there are bugs in software because of unclear requirements, software complexity, programming errors, changes in requirements, errors made in bug tracking, time pressure, poorly documented code and/or bugs in tools used in software development.
• There are unclear software requirements because there is miscommunication as to what the software should or shouldn’t do.
• Software complexity. All of the followings contribute to the exponential growth in software and system complexity: Windows interfaces, client-server and distributed applications, data communications, enormous relational databases and the sheer size of applications.
• Programming errors occur because programmers and software engineers, like everyone else, can make mistakes.
• As to changing requirements, in some fast-changing business environments, continuously modified requirements are a fact of life. Sometimes customers do not understand the effects of changes, or understand them but request them anyway. And the changes require redesign of the software, rescheduling of resources and some of the work already completed have to be redone or discarded and hardware requirements can be effected, too.
• Bug tracking can result in errors because the complexity of keeping track of changes can result in errors, too.
• Time pressures can cause problems, because scheduling of software projects is not easy and it often requires a lot of guesswork and when deadlines loom and the crunch comes, mistakes will be made.
• Code documentation is tough to maintain and it is also tough to modify code that is poorly documented. The result is bugs. Sometimes there is no incentive for programmers and software engineers to document their code and write clearly documented, understandable code. Sometimes developers get kudos for quickly turning out code, or programmers and software engineers feel they cannot have job security if everyone can understand the code they write, or they believe if the code was hard to write, it should be hard to read.
• Software development tools , including visual tools, class libraries, compilers, scripting tools, can introduce their own bugs. Other times the tools are poorly documented, which can create additional bugs.

Q: Give me five common problems that occur during software development!
A: Poorly written requirements, unrealistic schedules, inadequate testing, adding new features after development is underway and poor communication.
1. Requirements are poorly written when requirements are unclear, incomplete, too general, or not testable; therefore there will be problems.
2. The schedule is unrealistic if too much work is crammed in too little time.
3. Software testing is inadequate if none knows whether or not the software is any good until customers complain or the system crashes.
4. It’s extremely common that new features are added after development is underway.
5. Miscommunication either means the developers don’t know what is needed, or customers have unrealistic expectations and therefore problems are guaranteed.

Q: Give me five solutions to problems that occur during software development!
A: Solid requirements, realistic schedules, adequate testing, firm requirements and good communication.
1. Ensure the requirements are solid, clear, complete, detailed, cohesive, attainable and testable. All players should agree to requirements. Use prototypes to help nail down requirements.
2. Have schedules that are realistic. Allow adequate time for planning, design, testing, bug fixing, re-testing, changes and documentation. Personnel should be able to complete the project without burning out.
3. Do testing that is adequate. Start testing early on, re-test after fixes or changes, and plan for sufficient time for both testing and bug fixing.
4. Avoid new features. Stick to initial requirements as much as possible. Be prepared to defend design against changes and additions, once development has begun and be prepared to explain consequences. If changes are necessary, ensure they’re adequately reflected in related schedule changes. Use prototypes early on so customers’ expectations are clarified and customers can see what to expect; this will minimize changes later on.
5. Communicate. Require walkthroughs and inspections when appropriate; make extensive use of e-mail, networked bug-tracking tools, tools of change management. Ensure documentation is available and up-to-date. Use documentation that is electronic, not paper. Promote teamwork and cooperation.
Q: Do automated testing tools make testing easier?
A: Yes and no. For larger projects, or ongoing long-term projects, they can be valuable. But for small projects, the time needed to learn and implement them is usually not worthwhile. A common type of automated tool is the record/playback type. For example, a test engineer clicks through all combinations of menu choices, dialog box choices, buttons, etc. in a GUI and has an automated testing tool record and log the results. The recording is typically in the form of text, based on a scripting language that the testing tool can interpret. If a change is made (e.g. new buttons are added, or some underlying code in the application is changed), the application is then re-tested by just playing back the recorded actions and compared to the logged results in order to check effects of the change. One problem with such tools is that if there are continual changes to the product being tested, the recordings have to be changed so often that it becomes a very time-consuming task to continuously update the scripts. Another problem with such tools is the interpretation of the results (screens, data, logs, etc.) that can be a time-consuming task.

Q: What software tools are in demand these days?
A: The software tools currently in demand include LabView, LoadRunner, Rational Tools, and WinRunner — and especially the LoadRunner and Rational Toolset — but there are many others, depending on the end client, and their needs, and preferences

Q: What makes a good QA/Test Manager?
A: QA/Test Managers are familiar with the software development process; able to maintain enthusiasm of their team and promote a positive atmosphere; able to promote teamwork to increase productivity; able to promote cooperation between Software and Test/QA Engineers, have the people skills needed to promote improvements in QA processes, have the ability to withstand pressures and say *no* to other managers when quality is insufficient or QA processes are not being adhered to; able to communicate with technical and non-technical people; as well as able to run meetings and keep them focused.
Q: What is the role of documentation in QA?
A: Documentation plays a critical role in QA. QA practices should be documented, so that they are repeatable. Specifications, designs, business rules, inspection reports, configurations, code changes, test plans, test cases, bug reports, user manuals should all be documented. Ideally, there should be a system for easily finding and obtaining of documents and determining what document will have a particular piece of information. Use documentation change management, if possible.

Q: What about requirements?
A: Requirement specifications are important and one of the most reliable methods of insuring problems in a complex software project is to have poorly documented requirement specifications. Requirements are the details describing an application’s externally perceived functionality and properties. Requirements should be clear, complete, reasonably detailed, cohesive, attainable and testable. A non-testable requirement would be, for example, “user-friendly”, which is too subjective. A testable requirement would be something such as, “the product shall allow the user to enter their previously-assigned password to access the application”. Care should be taken to involve all of a project’s significant customers in the requirements process. Customers could be in-house or external and could include end-users, customer acceptance test engineers, testers, customer contract officers, customer management, future software maintenance engineers, salespeople and anyone who could later derail the project. If his/her expectations aren’t met, they should be included as a customer, if possible. In some organizations, requirements may end up in high-level project plans, functional specification documents, design documents, or other documents at various levels of detail. No matter what they are called, some type of documentation with detailed requirements will be needed by test engineers in order to properly plan and execute tests. Without such documentation there will be no clear-cut way to determine if a software application is performing correctly.
Q: What is a test plan?
A: A software project test plan is a document that describes the objectives, scope, approach and focus of a software testing effort. The process of preparing a test plan is a useful way to think through the efforts needed to validate the acceptability of a software product. The completed document will help people outside the test group understand the why and how of product validation. It should be thorough enough to be useful, but not so thorough that none outside the test group will be able to read it.

Q: What is a test case?
A: A test case is a document that describes an input, action, or event and its expected result, in order to determine if a feature of an application is working correctly. A test case should contain particulars such as a…
• Test case identifier;
• Test case name;
• Objective;
• Test conditions/setup;
• Input data requirements/steps, and
• Expected results.
Please note, the process of developing test cases can help find problems in the requirements or design of an application, since it requires you to completely think through the operation of the application. For this reason, it is useful to prepare test cases early in the development cycle, if possible.

Q: What should be done after a bug is found?
A: When a bug is found, it needs to be communicated and assigned to developers that can fix it. After the problem is resolved, fixes should be re-tested. Additionally, determinations should be made regarding requirements, software, hardware, safety impact, etc., for regression testing to check the fixes didn’t create other problems elsewhere. If a problem-tracking system is in place, it should encapsulate these determinations. A variety of commercial, problem-tracking/management software tools are available. These tools, with the detailed input of software test engineers, will give the team complete information so developers can understand the bug, get an idea of its severity, reproduce it and fix it.
Q: What if the software is so buggy it can’t be tested at all?
A: In this situation the best bet is to have test engineers go through the process of reporting whatever bugs or problems initially show up, with the focus being on critical bugs. Since this type of problem can severely affect schedules and indicates deeper problems in the software development process, such as insufficient unit testing, insufficient integration testing, poor design, improper build or release procedures, managers should be notified and provided with some documentation as evidence of the problem.
Q: How do you know when to stop testing?
A: This can be difficult to determine. Many modern software applications are so complex and run in such an interdependent environment, that complete testing can never be done. Common factors in deciding when to stop are…
• Deadlines, e.g. release deadlines, testing deadlines;
• Test cases completed with certain percentage passed;
• Test budget has been depleted;
• Coverage of code, functionality, or requirements reaches a specified point;
• Bug rate falls below a certain level; or
• Beta or alpha testing period ends.
Q: What if there isn’t enough time for thorough testing?
A: 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. Use risk analysis to determine where testing should be focused. This requires judgment skills, common sense and experience. The checklist should include answers to the following questions:

• 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?
Q: What if the project isn’t big enough to justify extensive testing?
A: Consider the impact of project errors, not the size of the project. However, if extensive testing is still not justified, risk analysis is again needed and the considerations listed under “What if there isn’t enough time for thorough testing?” do apply. The test engineer then should do “ad hoc” testing, or write up a limited test plan based on the risk analysis.

Q: What can be done if requirements are changing continuously?
A: Work with management early on to understand how requirements might change, so that alternate test plans and strategies can be worked out in advance. It is helpful if the application’s initial design allows for some adaptability, so that later changes do not require redoing the application from scratch. Additionally, try to…
• Ensure the code is well commented and well documented; this makes changes easier for the developers.
• Use rapid prototyping whenever possible; this will help customers feel sure of their requirements and minimize changes.
• In the project’s initial schedule, allow for some extra time to commensurate with probable changes.
• Move new requirements to a ‘Phase 2′ version of an application and use the original requirements for the ‘Phase 1′ version.
• Negotiate to allow only easily implemented new requirements into the project; move more difficult, new requirements into future versions of the application.
• Ensure customers and management understand scheduling impacts, inherent risks and costs of significant requirements changes. Then let management or the customers decide if the changes are warranted; after all, that’s their job.
• Balance the effort put into setting up automated testing with the expected effort required to redo them to deal with changes.
• Design some flexibility into automated test scripts;
• Focus initial automated testing on application aspects that are most likely to remain unchanged;
• Devote appropriate effort to risk analysis of changes, in order to minimize regression-testing needs;
• Design some flexibility into test cases; this is not easily done; the best bet is to minimize the detail in the test cases, or set up only higher-level generic-type test plans;
• Focus less on detailed test plans and test cases and more on ad-hoc testing with an understanding of the added risk this entails.
Q: What if the application has functionality that wasn’t in the requirements?
A: It may take serious effort to determine if an application has significant unexpected or hidden functionality, which it would indicate deeper problems in the software development process. If the functionality isn’t necessary to the purpose of the application, it should be removed, as it may have unknown impacts or dependencies that were not taken into account by the designer or the customer.
If not removed, design information will be needed to determine added testing needs or regression testing needs. Management should be made aware of any significant added risks as a result of the unexpected functionality. If the functionality only affects areas, such as minor improvements in the user interface, it may not be a significant risk.

Q: How is testing affected by object-oriented designs?
A: A well-engineered object-oriented design can make it easier to trace from code to internal design to functional design to requirements. While there will be little affect on black box testing (where an understanding of the internal design of the application is unnecessary), white-box testing can be oriented to the application’s objects. If the application was well designed this can simplify test design.
Q: What is software quality assurance?
A: Software Quality Assurance, when Rob Davis does it, is oriented to *prevention*. It involves the entire software development process. Prevention is monitoring and improving the process, making sure any agreed-upon standards and procedures are followed and ensuring problems are found and dealt with. Software Testing, when performed by Rob Davis, is also oriented to *detection*. Testing involves the operation of a system or application under controlled conditions and evaluating the results. Organizations vary considerably in how they assign responsibility for QA and testing. Sometimes they’re the combined responsibility of one group or individual. Also common are project teams, which include a mix of test engineers, testers and developers who work closely together, with overall QA processes monitored by project managers. It depends on what best fits your organization’s size and business structure.
Q: What is quality assurance?
A: Quality Assurance ensures all parties concerned with the project adhere to the process and procedures, standards and templates and test readiness reviews.
Rob Davis’ QA service depends on the customers and projects. A lot will depend on team leads or managers, feedback to developers and communications among customers, managers, developers’ test engineers and testers.
Q: Process and procedures – why follow them?
A: Detailed and well-written processes and procedures ensure the correct steps are being executed to facilitate a successful completion of a task. They also ensure a process is repeatable. Once Rob Davis has learned and reviewed customer’s business processes and procedures, he will follow them. He will also recommend improvements and/or additions.
Q: What are the different levels of testing?
A: Rob Davis has expertise in testing at all testing levels listed below. At each test level, he documents the results. Each level of testing is either considered black or white box testing.

Q: What is black box testing?
A: Black box testing is functional testing, not based on any knowledge of internal software design or code. Black box testing are based on requirements and functionality.

Q: What is white box testing?
A: White box testing is based on knowledge of the internal logic of an application’s code. Tests are based on coverage of code statements, branches, paths and conditions.

Q: What is unit testing?
A: Unit testing is the first level of dynamic testing and is first the responsibility of developers and then that of the test engineers. Unit testing is performed after the expected test results are met or differences are explainable/acceptable.

Q: What is parallel/audit testing?
A: Parallel/audit testing is testing where the user reconciles the output of the new system to the output of the current system to verify the new system performs the operations correctly.

Q: What is functional testing?
A: Functional testing is black-box type of testing geared to functional requirements of an application. Test engineers *should* perform functional testing.

Q: What is usability testing?
A: Usability testing is testing for ‘user-friendliness’. Clearly this is subjective and depends on the targeted end-user or customer. User interviews, surveys, video recording of user sessions and other techniques can be used. Programmers and developers are usually not appropriate as usability testers.

Q: What is incremental integration testing?
A: Incremental integration testing is continuous testing of an application as new functionality is recommended. This may require that various aspects of an application’s functionality are independent enough to work separately, before all parts of the program are completed, or that test drivers are developed as needed. This type of testing may be performed by programmers, software engineers, or test engineers.

Q: What is integration testing?
A: Upon completion of unit testing, integration testing begins. Integration testing is black box testing. The purpose of integration testing is to ensure distinct components of the application still work in accordance to customer requirements. Test cases are developed with the express purpose of exercising the interfaces between the components. This activity is carried out by the test team.
Integration testing is considered complete, when actual results and expected results are either in line or differences are explainable/acceptable based on client input.
Q: What is system testing?
A: System testing is black box testing, performed by the Test Team, and at the start of the system testing the complete system is configured in a controlled environment. The purpose of system testing is to validate an application’s accuracy and completeness in performing the functions as designed. System testing simulates real life scenarios that occur in a “simulated real life” test environment and test all functions of the system that are required in real life. System testing is deemed complete when actual results and expected results are either in line or differences are explainable or acceptable, based on client input.
Upon completion of integration testing, system testing is started. Before system testing, all unit and integration test results are reviewed by Software QA to ensure all problems have been resolved. For a higher level of testing it is important to understand unresolved problems that originate at unit and integration test levels.
Q: What is end-to-end testing?
A: Similar to system testing, the *macro* end of the test scale is testing a complete application in a situation that mimics real world use, such as interacting with a database, using network communication, or interacting with other hardware, application, or system.
Q: What is regression testing?
A: The objective of regression testing is to ensure the software remains intact. A baseline set of data and scripts is maintained and executed to verify changes introduced during the release have not “undone” any previous code. Expected results from the baseline are compared to results of the software under test. All discrepancies are highlighted and accounted for, before testing proceeds to the next level.
Q: What is sanity testing?
A: Sanity testing is performed whenever cursory testing is sufficient to prove the application is functioning according to specifications. This level of testing is a subset of regression testing. It normally includes a set of core tests of basic GUI functionality to demonstrate connectivity to the database, application servers, printers, etc.

Q51. What is performance testing?
A: Although performance testing is described as a part of system testing, it can be regarded as a distinct level of testing. Performance testing verifies loads, volumes and response times, as defined by requirements.

Q: What is load testing?
A: Load testing is testing an application under heavy loads, such as the testing of a web site under a range of loads to determine at what point the system response time will degrade or fail.

Q: What is installation testing?
A: Installation testing is testing full, partial, upgrade, or install/uninstall processes. The installation test for a release is conducted with the objective of demonstrating production readiness. This test includes the inventory of configuration items, performed by the application’s System Administration, the evaluation of data readiness, and dynamic tests focused on basic system functionality. When necessary, a sanity test is performed, following installation testing.

Q: What is security/penetration testing?
A: Security/penetration testing is testing how well the system is protected against unauthorized internal or external access, or willful damage. This type of testing usually requires sophisticated testing techniques.

Q: What is recovery/error testing?
A: Recovery/error testing is testing how well a system recovers from crashes, hardware failures, or other catastrophic problems.

Q: What is compatibility testing?
A: Compatibility testing is testing how well software performs in a particular hardware, software, operating system, or network environment.

Q: What is comparison testing?
A: Comparison testing is testing that compares software weaknesses and strengths to those of competitors’ products.

Q: What is acceptance testing?
A: Acceptance testing is black box testing that gives the client/customer/project manager the opportunity to verify the system functionality and usability prior to the system being released to production. The acceptance test is the responsibility of the client/customer or project manager, however, it is conducted with the full support of the project team. The test team also works with the client/customer/project manager to develop the acceptance criteria.

Q: What is alpha testing?
A: Alpha testing is testing of an application when development is nearing completion. Minor design changes can still be made as a result of alpha testing. Alpha testing is typically performed by end-users or others, not programmers, software engineers, or test engineers.

Q: What is beta testing?
A: Beta testing is testing an application when development and testing are essentially completed and final bugs and problems need to be found before the final release. Beta testing is typically performed by end-users or others, not programmers, software engineers, or test engineers.
Q: What testing roles are standard on most testing projects?
A: Depending on the organization, the following roles are more or less standard on most testing projects: Testers, Test Engineers, Test/QA Team Lead, Test/QA Manager, System Administrator, Database Administrator, Technical Analyst, Test Build Manager and Test Configuration Manager. Depending on the project, one person may wear more than one hat. For instance, Test Engineers may also wear the hat of Technical Analyst, Test Build Manager and Test Configuration Manager.
Q: What is a Test/QA Team Lead?
A: The Test/QA Team Lead coordinates the testing activity, communicates testing status to management and manages the test team.

Q: What is a Test Engineer?
A: Test Engineers are engineers who specialize in testing. We, test engineers, create test cases, procedures, scripts and generate data. We execute test procedures and scripts, analyze standards of measurements, evaluate results of system/integration/regression testing. We also…
• Speed up the work of the development staff;
• Reduce your organization’s risk of legal liability;
• Give you the evidence that your software is correct and operates properly;
• Improve problem tracking and reporting;
• Maximize the value of your software;
• Maximize the value of the devices that use it;
• Assure the successful launch of your product by discovering bugs and design flaws, before users get discouraged, before shareholders loose their cool and before employees get bogged down;
• Help the work of your development staff, so the development team can devote its time to build up your product;
• Promote continual improvement;
• Provide documentation required by FDA, FAA, other regulatory agencies and your customers;
• Save money by discovering defects ‘early’ in the design process, before failures occur in production, or in the field;
• Save the reputation of your company by discovering bugs and design flaws; before bugs and design flaws damage the reputation of your company.

Q: What is a Database Administrator?
A: Test Build Managers, System Administrators and Database Administrators deliver current software versions to the test environment, install the application’s software and apply software patches, to both the application and the operating system, set-up, maintain and back up test environment hardware. Depending on the project, one person may wear more than one hat. For instance, a Test Engineer may also wear the hat of a Database Administrator.

Q: What is a Technical Analyst?
A: Technical Analysts perform test assessments and validate system/functional test requirements. Depending on the project, one person may wear more than one hat. For instance, Test Engineers may also wear the hat of a Technical Analyst.

Q: What is a Test Configuration Manager?
A: Test Configuration Managers maintain test environments, scripts, software and test data. Depending on the project, one person may wear more than one hat. For instance, Test Engineers may also wear the hat of a Test Configuration Manager.

Q: What is a test schedule?
A: The test schedule is a schedule that identifies all tasks required for a successful testing effort, a schedule of all test activities and resource requirements.

Q: What is software testing methodology?
A: One software testing methodology is the use a three step process of…
1. Creating a test strategy;
2. Creating a test plan/design; and
3. Executing tests.
This methodology can be used and molded to your organization’s needs. Rob Davis believes that using this methodology is important in the development and in ongoing maintenance of his customers’ applications.

Q: What is the general testing process?
A: The general testing process is the creation of a test strategy (which sometimes includes the creation of test cases), creation of a test plan/design (which usually includes test cases and test procedures) and the execution of tests.

Q: How do you create a test strategy?
A: The test strategy is a formal description of how a software product will be tested. A test strategy is developed for all levels of testing, as required. The test team analyzes the requirements, writes the test strategy and reviews the plan with the project team. The test plan may include test cases, conditions, the test environment, a list of related tasks, pass/fail criteria and risk assessment.

Inputs for this process:
• A description of the required hardware and software components, including test tools. This information comes from the test environment, including test tool data.
• A description of roles and responsibilities of the resources required for the test and schedule constraints. This information comes from man-hours and schedules.
• Testing methodology. This is based on known standards.
• Functional and technical requirements of the application. This information comes from requirements, change request, technical and functional design documents.
• Requirements that the system can not provide, e.g. system limitations.
Outputs for this process:
• An approved and signed off test strategy document, test plan, including test cases.
• Testing issues requiring resolution. Usually this requires additional negotiation at the project management level.
Q: How do you create a test plan/design?
A: Test scenarios and/or cases are prepared by reviewing functional requirements of the release and preparing logical groups of functions that can be further broken into test procedures. Test procedures define test conditions, data to be used for testing and expected results, including database updates, file outputs, report results. Generally speaking…
• Test cases and scenarios are designed to represent both typical and unusual situations that may occur in the application.
• Test engineers define unit test requirements and unit test cases. Test engineers also execute unit test cases.
• It is the test team who, with assistance of developers and clients, develops test cases and scenarios for integration and system testing.
• Test scenarios are executed through the use of test procedures or scripts.
• Test procedures or scripts define a series of steps necessary to perform one or more test scenarios.
• Test procedures or scripts include the specific data that will be used for testing the process or transaction.
• Test procedures or scripts may cover multiple test scenarios.
• Test scripts are mapped back to the requirements and traceability matrices are used to ensure each test is within scope.
• Test data is captured and base lined, prior to testing. This data serves as the foundation for unit and system testing and used to exercise system functionality in a controlled environment.
• Some output data is also base-lined for future comparison. Base-lined data is used to support future application maintenance via regression testing.
• A pretest meeting is held to assess the readiness of the application and the environment and data to be tested. A test readiness document is created to indicate the status of the entrance criteria of the release.
Inputs for this process:
• Approved Test Strategy Document.
• Test tools, or automated test tools, if applicable.
• Previously developed scripts, if applicable.
• Test documentation problems uncovered as a result of testing.
• A good understanding of software complexity and module path coverage, derived from general and detailed design documents, e.g. software design document, source code and software complexity data.
Outputs for this process:
• Approved documents of test scenarios, test cases, test conditions and test data.
• Reports of software design issues, given to software developers for correction.
Q: How do you execute tests?
A: Execution of tests is completed by following the test documents in a methodical manner. As each test procedure is performed, an entry is recorded in a test execution log to note the execution of the procedure and whether or not the test procedure uncovered any defects. Checkpoint meetings are held throughout the execution phase. Checkpoint meetings are held daily, if required, to address and discuss testing issues, status and activities.
• The output from the execution of test procedures is known as test results. Test results are evaluated by test engineers to determine whether the expected results have been obtained. All discrepancies/anomalies are logged and discussed with the software team lead, hardware test lead, programmers, software engineers and documented for further investigation and resolution. Every company has a different process for logging and reporting bugs/defects uncovered during testing.
• A pass/fail criteria is used to determine the severity of a problem, and results are recorded in a test summary report. The severity of a problem, found during system testing, is defined in accordance to the customer’s risk assessment and recorded in their selected tracking tool.
• Proposed fixes are delivered to the testing environment, based on the severity of the problem. Fixes are regression tested and flawless fixes are migrated to a new baseline. Following completion of the test, members of the test team prepare a summary report. The summary report is reviewed by the Project Manager, Software QA Manager and/or Test Team Lead.
• After a particular level of testing has been certified, it is the responsibility of the Configuration Manager to coordinate the migration of the release software components to the next test level, as documented in the Configuration Management Plan. The software is only migrated to the production environment after the Project Manager’s formal acceptance.
• The test team reviews test document problems identified during testing, and update documents where appropriate.

Inputs for this process:
• Approved test documents, e.g. Test Plan, Test Cases, Test Procedures.
• Test tools, including automated test tools, if applicable.
• Developed scripts.
• Changes to the design, i.e. Change Request Documents.
• Test data.
• Availability of the test team and project team.
• General and Detailed Design Documents, i.e. Requirements Document, Software Design Document.
• A software that has been migrated to the test environment, i.e. unit tested code, via the Configuration/Build Manager.
• Test Readiness Document.
• Document Updates.
Outputs for this process:
• Log and summary of the test results. Usually this is part of the Test Report. This needs to be approved and signed-off with revised testing deliverables.
• Changes to the code, also known as test fixes.
• Test document problems uncovered as a result of testing. Examples are Requirements document and Design Document problems.
• Reports on software design issues, given to software developers for correction. Examples are bug reports on code issues.
• Formal record of test incidents, usually part of problem tracking.
• Base-lined package, also known as tested source and object code, ready for migration to the next level.
Q: What testing approaches can you tell me about?
A: Each of the followings represents a different testing approach:
• Black box testing,
• White box testing,
• Unit testing,
• Incremental testing,
• Integration testing,
• Functional testing,
• System testing,
• End-to-end testing,
• Sanity testing,
• Regression testing,
• Acceptance testing,
• Load testing,
• Performance testing,
• Usability testing,
• Install/uninstall testing,
• Recovery testing,
• Security testing,
• Compatibility testing,
• Exploratory testing, ad-hoc testing,
• User acceptance testing,
• Comparison testing,
• Alpha testing,
• Beta testing, and
• Mutation testing.
Q: What is stress testing?
A: Stress testing is testing that investigates the behavior of software (and hardware) under extraordinary operating conditions. For example, when a web server is stress tested, testing aims to find out how many users can be on-line, at the same time, without crashing the server. Stress testing tests the stability of a given system or entity. It tests something beyond its normal operational capacity, in order to observe any negative results. For example, a web server is stress tested, using scripts, bots, and various denial of service tools.

Q: What is load testing?
A: Load testing simulates the expected usage of a software program, by simulating multiple users that access the program’s services concurrently. Load testing is most useful and most relevant for multi-user systems, client/server models, including web servers. For example, the load placed on the system is increased above normal usage patterns, in order to test the system’s response at peak loads.
Q: What is the difference between performance testing and load testing?
A: Load testing is a blanket term that is used in many different ways across the professional software testing community. The term, load testing, is often used synonymously with stress testing, performance testing, reliability testing, and volume testing. Load testing generally stops short of stress testing. During stress testing, the load is so great that errors are the expected results, though there is gray area in between stress testing and load testing.

Q: What is the difference between reliability testing and load testing?
A: Load testing is a blanket term that is used in many different ways across the professional software testing community. The term, load testing, is often used synonymously with stress testing, performance testing, reliability testing, and volume testing. Load testing generally stops short of stress testing. During stress testing, the load is so great that errors are the expected results, though there is gray area in between stress testing and load testing.
Q81. What is the difference between volume testing and load testing?
A: Load testing is a blanket term that is used in many different ways across the professional software testing community. The term, load testing, is often used synonymously with stress testing, performance testing, reliability testing, and volume testing. Load testing generally stops short of stress testing. During stress testing, the load is so great that errors are the expected results, though there is gray area in between stress testing and load testing.
Q: What is incremental testing?
A: Incremental testing is partial testing of an incomplete product. The goal of incremental testing is to provide an early feedback to software developers.
Q: What is software testing?
A: Software testing is a process that identifies the correctness, completeness, and quality of software. Actually, testing cannot establish the correctness of software. It can find defects, but cannot prove there are no defects.

Q: What is automated testing?
A: Automated testing is a formally specified and controlled method of formal testing approach.

Q: What is the difference between alpha and beta testing?
A: Alpha testing is performed by in-house developers and software QA personnel. Beta testing is performed by the public, a few select prospective customers, or the general public.
Q: What is clear box testing?
A: Clear box testing is the same as white box testing. It is a testing approach that examines the application’s program structure, and derives test cases from the application’s program logic.
Q: What is boundary value analysis?
A: Boundary value analysis is a technique for test data selection. A test engineer chooses values that lie along data extremes. Boundary values include maximum, minimum, just inside boundaries, just outside boundaries, typical values, and error values. The expectation is that, if a systems works correctly for these extreme or special values, then it will work correctly for all values in between. An effective way to test code, is to exercise it at its natural boundaries.
Q: What is ad hoc testing?
A: Ad hoc testing is a testing approach; it is the least formal testing approach.
Q: What is gamma testing?
A: Gamma testing is testing of software that has all the required features, but it did not go through all the in-house quality checks. Cynics tend to refer to software releases as “gamma testing”.
Q: What is glass box testing?
A: Glass box testing is the same as white box testing. It is a testing approach that examines the application’s program structure, and derives test cases from the application’s program logic.

Q: What is open box testing?
A: Open box testing is same as white box testing. It is a testing approach that examines the application’s program structure, and derives test cases from the application’s program logic.
Q: What is black box testing?
A: Black box testing a type of testing that considers only externally visible behavior. Black box testing considers neither the code itself, nor the “inner workings” of the software.
Q: What is functional testing?
A: Functional testing is same as black box testing. Black box testing a type of testing that considers only externally visible behavior. Black box testing considers neither the code itself, nor the “inner workings” of the software.

Q: What is closed box testing?
A: Closed box testing is same as black box testing. Black box testing a type of testing that considers only externally visible behavior. Black box testing considers neither the code itself, nor the “inner workings” of the software.

Q: What is bottom-up testing?
A: Bottom-up testing is a technique for integration testing. A test engineer creates and uses test drivers for components that have not yet been developed, because, with bottom-up testing, low-level components are tested first. The objective of bottom-up testing is to call low-level components first, for testing
purposes.
Q: What is a software fault?
A: Software faults are hidden programming errors. Software faults are errors in the correctness of the semantics of computer programs.
Q: What is software failure?
A: A software failure occurs when the software does not do what the user expects to see.
Q: What is the difference between a software fault and a software failure?
A: A software failure occurs when the software does not do what the user expects to see. A software fault, on the other hand, is a hidden programming error. A software fault becomes a software failure only when the exact computation conditions are met, and the faulty portion of the code is executed on the CPU. This can occur during normal usage. Or, when the software is ported to a different hardware platform. Or, when the software is ported to a different complier. Or, when the software gets extended.
Q: What is a test engineer?
A: Test engineers are engineers who specialize in testing. We, test engineers, create test cases, procedures, scripts and generate data. We execute test procedures and scripts, analyze standards of measurements, evaluate results of system/integration/regression testing.

Q: What is the role of test engineers?
A: Test engineers speed up the work of the development staff, and reduce the risk of your company’s legal liability. We, test engineers, also give the company the evidence that the software is correct and operates properly. We also improve problem tracking and reporting, maximize the value of the software, and the value of the devices that use it. We also assure the successful launch of the product by discovering bugs and design flaws, before…
users get discouraged, before shareholders loose their cool and before employees get bogged down. We, test engineers help the work of software development staff, so the development team can devote its time to build up the product. We, test engineers also promote continual improvement. They provide documentation required by FDA, FAA, other regulatory agencies, and your customers. We, test engineers save your company money by discovering defects EARLY in the design process, before failures occur in production, or in the field. We save the reputation of your company by discovering bugs and design flaws, before bugs and design flaws damage the reputation of your company.

Q: What is a QA engineer?
A: QA engineers are test engineers, but QA engineers do more than just testing. Good QA engineers understand the entire software development process and how it fits into the business approach and the goals of the organization. Communication skills and the ability to understand various sides of issues are important. We, QA engineers, are successful if people listen to us, if people use our tests, if people think that we’re useful, and if we’re happy doing our work. I would love to see QA departments staffed with experienced software developers who coach development teams to write better code. But I’ve never seen it. Instead of coaching, we, QA engineers, tend to be process people.

Q: What is role of the QA engineer?
A: The QA Engineer’s function is to use the system much like real users would, find all the bugs, find ways to replicate the bugs, submit bug reports to the developers, and to provide feedback to the developers, i.e. tell them if they’ve achieved the desired level of quality.
Q: What are the responsibilities of a QA engineer?
A: Let’s say, an engineer is hired for a small software company’s QA role, and there is no QA team. Should he take responsibility to set up a QA infrastructure/process, testing and quality of the entire product? No, because taking this responsibility is a classic trap that QA people get caught in. Why? Because we QA engineers cannot assure quality. And because QA departments cannot create quality. What we CAN do is to detect lack of quality, and prevent low-quality products from going out the door. What is the solution? We need to drop the QA label, and tell the developers, they are responsible for the quality of their own work. The problem is, sometimes, as soon as the developers learn that there is a test department, they will slack off on their testing. We need to offer to help with quality assessment only.
Q: How do you perform integration testing?
A: First, unit testing has to be completed. Upon completion of unit testing, integration testing begins. Integration testing is black box testing. The purpose of integration testing is to ensure distinct components of the application still work in accordance to customer requirements. Test cases are developed with the express purpose of exercising the interfaces between the components. This activity is carried out by the test team. Integration testing is considered complete, when actual results and expected results are either in line or differences are explainable/acceptable based on client input.
Q: What is integration testing?
A: Integration testing is black box testing. The purpose of integration testing is to ensure distinct components of the application still work in accordance to customer requirements. Test cases are developed with the express purpose of exercising the interfaces between the components. This activity is carried out by the test team. Integration testing is considered complete, when actual results and expected results are either in line or differences are explainable/acceptable based on client input.

Q: How do test plan templates look like?
A: The test plan document template helps to generate test plan documents that describe the objectives, scope, approach and focus of a software testing effort. Test document templates are often in the form of documents that are divided into sections and subsections. One example of this template is a 4-section document, where section 1 is the description of the “Test Objective”, section 2 is the the description of “Scope of Testing”, section 3 is the the description of the “Test Approach”, and section 4 is the “Focus of the Testing Effort”. All documents should be written to a certain standard and template. Standards and templates maintain document uniformity. They also help in learning where information is located, making it easier for a user to find what they want. With standards and templates, information will not be accidentally omitted from a document. Once Rob Davis has learned and reviewed your standards and templates, he will use them. He will also recommend improvements and/or additions. A software project test plan is a document that describes the objectives, scope, approach and focus of a software testing effort. The process of preparing a test plan is a useful way to think through the efforts needed to validate the acceptability of a software product. The completed document will help people outside the test group understand the why and how of product validation.

Q: What is a “bug life cycle”?
A: Bug life cycles are similar to software development life cycles. At any time during the software development life cycle errors can be made during the gathering of requirements, requirements analysis, functional design, internal design, documentation planning, document preparation, coding, unit testing, test planning, integration, testing, maintenance, updates, re-testing and phase-out. Bug life cycle begins when a programmer, software developer, or architect makes a mistake, creates an unintentional software defect, i.e. a bug, and ends when the bug is fixed, and the bug is no longer in existence. What should be done after a bug is found? When a bug is found, it needs to be communicated and assigned to developers that can fix it. After the problem is resolved, fixes should be re-tested. Additionally, determinations should be made regarding requirements, software, hardware, safety impact, etc., for regression testing to check the fixes didn’t create other problems elsewhere. If a problem-tracking system is in place, it should encapsulate these determinations. A variety of commercial, problem-tracking/management software tools are available. These tools, with the detailed input of software test engineers, will give the team complete information so developers can understand the bug, get an idea of its severity, reproduce it and fix it
.
Q: When do you choose automated testing?
A: For larger projects, or ongoing long-term projects, automated testing can be valuable. But for small projects, the time needed to learn and implement the automated testing tools is usually not worthwhile. Automated testing tools sometimes do not make testing easier. One problem with automated testing tools is that if there are continual changes to the product being tested, the recordings have to be changed so often, that it becomes a very time-consuming task to continuously update the scripts. Another problem with such tools is the interpretation of the results (screens, data, logs, etc.) that can be a time-consuming task.
Q: What is the ratio of developers and testers?
A: This ratio is not a fixed one, but depends on what phase of the software development life cycle the project is in. When a product is first conceived, organized, and developed, this ratio tends to be 10:1, 5:1, or 3:1, i.e. heavily in favor of developers. In sharp contrast, when the product is near the end of the software development life cycle, this ratio tends to be 1:1, or even 1:2, in favor of testers.
Q: What is your role in your current organization?
A: I’m a Software QA Engineer. I use the system much like real users would. I find all the bugs, find ways to replicate the bugs, submit bug reports to developers, and provides feedback to the developers, i.e. tell them if they’ve achieved the desired level of quality.
Q: What are some of the software configuration management tools?
A: Software configuration management tools include Rational ClearCase, DOORS, PVCS, CVS; and there are many others. Rational ClearCase is a popular software tool, made by Rational Software, for revision control of source code. DOORS, or “Dynamic Object Oriented Requirements System”, is a requirements version control software tool. CVS, or “Concurrent Version System”, is a popular, open source version control system to keep track of changes in documents associated with software projects. CVS enables several, often distant, developers to work together on the same source code. PVCS is a document version control tool, a competitor of SCCS. SCCS is an original UNIX program, based on “diff”. Diff is a UNIX command that compares contents of two files. You CAN learn to use SCM tools, with little or no outside help.

Q: What is software configuration management?
A: Software Configuration management (SCM) is the control, and the recording of, changes that are made to the software and documentation throughout the software development life cycle (SDLC). SCM covers the tools and processes used to control, coordinate and track code, requirements, documentation, problems, change requests, designs, tools, compilers, libraries, patches, and changes made to them, and to keep track of who makes the changes. Rob Davis has experience with a full range of CM tools and concepts, and can easily adapt to an organization’s software tool and process needs.

Q: What other roles are in testing?
A: Depending on the organization, the following roles are more or less standard on most testing projects: Testers, Test Engineers, Test/QA Team Leads, Test/QA Managers, System Administrators, Database Administrators, Technical Analysts, Test Build Managers, and Test Configuration Managers. Depending on the project, one person can and often wear more than one hat. For instance, we Test Engineers often wear the hat of Technical Analyst, Test Build Manager and Test Configuration Manager as well.

Q: What’s the difference between priority and severity?
A: “Priority” is associated with scheduling, and “severity” is associated with standards. “Priority” means something is afforded or deserves prior attention; a precedence established by order of importance (or urgency). “Severity” is the state or quality of being severe; severe implies adherence to rigorous standards or high principles and often suggests harshness; severe is marked by or requires strict adherence to rigorous standards or high principles, e.g. a severe code of behavior. The words priority and severity do come up in bug tracking. A variety of commercial, problem-tracking/management software tools are available. These tools, with the detailed input of software test engineers, give the team complete information so developers can understand the bug, get an idea of its ’severity’, reproduce it and fix it. The fixes are based on project ‘priorities’ and ’severity’ of bugs. The ’severity’ of a problem is defined in accordance to the customer’s risk assessment and recorded in their selected tracking tool. A buggy software can ’severely’ affect schedules, which, in turn can lead to a reassessment and renegotiation of ‘priorities’.

Q: What is usability?
A: Usability means ease of use; the ease with which a user can learn to operate, prepare inputs for, and interpret outputs of a software product.

Q: What is user interface?
A: User interface is the interface between a human user and a computer system. It enables the passage of information between a human user and hardware or software components of a computer system.

Q: What is V&V?
A: V&V is an acronym for verification and validation.

Q: What is verification and validation (V&V)?
A: Verification and validation (V&V) is a process that helps to determine if the software requirements are complete, correct; and if the software of each development phase fulfills the requirements and conditions imposed by the previous phase; and if the final software complies with the applicable software requirements.

Q: What is the waterfall model?
A: Waterfall is a model of the software development process in which the concept phase, requirements phase, design phase, implementation phase, test phase, installation phase, and checkout phase are performed in that order, probably with overlap, but with little or no iteration.

Q: What are the phases of the software development process?
A: The software development process consists of the concept phase, requirements phase, design phase, implementation phase, test phase, installation phase, and checkout phase.

Q: What models are used in software development?
A: In software development process the following models are used: waterfall model, incremental development model, rapid prototyping model, and spiral model.

QTP METHODS AND PROPERTIES

QTP DIALOG BOX PROPERTIES

1. Activate: Activates the current Dialog Box.
Syntax: object.Activate [BUTTON]
Example:
Sub Activate_Example()
‘The following example uses the Activate method to activate the
‘Internet Options dialog box.
Browser(“Mercury Tours”).Dialog(“Internet Options”).Activate
End Sub

2. CaptureBitmap: Saves the screen capture of the object as a .png or .bmp image using the specified file name.
Syntax: object.CaptureBitmap FullFileName, [OverrideExisting]
Example:
Sub CaptureBitmap_Example1()
‘The following example uses the CaptureBitmap method to capture a
’screen shot of the Internet Options dialog box. The file is
‘automatically saved to a different folder (the test run results
‘folder) in each run.
Browser(“Mercury Tours”).Dialog(“Internet Options”).CaptureBitmap “internet_options.bmp”
End Sub

3. ChildObjects: Returns the collection of child objects contained within the object.
Syntax: object.ChildObjects (pDescription)
Example:
‘The following example uses the ChildObjects method to retrieve a
’set of child objects matching the description listed in the function
‘call and uses the method to display a message indicating how many
‘objects are found with the specified description: none, one (unique),
‘or several (not unique).
Public Function CheckObjectDesription(parent, descr)
Dim oDesc
‘ Create description object
Set oDesc = Description.Create()
arProps = Split(descr, “,”)
For i = 0 To UBound(arProps)
arProp = Split(arProps(i), “:=”)
If UBound(arProp) = 1 Then
PropName = Trim(arProp(0))
PropValue = arProp(1)
oDesc(PropName).Value = PropValue
End If
Next
‘ Get all child objects with the given description
Set children = parent.ChildObjects(oDesc)
If children.Count = 1 Then
CheckObjectDesription = “Object Unique”
ElseIf children.Count = 0 Then
CheckObjectDesription = “Object Not Found”
Else
CheckObjectDesription = “Object Not Unique”
End If
End Function

4. Click: Clicks on a object.
Syntax: object.Click [X], [Y], [BUTTON]
Example:
Sub Click_Example()
‘The following example uses the Click method to click a right mouse
‘button at coordinates 47, 131 on the Internet Options dialog box.
Browser(“Mercury Tours”).Dialog(“Internet Options”).Click 47, 131, 1
End Sub

5. Close: Closes the Dialog Box.
Syntax: object.Close
Example:
Sub Close_Example()
‘The following example uses the Close method to close the Internet
‘Options dialog box.
Browser(“Mercury Tours”).Dialog(“Internet Options”).Close
End Sub

6. DblClick: Double clicks on a object.
Syntax: object.DblClick X, Y, [BUTTON]
Example:
Sub DblClick_Example()
‘The following example uses the DblClick method to double-click a right
‘mouse button at coordinates 73, 120 on the SysListView32 object.
Window(“Exploring”).WinListView(“SysListView32″).DblClick 73, 120, 1
End Sub

7. Drag: Performs the ‘drag’ part of a drag and drop operation.
Syntax: object.Drag X, Y, [BUTTON]
Example:
Sub Drag_Example1()
‘The following example uses the Drag and Drop methods to drag the object from
‘coordinates 10, 20 within the Test window and drop the object at
‘coordinates 30, 40 within the same window.
Window(“Test”).Drag 10, 20
Window(“Test”).Drop 30, 40
End Sub

8. Drop: Performs the ‘drop’ part of a drag and drop operation.
Syntax: object.Drop X, Y, [BUTTON]
Example:
Sub Drop_Example1()
‘The following example uses the Drag and Drop methods to drag the object from
‘coordinates 10, 20 within the Test window and drop the object at
‘coordinates 30, 40 within the same window.
Window(“Test”).Drag 10, 20
Window(“Test”).Drop 30, 40
End Sub

9. Exist: Checks that an object exists.
Syntax: object.Exist([TimeOut])
Example:
Sub Exist_Example()
‘The following example uses the Exist method to determine the existence
‘of the Internet Options dialog box. If the dialog box exists a
‘message box appears confirming its appearance.
If Browser(“Mercury Tours”).Dialog(“Internet Options”).Exist Then
MsgBox (“The object exists.”)
End If
End Sub

10. GetRoProperty: Returns the current value of the test object property from the object in the application.
Syntax: object.GetROProperty (Property, [PropData])
Example:
Sub GetROProperty_Example()
‘The following example uses the GetROProperty method to retrieve the
‘x coordinate of the Test window.
x = Window(“Test”).GetROProperty(“x”)
y = Window(“Test”).GetROProperty(“y”)
End Sub

11. GetTextLocation: Checks whether the specified text string is contained in the specified window area.
Syntax: object.GetTextLocation (TextToFind, Left, Top, Right, Bottom, [MatchWholeWordOnly])
Example:
Sub GetTextLocation_Example()
‘The following example uses the GetTextLocation method to retrieve
‘all of the text within the object.
l = -1
t = -1
r = -1
b = -1
result = Dialog(“Dialog”).WinObject(“Date”).GetTextLocation(“2002″, l, t, r, b)
If result Then
MsgBox “Text found. Coordinates:” & l & “,” & t & “,” & r & “,” & b
End If
End Sub

12. GetToProperties: Returns the collection of properties and values used to identify the object.
Syntax: object.GetTOProperties
Example:
Sub GetTOProperties_Example1()
‘The following example uses the GetTOProperties method to retrieve the
‘list of properties and values used to identify the Internet Options
‘dialog box.
IEOptsDialog = Browser(“Mercury Tours”).Dialog(“Internet Options”).GetTOProperties()
End Sub

13. GetToProperty: Returns the value of a specified property from the test object description.
Syntax: object.GetTOProperty (Property)
Example:
Sub GetTOProperty_Example()
‘The following example uses the GetTOProperty method to retrieve the
‘RegExpWndClass property from the Object Repository.
Dim ObjectName
RegExpWndClass = Window(“Test”).GetTOProperty(“RegExpWndClass”)
End Sub

14. GetVisibleText: Returns the text from specified area.
Syntax: object.GetVisibleText ([Left], [Top], [Right], [Bottom])
Example:
Sub GetVisibleText_Example1()
‘The following example uses the GetVisibleText method to retrieve the
‘text from the Telnet window. If the returned string contains the “login:”
’sub-string, the Type method is used to type the guest string in the
‘window.
TelnetText = Window(“Telnet”).GetVisibleText
If InStr(1, TelnetText, “login:”, 1) > 0 Then
Window(“Telnet”).Type “guest”
End If
End Sub

15. MouseMove: Moves the mouse pointer to the designated position inside the activeXobject.
Syntax: object.MouseMove X, Y
Example:
Sub MouseMove_Example()
‘The following example uses the MouseMove method to move the mouse
‘pointer to the position (20, 30) inside the Advanced object.
Browser(“MyPage”).Dialog(“Settings”).WinObject(“Advanced”).MouseMove 20, 30
End Sub

16. Move: Moves the dialog box to the specified absolute location on the screen.
Syntax: object.Move X, Y
Example:
Sub Move_Example()
‘The following example uses the Move method to move the Internet
‘Options dialog box to the specified location.
Browser(“Mercury Tours”).Dialog(“Internet Options”).Move 659, 35
End Sub

17. Maximize: Maximize the dialog box to fill the entire screen.
Syntax: object.Maximize
Example:
Sub Maximize_Example()
‘The following example uses the Maximize method to maximize the
‘Internet Options dialog box.
Browser(“Mercury Tours”).Dialog(“Internet Options”).Maximize
End Sub

18. Minimize: Minimizes the dialog box to an icon.
Syntax: object.Minimize
Example:
Sub Minimize_Example()
‘The following example uses the Minimize method to minimize the
‘Internet Options dialog box.
Browser(“Mercury Tours”).Dialog(“Internet Options”).Minimize
End Sub

19. Resize: Resize the dialog box to the specified dimensions.
Syntax: object.Resize Width, Height
Example:
Sub Resize_Example()
‘The following example uses the Resize method to resize the Internet
‘Options dialog box.
Browser(“Mercury Tours”).Dialog(“Internet Options”).Resize 296, 348
End Sub

20. Restore: Restores the dialog box to its previous size.
Syntax: object.Restore
Example:
Sub Restore_Example()
‘The following example uses the Restore method to restore the
‘Internet Options dialog box to its previous size.
Browser(“Mercury Tours”).Dialog(“Internet Options”).Restore
End Sub

21. SetToProperty: Sets the value of the specified property in its test object description.
Syntax: object.SetTOProperty Property, Val
Example:
Sub SetTOProperty_Example()
‘The following example uses the SetTOProperty method to set the
‘index of a window’s description.
Window(“Test”).SetTOProperty “Index”, 2
End Sub

22. Type: Type the specified string in the dialog box.
Syntax: object.Type KeyboardInput
Example: Not Available

23. WaitProperty: Waits until the specified object property achieves the specified value or exceeds the specified timeout before continuing to the next step.
Syntax: object.WaitProperty (PropertyName, PropertyValue, [lTimeOut])

Example:
Sub WaitProperty_Example()
‘The following example uses the WaitProperty method to make the
‘program wait for the “Test” window to become active or for 3 seconds
‘(3 milliseconds) to pass, whichever comes first.
y = Window(“Test”).WaitProperty(“focused”, True, 3000)
End Sub

24. Output: Retrieves the current value of an item and stores it in a specified location.
Syntax: object.Output pVerify
Example:
Sub Output_Example()
‘The following example uses the Output method to output text into the
‘”You can change” Data Table column.
Browser(“index”).Dialog(“Internet Options”).Static(“You can change”).Output CheckPoint(“You can change”)
End Sub

QTP COMBO BOX PROPERTIES

1. GetContent: Returns a string containing the names of all of the items in the combo box.
Syntax: object.GetContent
Example:
Sub GetContent_Example ()
‘The following example uses the getcontent method to return the items in the ‘fly from list.
With window (“Flight Reservation”)
Content= .WinCombobox (“Fly From:”).GetContent
End With
End sub

2. GetItem: Returns the value of the item specified by the index.
Syntax: object.GetItem (Item)
Example:
Sub GetItem_Example()
‘The following example uses the GetItem method to return the value
‘of the fifth item in the list.
itemVal = Window(“Flight Reservation”).WinComboBox(“Fly To:”).GetItem(4)
End Sub

3. GetItemsCount: Returns the number of items in the combo box specified by the index.
Syntax: object.GetItemsCount
Example:
Sub GetItemsCount_Example()
‘The following example uses the GetItemsCount method to return the
‘number of items in the Fly From combo box.
With Window(“Flight Reservation”)
cnt = .WinComboBox(“Fly From:”).GetItemsCount
End With
End Sub

4. GetSelection: Returns a string containing the names of all selected items in the combo box.
Syntax: object. GetSelection
Example:
Sub GetSelection_Example()
‘the following example uses the GetSelection method to return the
’selected items in the Fly From combo box.
With Window(“Flight Reservation”)
sel = .WinComboBox(“Fly From:”) .GetSelection
End With
End Sub

5. Select: Select an item from the combo box.
Syntax: object. Select item
Example:
Sub Select_Example()
‘The following example uses the Select method to select the item 22
‘from the Size combo box.
Window(“Notepad”).Dialog(“Font”).WinComboBox(“&Size:”).Select “22″
‘or
Window(“Notepad”).Dialog(“Font”).WinComboBox(“&Size:”).Select 7
End Sub

QTP ACTIVE X PROPERTIES

1. Click: Click an ActiveX object.
Syntax: object.Click [X], [Y], [BUTTON]
Example:
Sub Click_Example()
‘The following example uses the Click method to click a
‘”Flight Reservations” AcxTable object at coordinates 20, 10.
Browser(“Flight”).Page(“Flight”).AcxTable(“Flight Reservations”).Click 20, 10
End Sub

2. Dblclick: Double clicks an ActiveX object.
Syntax: object.DblClick X, Y, [button]
Example:
Sub DblClick_Example()
‘The following example uses the DblClick method to double-click a
‘”Calendar” ActiveX object at coordinates 73, 120.
Browser(“Flight”).Page(“Flight”).ActiveX(“Calendar”).DblClick 73, 120, 1
End Sub

3. FireEvent: Simulates an event on the ActiveX object.
Syntax: object.FireEvent Eventname, [Args()]
Example:
Sub FireEvent_Example()
‘The following example uses the FireEvent method to simulate a
‘click event on the Save button.
Browser(“Homepage”).Page(“Welcome”).AcxButton(“Save”).FireEvent “Click”
End Sub

4. MakeVisible: Scrolls an ActiveX object into view if it is not visible in the window.
Syntax: object.MakeVisible
Example:
Sub MakeVisible_Example()
‘The following example uses the MakeVisible method to bring the
‘CIRC3 AcxRadioButton into view.
Browser(“Welcome to A-Soft”).Page(“Untitled Normal”).AcxRadioButton(“CIRC3.Circ3Ctrl.1″).MakeVisible
End Sub

5. MouseMove: Moves the mouse pointer to the designated position inside the ActiveX object.
Syntax: object. MouseMove X,Y
Example:
Sub MouseMove_Example()
‘The following example uses the MouseMove method to move the
‘mouse pointer to the top left corner of the “Calendar” object:
Window(“Date”).ActiveX(“Calendar”).MouseMove 0, 0
End Sub

6. Object: Accesses the internal methods and properties of the ActiveX object.
Syntax: object.Object
Example:
Sub Object_Example()
‘The following example uses the Object method to activate the AboutBox
‘method, you would insert the following statement into your test script.
‘The assumption is that the AboutBox method is supported for your
‘ActiveX control.
Browser(“Flight Reservation”).Page(“Flight details”).ActiveX(“Calendar”).Object.AboutBox
‘Alternatively, you could insert the following:
Set MyObj = Browser(“Flight Reservation”).Page(“Flight details”).ActiveX(“Calendar”).Object
MyObj.AboutBox
End Sub

7. Type: Types the specified string in the ActiveX object.
Syntax: object.Type wsTypeSeq
Example:
Sub Type_Example()
‘The following example uses the Type method to type “ABC” in the
‘AcxTable object.
Browser(“Homepage”).Page(“Welcome”).AcxTable(“MSFlexGrid”).Type “ABC”
End Sub

QTP RADIO BUTTON PROPERTIES

1. Set: Sets the radio button as the selected radio button.
Syntax: object.Set
Example:
Sub Set_Example()
‘The following example uses the Set method to select the “Not Shared”
‘radio button.
Window(“Window”).Dialog(“System Properties”).WinRadioButton(“Not Shared”).Set
End Sub

QTP MENU PROPERTIES

1. BuildMenuPath: Returns the path of specified Menu Item.
Syntax: object.BuildMenuPath (Args())
Example:
Sub BuildMenuPath_Example1()
‘The following example uses the BuildMenuPath method to construct the
‘menu item path string for selecting the second menu item under the
‘File menu. This method returns the string File;:
Path = Window(“Notepad”).WinMenu(“Menu”).BuildMenuPath(“File”, 2)
Window(“Notepad”).WinMenu(“Menu”).Select Path
End Sub

2. GetItemProperty: Returns the current value of the specified property for the specified Menu Item.
Syntax: object.GetItemProperty(Item, Property)
Example:
Sub GetItemProperty_Example1()
‘The following example uses the GetItemProperty method to retrieve the
‘label property of a menu item.
itemLabel = Window(“Notepad”).WinMenu(“Menu”).GetItemProperty(“;”, “Label”)
End Sub

3. Select: Selects the specified item in the menu.
Syntax: object.Select Item
Example:
Sub Select_Example()
‘The following example uses the Select method to open the Open File
‘dialog box in Notepad.
Window(“Notepad”).WinMenu(“Menu”).Select “File;Open… Ctrl+O”
‘You can also open a menu item according to its indexed number.
Window(“Notepad”).WinMenu(“Menu”).Select “;”
End Sub

4. ExpandMenu: Indicates whether to expand the menu when retrieving menu item properties.
Syntax: object. ExpandMenu[=Value]
Example:
Sub ExpandMenu_Example()
‘The following example uses the ExpandMenu method to instruct
”QuickTest NOT to open each menu item when retrieving the menu item’s
‘property. The GetItemProperty method retrieves the Label property of
‘each menu item and writes them in the test’s report log.
Window(“Notepad”).WinMenu(“Menu”).ExpandMenu = False
Window(“Notepad”).Activate
GetNamesRec “”, Window(“Notepad”).WinMenu(“Menu”)

QTP LISTBOX PROPERTIES

1. Activate: Activates the specified item in the list.
Syntax: object.Activate Item, [btn]
Example:
Sub Activate_Example()
‘The following example uses the Activate method to double-click the
‘MyFile item in the Files list.
Dialog(“Open”).WinList(“Files”).Activate “MyFile”
‘or
Dialog(“Open”).WinList(“Files”).Activate 2
End Sub

2. Deselects: Deselects an item in the list.
Syntax: object. Deselects item
Example:
Sub Deselect_Example()
‘The following example uses the Deselect method to deselect a selected
‘item from the Files list.
Dialog(“Open”).WinList(“Files”).Deselect “MyFile”
‘or
Dialog(“Open”).WinList(“Files”).Deselect 3
End Sub

3. ExtendSelect: Selects an additional item from the multi-selection list.
Syntax: object. ExtendSelect item
Example:
Sub ExtendSelect_Example()
‘The following example uses the ExtendSelect method to add an item
‘to a multiple-selection list in the Files list.
Dialog(“Open”).WinList(“Files”).ExtendSelect “MyFile”
‘or
Dialog(“Open”).WinList(“Files”).ExtendSelect 2
End Sub

4. GetContent: Returns all of the items in the list.
Syntax: object.GetContent
Example:
Sub GetContent_Example()
‘The following example uses the GetContent method to return the items
‘in the Files list.
Contents = Dialog(“Open”).WinList(“Files”).GetContent()
End Sub

5. GetItemProperty: Returns the current value of a property from an item in the list.
Syntax: object.GetItemProperty(Item, Property)
Example:
Sub GetItemProperty_Example()
‘The following example uses the GetItemProperty method to gather
‘information about various properties for items in a list.
sReport = “”
With Window(“WinBurger”).WinList(“ListBox”)
For i = 0 To 4
sReport = sReport & .GetItemProperty(i, “Selected”) & vbTab
sReport = sReport & .GetItemProperty(i, “Checked”) & vbTab
sReport = sReport & .GetItemProperty(i, “Focused”) & vbTab
sReport = sReport & .GetItemProperty(i, “IsAnchor”) & vbTab
sReport = sReport & .GetItemProperty(i, “Height”) & vbCr
Next
End With
Reporter.ReportEvent micDone, “List data”, sReport
End Sub

6. GetItemsCount: Returns the number of items in the list.
Syntax: object.GetItemsCount
Example:
Sub GetItemsCount_Example()
‘The following example uses the GetItemsCount method to return the
‘number of items in the Files list.
NumberOfItems = Dialog(“Open”).WinList(“Files”).GetItemsCount
End Sub

7. GetSelection: Returns all of the selected items in the list.
Syntax: object.GetSelection
Example:
Sub GetSelection_Example()
‘The following example uses the GetSelection method to return the
’selected items in the “Files” list.
Dialog(“Open”).WinList(“Files”).Select “bin”
Dialog(“Open”).WinList(“Files”).ExtendSelect “dat”
Dialog(“Open”).WinList(“Files”).ExtendSelect “encrypt”
Selection = Dialog(“Open”).WinList(“Files”).GetSelection
End Sub

8. Select: Selects an item from the list.
Syntax: object.Select Item, [BUTTON], [Offset]
Example:
Sub Select_Example1()
‘The following example uses the Select method to select the item
‘CONTENTS from the list.
With Window(“Windows Help”)
.WinList(“ListBox”).Select “CONTENTS”
End With
End Sub

9. SelectRange: Select all list items between ( and including) the two specified items.
Syntax: object.SelectRange Item, [ItemTo]
Example:
Sub SelectRange_Example1()
‘The following example uses the SelectRange method to select all the
‘items between (and including) Red and Blue.
Dialog(“Select Color”).WinList(“Colors”).SelectRange “Red”, “Blue”
End Sub

10. SetItemState: Sets the state of check box icon of the specified item in the list.
Syntax: object.SetItemState vItem, State
Example: NOT AVAILABLE

QTP CHECKBOX PROPERTIES

1. Set: Sets value of the check box.
Syntax: object. Set value
Example:
Sub Set_Example()
‘The following example uses the Set method to set the Include
’subfolders check box in the Find: All Files dialog box to ON.
Dialog(“Find: All Files”).WinCheckBox(“Include &subfolders”).Set “ON”
End Sub

QTP WINDOW PROPERTIES

1. RunAnalog: Runs the specified analog track.
Syntax: object. RunAnalog Actionid, [Speed]
Example:
Sub RunAnalog_Example1()
‘The following example uses the RunAnalog method to perform the
‘mouse drags used to replicate a user’s signature on a window using
‘the Fast run speed. QuickTest clicks in the signature area of a
‘flight reservation application and then uses the RunAnalog method
‘to run the external Track1 analog file.
Window(“Flight Reservation”).Dialog(“Fax Order No.”).Click 216, 204
Window(“Flight Reservation”).Window(“Fax Order No.”).RunAnalog “Track1″
End Sub

DO’S & DONT’S AS A Tester

Software Testing
Introduction
Reliable and Quality Software is what everyone needs but only few people cares of. Testing of web applications during development is critical because problems if found later during deployment is going to cost high than if it were caught during development
What is web testing?
Web testing in its broader sense attribute to testing of either Internet or intranet web applications where the client interface is an Internet browser. The browser can be anything like Internet Explorer, Netscape Navigator, and Opera etc.

Software Testing Process
The Approach
This section will not detail more on the testing process but will throw some light on a standard testing process. Any testing process will start with the planning of a test (Test Plan), building a strategy (How To Test), Preparation of test cases (What To Test), Execution of test cases (Testing) and end in reporting the results (Defects).
The above process need not be wholly iterative but execution of test cases and reporting results can be considered iterative in most cases. But now comes a question of how different is a web testing process over other testing process? Practically it is not difference it is the priority areas which needs to be set for a web testing. For web testing the following few key focus areas like Compatibility, Navigation, User Interaction, Usability, Performance, Scalability, Reliability, and Availability etc can be considered during the testing phase.

The Do’s
This section will have a list of areas or tasks, which one has to follow in a web testing process. Though it might be common with other testing process it is suggested that these areas are given enough attention.

Plan & Strategy
Neatly document the test plan and test strategy for the application under test. Test Plan serves as the basis for all testing activities throughout the testing life cycle. Being an umbrella activity this should reflect the customers needs in terms of milestones to be met, the test approach (test strategy), resources required etc. The plan and strategy should give a clear visibility of the testing process to the customer at any point of time.
Functional and Performance test plans if developed separately will give lot more lucidity for functional and performance testing. Performance test plan is optional if the application does not entail any performance requirements.
The Do’s

• Develop test plan based on a approved Project Plan
• Document test plan with major testing milestones
• Identify and document all deliverables at the end of these milestones
• Identify the resources (Both Hardware/Software and Human) required
• Identify all other external systems, which is going to interact with the application. For example the application can get the data from any other mainframe server. Identification of such systems will help one plan for integration testing as well
• If performance testing is under the scope of testing then clearly identify the application performance requirements like number of hits/second, response time, number of concurrent user etc. Details about different testing methodologies (Spike testing, Endurance testing, stress testing, capacity testing) during the performance testing phase can also be documented.
• Get the test plan approved.

• Include Features to be tested to communicate to customer what all will be tested during the testing life cycle
• Include Features not tested to communicate to customer what all will not be tested during the testing life cycle. (As part of risk management)
The Don’ts

• Do not use draft (unapproved) test plans for reference
• Do not ignore the test strategies identified in the test plan during testing.
• Do not make changes to any approved test plan without official change request
Test Case Design
• Do not mix the stages of testing (Unit testing, Integration testing, System testing, Functional testing etc) with the types of testing (Regression testing, Sanity testing, User Interface testing, Smoke testing etc) in the test plan. Identify them uniquely with their respective input and exit criteria.
Any good and complete testing is as good as its test cases, since test cases reflect the understandability of the test engineer over the application requirements. A good test case should identify the yet undiscovered errors in testing.

The Do’s
• Identify test cases for each module
• Write test cases in each executable step.
• Design more functional test cases.
• Clearly identify the expected results for each test case
• Design the test cases for workflow so that the test cases follow a sequence in the web application during testing. For example for mail applications say yahoo, it has to start with a registration process for new users, then signing up, composing mail, sending mail etc.
• Security is high priority in web testing. Hence document enough test cases related to application security.
• Develop a trace ability matrix to understand the test case coverage with the requirements

The Don’ts
• Do not write repetitive UI test cases. This will lead to high maintenance since UI will evolve over due course.
• Do not write more than one execution step in each test case.
• Do not concentrate on negative paths for User acceptance test cases if the business requirements clearly indicate on the application behavior and usage by the business users.
• Do not fail to get the test cases reviewed by individual module owners of the development team. This will enable the entire team to be in the same line.
• Do not leave any functionality uncovered in the test cases unless and until if it is specified in the test plan as features not tested.
• Try not to write test cases on error messages based on assumptions. Document error message validation test cases if the exact error message to be displayed is given in requirements.

Testing

This phase is little crucial in terms of customer standpoint, be it internal or external. All the efforts put in earlier phases of testing is going to reap results only in this phase.
A good test engineer should always work towards breaking the product right from the first release till the final release of the application (Killer attitude). This section will not just focus on testing but all the activities related to testing is it defect tracking, configuration management or testing itself.
The Do’s

• Ensure if the testing activities are in sync with the test plan
• Identify technically not strong areas where you might need assistance or trainings during testing. Plan and arrange for these technical trainings to solve this issue.
• Strictly follow the test strategies as identified in the test plan
• Try getting a release notes from the development team which contains the details of that release that was made to QA for testing. This should normally contain the following details
o The version label of code under configuration management
o Features part of this release
o Features not part of this release
o New functionalities added/Changes in existing functionalities
o Known Problems
o Fixed defects etc.
• Stick to the input and exit criteria for all testing activities. For example, if the input criteria for a QA release is sanity tested code from development team, ask for sanity test results.
• Update the test results for the test cases as and when you run them
• Report the defects found during testing in the tool identified for defect tracking
• Take the code from the configuration management (as identified in plan) for build and installation.
• Ensure if code is version controlled for each release.
• Classify defects (It can be P1, P2, P3, P4 or Critical or High or Medium or Low or anything) in a mutual agreement between the development team so as to aid developers prioritize fixing defects
• Do a sanity testing as and when the release is made from development team.
The Don’ts

• Do not update the test cases while executing it for testing. Track the changes and update it based on a written reference (SRS or functional specification etc). Normally people tend to update the test case based on the look and feel of the application.
• Do not track defects in many places i.e. having defects in excel sheets and in any other defect tracking tools. This will increase the time to track all the defects. Hence use one centralized repository for defect tracking
• Do not get the code from the developers sandbox for testing, if it is a official release from the development team
• Do not spend time in testing the features that are not part of this release
• Do not focus your testing on the non critical areas (from the customers perspective)
• Even if the defect identified is of low priority, do not fail to document it.
• Do not leave room for assumptions while verifying the fixed defects. Clarify and then close!
• Do not hastily update the test cases without running them actually, assuming that it worked in earlier releases. Sometimes these pre conceived notions would be a big trouble if that functionality is suddenly not working and is later found by the customer.
• Do not focus on negative paths, which are going to consume lots of time but will be least used by customer. Though this needs to be tested at some point of time the idea really is to prioritize tests.

Test Results

What comes next after the testing is complete. Can it be considered completed?
The answer is No. Any testing activity at the end should always be accompanied with the test results. The test result can be of both defects and the results from the test cases, which were executed during testing.
The Do’s

• Ensure that a defect summary report is sent to the Project Lead after each release testing. This on a high level can discuss on the number of open/reopen/closed/fixed defects. To drill down the report can also contain the priority of open and reopen defects.
• Ensure that a test summary report is sent to the Project Lead after each release testing. This can contain details about the total number of test cases, total number of test cases executed, total number of passed test cases, total number of failed test cases, total number of test cases that were not run (This here means the test cases were not able to run here either due to non-availability of production environment or non-availability of real time data or some other dependencies. Hence looking at the non-run test cases should give a clear picture what areas were not tested. This should not contain information on the test cases which were not run due to lack of time), total number of test cases that were not applicable.
• On a high level if the above details can be tracked for all releases then this should give a clear picture on the growing stability of the application.
• Track metrics as identified during the plan stage
The Don’ts

• Do not attempt to update anyone with huge information on test results. It has to be precise. You need not give information of the test execution steps which failed during testing as this will be a tedious process for one to sit and go through these test cases
• Finally what it comes out is how easily is the test result information can be interpreted. Hence do not leave room for assumptions while interpreting the test metrics. Make it simple!
Conclusion
As a conclusion testing should focus on 100% test coverage rather than 100% test case coverage because at times 100% test coverage cannot fully guarantee that the application is thoroughly tested, it is the test coverage which really matters. Testing is a not a monotonous jobs anymore as it imposes lot more challenges than it was thought to be. The Quality of the product is finally the outcome of how good was the testing done. At last the effectiveness testing is what it counts when comes to customer satisfaction. Testing gives boulevard learn new tools, which can help one in the testing process. But testing can only identify the presence of defects and cannot certify the absence of defects. Hence it really counts to deliver a defect free product.

How to use Database functions in QTP / DATA BASE FUNCTIONS

DATA BASE FUNCTIONS

”************************************************************************************
‘ Example use DSN created for database of Flight sample application.
”************************************************************************************
SQL=”SELECT * FROM ORDERS”
connection_string=”QT_Flight32″

isConnected = db_connect ( curConnection ,connection_string )
If isConnected = 0 then
‘ execute the basic SQL statement
set myrs=db_execute_query( curConnection , SQL )

‘ report the query and the connection string
Reporter.ReportEvent micInfo ,”Executed query and created recordset “,”Connection_string is ==> ” & connection_string & ” SQL query is ===> ” & SQL
‘ show the number of rows in the table using a record set
msgBox ” Quantity of rows in queried DB ( db_get_rows_count )==> ” & db_get_rows_count( myrs )
‘ show the number of rows in the table using a new SQL statement
msgBox ” Quantity of rows in queried DB (db_get_rows_count_SQL ) ==> ” & db_get_rows_count_SQL( curConnection , “SELECT COUNT(*) FROM ORDERS” )

‘ change a value of a field in an existing row
rc = db_set_field_value (curConnection, “ORDERS” , “Agents_Name” , “test”, “Agents_Name”, “AGENT_TESTER”)

‘ examples of how to retrieve values from the table
msgBox “val row 0 col 0: ” & db_get_field_value( myrs , 0 , 0 )
msgBox “val row 0 col 1: ” & db_get_field_value( myrs , 0 , 1 )
msgBox “val row 1 col Name: ” & db_get_field_value( myrs , 1 , “Agents_Name” )
msgBox “val SQL row 1 col Name: ” & db_get_field_value_SQL( curConnection , “ORDERS” , 1 , “Agents_Name” )

db_disconnect curConnection
End If

”****************************************************************************************

‘ Database Functions library
‘******************************************************************************************
‘db_connect
‘ —————
‘ The function creates a new connection session to a database.
‘ curSession – the session name (string)
‘ connection_string – a connection string
‘ for example the connection_string can be “DSN=SQLServer_Source;UID=SA;PWD=abc123″
‘******************************************************************************************
Function db_connect( byRef curSession ,connection_string)
dim connection
on error Resume next
‘ Opening connection
set connection = CreateObject(“ADODB.Connection”)
If Err.Number <> 0 then
db_connect= “Error # ” & CStr(Err.Number) & ” ” & Err.Description
err.clear
Exit Function
End If

connection.Open connection_string
If Err.Number <> 0 then
db_connect= “Error # ” & CStr(Err.Number) & ” ” & Err.Description
err.clear
Exit Function
End If
set curSession=connection
db_connect=0
End Function

‘********************************************************************************************
‘ db_disconnect
‘ ———————
‘ The function disconnects from the database and deletes the session.
‘ curSession – the session name (string)
‘********************************************************************************************
Function db_disconnect( byRef curSession )
curSession.close
set curSession = Nothing
End Function

‘*********************************************************************************************
‘ db_execute_query
‘ —————————
‘ The function executes an SQL statement.
‘ Note that a db_connect for (arg1) must be called before this function
‘ curSession – the session name (string)
‘ SQL – an SQL statement
‘**********************************************************************************************
Function db_execute_query ( byRef curSession , SQL)
set rs = curSession.Execute( SQL )
set db_execute_query = rs
End Function

”***********************************************************************************************
‘ db_get_rows_count
‘ —————————-
‘ The function returns the number of rows in the record set
‘ curRS – variable , contain record set , that contain all values that retrieved from DB by query execution
”***********************************************************************************************
Function db_get_rows_count( byRef curRS )
dim rows
rows = 0
curRS.MoveFirst
Do Until curRS.EOF
rows = rows+1
curRS.MoveNext
Loop
db_get_rows_count = rows
End Function

”************************************************************************************************
‘ db_get_rows_count_SQL
‘ ————————————
‘ The function returns the number of rows that are the result of a given SQL statement
‘ curSession – the session name (string)
‘ CountSQL – SQL statement
”************************************************************************************************
Function db_get_rows_count_SQL( byRef curSession ,CountSQL )
dim cur_rs
set cur_rs = curSession.Execute( CountSQL )
db_get_rows_count_SQL = cur_rs.fields(0).value
End Function

”*************************************************************************************************
‘ db_get_field_value_SQL
‘ ———————————–
‘ curSession – variable denote current active connection
‘ tableName – name of the table , where value should be retrieved
‘ rowIndex – row number
‘ colName – the column name.
‘*************************************************************************************************
Function db_get_field_value_SQL( curSession , tableName , rowIndex , colName )
dim rs
SQL = ” select ” & colName & ” from ” & tableName
set rs = curSession.Execute( SQL )

rs.move rowIndex
db_get_field_value_SQL = rs.fields(colName).value
End Function

‘*************************************************************************************************
‘ db_get_field_value
‘ ————————–
‘ The function returns the value of a single item of an executed query.
‘ Note that a db_execute_query for (arg1) must called before this function

‘ curRecordSet – variable , contain record set , that contain all values that retrieved from DB by query execution
‘ rowIndex – the row index number (zero based)
‘ colIndex – the column index number (zero based) or the column name.
‘ returned values
‘ -1 – requested field index more than exists in record set
‘*************************************************************************************************
Function db_get_field_value( curRecordSet , rowIndex , colIndex )
dim curRow

curRecordSet.MoveFirst
count_fields = curRecordSet.fields.count-1
If ( TypeName(colIndex)<> “String” ) and ( count_fields < colIndex ) then
db_get_field_value = -1 ‘requested field index more than exists in recordset
Else
curRecordSet.Move rowIndex
db_get_field_value = curRecordSet.fields(colIndex).Value
End If
End Function

‘*************************************************************************************************
‘ db_set_field_value
‘ —————————
‘ The function changes the value of a field according to a search criteria.
‘ We search for a certain row according to a column name and the desired vale, then we change a value in that row according
‘ to a desired columns

‘ curConnection – the session name (string)
‘ tableName – name of the table , where value should be retrieved
‘ colFind – the column we search the criteria in
‘ colFindValue – the value we search in the column
‘ colChange – the column were we want to change the value
‘ colChangeValue – the new value

‘ returned values
‘ -1 – requested field index that doesn’t exists in the recordset
‘*************************************************************************************************
Function db_set_field_value(curConnection, tableName , colFind , colFindValue, colChange, colChangeValue)
dim curRow
dim updateSQL
dim checkSQL

checkSQL = “select * from Details”
set myrs1 = db_execute_query( curConnection , SQL )
myrs1.MoveFirst
count_fields = myrs1.fields.count
If ( TypeName(colFind)<> “String” ) or ( TypeName(colChange)<> “String” ) then
db_set_field_value = -1 ‘requested field index that doesn’t exists in the record set
Else
updateSQL = “UPDATE ” & tableName & ” SET ” & colChange & “=’” & colChangeValue & “‘ WHERE ” & colFind & “=’” & colFindValue & “‘”
set myrs1 = db_execute_query( curConnection , updateSQL )
db_set_field_value = 1 ‘operation suceeded
End If
End Function

‘*************************************************************************************************
‘ db_add_row
‘ —————–
‘ The function adds a new row to the desired table

‘ curConnection – variable , contains a recordset , that contains all the values to be retrieved from DB by query execution
‘ tableName – name of the table , where value should be retrieved from
‘ values – array that contains values to be entered in a new row to the table.

‘ Note: the function must receive values for all the columns in the table!
‘ returned values
‘ -1 – the number of values to be entered to the table doesn’t fit the number of columns
‘ 1 – execution of the query succeed and the data was entered to the table
‘*************************************************************************************************
Function db_add_row(curConnection, tableName , byRef values)
dim i
dim updateSQL
dim myrs1

updateSQL = “INSERT INTO ” & tableName & ” VALUES (“
arrLen = UBound (values) – LBound (values) + 1

set myrs1=db_execute_query( curConnection , SQL )
myrs1.MoveFirst
count_fields = myrs1.fields.count
‘ check if numbers of values fit the numbers of columns
If arrLen <> count_fields then
db_add_row = -1
Else
For i = 0 to arrLen-1
updateSQL = updateSQL & values (i)
If i <> arrLen-1 then
updateSQL = updateSQL & “,”
End If
Next
updateSQL = updateSQL & “)”
set myrs1 = db_execute_query( curConnection , updateSQL )
db_add_row = 1
End If
End Function

‘*************************************************************************************************
‘ represent_values_of_RecordSet
‘ ———————————————
‘ the function reports all the values on fields in a record set
‘ curRS – variable , contains the recordset , that contains all the values that were retrieved from the DB by the query execution
‘*************************************************************************************************
Function represent_values_of_RecordSet( myrs)
dim curRowString
myrs.MoveFirst
reporter.ReportEvent 4,”Fields quantity” , myrs.fields.count
count_fields = myrs.fields.count-1
curRow=0
Do Until myrs.EOF
curRowString= “”
curRow = curRow+1
For ii=0 to count_fields
curRowString = curRowString& “Field ” &”==> ” & myrs.fields(ii).Name &” : Value ==>” & myrs.fields(ii).Value & vbCrLf
Next
myrs.MoveNext
reporter.ReportEvent 4,”Current row”& curRow , curRowString
Loop
End Function

Key word Driven Testing

Mercury QuickTest Professional is the advanced solution for functional test and regression test automation. This next-generation automated testing solution deploys the concept of keyword-driven testing to enhance test creation and maintenance. Keyword-driven testing is a technique that separates much of the programming work from the actual test steps so that the test steps can be developed earlier and can often be maintained with only minor updates, even when the application or testing needs change significantly.

Using the 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.

You create a test either by building an object repository and adding steps manually or by recording a session on your application. You can create steps using the table-like, graphical Keyword View using keyword-driven functionality—or you can use the Expert View, if you prefer programming steps directly in VBScript.

The Keyword View enables you to create and view the steps of your test in a keyword-driven, modular, table format. The Keyword View is comprised of a table-like view, in which each step is a separate row in the table, and each column represents different parts of the steps. You can modify the columns displayed to suit your requirements. You create and modify tests by selecting items and operations in the Keyword View and entering information as required. Each step is automatically documented as you complete it, enabling you to view a description of your test steps in understandable English.

You can design tests using the keyword-driven methodology, step recording, or a combination of both.
In comparison to recording, the keyword-driven methodology generally requires a longer time-investment and at least one automation expert with a high-level of QuickTest expertise to prepare the infrastructure required for your tests, but once the infrastructure is in place, tests can be created at a more application-specific level and with a more structured design. Additionally, all the tests for a given application can be maintained more efficiently and with more flexibility than a recorded test.

Creating a Test Using the Keyword-Driven Methodology

Keyword-driven testing is a technique that separates much of the programming work from the actual test steps so that the test steps can be developed earlier and can often be maintained with only minor updates, even when the application or testing needs change significantly. The keyword-driven testing methodology divides test creation into two stages:  Preparing a set of testing resources (the test automation infrastructure).

•    Preparing the test automation infrastructure includes a planning stage and an implementation stage.
•    Creating tests in the QuickTest Keyword View by selecting the keywords (objects and/or operations) that represent the application functionality you want to test.

Planning Stage
•    Analyzing the application and determining which objects and operations are used by the set of business processes that need to be tested.
•    Determining which operations require customized keywords to provide additional functionality, to achieve business-level clarity, and/or to maximize efficiency and maintainability.

Implementation Stage

•    Building the object repository and ensuring that all objects have clear names that follow any predetermined naming conventions. You can create object repositories using QuickTest functionality to recognize and learn the objects in your application, or you can manually define objects. The object repository should contain all the objects that are relevant for the tests using this infrastructure.
•    Developing and documenting business-level keywords in function libraries. Creating function libraries involves developing customized functions for the application you want to test. You may want to develop functions to test special application functionality that is not already supplied by the methods in the QuickTest object model. It is also useful to wrap existing methods and functions together with additional programming to create application-specific functions for testing operations or sequences that are commonly performed in your application. The functions you create will be available either as extra keywords or as replacements for built-in QuickTest keywords during the test creation stage.

Although this methodology requires more planning and a longer initial time-investment than going directly to the test creation stage and recording your steps, this methodology makes the test creation and test maintenance stages more efficient and keeps the structure of individual tests more readable and easier to modify.
By encapsulating much of the complex programming into function libraries, and by making these functions flexible enough to use in many testing scenarios (through the use of function parameters that control the way the functions behave), one or a few automation experts can prepare the keywords that many application testers who are less technical can include in multiple tests. This also makes it possible to update testing functionality without having to update all the tests that use the keywords.

In a similar fashion, by maintaining all objects that are relevant to a particular application or area of an application within one shared object repository, and by associating that object repository with all relevant tests, changes to the application can be reflected in the object repository without the need to update tests.
After the object and function library keywords are ready, application testers can use these keywords to build keyword-driven tests.

Recorded tests tend to be specific to a single procedure or set of procedures. When the application changes, especially when it changes significantly from one version to another, much of the test often needs to be rerecorded.

By creating your tests with a keyword-driven methodology in mind, your tests become more modular, focusing on the operations to test using both QuickTest built-in keywords and your own user-defined keywords. Additionally, because it is possible to add objects to the object repository before they exist in an application, it is possible to begin preparing your automated keyword-driven tests even before a build containing the new objects is available.
Developing a Keyword-Driven Automation Infrastructure
One or a few automation experts usually develop the test automation infrastructure that all tests related to a certain application or functionality will use. The automation infrastructure usually includes one or more shared object repositories and one or more function libraries. The information in the sections below gives you some guidance on the main tasks involved in creating these resources and describes where you can find detailed documentation for these tasks. After the test automation infrastructure is ready, the application testers can begin designing their keyword-driven tests by selecting objects and operation keywords in the Keyword View.

Creating a Shared Object Repository
The tasks involved in creating a shared object repository for the test automation infrastructure can include:
•    Adding (learning) objects from your application.
•    Creating new objects to represent objects that do not yet exist in your application and then later updating the properties and values of these objects as necessary once they exist in the application.
•    Ensuring that objects in the object repository have names that are easy for application testers to recognize and that follow any established object naming guidelines.
•    Copying or moving objects from one repository to another.
•    Merging objects added to local repositories by application testers into the shared object repositories of the automation infrastructure, and merging two or more existing repositories.

Creating a Function Library
The tasks involved in creating a function library for the test automation infrastructure can include:
•    Determining which keywords are needed.
•    Creating and editing function library files in the QuickTest Function Library window.
•    Creating the actual functions within the function libraries. You can do this manually, or you can use the Function Definition Generator to generate function definitions and header information.
•    Defining functions as new or replacement methods for test objects. Debugging the function libraries.

Note: Although not directly associated with the keyword-driven methodology, the automation experts who maintain the object repositories and function libraries also often maintain a set of recovery scenarios that all application testers can associate with their tests.

Deciding When to Use the Keyword-Driven Methodology
You can create the steps in your tests using the keyword-driven methodology, recording, or a combination of both. Recording can be useful in the following situations:
•    Recording is useful for novice QuickTest users. It helps you to learn how QuickTest interprets the operations you perform on your application and how it converts them to QuickTest objects and built-in operations.
•    For the same reasons as described above, recording is also useful for more advanced QuickTest users when working with a new application or major new features of an existing application. It is also helpful while developing functions that incorporate built-in QuickTest keywords
•    Recording can be useful when you need to quickly create a test that tests the basic functionality of an application or feature and does not require long-term maintenance. Keyword-driven testing advantages include the following:
•    Keyword-driven testing enables you to design your tests at a business level rather than at the object level. For example, QuickTest may recognize a single option selection in your application as several steps: a click on a button object, a mouse operation on a list object, and then a keyboard operation on a list sub-item. You can create an appropriately-named function to represent all of these lower-level operations in a single, business-level keyword.

•    Similarly, by incorporating technical operations, such as a synchronization statement that waits for client-server communications to finish, into higher level keywords, tests are easier to read and easier for less technical application testers to maintain when the application changes.
•    Keyword-driven testing naturally leads to a more efficient separation between resource maintenance and test maintenance. This enables the automation experts to focus on maintaining objects and functions while application testers focus on maintaining the test structure and design.
•    When you record tests, you may not notice that new objects are being added to the local object repository. This may result in many testers maintaining local object repositories with copies of the same objects. When using a keyword-driven methodology, you select the objects for your steps from the existing object repository. When you need a new object, you can add it to your local object repository temporarily, but you are also aware that you need to add it to the shared object repository for future use.
•    When you record a test, QuickTest enters the correct objects, methods, and argument values for you. Therefore, it is possible to create a test with little preparation or planning. Although this makes it easier to create tests quickly, such tests are harder to maintain when the application changes and often require re-recording large parts of the test. When you use a keyword-driven methodology, you select from existing objects and operation keywords. Therefore, you must be familiar with both the object repositories and the function libraries that are available. You must also have a good idea of what you want your test to look like before you begin inserting steps. This usually results in well-planned and better-structured tests, which also results in easier long-term maintenance.

•    Automation experts can add objects and functions based on detailed product specifications even before a feature has been added to a product. Using keyword-driven testing, you can begin to develop tests for a new product or feature earlier in the development cycle.

Shortcut Keys Used In QTP

Mercury QuickTest Professional 9.2

Command Press

File Menu

New Test CTRL + N

Open Test CTRL + SHIFT + N

Business Component > New CTRL + SHIFT + O

Business Component > Open CTRL + SHIFT + E

Business Component > Edit

Template

CTRL + O

Save CTRL + S

Export to Zip File CTRL + ALT + S

Import from Zip File CTRL + ALT + O

Print CTRL + P

Edit Menu

Cut CTRL + X (EV only)

Copy CTRL + C

Paste CTRL + V

Delete DEL

Undo Ctrl + Z (EV only)

Redo CTRL + Y (EV only)

Rename Action F2

Find CTRL + F (EV only)

Replace CTRL + H (EV only)

Go To CTRL + G (EV only)

Bookmarks CTRL + B (EV only)

Complete Word CTRL + SPACE (EV only)

Argument Info CTRL + SHIFT + SPACE (EV only)

Apply “With” To Script CTRL + W (EV only)

Remove “With” Statements CTRL + SHIFT + W (EV only)

Insert Menu

Checkpoint > Standard

Checkpoint

F12

Output Value > Standard Output

Value

CTRL + F12

Step > Step Generator F7

New Step F8 (KV only)

New Step After Block SHIFT + F8 (KV only)

Key: KV = Keyword View

EV = Expert View

Test or

Component Menu

Record F3

Run F5

Stop F4

Analog Recording CTRL + SHIFT + F4

Low Level Recording CTRL + SHIFT + F3

Step

Menu

Object Properties CTRL + ENTER

Value Configuration Options CTRL + F11 on a value (KV only)

Debug Menu

Pause PAUSE

Step Into F11

Step Over F10

Step Out SHIFT + F11

Insert/Remove Breakpoint F9

Clear All Breakpoints CTRL + SHIFT + F9

Data Table Options

Edit > Cut CTRL + X

Edit > Copy CTRL + C

Edit > Paste CTRL + V

Edit > Clear > Contents CTRL + DEL

Edit > Insert CTRL + I

Edit > Delete CTRL + K

Edit > Fill Right CTRL + R

Edit > Fill Down CTRL + D

Edit > Find CTRL + F

Edit > Replace CTRL + H

Data > Recalc F9

Insert Multi-line Value CTRL + F2 while editing cell

Activate next/previous sheet CTRL + PAGEUP/

CTRL + PAGEDOWN

General Options

View Keyword View/Expert View CTRL + TAB

Open context menu for step or

Data Table cell

SHIFT + F10

or Application key ( )

Expand all branches * [on numeric keypad] (KV only)

Expand branch + [on numeric keypad] (KV only)

Collapse branch – [on numeric keypad] (KV only)

Test Automation Phases

The Test Automation can be basically split into 5 phases:

· Initiation

· Planning

· Design

· Execution

· Closure

The success of a Automation Test Suite depends absolutely on the Test Initiation and Planning.

Initiation:

· The Decision to go for Automation – Need Analysis

· Overcoming False Expectations – Teaching the Client

· Understand Benefits Of Automation

· Understand the Return on Investment

· System Study \ Understanding the Application

· Define Scope – Functional, Types Of Test, Test Coverage

· Tool Evaluation \ Tool selection

· Proof Of Concept (POC)

· Effort Estimation

· Client Discussions – Tool Evaluation and POC

· Test Automation Contract Sign Off

Planning:

· Test Tool Acquisition

· Team Formation

· Zeroing on Type of Test Management

· Defect Reporting Architecture

· Test Run Reporting Architecture (Study of Business Scenarios \ Test Cases) or (Study of Feature \ Module) (Freezing the Scenarios \ Test Cases) or (Functional Decomposition)

· Test Automation Frame Work

· Test Automation Design Specification Document (Frame Works, Architecture, Approach, Test Conditions, Coding Guide Lines, Naming convections, Test Design Life Cycle)

· Test Automation Strategy

· Preparation of Project Plan

· Client Review – Test Automation strategy, Test Automation Design Specification Document, Project Plan

· Approved – Test Automation strategy, Test Automation Design Specification Document, Project Plan

· Test Environment Setup

Design:

· General Settings setup, Test Setting Setup

· Object Identification Setup, Customizing Objects

· Recording Modes, Recording Levels, Active Screen recording Levels

· Data Sheet Design

· Recording Test Scenarios \ Functionality (Minimum process record)

· Adding to Object Repository, Creating Object Repository Files

· Parameterization of Data

· Enhancement Of Scripts

· Backend Data Base Verifications

· Addition of Functionalities, Methods, Logic

· Adding Custom Libraries and Use of External Scripts

· Design of Test Report \ Results

· Design of Bug Reporting – Defect Tracking Mechanisms

· Unit Test of Test Scripts using Trial Test Data

· Debugging of Unit Tests based upon generated Results

· Script Review and Version Control (Internal Review & Client Review)

· Daily, Weekly Status Report – Client Updates

Execution (Trial Run for Freezing of Scripts):

· Mapping Generated Tests to High Level Scenarios (Creation Of Test Sets)

· Test Data Preparation

· Setting Up the Test Environment – Hardware

· Configuring the Application Under Test (AUT)

· Setting Up the Test Environment – Software – Manual & Automated

· Trial Runs on Test Sets (80% of Coverage)

· Analysis Of Test Results

· Functional

· Test Result – Pass \ Fail

· Test Flow

· Test Data

· Object Level Validations

· Debugging Of Tests based upon Test Results

· Functional

· Logical

· Conditions and Controllers

· Reports and Results

· Test Script – Program Code

· Daily, Weekly Status Report – Client Updates on Test Runs

· Freezing of Tests and Test Data

· Review of Tests, Test Data, Results \ Reports (Internal Review & Client Review)

· Delivery of Tests and Test Data to Test Server, Test Management Tool, Version Control and Back Up

Closure:

Final Test Automation Check List (Scope vs. Coverage)

Test summary Report

Test Deliverables:

o Test Automation Strategy

o Test Automation Design Specification Document

o Project Plan

o Process Manuals (Test Manual, Data Design Manuals)

o Sample Test Data (Used for Debugging Scripts)

o Freezed Tests

o Freezed Test Data (Live)

Project Debrief

Project Summary Report

Running Automation Scripts on a Remote Computer

How do you run Automation Scripts on a Remote Computer ?

By default, when you create an Application object in your automation script, it is created on your local computer (using your local copy of QuickTest Professional). You also have the option to run automation scripts on a remote QuickTest computer. To do so, you must:

• Ensure that the Distributed COM (DCOM) Configuration Properties of the remote computer are set to allow you to run QuickTest Professional Automation from your computer.
• Specify the remote computer in the automation script in the application creation script line, for example, using the optional location argument in the VBScript CreateObject function.

Setting DCOM Configuration Properties on the Remote Computer

QuickTest automation enables QuickTest to act as a COM automation server. Therefore, to run a QuickTest automation script on a remote computer, you must ensure that the DCOM configuration properties for that computer give you the proper permissions to launch and configure the QuickTest COM server.

The procedure below describes the steps you need to perform on the remote computer to enable your automation script to run on that computer. Note that the DCOM Configuration Property the appearance and names of the dialog boxes and options mentioned here may vary depending on the computer’s operating system.

To enable automation scripts to access a QuickTest computer remotely:

1. On the computer where you want to run the automation script, choose Start > Run. The Run dialog box opens.
2. Enter dcomcnfg and click OK. The Distributed COM Configuration Properties dialog box or the Component Services window opens (depending on your operating system) and displays the list of COM applications available on the computer.
3. Select QuickTest Professional Automation from the list and open the Properties dialog box for the application. (Click the Properties button or right-click and choose Properties, depending on your operating system.)
4. In the QuickTest Professional Automation Properties dialog box, click the Security tab.
5. In the launch permissions section, choose the custom option and click Edit.
6. Use the Add and Remove options to select the network users or groups for which you want to allow or deny permission to launch QuickTest Professional via an automation script. When you are finished, click OK to save your settings.
7. Repeat steps 5 and 6 for the configuration permissions section to select the users or groups who can modify QuickTest Professional configuration options via an automation script.
8. In the QuickTest Professional Automation Properties dialog box, click the Identity tab and select the interactive user option.
9. Click OK to save the QuickTest Professional Automation Properties settings.
10. Click OK to close the Distributed COM Configuration Properties dialog box or the Component Services window.

Creating an Application Object on a Remote Computer

Once you have set the necessary DCOM Configuration settings for a remote computer, you can specify that computer in your automation script.

In VBScript, you do this by specifying the computer name as the optional location argument of the CreateObject function. The computer name should be the same as the computer name portion of a share name. For example, to run an automation script on a computer called MyServer, you could write:

Dim qtApp

Set qtApp = CreateObject(“QuickTest.Application”, “MyServer”)

For information on the syntax for specifying the remote computer in another language you are using, refer to the documentation included with your development environment or to general documentation for the programming language.

The Properties tab of the Test Settings dialog box, the General tab of the Options dialog box, and the Object Identification dialog box each contain a Generate Script button. Clicking this button generates an automation script file (.vbs) containing the current settings from the corresponding dialog box.

You can run the generated script as is to open QuickTest with the exact configuration of the QuickTest application that generated the script, or you can copy and paste selected lines from the generated files into your own automation script.

For example, the generated script for the Options dialog box may look something like this:

Dim App ‘As Application

Set App = CreateObject(“QuickTest.Application”)

App.Launch

App.Visible = True

App.Options.DisableVORecognition = False

App.Options.AutoGenerateWith = False

App.Options.WithGenerationLevel = 2

App.Options.TimeToActivateWinAfterPoint = 500

…

…

App.Options.WindowsApps.NonUniqueListItemRecordMode = “ByName”

App.Options.WindowsApps.RecordOwnerDrawnButtonAs = “PushButtons”

App.Folders.RemoveAll

For more information on the Generate Script button and for information on the options available in the Options, Object Identification, and Test Settings dialog boxes,

Description Object

Description Object

Description object is used to create an empty description object in the script. We can add properties and values to the created object.

Using an empty Description object

Set obj=Description. create

Here “obj” is an empty object and contains no properties. This refers any object in application.

Ex:-

Set obj=Description. create

Set objList=Browser(“micclass:=Browser”).Page(“micclass:=Page”).Childobjects( obj)

Msgbox objList.count ‘Gives Total objects count in the page

Using Description object with properties

Set obj=Description. create

obj(“micclass”).value=”Link”

Now “obj“is a link object and it refers all link objects in application.

Ex:-

1)

Set obj=Description. create

obj(“micclass”).value=”Link”

Set objList=Browser(“micclass:=Browser”).Page(“micclass:=Page”).Childobjects( obj)

Msgbox objList.count ‘Gives Total Link objects count in the page

2)

Set obj=Description. create

obj(“micclass”).value=”Link”

obj(“name”).value=”Login”

Set objList=Browser(“micclass:=Browser”).Page(“micclass:=Page”).Childobjects( obj)

Msgbox objList.count ‘Gives only the link which is having “Login” name

Description object is useful when object properties are changing dynamically or if objects are adding in application dynamically and also to handle the duplicate objects (repeated objects).

Latest QTP FAQS

1.What is File System Object?

File System is used to create file through scripting.

We can read, write and save data in txt file and use it after wards
during testing.

Here is example of creating txt file through FSO

Const ForReading = 1, ForWriting = 2
Dim fso, MyFile
Set fso = CreateObject( “Scripting. FileSystemObject “)
Set MyFile = fso.OpenTextFile( “c:testfile. txt”, ForWriting, True)
MyFile.WriteLine “Hello world!”
MyFile.WriteLine “The quick brown fox”
MyFile.Close
Set MyFile = fso.OpenTextFile( “c:testfile. txt”, ForReading)
ReadLineTextFile = MyFile.ReadLine ‘ Returns “Hello world!”

It will create testfile.txt and enter “This is a test” in that text
file.

You can later read that line “This is a test” from this file while
using

MyFile.ReadLine

We can save variables data during testing and then use that data in
future instances of testing and then delete that file.

2.Can we perform performance testing by qtp?

we can do the performance testing in QTP, which can be done only for
one user. We can do the performance testing using QTP by inserting
the start and end transactions for getting the response time of each
transaction with single user.

3.How can I execute PL/SQL stored procedure (with parameters)
thorough VBScript?
Here is the code:
conStr=”driver= sql
server;server= servername; database= test;uid= sa;pwd=sa”
Set cmdObj=createobject (“adodb.command” )
Set recObj=createobject (“adodb.recordse t”)
With cmdObj
.activeconnection= conStr
.commandtype= 4
.commandtext= “SP_Insert_ EMP” – SridharName
.parameters. refresh
.parameters( 1).value= 22 – Parameter values that i am passing to SP
.parameters( 2).value= “PULSE TECHNOLOGIES” -
.parameters( 3).value= “QA” -
.parameters( 4).value= 7777 -
.parameters( 5).value= NULL -
.execute
End with