QTP Automation Object Model Simplified | QTP AOM

We received couple of queries on QTP AOM. In this post we simplified the QTP AOM, so that a newbie in QTP can also understand what is Automation Object Model and how it works.
Automation is a technology through which we can access software objects inside one application from other applications. This can be done by VB scripting, VC++, Visual Basic, Javascript etc. So automation helps in managing the functionality of an application programmatically.


Object Model – Every software system consists of some objects & classes. System works because of these objects. And Object model is nothing but an object model is a structural representation of objects and classes. An object model defines a set of classes and interfaces, together with their properties, methods and events, and their relationships.


QTP Automation Object Model – Concluding from above two definitions – We can access QTP objects and control/managing its functionality by VB script. For example –

  • We can open QTP with the help of vb script.
  • We can run QTP tests without opening QTP manually. By vbscript, we can invoke QTP and define the testes which need to be executed.
  • We can set iterations for the execution of the test script and can also pass parameters.

All the above statements/conditions are defined in a vbscript. VBscript opens QTP and manages above functionality.


How this can be done? How VBscript controls QTP?
QTP provides an interface (object model), through which we can automate QTP itself by vbscript. By this we can automate tasks like – Run and configure QTP, Run scripts etc.
See below examples –  Run QTP – Copy the below code and pate in notepad, same file as “ABC.vbs”.
Dim qtApp
Set qtApp = CreateObject(“QuickTest.Application”) ‘ Create the application object
qtApp.Launch ‘Start QuickTest
qtApp.Visible = True ‘ Make it visible
Now Run the “ABC.vbs”. It will open QTP.


Simple way to create script for automating QTP:
QTP also provides the option to generate the automation script (which controls the automation and functionalities of QTP). For this, first you need to open QTP manually and define all the appropriate QTP settings like – test settings, results settings, Options, Action settings, iteration settings etc.
Now go to Test Settings -> In General tab and Object Identification tab, there is “Generate Script” button. Clicking on the button will generate a vbs file with the defined settings.

In Next post we will discuss when to use these QTP automation scripts.

Rate Yourself in Software Testing | Skills of a Professional Tester | Lets become Test Professional from Test Dummies.

Today employers want test professionals – not test dummies. There are unique skills of testers that are highly desired by employers to make the testing process more efficient and effective. See the checklist for a cross-section of the desirable skills of a test professional
✚ Know the best places to find bugs and defects and most effective methods for uncovering them
✚ Know how to prioritise testing based on risk exposure
✚ Develop test strategies that balance testing needs against management budget and commitment
✚ Apply testing methodologies, processes and analysis techniques
✚ Possess basic technical skills to aid testing (e.g.scripting in VB/Perl/batch files), fundamentals of SQL, MS Office tools for data collation, and report
generation
✚ Understand test automation tools and frameworks, including the advantages, disadvantages and adoption process
✚ Know inspection and review techniques
✚ Understand non-functional test issues, such as load and performance, availability, failover/recovery, compatibility, usability and security
✚ Manage and coordinate testing projects
✚ Build a test team and foster an effective test team culture
✚ Collect metrics and measurements to assess effectiveness of testing and quality of the product, and reporting mechanisms to inform management
of outcomes
✚ Know approaches to improving test processes.

Not everyone in the team needs to have all these skills – in fact, it would be quite uncommon to be experienced in all areas. However, there should be a strategy to ensure that a team can be assembled with a diverse cross-section of these skills. If you are an employer, consider including these skills in the tester’s position description. If your staff are lacking in some of these areas, ask yourself what it is costing your projects, and plan a strategy for increasing the skills of your existing team and/or seeking additional staff. If you are a tester, do a quick check to see whether you have these skills, as well as experience in these areas. If you are missing some, develop a strategy to increase your skills base – you will reap the rewards.


Other Comments: It is possible that Certified Software Testing Professionals with unique skills in test management, test automation, and load/performance testing, may increase their prospects of employment and income. Certification is required, reason is – “Clients demands that they need only certified people in their project” or “‘Companies convince their clients by saying that we have certified software test professionals, we deliver a high quality product.”

For further information on CSTP certification Contact “Dr Kelvin Ross” who is the coordinator for the CSTP program. E-mail: kelvinr@kjross.com.au
Source – K. J. Ross & Associates provides specialist services in software verification and validation, including test management, risk assessment and test strategy, test process
improvement, test outsourcing, automated testing, load and performance testing, independent test laboratory, and training and mentoring.
Visit: www.kjross.com.au

Effective Practical Test Reporting Tips & Techniques | Software Testing Summary Reports Generation

Effective Practical Test Reporting Tips & Techniques | Software Testing Summary Reports Generation




status-report
Testing is very important phase in the Life Cycle of Software Development so whatever the work testers and test lead are doing in this Phase it should be properly documented and testers should be able to provide the needful information in proper Reports. Here are some important documents, their frequency and the reason for those documents have a look at it:

