Selenium Notes

Automated testing:

The process of reducing and where possible removing human interactions from an existing manual test process.

Automated Manual

Easy to pass or fail a test case

Unlikely to change

Ran often

Quality over quantity

Able to test unique features

Able to detect and test ambiguous features.


  • Improves the accuracy and reliability of testing
  • Increases test coverage
  • Improves the scope of testing
  • Improves the speed of testing

Areas commonly automated:

  • Functional regression
  • Security
  • Test data
  • Performance

Prepare environment for recording > Record manual test cases > Enhance tests > Debug tests > Execute the tests > Debug test > Report defects.

Selenium integrated development environment (IDE) woks with Firefox and will be the basis of the following automated test explanations. It has the ability to log reference and inform on errors. Selenium is concerned with weather or not it can carry out all the tests to be executed.

Deprecated command: a command that is no longer necessary with updates, examples include verifyTextPresent.

Verify and Assert differ in that a test case will continue running if a verify condition fails, should an assert command fail the test case stops from executing.

Good Practices:

  • Put all variables at the top of the script, or in an external file. The variables must be ran before they are stored.
  • Don’t select open to add a new file to the test suite, use add test case
  • Don’t over complicate JavaScript
  • Avoid using outright values put all possible variances in variables
  • Only place assert where the application would fail in live environment.
  • Automate the test steps, not the pre conditions
  • Make sure the exit point of a test step is the entry point of another test case
  • Regular expressions are used more than Globbing, they are more specific

Selenium is an open source tool set, designed and built to facilitate an automated web testing framework.

2.0 WebDriver

  • Primary focus on furthering selenium functionality
  • Provides an object orientated API
  • Web driver directly initiates a web browser and controls it
    • This is done by being implemented through a browser specific driver, sending specific commands to the web browser and retrieving the results.
  • Usually integrated with selenium grid

Selenium Grid

  • Extension of WebDriver
  • Runs selenium test cases from a server which allows many tests to be ran in parallel across different configurations
  • Drastically reduces the time needed to test a large or slow test suite by breaking it down and running smaller suites simultaneously.
  • Same test suite can be ran across different environments.


  • Start basic and build up
  • Selenium DOES NOT do maths, JavaScript does
  • Type doesn’t actually mimic keyboard (sendkeys)
  • Double check everything
  • Test your tests

Selenium commands come in three varieties

  • Actions
  • Accessors
  • Assertions


Commands that manipulate the application under test (AUT) such as clicking links and selecting options, many actions may be appended with AndWait which can cause the program to wait while the program loads.


Accessors examine the current state of the AUT and stores the results into variables i.e. storeText, it is also used to automatically generate assertions.


Similar to accessors, they verify the findings against the expected results i.e. checking that a page has the correct title or that a checkbox has been checked. Assert, verify, and wait for are examples of assertions. When assert fails the currect test case is aborted and selenium will move onto the next case in the test suite. When verify fails the test will continue, logging the failure. Wait for commands wait for a condition to become true, it can be programmed to wait a designated length of time before supplying an error message.

Command Syntax

Command: the action to be taken

Target: the name of the target element to perform the action on i.e. name=CSS_Username.

Value: the input value

Common Commands

Open: opens a page using URL

Click: performs click operations

Verify: verifies the expected element


You can use selenium variables to store constants at the beginning of the script. An advanced use of variables is to combine them with data driven testing and pass values into selenium from the command line, another program or another file.

The vanilla store command is the most basic of the store commands, used to store a constant value in a selenium variable. Selenium takes two parameters: the text value and the variable name a variable is called by ${}.

StoreElementPresent: stores a Boolean (true/false) value depending on whether the element is found.

StoreText: uses a locator to identify specific text on a page if the text is found its stored in a variable.


Verifying UI elements on a web page is probably the most common feature in selenium. Always understand what you are verifying: is the specific text present on the page? Or is the specific text present at a specific location on the page.

Choosing between assert and verify comes down to the actions your test case should perform if it fails. Assert will abort the current test case; verify fails the test but continues the test case. Assert should only be used for critical functions.

Element locations

Element locations tells selenium where to look for a particular web element. There are several ways to locate elements:

By identifier //ID

By name //xpath

Hyperlinks in text //DOM


Typically the first element with a matching ID attribute is used, if no matching element is found the first element with a matching name attribute will be used. Locating by ID should be used when the elements ID is known. If multiple elements have the same value for a name attribute, filters can be used to refine your location.

Click name = symbol value = AU.L

Identifier, ID and name allow selenium to test a UI elements independence of its location on the page. Alterations to the page allow the tests to pass. Used for primarily testing the functionality on the webpage.


The language used for locating nodes in an XML document. It extends beyond locating by name or ID and is capable of locating third checkbox on a page. XPATH locators can be used to specify elements via attributes other than ID or name; this is useful when needing to use variables or recording against dynamic tables.

  • Used when you don’t have a suitable ID
  • It is not advised to use xpath in absolute terms.
    • Contains the location from the root.
    • Likely to fail upon even minor changes.
  • Relative to an element whose ID we do have e.g. a parent element.
    • Find a nearby element (ideally parent) you can locate your target element based on the relationship
    • Less likely to change therefore more robust.
Command Target Value
Click //tr[@id=’AMEC.L’]/td[4]/input  
Store AV.L compSym
Click //tr[@id=’${compSym}’]/td[4]/input  



Breakpoints: useful when you need a test to run to a certain point and stop

Start points: useful to have at a log in screen, no need to re-register.

Matching test patterns

The verify and assert commands utilise patterns, there are three types of pattern, globbing regular expression

Change Requests

A change request is an additional piece of work to be completed by the development team that was outside the original scope of the project. This may be a change to the current functionality or an addition of completely new functionality.

Change request raised > seek approvals > impact analysis > accept or reject work

Test Scripting

  • Scripted: everything is planned and written out.
  • Unscripted: no documentation, usually experience based.
  • Manual non-exploratory: strictly manual testing.
  • Manual exploratory: unscripted; test execution logging and learning are done simultaneously
  • Automated: manual testing instructions are recorded and ran.
  • Session based: time boxed session of exploratory testing

Behaviour Driven Development

Behaviour driven development is a software development process drawn from test driven development. The application evolves to match expected behaviour which is requirement based i.e. user stories.


Screen Shot 2017-06-15 at 14.45.53.png

Test Environment

A test environment consists of elements that support test execution with software, hardware and network configuration. Test environment configuration must mimic the production environment as close as possible in order to uncover any environment/configuration related issues. Different types of environment include: development- where the developer writes their code, test- where functional and non-functional testing is conducted, acceptance- the product owner or user does acceptance testing after deploying to this environment after the print, production- finally a release is deployed to the production environment. Typical environmental configuration for web based applications include: Webserver –IIS/Apache, Database- MS SQL, OS- Windows/Linux, and Browser- IE/Firefox.


Each test condition must be prioritised; it helps define the order that test cases are executed. The priority of each test condition directly correlates to the priority of the test case; priority is decided by the subject matter expert, business analyst or stakeholder.

1 2 3 4 5
Critical to functionality i.e. log in page Major feature of the application, do all the links work? Moderate importance to the application i.e. filters Minor features of the website, easily worked around Cosmetic features of the application, i.e.  spelling mistakes

Incident Report IEEE829

  1. Test incident report identifier: ID associated with the documentation.
  2. Summary: summary of any expected verses actual divergence.
  3. Incident description: detailed description of the incident this can include:
    1. Inputs
    2. Anomalies
    3. Environment
    4. Expected results
    5. Actual results
    6. Date and time
    7. Procedure steps
  4. Impact: what impact did the impact have on the progress overall.


Risk is the chance of an event, hazard, threat or situation occurring and resulting in undesirable consequences or potential problems.

Level of risk = probability x impact

  • Project risk is related to people.
  • Product risk is product focused.

Incident Management

Incident management comes under service management and is the logging of discrepancies between actual and expected outcomes of a test. Incidents need to be tracked from discovery and classification to the correction and confirmation of the solution. They provide the developer with clear feedback, the test lead with a way to track the quality of the system under test as well as provide ideas fir test process improvement.

Test Plan Documentation IEEE829

Test planning documentation may include some or all of the following aspects.

  1. Test plan identifier: a unique identifying reference.
  2. Introduction: a brief introduction to the document and project.
  3. Test items: the software item that is the object of testing.
  4. Features to be tested: identified in the test design specification and techniques.
  5. Features not to be tested: self-explanatory, also includes the reasoning for not testing.
  6. Approach: this details the overall approach to testing.
  7. Item pass/fail criteria: determines if the software item has passed or failed.
  8. Suspension and resumption criteria: used to determine the requirements for stopping and resuming part or the entire test.
  9. Test deliverables: the documentation that testing will deliver including test plans.
  10. Environmental needs: definition of all test environmental needs.
  11. Testing tasks: planning and execution of testing.
  12. Responsibilities: Identifying the tasks and roles to be used in the test project and who will own it.
  13. Staffing and training needs: identifying the staffing requirements and special skills or training that will need to be done to work on the project.
  14. Schedule: document dates and key milestones.
  15. Risks and contingencies.
  16. Approvals: identities and approvals of the documentation dated and signed.