How to Use Selenium RC with Java

I know most of them are familiar using selenium IDE at the same time many of them are wondering how to use Selenium RC .

I was one among you all but with help from one of my friend I started working on Selenium RC and realised that Selenium RC is very powerful, useful and not a difficult one.I installed it on Ubuntu system and started writing Test cases with JUnit

  • Install Eclipse
  • Install selenium  IDE as add on to your firefox browser
  • Install Selenium RC – make sure you have all the following 3 files
    • selenium-server-coreless.jar
    • selenium-server.jar
    • selenium-server-sources.jar

To start selenium server on your machine got to the directory where the above 3 files are present and then type in the following command “java -jar selenium-server.jar” and it should start the selenium server with out any exceptions.

Open your Eclipse and go to File ->New -> Project

Name your Project say “TestProject”

Right Click on Test and say New Package and name it as “TestPackage”

Right click on TestPackage and create a new Class and name it as “NewClass”

In the class put in the following code:

package mainpackage;

import java.util.Random;

import org.junit.Test;

import com.thoughtworks.selenium.SeleneseTestCase;
import com.thoughtworks.selenium.Selenium;

public class Logintest extends SeleneseTestCase  {
// We create our Selenium test case
 
 public void setUp() throws Exception {
  setUp(“http://www.yourtestingsite.com/“, “*firefox”);
 // We instantiate and start the browser
 }
  
@Test  //This is mandatory to put @Test at the start of each test

 public void testSignUp() throws Exception {

//this code you get it from the recorded IDE session

  selenium.open(“/”);
  selenium.click(“link=Sign up”);
  selenium.waitForPageToLoad(“30000″);
  selenium.type(“username”, “random@random.com“);
  selenium.type(“password”, “password”);
  selenium.type(“confirm_pass”, “password”);
  selenium.type(“display_name”, “random”);
  selenium.click(“display_name”);
  selenium.type(“display_name”, “random”);
  selenium.click(“acceptUsage”);
  selenium.click(“Login”);
  selenium.waitForPageToLoad(“30000″);
  verifyTrue(selenium.isTextPresent(“You’re almost done! One last thing … You just need to activate your account. Simply click on the link we’ve emailed you and you’re ready to go!”));
  Results.result(“Signup is successful”);
 }

To get the java code from recorded IDE you just need to click on Options -> Format ->Java(JUnit)-SeleniumRC

copy paste the code into your IDE and run the code.

Put in some tweaks to suit your testing needs.

Will post some more on RC code soon

Powered By Wordpress Tabs Slides

Software testing Terminology

Testing Levels / Phases

Testing levels or phases should be applied against the application under test when the previous phase of testing is deemed to be complete . or .complete enough.. Any defects detected during any level or phase of testing need to be recorded and acted on appropriately.

Design Review

“The objective of Design Reviews is to verify all documented design criteria before development begins.” The design deliverable or deliverables to be reviewed should be complete within themselves. The environment of the review should be a professional examination of the deliverable with the focus being the deliverable not the author (or authors). The review must ensure each design deliverable for: completeness, correctness, and fit (both within the business model, and system architecture).

Design reviews should be conducted by: system matter experts, testers, developers, and system architects to ensure all aspects of the design are reviewed.

Unit Test

“The objective of unit test is to test every line of code in a component or module.” The unit of code to be tested can be tested independent of all other units. The environment of the test should be isolated to the immediate development environment and have little, if any, impact on other units being developed at the same time. The test data can be fictitious and does not have to bear any relationship to .real world. business events. The test data need only consist of what is required to ensure that the component and component interfaces conform to the system architecture. The unit test must ensure each component: compiles, executes, interfaces, and passes control from the unit under test to the next component in the process according to the process model.

The developer in conjunction with a peer should conduct unit test to ensure the component is stable enough to be released into the product stream.

Function Test

“The objective of function test is to measure the quality of the functional (business) components of the system.” Tests verify that the system behaves correctly from the user / business perspective and functions according to the requirements, models, storyboards, or any other design paradigm used to specify the application. The function test must determine if each component or business event: performs in accordance to the specifications, responds correctly to all conditions that may be presented by incoming events / data, moves data correctly from one business event to the next (including data stores), and that business events are initiated in the order required to meet the business objectives of the system.

Function test should be conducted by an independent testing organization to ensure the various components are stable and meet minimum quality criteria before proceeding to System test.

System Test

“The objective of system test is to measure the effectiveness and efficiency of the system in the “real-world” environment.” System tests are based on business processes (workflows) and performance criteria rather than processing conditions. The system test must determine if the deployed system: satisfies the operational and technical performance criteria, satisfies the business requirements of the System Owner / Users / Business Analyst, integrates properly with operations (business processes, work procedures, user guides), and that the business objectives for building the system were attained.

There are many aspects to System testing the most common are:

  • Security Testing: The tester designs test case scenarios that attempt to subvert or bypass security.
  • Stress Testing: The tester attempts to stress or load an aspect of the system to the point of failure; the goal being to determine weak points in the system architecture.
  • Performance Testing: The tester designs test case scenarios to determine if the system meets the stated performance criteria (i.e. A Login request shall be responded to in 1 second or less under a typical daily load of 1000 requests per minute.)
  • Install (Roll-out) Testing: The tester designs test case scenarios to determine if the installation procedures lead to an invalid or incorrect installation.
  • Recovery Testing: The tester designs test case scenarios to determine if the system meets the stated fail-over and recovery requirements.

System test should be conducted by an independent testing organization to ensure the system is stable and meets minimum quality criteria before proceeding to User Acceptance test.

User Acceptance Test

“The objective of User Acceptance test is for the user community to measure the effectiveness and efficiency of the system in the “real-world” environment.”. User Acceptance test is based on User Acceptance criteria, which can include aspects of Function and System test. The User Acceptance test must determine if the deployed system: meets the end Users expectations, supports all operational requirements (both recorded and non-recorded), and fulfills the business objectives (both recorded and non-recorded) for the system.

User Acceptance test should be conducted by the end users of the system and monitored by an independent testing organization. The Users must ensure the system is stable and meets the minimum quality criteria before proceeding to system deployment (roll-out).

Powered By Wordpress Tabs Slides

Agile Testing

Hi All,

Anyone interested in Agile testing methodolgy?

Let me know and I can cover this topic off with some real time examples.

Cheers,

Vemu

Here are few details about the Agile development that we follow

One of the framework in Agile is called Scrum that we follow in our company

Scrum is a lightweight process framework for agile development, and the most widely-used one.

  • The Scrum process framework requires the use of development cycles called Sprints
  • “Lightweight” means that the overhead of the process is kept as small as possible, to maximize the amount of productive time available for getting useful work done.

Scrum is most often used to manage complex software and product development, using iterative and incremental practices. Scrum significantly increases productivity and reduces time to benefits relative to classic “waterfall” processes.  Scrum processes enable organizations to adjust smoothly to rapidly-changing requirements, and produce a product that meets evolving business goals.

An agile Scrum process benefits the organization by helping it to

  • Increase the quality of the deliverables provided every team involved is disciplined enough
  • Cope better with change (and expect the changes)
  • Provide better estimates while spending less time creating them – because estimates are given by individual team members who does the actual work rather than given by technical lead
  • Be more in control of the project schedule and state

As a result, Scrum projects achieve higher customer/business stakeholders satisfaction rates.

Requirements in scrum:

Scrum does not define just what form requirements are to take, but simply says that they are gathered into the Product Backlog, and referred to generically as “Product Backlog Items” . Given the time-boxed nature of a Sprint, we can also infer that each set should require significantly less time to implement than the duration of the Sprint.

Most Scrum projects borrow the “XP” (Extreme Programming) practice of describing a feature request as a “User Story,” although a minority uses the older concept of a “Use Case.” We will go with the majority view here, and describe three reasonably-standard requirements artifacts found in Product Backlogs.

User Story

A User Story describes a desired feature (functional requirement) in narrative form. User Stories are usually written by the Product Owner, and are the Product Owner’s responsibility. The format is not standardized, but typically has a name, some descriptive text, references to external documents (such as screen shots), and information about how the implementation will be tested.

For example, a Story might resemble the following:

As a <type of user role>

I want  <some goal>

so that <some reason can be achieved>

How to test: The implementation of a Story is defined to be complete if, and only if, it passes all acceptance tests developed for it. This section provides a brief description of how the story will be tested. As for the feature itself, the description of testing methods is short, with the details to be worked out during implementation, but we need at least a summary to guide the estimation process.

There are two reasons for including the information about how to test the Story. The obvious reason is to guide development of test cases (acceptance tests) for the Story. The less-obvious, but important, reason, is that the Team will need this information in order to estimate how much work is required to implement the story (since test design and execution is part of the total work).

Technical Story

Not all requirements for new development represent user-facing features, but do represent significant work that must be done. These requirements often, but not always, represent work that must be done to support user-facing features. We call these non-functional requirements “Technical Stories.”

Technical Stories have the same elements as User Stories, but need not be cast into narrative form if there is no benefit in doing so.

Technical Stories are usually written by Team members, and are added to the Product Backlog. The Product Owner must be familiar with these Stories, and understand the dependencies between these and User Stories in order to rank (sequence) all Stories for implementation.

In our company we follow 4 week sprint cycles but i know few companies which follow 1 week spring and few that follow 3 month sprint cycles.

it really depends on amount of work that you want to do and amount of resources available.

Powered By Wordpress Tabs Slides
Return top

INFORMATION

Do not forget to leave a comment if you find the posts useful.