Monday, 17 February 2014

what is the use of validation automation testing

The process of evaluating software during or at the end of the development process to determine whether it satisfies specified business requirements.
To ensure that the product actually meets the user’s needs, and that the specifications were correct in the first place. In other words, to demonstrate that the product fulfills its intended use when placed in its intended environment.
Determining if the system complies with the requirements and performs functions for which it is intended and meets the organization’s goals and user needs.
Validation is done at the end of the development process and takes place after verifications are completed.
It answers the question like: Am I building the right product?
Am I accessing the right data (in terms of the data required to satisfy the requirement).
It is a High level activity.
Performed after a work product is produced against established criteria ensuring that the product integrates correctly into the environment.
Determination of correctness of the final software product by a development project with respect to the user needs and requirements.

According to the Capability Maturity Model(CMMI-SW v1.1) we can also define validation as The process of evaluating software during or at the end of the development process to determine whether it satisfies specified requirements. [IEEE-STD-610].
The most tested attributes in validation tasks may include, but are not limited to
  • Selectivity/specificity
  • Accuracy and precision
  • Repeatability
  • Reproducibility
  • Limit of detection – especially for trace elements
  • Limit of quantification
  • Curve fitting and its range
  • System suitability


Tuesday, 11 February 2014

Unit testing with JUnit



JUnit is a unit testing framework for the Java programming language. JUnit has been important in the development of test-driven development, and is one of a family of unit testing frameworks collectively known as xUnit that originated with JUnit.
we'll define a unit test as a test of a single isolated component in a repeatable way. Let's go thru that one section at a time to get a clearer idea of what goes into a unit test.

"a test". This means to verify something is correct. In order for us to have a valid unit test, we need to actually validate that after a start condition A, an end condition B exists. "...a single isolated component...". This is what separates a unit test from other types of tests.
 In order for it to be a unit test, it must test something in isolation, aka without dependencies. The reason for this is that we are testing the component itself and not it's interaction with other components (that is an integration test).
Finally, although most definitions don't include this piece, "...in a repeatable way" is a very important piece of the definition. It's one thing to run a test that passes. It's quite different to have something you can run in a repeatable manor at any point to see if changes you made effected how the component behaves. For example, if you choose to do some refactoring to improve performance, can you rerun your unit test to verify that you didn't change the behavior of the component.

In test driven design, we develop the unit test before the functionality. We write a test that verifies that the class should do X after our call. We prove that the test fails, we then create the component to make the test pass. In this case, we are going to create a service with a method that authenticates a user. Below is a class diagram of the scenario.

JUnit class diagram
The interfaces
We will start our coding by defining two interfaces, LoginService and Userx We will implement LoginService, For LoginService, we have a single method that takes a String userName and String password and returns a boolean (true if the user was found, false if it was not). The interface looks like this:

Provides authenticated related processing.
public interface LoginService {
     Handles a request to login.  Passwords are stored as an MD5 Hash in
     this system.  The login service creates a hash based on the paramters
     received and looks up the user.  If a user with the same userName and
     password hash are found, true is returned, else false is returned.
     boolean login(String userName, String password);
}
The Userx  interface will look very similar to the LoginService. It will have a single method that takes a userName and hash. The hash is an MD5 hashed version of the password, provided by the above service.

Provides database access for login related functions
public interface User x{
 Loads a User object for the record that
 is returned with the same username and password.

     User loadByUsernameAndPassword(String userName, String password);
}
The test case
Before we begin development, we will develop our test. Tests are structured by grouping methods that perform a test together in a test case. A test case is a class that extends junit.framework.TestCase. So in this case, we will begin by developing the test case for LoginService. To start, in your test directory, create a new class named LoginServiceTest and make it extend junit.framework.TestCase.

The lifecycle of a test execution consists of three main methods:

public void setUp()
setUp is executed before each of the test. It is used to perform any setup required before the execution of your test. Your implementation will override the default empty implementation in TestCase.
testSomething is the actual test method. You may have many of these within a single test case. Each one will be executed by your test runner and all errors will be reported at the end.
public void tearDown()
tearDown is executed after each test method. It is used to perform any cleanup required after your tests.
So to begin flushing out our test case, we'll start with the setUp method. In this method, we'll instantiate an instance of the service to be tested. We'll also create our first mock object, UserDAO. You can see the source of our test below.


Monday, 10 February 2014

How To Use DOM



The Document Object Model represents an HTML document and can be accessed using JavaScript. This location strategy takes JavaScript that evaluates to an element on the page, which can be simply the element’s location using the hierarchical dotted notation.

Since only dom locators start with “document”, it is not necessary to include the dom= label when specifying a DOM locator.
DOM stands for Document Object Model. DOM is convention for representing objects in HTML documents. Selenium interact with these objects using javascript.

</pre>
<form id="loginForm">Login Username: <input id="username" type="text" name="username" />
 Password: <input type="password" name="password" />
 <input type="submit" name="login" value="Log in" /></form>
<pre>
In this page, you can locate the highlighted input field using:
document.forms[0].elements[0]
document.forms['loginForm'].elements['username']
dom=document.forms['loginForm'].username
dom=document.getElementById('username')

You can use Selenium itself as well as other sites and extensions to explore the DOM of your web application

Tuesday, 4 February 2014

what is the use of validation in automation testing


The process of evaluating software during or at the end of the development process to determine whether it satisfies specified business requirements.
To ensure that the product actually meets the user’s needs, and that the specifications were correct in the first place. In other words, to demonstrate that the product fulfills its intended use when placed in its intended environment.   
Determining if the system complies with the requirements and performs functions for which it is intended and meets the organization’s goals and user needs.
    Validation is done at the end of the development process and takes place after verifications are completed.
    It answers the question like: Am I building the right product?
    Am I accessing the right data (in terms of the data required to satisfy the requirement).
    It is a High level activity.
    Performed after a work product is produced against established criteria ensuring that the product integrates correctly into the environment.
    Determination of correctness of the final software product by a development project with respect to the user needs and requirements.