Test Documentation Frequency Reason
High Level Test Plan Each project A test plan is produced for each project. It defines what functions will be tested and what functions will not be tested. This document will detail any risks and contingencies as well as stating assumptions and defining required resources.
Test Specification Each stage This document details the test conditions and test cases for each stage of testing. This will be used by the testers in the running of their tests.
Test Logs Each stage Test Logs are to be produced by each tester – this will enable progress to be monitored and controlled. It will also provide a suitable test audit at the end of the project.
Test Progress Report Weekly This report will provide managers with a weekly progress on the testing being carried out. ‘S’ curves to show test progress will be used as well as faults found/fixed.
Test Summary Report When required This summary report will be produced when requested by Senior Management at any stage of the development lifecycle. This will be a condensed version of the Test Progress Report specifically aimed at Senior Management.
Post Project Report Each project At the end of each project a ‘Post Project Review’ will be carried. This activity will contain an analysis of what went well and what didn’t go well in terms of the project. A report will be produced detailing the changes for process improvement.

Some or all of the following charts should be used to monitor progress. It is recommended that the graphs be displayed clearly on a wall so everyone is made aware of the current situation. Charts, rather than tables, are also recommended since they are easier to read and are more likely to attract attention and be taken notice of:

Faults Found:
Fault Found in each day of testing
This chart simply logs the number of faults found during each day of the test schedule. The severity of faults could be indicated by using different columns on the chart.
Faults Found vs. Faults Fixed:

Fault Found vs Faults fixedMonitoring the number of faults found together with the number of faults fixed is a useful way to spot potential scheduling problems early. In the example above the increasing gap between the number of faults found and the number fixed suggests that more development effort is needed to fix more of the outstanding faults. Leaving these until the last moment invariably ends in disaster (delayed release, poor quality system, or both).
Tests Run and Tests Passed vs. Tests Planned:

Tests Run and tests Passed vs Planned
Since we will know at the start of a test effort how many tests we are intending to run (defined by the scope) it is possible to plan the number of tests that should be completed each day of the test effort. This will normally look like an S-Curve, as shown on the example graph above (this is a third-order polynomial). Plotting both the number of tests actually run and the number of tests that have passed will quickly highlight any of a number of problems. For example, if the number of tests run falls below the number planned then either more testers or more time will be needed. If the number of tests passed falls much below the number run (i.e. if a large number of tests fail) then more faults than expected are being found and this will impact both the test team and the developers.
Faults Per Owner:

Faults per Owner
It is important to know how many faults are being worked on at any one time and by whom. This chart will show whether there is a balance of faults being assigned to the team. Each “column” on the bar chart can show priority and/or severity for further analysis.
Number of Defects for each Cycle:
This Graph shows the number of bugs (New bugs, Assigned Bugs, Open Bugs, Fixed Bugs, Reviewed-not-ok Bugs, Closed Bugs, Deferred Bugs) in each cycle for every release. The status of the bugs may be different from company to company. So based on the company the testers have to change the Status in Graph.
 Testing Cycle vs Defect Status Number of different severity bugs in each Cycle:
This Graph shows the number of bugs of different severity (Critical bugs, Major Bugs, Minor Bugs, Cosmetic Bugs) in each cycle for every release. This Severity also each and every organization maintains their own standards so it may be different from company to company. Based on their own standards they have to change the Graph.
Test Cycles Vs Severity

Number of different severity bugs in each Test Level:
This Graph shows the number of bugs of different severity (Critical bugs, Major Bugs, Minor Bugs, Cosmetic Bugs) in test level (Unit Testing, Integration Testing, System Testing and User Acceptance Testing) for every release. This Severity also each and every organization maintains their own standards so it may be different from company to company. Based on their own standards they have to change the Graph.

Type of testing Vs Bug Severity
 Number of different severity bugs in each Version:

This Graph shows the number of bugs of different severity (Critical bugs, Major Bugs, Minor Bugs, Cosmetic Bugs) in each Version. This Severity also each and every organization maintains their own standards so it may be different from company to company. Based on their own standards they have to change the Graph.
Version vs Bug Severity

End of the day reports for Testing Engineer:

For each individual Tester he can prepare a separate report for each and every task
End of the day reports for Testing Engineer.doc

Reports generated by Test Lead


For Test Lead he is having so many tasks like Client Meeting, Conference Calls, Test Strategy, Test Plan preparation, Knowledge Transfer, Organization internal meetings and Meeting with Testers.
But here are some important reports:
Reports generated by Test Lead.doc
 ————————————————————————————————————
Author – unknown. [Posted from our old forum and old blog. If you know the author, or if you are the author please contact us, we will update the  post]

Tips to Prioritizing the tests | A way to achieve Time-boxing in testing

