Software Testing Using Selenium Innovation

COURTESY :- vrindawan.in

Wikipedia

Software testing is the act of examining the artifacts and the behavior of the software under test by validation and verification. Software testing can also provide an objective, independent view of the software to allow the business to appreciate and understand the risks of software implementation. Test techniques include, but not necessarily limited to:

analyzing the product requirements for completeness and correctness in various contexts like industry perspective, business perspective, feasibility and viability of implementation, usability, performance, security, infrastructure considerations, etc.
reviewing the product architecture and the overall design of the product
working with product developers on improvement in coding techniques, design patterns, tests that can be written as part of code based on various techniques like boundary conditions, etc.
executing a program or application with the intent of examining behavior
reviewing the deployment infrastructure and associated scripts and automation
take part in production activities by using monitoring and obser avability techniques

Software testing can provide objective, independent information about the quality of software and risk of its failure to users or sponsors.

Although software testing can determine the correctness of software under the assumption of some specific hypotheses (see the hierarchy of testing difficulty below), testing cannot identify all the failures within the software. Instead, it furnishes a criticism or comparison that compares the state and behavior of the product against test oracles — principles or mechanisms by which someone might recognize a problem. These oracles may include (but are not limited to) specifications, contracts, comparable products, past versions of the same product, inferences about intended or expected purpose, user or customer expectations, relevant standards, applicable laws, or other criteria.

A primary purpose of testing is to detect software failures so that defects may be discovered and corrected. Testing cannot establish that a product functions properly under all conditions, but only that it does not function properly under specific conditions. The scope of software testing may include the examination of code as well as the execution of that code in various environments and conditions as well as examining the aspects of code: does it do what it is supposed to do and do what it needs to do. In the current culture of software development, a testing organization may be separate from the development team. There are various roles for testing team members. Information derived from software testing may be used to correct the process by which software is developed.

Every software product has a target audience. For example, the audience for video game software is completely different from banking software. Therefore, when an organization develops or otherwise invests in a software product, it can assess whether the software product will be acceptable to its end users, its target audience, its purchasers, and other stakeholders. Software testing assists in making this assessment.

Software faults occur through the following process: A programmer makes an error (mistake), which results in a fault (defect, bug) in the software source code. If this fault is executed, in certain situations the system will produce wrong results, causing a failure.

Not all faults will necessarily result in failures. For example, faults in the dead code will never result in failures. A fault that did not reveal failures may result in a failure when the environment is changed. Examples of these changes in environment include the software being run on a new computer hardware platform, alterations in source data, or interacting with different software. A single fault may result in a wide range of failure symptoms.

Not all software faults are caused by coding errors. One common source of expensive defects is requirement gaps, that is, unrecognized requirements that result in errors of omission by the program designer. Requirement gaps can often be non-functional requirements such as test ability, scalability, maintainability, performance, and security.

Selenium is an open source umbrella project for a range of tools and libraries aimed at supporting browser automation. It provides a playback tool for authoring functional tests across most modern web browsers, without the need to learn a test scripting language (Selenium IDE). It also provides a test domain-specific language (Selenese) to write tests in a number of popular programming languages, including JavaScript (Node.js), C#, Groovy, Java, Perl, PHP, Python, Ruby and Scala. Selenium runs on Windows, Linux, and mac OS. It is open-source software released under the Apache License 2.0.

Selenium was originally developed by Jason Huggins in 2004 as an internal tool at Thought Works. Huggins was later joined by other programmers and testers at Thought Works, before Paul Hammant joined the team and steered the development of the second mode of operation that would later become “Selenium Remote Control” (RC). The tool was open sourced that year.

In 2005 Dan Fabulich and Nelson Sproul (with help from Pat Lightbody) made an offer to accept a series of patches that would transform Selenium-RC into what it became best known for. In the same meeting, the steering of Selenium as a project would continue as a committee, with Huggins and Hammant being the Thought Works representatives.

In 2007, Huggins joined Google. Together with others like Jennifer Bevan, he continued with the development and stabilization of Selenium RC. At the same time, Simon Stewart at Thought Works developed a superior browser automation tool called Web Driver. In 2009, after a meeting between the developers at the Google Test Automation Conference, it was decided to merge the two projects, and call the new project Selenium Web Driver, or Selenium 2.0.

In 2008, Philippe Hanrigou (then at Thought Works) made “Selenium Grid”, which provides a hub allowing the running of multiple Selenium tests concurrently on any number of local or remote systems, thus minimizing test execution time. Grid offered, as open source, a similar capability to the internal/private Google cloud for Selenium RC. Pat Light body had already made a private cloud for “Hosted QA” which he went on to sell to Gomez, Inc.

The name Selenium comes from a joke made by Huggins in an email, mocking a competitor named Mercury, saying that you can cure mercury poisoning by taking selenium supplements. The others that received the email took the name and ran with it.

Selenium is composed of several components with each taking on a specific role in aiding the development of web application test automation.

