Archive

Posts Tagged ‘Add new tag’

Everything About CheckPoints in QTP

The following section gives a gist of the Check points available in QTP (HP QuickTest Professional) . Though it doesn’t give you a practical idea but it does cover the complete theory part of the check points and types of check points.

Check Points are nothing but verification points which compares the run time value of a specific object with the recorded/expected value of that Object. In other terminology it can be called as validation points in a application.

Ex- Like when a user enter a uername and a password in a application the submit button gets activated. So the tester needs to validate that as soon as the username is entered the Submit button is activated. So in QTP with the use of check point the user can put a button/Standard check point to check whether the button is active or not.

How to Use Check points

  • Check points can be inserted/ added while recording as well as during editing of the script.
  • The check point can be inserted through the Insert menu item.
  • The check points can be inserted through the keyword view by going to the object for which check point will be added.
  • Check point can also be added through the Active screen provided the active screen has captured the property of the object for which check point will be added

Types of Check Points:-

Standard Check Point –

  • Its a normal check point where it checks the property value of an object in your application or web page.
  • It can be used on various types of object like check box,radio button, edit boxes, combo box, button etc.
  • It supports all the add-in environments of QTP.

Image Check Point:-

  • It checks the value of the Image in AUT. Ex-Check that a selected Image’s source file is correct.
  • Image check point is created as a standard check point on a Image object.
  • Image Check points are supported for only Web environments.
  • Unlike Bitmap check point Image check point can not check the bitmap of the image.

BitMap CheckPoint –

  • This check point helps user in checking bitmap of an image or a full web page.
  • During run time the bit map check point can be inserted.
  • Bit map checkpoints are supported for all the add-in environments.

Table Checkpoints:-

  • It checks the information within the table.
  • its created  by inserting a standard check point on a table object.
  • it supports only web and ActiveX environments.
  • It can dynamically check the contents of cells appearing in all environment.
  • It can also check verious table properties like row height, cell width and so on.

Text Checkpoints:-

  • checks that a text string is displayed in the appropriate place in the AUT.
  • it supports all the environments.

Text Area CheckPoints:-

  • It checks that a text string is displayed within a defined area in a windows application according to specified criteria.
  • It support for standard windows, visual basic, ActiveX add-in environments.

Accessibility CheckPoint:-

  • It checks the areas of your website that may not conform to the world wide web consortium (W3C) Web Content Accessibility guidelines.
  • It supports only Web Environments.
  • The user can be instruct QTP for inserting automatic accessibility check point for every page you record.

Page CheckPoints:-

  • Checks the characteristics of a web page.
  • Its created by entering a standard checkpoint on a Page Object.
  • It supports only web environment.
  • Its used to check total number of link and images in the web page.
  • Page check points can be used to check Load time.
  • It can also check the HTML source tags and broken links.
  • Useful for regression testing.

Database CheckPoints:-

  • Checks the content of a database used in AUT.
  • it supports all environments.

XML CheckPoint:-

  • It checks the data content of XML documents in XML files or XML documents in web pages and Frames.
  • XML check points for web pages/frames are supported for Web environments and for Files are supported by all environments.

NOTES

– Standard check point is supported in all add-in environments.

– the Insert statement option is not available while adding a check point during recording and when modifying an existing object check points.

Please have a look to this and share your comments and feedback to enhance this.

Enhanced by Zemanta

TestCase Developement

Looking at so many projects which runs into problems because of client finding out defects in either production or client testing, though test execution plays big role but I feel test coverage plays a bigger role. I agree exhaustive testing is not possible but the target should be to test all possible path and bigger challenge is to identify all the possible path. The conventional way of writing test cases is not enough to achieve a good test coverage. You need to have a different approach matching today’s application complexity. With my experience I feel if we do just reverse of what we are doing in test case writing cycle will help.

Normally once we complete writing test cases we used to review the test cases based on the checklist which contains all the types of test cases possible for this project. I feel we should have a robust checklist which should be designed based on the domain and technology used in developing the application. While we start writing test cases instead of straightway writing the test cases if we first find out the scenarios and then match those scenarios with the checklist then probably we will have a small test case writing cycle and since the checklist is tailor made for the application we hardly miss scenarios. But this approach of test case writing has a dependency on how good is your checklist and how well it cover all the scenarios possible in the application. The following points can be considered while preparing the checklist.