A common problem is faced in testing phases (especially when UAT/release is near) – There are so many tests for testing/execution but there is so less time. In 2004, Johanna Rothman gives a recipe in her article “So Many Tests, So Little Time
| TimeBox the testing”. From Johanna’s article, I conclude that Prioritizing the tests is one important step to achieve time-boxing in testing.


For those who don’t know what is time-boxing:
Time-boxing is a well-established project management (time management technique) used to limit project scope in a fixed duration by forcing tradeoffs. Time-boxing is a valuable technique for testing as well. For example you need to test the application before UAT and there are only 4 weeks left.
Here we will discuss, how to prioritize tests (test scripts/test cases), complete the most important tests in given time and deliver a high quality product. There can be many other best practices for time-boxing the testing but Prioritizing the tests is one important step to achieve time-boxing in testing.


Why to Prioritize Tests:

  • We can’t test everything.
  • There is never enough time to do all testing you would like.

(Read Testing Limitations)
Tips to Prioritizing the tests:

  • Possible ranking criteria ( all risk based)
  • Test where a failure would be most serve (take help from development team)
  • Test where failures would be most visible (take help from development team)
  • Take the help of customer/Business Analyst in understanding what is most important to him.
  • What is most critical to the customers business? (Take the help of customer/Business Analyst)
  • Areas changed most often. (take help from development team)
  • Areas with most problems in the past. (take help from development team)
  • Most complex areas, or technically critical. (take help from development team, Business Analyst)

Note: If you follow above, whenever you stop testing, you have done the best testing in the time available.

Choosing right scripting technique/Framework for Automation Testing

While planning for automation testing for any project, a tough question for Testing automation engineers are – “Which automation scripting techniques or framework should be chosen?”
Choosing right framework/scripting technique helps in maintaining the costs and maintaining good ROI. Costs associated with test scripting are due to the development effort and the maintenance efforts. The approach of scripting used during test automation has effect on the costs


Various framework/scripting techniques are generally used:
1. Linear (simple record and playback)
2. Structured (uses control structures – typically ‘if-else’, ‘switch’, ‘for’, ‘while’ conditions/ statements)
3. Hybrid
4. Data driven (data is separated and stored in external excel sheets)
5. Keyword driven


Note:

  • In Easy techniques like record and playback, there is low development cost but high maintenance cost.
  • In Advanced techniques like keyword driven testing, there is high development cost but low maintenance cost.

So Test managers/test Architects should be wise in choosing the right automation framework. Test managers need to identify the following for each scripting technique / framework:

  • Is the approach structured?
  • How much programming/development is required? As scripting approach changes from liner to keyword driven scripts, the development costs are increases.
  • What kind of programming skills needed? Like – In linear less proficiency is required in programming, but in keyword driven more proficiency is required in programming.
  • How much planning and management efforts required for the automation project? Planning required managing the automation project increases as we move from linear to Keyword framework.
  • How much Maintenance is required? Maintenance cost of automation project decreases as we move from linear to Keyword framework.

References:
1. Software Test Automation: Effective use of test execution tools by Dorothy Graham and Mark Fewster

Selenium for Functional testing of web applications

Functional testing and black box is a methodology used to test the behavior that has an application from the viewpoint of their functions, validated for this purpose various aspects ranging from the aesthetics of the front end, the navigation within your pages between pages within the forms, the compliance of technical specifications associated with fields, buttons, bars, among other pages, entry permits and access to consultations and modifications, management of parameters, the management of the modules that constitute , and other conditions that make up the various “features” expected to provide the system to operate the end user as a normal and correct.
To meet this objective, the tester must choose a set of inputs under certain pre-defined within a certain context, and to check whether the outputs are correct or incorrect depending on the outcome defined in advance between the parties and / or techniques for the customer / supplier.

This form of testing an application is made “outside”, that is why “black box testing” because the test covers the roads that follow the internal procedures of the program.

In connection with this test, although there are many tools now that this one out for various reasons will be published in future articles is: Selenium.

Selenium works directly on the web browser, its installation is simple and handling is so intuitive that allows quickly define and configure a test case, recording the journey in a page and then save the sequence of steps as a test script and and then play it when you want.
Useful points:

  • Selenium is an open-source tool that not only allows the testing of the system but also facilitates the acceptance testing of web applications.
  • Integrates with Firefox, and includes the ability to write the tests directly in Java, C #, Python and Ruby.
  • This solution has three basic tools to record a sequence of steps within a website, simulate the test with different browsers and automated test generation.
  • Selenium IDE is a plug-in for Firefox which allows you to record and execute scripts directly from your browser.
  • Selenium RC is a library and server written in Java that allows you to run scripts from local or remote through commands.
  • Grids Selenium: Selenium server allows multiple coordinate in order to run scripts on multiple platforms and devices at the same time.

Download – Selenium IDE is a plug-in for Firefox.

Useful links

  • Firefox Install Link
  • Firefox Addons Link
  • OpenQA WebSite