Selenium IDE is a complete integrated development environment (IDE) for Selenium tests. It is implemented as a Firefox Add-On and as a Chrome Extension. It allows for recording, editing and debugging of functional tests. It was previously known as Selenium Recorder. Selenium-IDE was originally created by Shinya Kasatani and donated to the Selenium project in 2006. Selenium IDE began being actively maintained in 2018.

Scripts may be automatically recorded and edited manually providing auto completion support and the ability to move commands around quickly. Scripts are recorded in Selenese, a special test scripting language for Selenium. Selenese provides commands for performing actions in a browser (click a link, select an option) and for retrieving data from the resulting pages.

The 2.x version of the Selenium IDE for Firefox stopped working after the Firefox 55 upgrade and has been replaced by Selenium IDE 3.x.

In addition to the official Selenium IDE project, two alternative Selenium IDE browser extensions are actively maintained: Kantu (Open-Source GPL license) and Katalon Recorder (Open-Source).

As an alternative to writing tests in Selenese, tests can also be written in various programming languages. These tests then communicate with Selenium by calling methods in the Selenium Client API. Selenium currently provides client APIs for Java, C#, Ruby, JavaScript, R and Python.

With Selenium 2, a new Client API was introduced (with Web Driver as its central component). However, the old API (using class Selenium) is still supported.

Selenium Remote Control (RC) is a server, written in Java, that accepts commands for the browser via HTTP. RC makes it possible to write automated tests for a web application in any programming language, which allows for better integration of Selenium in existing unit test frameworks. To make writing tests easier, Selenium project currently provides client drivers for PHP, Python, Ruby, .NET, Perl and Java. The Java driver can also be used with JavaScript (via the Rhino engine). An instance of selenium RC server is needed to launch html test case – which means that the port should be different for each parallel run.However, for Java/PHP test case only one Selenium RC instance needs to be running continuously.

Selenium Remote Control was a refactoring of Driven Selenium or Selenium B designed by Paul Hammant, credited with Jason as co-creator of Selenium. The original version directly launched a process for the browser in question, from the test language of Java, .NET, Python or Ruby. The wire protocol (called ‘Selenese’ in its day) was reimplemented in each language port. After the refactor by Dan Fabulich and Nelson Sproul (with help from Pat Lightbody) there was an intermediate daemon process between the driving test script and the browser. The benefits included the ability to drive remote browsers and the reduced need to port every line of code to an increasingly growing set of languages. Selenium Remote Control completely took over from the Driven Selenium code-line in 2006. The browser pattern for ‘Driven’/’B’ and ‘RC’ was response/request, which subsequently became known as Comet.

Selenium RC served as the flagship testing framework of the entire project of selenium for a long-standing time. And significantly Selenium RC is the first and foremost automated web testing tool that enabled users to adopt their preferred programming language.

With the release of Selenium 2, Selenium RC has been officially deprecated in favor of Selenium Web Driver.

At the core of Selenium is Selenium WebDriver, an interface to write instructions that work interchangeably across browsers. It is the successor to Selenium RC. Selenium WebDriver accepts commands (sent in Selenese, or via a Client API) and sends them to a browser. This is implemented through a browser-specific browser driver, which sends commands to a browser and retrieves results. Most browser drivers actually launch and access a browser application (such as Firefox, Google Chrome, Internet Explorer, Safari, or Microsoft Edge); there is also an Html Unit browser driver, which simulates a browser using the headless browser Html Unit.

Unlike in Selenium 1, where the Selenium server was necessary to run tests, Selenium Web Driver does not need a special server to execute tests. Instead, the Web Driver directly starts a browser instance and controls it. However, Selenium Grid can be used with Web Driver to execute tests on remote systems (see below). Where possible, Web Driver uses native operating system level functionality rather than browser-based JavaScript commands to drive the browser. This bypasses problems with subtle differences between native and JavaScript commands, including security restrictions.

In practice, this means that the Selenium 2.0 API has significantly fewer calls than does the Selenium 1.0 API. Where Selenium 1.0 attempted to provide a rich interface for many different browser operations, Selenium 2.0 aims to provide a basic set of building blocks from which developers can create their own domain-specific language (DSL). One such DSL already exists: the Watir project in the Ruby language has a rich history of good design. Watir-webdriver implements the Watir API as a wrapper for Selenium Web Driver in Ruby. Watir-web driver is created entirely automatically, based on the WebDriver specification and the HTML specification.

As of early 2012, Simon Stewart (inventor of Web Driver), who was then with Google, and David Burns of Mozilla were negotiating with the W3C to make Web Driver an Internet standard. In July 2012, the working draft was released and the recommendation followed in June 2018. Selenium WebDriver (Selenium 2.0) is fully implemented and supported in JavaScript (Node.js), Python, Ruby, Java, Kotlin (programming language), and C#. As of 2021, Selenium 4 is a release candidate.