According to the Capability Maturity Model(CMMI-SW v1.1) we can also define validation as The process of evaluating software during or at the end of the development process to determine whether it satisfies specified requirements. [IEEE-STD-610].
The most tested attributes in validation tasks may include, but are not limited to
·         Selectivity/specificity
·         Accuracy and precision
·         Repeatability
·         Reproducibility
·         Limit of detection – especially for trace elements
·         Limit of quantification
·         Curve fitting and its range
·         System suitability


Tuesday, 28 January 2014

Working with Different Drivers Like HtmlUnitDriver,FirefoxDriver, InternetExplorerDriver


The existing drivers are the ChromeDriver, InternetExplorerDriver, FirefoxDriver, OperaDriver and HtmlUnitDriver. including their relative strengths and weaknesses There is also support for mobile testing via the AndroidDriver, OperaMobileDriver and IPhoneDriver
While working with selenium webdriver you have an option to choose from multiple webdrivers, such as HtmlUnitDriver, FirefoxDriver, InternetExplorerDriver, ChromeDriver and OperaDriver. Each one of them is a separate implementation of the WebDriver interface provided by Selenium.
The first major point to note is that there are two groups of driver implementations. One of those that invoke the actual browser installed on your system and the other that emulates the behavior of another browser. FirefoxDriver, InternetExplorerDriver, ChromeDriver and OperaDriver invoke the actual browser installed on the machine; however the HtmlUnitDriver emulates other browsers JS behavior.
This is currently the fastest and most lightweight implementation of WebDriver. As the name suggests, this is based on HtmlUnit.
·         Fastest implementation of WebDriver
·         A pure Java solution and so it is platform independent.
·         Supports Javascript

 HtmlUnit is a java based framework for testing webApps basically a wrapper around ‘HttpClient’ by Jakarta. HtmlUnit provides UI-Less emulation of browsers to test web applications. The HtmlUnit APIs let you do the typical functions performed in an actual web browser, such as click links, fill forms, invoke web pages, submit values etc. HtmlUnit supports java script and complex AJAX libraries. Javascript is disabled in the HtmlUnitDriver by default, however if it can be enabled if required. The mechanism to enable javascript with the HtmlUnitDriver is as follows:

HtmlUnitDriver MyhtmlDriver = new HtmlUnitDriver();
 MyhtmlDriver.setJavascriptEnabled(true);
OR
HtmlUnitDriver MyhtmlDriver = new HtmlUnitDriver(true);

When enabled, the HtmlUnitDriver emulates the java script behavior of Internet Explorer by default. However we can direct the HtmlUnitDriver to emulate the JavaScript behavior of the browser of our choice by invoking the constructor that accepts the browser version. This can be done as follows:
HtmlUnitDriver MyhtmlDriver = new HtmlUnitDriver(BrowserVersion.Firefox_2);
The InternetExplorerDriver is a standalone server which implements WebDriver's wire protocol. This driver has been tested with IE 6, 7, 8 and 9 on appropriate combinations of XP, Vista and Windows 7.

The driver supports running 32-bit and 64-bit versions of the browser. The choice of how to determine which "bit-ness" to use in launching the browser depends on which version of the IEDriverServer.exe is launched. If the 32-bit version of IEDriverServer.exe is launched, the 32-bit version of IE will be launched. Similarly, if the 64-bit version of IEDriverServer.exe is launched, the 64-bit version of IE will be launched.
 The IE driver class ‘InternetExplorerDriver.class’ is located at ‘\org\openqa\selenium\ie\’ directory in the ‘selenium-server-standalone-2.7.0.jar’. To use the InternetExplorerDriver all you need to do is to have the selenium-server-standalone-2.7.0.jar in your CLASSPATH.  The IE driver runs only on windows and supports both 32-bit and 64-bit operations. Depending on the thread that instantiates the InternetExplorerDriver corresponding version of the IE is launched i.e. if the thread instantiating driver is running in 32-bit then the 32-bit version of the IE will be launched and if the thread instantiating driver is running in 64-bit then the 64-bit version of the IE will be launched.

The Internet Explorer driver uses the native or OS-level events to perform various functions on the browser, such as inputs from keyboard and mouse. This approach has both advantages and limitations both. The advantages are that it bypasses the limitations of the Javascript sandbox but there can be issues like the browser window under test might be out of focus.

‘selenium-server-standalone-X.X.X.jar’ contains all the drivers implementing the WebDriver interface of selenium. Hence the 'FirefoxDriver.class' can be found in the ‘\org\openqa\selenium\firefox directory in the selenium-server-standalone-X.X.X.jar. The driver when instantiated is added as an extension to the firefox profile. You can specify the profile with which you want to load firefox session. If no profile is specified then the driver creates an anonymous profile by default.
A profile can be created for the firefox driver as follows:

FirefoxProfile myProfile = new FirefoxProfile();

Multiple operations can be performed on the newly created profile, such as:

myProfile.addExtension(File);
myProfile.clean();
myProfile.getPort();
myProfile.setPort(int port);
myProfile.enableNativeEvents();
myProfile.setPreference(String key, String value); etc...

After creating the your profile you can pass the profile while creating the driver instance as follows:
WebDriver myFireFoxDriver = new FirefoxDriver(myProfile);

This driver is faster than the InternetExplorerDriver and executes the test in real Firefox web browser.