Functionality – It should contain all the functionality scenarios, or the happy paths of the application which we say the positive scenarios. The positive scenarios can be found out from the SRS or Use cases. We normally don’t miss those scenarios as long as the project modules are tightly coupled. If that’s the case then we need to have knowledge on the complete flow of the application to write all the positive scenarios.

Negative Scenario – This is where we miss the scenarios and having maximum challenge .Most of the associates not able to identify all the negative scenarios possible. So the checklist should contain check points for all types of negative scenarios possible for the application. Negative scenario may be based on functionality, scenario based on data, scenarios related to DB, scenarios related to experience based on the domain, scenarios based on the technology etc.

Test data – The test data should be extensive. We should consider boundary value and equivalence partitioning where ever applicable. Normally what we do is we find out the business data and forget about the negative data and field level validation data. So the checklist should have the check points for such data as well.

Non-Functional – Non functional scenarios are basically kind of negative scenarios and basic level of security scenarios like user click the browser back button, click on the refresh button, user copy the url and paste in the address bar and access the application, user closes browser without closing the application etc. The checklist should cover those points as well.

Abnormal Scenarios – Abnormal scenarios are those like if the LAN cable is disconnected, Internet is down, DB is down and Server is down etc. These should give proper error message to user instead of misguiding the user.

Database checks – we normally forget the database checks for the actions we are doing on the application.  For every database action there should be a database check to ensure the DB entry is happening. And also the negative test should not entering data into the DB.

Experience – Experience plays a big role in preparing the checklist. With experience related to the domain and technology you can add check points which normally happens to be defect with the corresponding technology and domain.

Security – Apart from the authentication and authorization related security issues  the checklist should have check points for the security testing like SQL injection, CSS, LDAP ,XSS injections, concurrency issues etc.

All these points I guess will help you in getting a  good test coverage provided the checklist is prepared well. But don’t forget to do a monkey testing after each cycle of testing and convert the monkey testing defects into test cases.   I have implemented this approach successfully.

Reblog this post [with Zemanta]

Acceptance Testing (UAT)

The New Black Box
Image via Wikipedia

The user acceptance testing is usually a black box type of testing. In other words, the focus is on the functionality and the usability of the application rather than the technical aspects. It is generally assumed that the application would have already undergone Unit, Integration and System Level Testing. However, it is useful if the User acceptance Testing is carried out in an environment that closely resembles the real world or production environment.

The steps taken for User Acceptance Testing typically involve one or more of the following: …….1) User Acceptance Test (UAT) Planning …….2) Designing UA Test Cases …….3) Selecting a Team that would execute the (UAT) Test Cases …….4) Executing Test Cases …….5) Documenting the Defects found during UAT …….6) Resolving the issues/Bug Fixing …….7) Sign Off User Acceptance Test (UAT)

Planning: As always the Planning Process is the most important of all the steps. This affects the effectiveness of the Testing Process. The Planning process outlines the User Acceptance Testing Strategy. It also describes the key focus areas, entry and exit criteria.

Designing UA Test Cases: The User Acceptance Test Cases help the Test Execution Team to test the application thoroughly. This also helps ensure that the UA Testing provides sufficient coverage of all the scenarios.The Use Cases created during the Requirements definition phase may be used as inputs for creating Test Cases. The inputs from Business Analysts and Subject Matter Experts are also used for creating.Each User Acceptance Test Case describes in a simple language the precise steps to be taken to test something.The Business Analysts and the Project Team review the User Acceptance Test Cases.

Selecting a Team that would execute the (UAT) Test Cases: Selecting a Team that would execute the UAT Test Cases is an important step. The UAT Team is generally a good representation of the real world end users. The Team thus comprises of the actual end users who will be using the application.

Executing Test Cases: The Testing Team executes the Test Cases and may additional perform random Tests relevant to them Documenting the Defects found during UAT: The Team logs their comments and any defects or issues found during testing.

Resolving the issues/Bug Fixing: The issues/defects found during Testing are discussed with the Project Team, Subject Matter Experts and Business Analysts. The issues are resolved as per the mutual consensus and to the satisfaction of the end users.

Sign Off: Upon successful completion of the User Acceptance Testing and resolution of the issues the team generally indicates the acceptance of the application. This step is important in commercial software sales. Once the User “Accept” the Software delivered they indicate that the software meets their requirements. The users now confident of the software solution delivered and the vendor can be paid for the same.

Reblog this post [with Zemanta]
%d bloggers like this: