Chrome Developer Tool

Chrome Developer Tool, a QA’s best friend

Google is an amazing place and it should be no surprise that they develop some pretty amazing tools.

In this post, let’s look at the ‘Chrome Developer Tool’.

Chrome Developer Tool

Chrome Developer Tool comes automatically installed in Chrome Browser and has helped many Developers and Testers (QA). Benefits comes in the form of UI Automation. If you dig deep enough, you can use the Tool to make performance improvements to a website also.

In this post, I have listed some of the biggest benefits of the tool and why you should consider using it.

Under The Hood

You get to have a cheeky peek

Well not really, you get to see the entire thing!

The tool can be accessed via the setting menu. Once you open the Tool, one of the first things you see are the DOM (HTML code) and Styles. This allows you to inspect the body of the page and it’s makeup.

Chrome Developer Tool Element

Wait a second, why is this so important?

For a QA, being able to write UI Automated tests requires that s/he has access to the source of the page. Looking at the HTML source code makes this easier. The QA is able to highlight and select specific elements on a web page. This then highlights the relevant HTML code under the Elements tab.

This allows the QA to cherry pick HTML code that they need to interact with which later allows the QA to write UI tests.


The Networking tab is perhaps a God send from Google.

If used correctly, information persisted in the Network tab can be used to identify a number of areas. This include page load time, causes of slow loads, resource and asset size etc.

This tab becomes very handy for anyone who is either interested or invested in Performance Testing.

Chrome Developer Tool Networking

For instance, it is possible to see:

  • What the largest file size is
  • The queue or order in which files loads
  • If any files resources stop other resources from loading

So what if we can see these files, how is the actually helpful?

Before being able to resolve an issue, you need to understand what the issue is.

Using the Network tab helps to identify ‘issues’. The tab becomes a hot bed to highlight potential performance fixes.


The Audit tab is a good place to start if you want to quickly measure:

  • Page and Network performance
  • Accessibility
  • Web best practices

It very nicely supplements the Network tab.

Chrome Developer Tool Auditing

It is possible to run an Audit on a given web page which returns a number of suggestions. These suggestions are provided by Google.

Suggestions may come in the form of CSS tweaks, cookie size, script load order etc.

Implementing these suggestions could potentially help rank your page higher in search engines and make your website more accessible around the world.


The ‘Audit’ and ‘Networking’ tabs can be used to make performance improvements. However, the Performance tab has a slightly more direct approach.

The Performance tab allows the user to create a profile view of the current page. This essentially allows the user to see the series of events, API calls and resources which load to make the makeup of the page.

This allows the user to measure the first instance a page is loaded and when the user can first interact with the page. It also provides a pretty cool pie chart of the total load time.

Chrome Developer Tool Performance


Google Chrome Developer Tool is a free tool which can be used to make vast performance improvements and help write UI tests.

A QA should strongly consider adding Chrome Developer Tool to their ‘key best tool favorite list’.

Bad Software Testers

Not all testers are the same, some are really bad software testers

By profession, I am a Software Tester, QA and Automation Engineer and I have meet some really bad ones.

With this said, what constitutes as a bad tester? The answer is a selection of poor traits and attitude.

This post is not meant to discourage or dishonour Testers. It is meant to highlight my experience with poor testers and how I approached the problem.

Bad Software Testers

In this post let’s look at some of the key traits which sadly defines what a bad Software Tester is and the solutions that I tried to implement.

The ‘Forgetful’ One

It’s common for a given person to forget things, that is normal. In a professional environment, forgetfulness is something that can not always be ignored.

In this instance the Tester will very commonly forget to make backups of test plans, test data, reports. They will also raise issues and bugs but not supply any steps to reproduce. When asked what the steps are, sometimes their response is that they don’t remember.

Their approach to reporting is usually very junior. This can leads to wasted time in investigations, spikes and other time sensitive aspects.

Fortunately this trait is common for Junior Testers and is remedied automatically overtime. The best approach here is to guide and train the Tester.

The ‘I Don’t Want To’ One

We have all encountered someone who possesses the mentality of saying ‘I don’t want to’, sadly this can be a common trait amongst all level of Testers.

Anyone who broadcasts this type of attitude usually differs any work given to them and are not strong team players.

This said, they also favor tasks which appear to be easy, straight forward or where someone else has done the leg work.

Resolving this can be challenging. The approach which I have seen to work best is to simple talk to the Tester and try to find out why they are not happy to pick up tasks.

Most of the time it is due to a lack of confidence, domain knowledge or a lack of willingness to work with people who seem very dominating. For me, talking has always helped to resolve this attitude.

The ‘I Did This, I Did That’ One

The ‘I did this, I did that’ trait belongs to someone who is more concerned with the work that they do and do not take the time to care or appreciate the effort that others are putting in. This particular trait makes it difficult to work with the Tester.

Testers with this view are usually found in Waterfall environments. This is because Waterfall promotes the idea of working in batches, in patches but not in sync.

To resolve this, I usually approach the Tester and try to understand why they appear to have strong feelings about what they and others did. Usually it comes down to their view on ‘what is fare’.

I try to resolve this by simply listing out the tasks that they and others have done however the focus here is not to compare. Instead I do this in hopes of trying to build a bridge and say that no one task can be sufficiently completed by only on person.

With time, this leads to a greater understanding of ‘US vs ME’.

The ‘My Way Or Highway’ One

It becomes very difficult to work with someone who is strongly passionate and adamant about their views and believes, especially when they are not open to ideas.

Sadly, this is usually found amongst the more senior members on a team. Through experience, senior Testers’s can sometimes ignore simple solutions and try to employ more difficult and complex ones.

Working with someone like this can almost always feel like a battle. It feels like a fight of diplomacy, ideas and sacrifice.

Passion plays a strong part in almost all discussions when speaking to someone who has very strong views. When trying to deal with someone like this, I try to convince ideas and thoughts for only some discussions and give into the many.

The idea here is to slowly win the confidence of the Senior Tester which in time becomes a strong relation. With some luck this leads to more comfortable discussions with an open mind form both parties.

The ‘Whatever’ One

There is always someone who is so relaxed and chilled that they do not care unless their salary is on the line.

Usually this means that the person does not take an active role in trying to resolve issues, take part in conversation or pro-actively investigate better solutions to existing problems.

They are very content with their current tasks and are more than happy to just coast along.

I have always found it to be a challenge when working with someone like this. My approach has been to try and give the Tester some small responsibilities. I have found that this helps to motivate the Tester to think about the problem and be more active in other roles.

The ‘Whatever’ attitude appears to disappear when the Tester’s see their contributions and efforts are valued.

The ‘I’m Not A Developer’ One

Having to look at code as a Tester is becoming more and more common however this becomes a problem when the Tester is just not happy about looking or reading code. The Tester in this instance is more than happy to get someone who is a little more intimate with coding to look at it instead.

This means the task takes longer and this could potentially hold up progress on other tasks.

I have found that pairing, training and teaching are the best tools to help someone get up to speed with coding.

Software Testing is Tough

It’s long, it’s hard but it’s worth it

Software testing is tough. Software Testers find bugs, write tests, firefight issues, teach, are expected to learn quickly and as a result it can become a difficult experience.

A Software Tester can constantly face many hardships, let’s have a look at some of them.

Hardships of a Tester

On a day-to-day basis, here are some of the key struggles that a Tester may face:

Testers VS Developers

At times, it may feel like a Tester is constantly having to stand their ground, make their point and convince Developers about bugs and non-functional issues.

Firstly of all let’s make one clear point. Testers and Developers are important for different things. The real benefits comes from the synergy of both roles.

Sadly, this silly thought of Testes VS Developers is simply unhealthy. This sort of thinking breeds segregation and isolation. Therefore, this helps to encourage a very ‘blame’ and ‘fault’ culture.

Unfortunately I have been exposed to this, most noticeably in a Waterfall environment. In a Waterfall environment, since the whole development is done in stages, there is little to no day-to-day interaction between Developers and Testers. This can lead to a very us vs them mentality.

Fortunately, Agile completely promotes a mixture of Developers and Testers therefore somewhat mitigating the idea behind Testers VS Developers. In an Agile environment, Testers VS Developers becomes Testers AND Developers.

Regression: The Silver Bullet

What is Regression?

For starters, it is not there to ensure that an application is bug proof. Regression means one single and simple thing; is everything still working, has a new issue been introduced. Sadly, not everyone understands this.

In some instances, Regression is seen as the ‘Application God Process’ which will catch-all the bugs, find all the holes, makes everyone super happy.

What do I mean by this?

Simply put, a misunderstanding in Regression stems from people, not the process.

In an ideal world, Regression should not be a laborious, long or a difficult task. It should be quick, painless and swift. People on the other hand have a magical gift to turn Regression into a nightmare.

On a whim’s notice, Testers are asked to consider new browsers, new devices, add a hundred more test scenarios, consider extra testing to cover for other teams etc. It feels like people forget how draining Regression can be.

Performing Regression is an important aspect of a Testers life. However, I have seen (first hand) how difficult it can be when last-minute requirements, favors and the need to test everything makes things difficult.

Proxy PO and BA

Overtime time, since Testers go through the application more times than ‘failure of unstable UI tests’, Testers become domain knowledge experts.

Initially, a Tester mostly needs to work with Developers (and other Testers) to test an application and ensure that it works. Overtime the role can become more challenging.

It becomes more and more difficult to devote time towards actual testing. Instead you may find yourself in meetings, talking about plans, strategies and much more. On the surface this is a great thing. This gives the ability to influence decisions, technology and perhaps a promotion.

Hence this drags the Tester away from their actual work i.e. to test.

Software Testing is Tough! Well, Is It?

Most noteworthy yes, Software Testing is tough. Seems like Testers are team players, how could Testers not be?

Developers, Testers, PO, BA all need to work together to convert a well thought plan into a delivered product. If the processes are taken care of, the team will be happy.

Testers are part of the backbone of any software development team and should be treasured.

Failing Fast

Failing fast leads to one thing, Success

It is important that your code base, continuous integration, tools and even your processes are able to fail fast. Human’s are a different consideration.

Why should a given process fail fast? What value is there in failing quickly?

Failing Fast

The greatest value in failing quickly is perhaps the ability to react to changes quickly.

Why fail fast? Failing quickly helps to resolve issues quicker since they are surfaced sooner. Let’s have a look at some of them:

Bug Cost

The earlier a bug is caught, the cheaper it is to fix

Wait, what does that mean? Cheaper in what sense, money, time, fingers?

Depending on the stage at which a bug is captured, the cheaper or quicker it may be to fix. It is therefore in your interest to fail quickly.

Let’s assume that a developer is working on a feature branch which is yet to be ‘merged’ into the master code base. Assume that a bug was found on the branch before the code was merged. Now let’s assume the same bug was found sometime after the code was merged.

In the above scenario, would the bug be easier and potentially quicker to fix before or after the merge? Does it even matter?

You can bet your bottom that it absolutely matters!

The sooner a bug is found between planning and deployment, the quicker it is to fix. Having to fix a bug with less code and less overhead makes it easier and quicker to fix.

Failing quickly directly impacts bug cost

Test Pyramid

What is the Test Pyramid?

The Test Pyramid is the principle of rationally dividing up the number of ‘types of tests’ one may write for an application. This is what the pyramid looks like:
testing pyramid

The length of each slice in the pyramid represents the number of tests you would write.

In short, the principle here is to write many unit tests, some integration and very few UI tests. Enough theory, how does this help to capture failures quickly?

The lower the test form, the quicker it runs!

Unit tests run faster than integration tests, integration tests are quicker than UI tests and UI tests are the slowest horse in the race. Let’s not get into the why or how, just take my word for it.

If we accept this concept, then this directly can help us to fail quickly. For instance, if we capture a bug on the unit test level, it would be quicker to fix since we found it quicker.

In conclusion, if a bug is not capture in a unit test and instead a UI test, it may be more expensive to fix.

Learn Quickly, Make New Mistakes

Failing quickly provides an opportunity to learn quickly

If you are able to fail quickly, this helps to promote learning.

As a result, the probability of repeating the same mistake should decrease. Consequently, this also means the probability of making new mistakes should increase.

In Agile, this is an important concept. This effectively means to quickly translate an issue into a learning outcome.

Failing Quickly, Any Real Benefits?

It should be clear that failing quickly does hold a lot of benefits, the biggest perhaps being able to adapt to changes.

We should absolutely leverage existing concepts such as the Test Pyramid to quickly capture bugs and reduce the cost of fixing them.

Some of the greatest inventions have come out of failures, it should be in your interest to fail quickly. Your future self may thank you.

Stand Up, Are You Doing it Right

A Stand Up is powerful, only when done right

Most of us have experienced taking part in one, have you had bad one?

The Traditional Stand Up

Let’s quickly establish the fundamental rules:

  • For starters, you must physical stand up at a set time every day
  • You must answer the following three questions:

    • 1. What you did yesterday?
    • 2. What you plan on doing today?
    • 3. Are you blocked on anything?
  • Your answer to the above three questions must be relevant to everyone
  • Finally, you refer to a board which helps to reflect the progress of tasks and / or stories

The above are all hallmarks of a quick, clean and valuable Stand Up. However, some bad habits can pollute the form.

Here are some interesting behaviors that I have observed over my career:

Virtual Stand Ups

Part of the philosophy of physically standing up in close proximity to your peers is to help encourage quick discussion.

A Stand Up is not designed to help people get comfortable. When conducting a virtual Stand Up, this almost goes against the thinking behind it.

Now, let me be clear. I am not knocking the idea of virtual Stand Ups. Sometimes you are simply not able to physically make the Stand Up in person and as such need to sign or log in virtually.

It is however important to mention that virtual Stand Up’s may encourage taking more time than needed.

Sit Downs

Sit Downs is a trend that I have seen, sadly.

In this instance, everyone is encouraged to sit down as opposed to standing up (assuming you are physically able to Stand Up). When a number of people get together and sit down, can it be considered a Stand Up?

I think physically Standing Up is vital to the theory of taking part in a Stand Up. It is not supposed to be a place where you get comfortable and relaxed. It is a format in which you deliver very quick and precise information whilst also being conscious of the time.

20 Minute Marathons

This is perhaps the worst that I have seen. In this instance, the Scrum Master appears to take turns talking to each member. As opposed to letting everyone quickly go through their updates, instead small discussions take place. The Stand Up is not a forum where you should have long running discussion.

What’s worst, anyone who actually wants to simply get away to their desk is not able to since everyone who is taking part is yet to speak.


This is a little new, perhaps very radical.

The approach here is to hold a plank whilst giving your updates. I came across this method in a particular place and it was a very interesting approach.

The idea behind it was to encourage everyone taking part to only contribute words and sentences which answered the above three questions. This approach certainly made it a lot quicker and cleaner. However, this also made it more difficult. If not for all, then certainly for some.

The downside to this was the fact that contributers were sometimes more concerned with out-planking each other instead of listening and making contributions.

Is it worth making something more difficult in favor of getting it done quicker?

Clean Stand Up Benefits

The traditional approach of the Stand Up is great. It works very well, really helps to deliver vital information in a quick, small time frame and also provides the opportunity to quickly plan for change. It seems the traditional approach works for the most part.

If the traditional approach works, why change it, why break it?

I Pushed a Bug in Production

It’s inevitable, at some point you will push a bug in production

Statistically speaking, at some point you will push a bug to production. It may be something small, it may be something big. It might be a small UI issue, it may be a rather large functional issue. Sadly, at some point it will happen.

So, how can we stop this, how can this be mitigated?

Stop Bugs going in Production

Unknowingly, I have pushed bugs to productions. Not my most favorite confession but it has happened. It wasn’t the most joyful of feeling, but you live and learn.

Here is a list of actions I live by to help reduce instances of bug getting past me, into production.

Play ‘The 5 WHY’ Game

This is perhaps one of my most powerful techniques. The ‘5 WHY’ approach is simple, you ask yourself 5 WHY based questions which help to diagnose the root cause to a problem.

For instance, let’s assume a bug around user login made it into production.

  • 1. WHY was the user not logged in?
  • 2. WHY was the user account not recognized?
  • 3. WHY did the user account have a duplicate user ID?
  • 4. WHY was the database able to store multiple user accounts with the same ID?
  • 5. WHY was the ID code generator not producing unique ID’s?

Following the above line of question would help to identify a flaw in the process. Perhaps if there was an automated test for ID generation, the bug may not have gone through to production.

The ‘5 WHY’ game has helped me to think about bug prevention in production. It has also helped me to triage situations where a bug has gone through.

Catch It, Automate It

Not a super fan about this particular approach but one of the best ways to ensure that the same bug does not make it through again is to write an automated test for it. This approach may however unnecessarily balloon the number of tests that you have. You may write many tests which run every time but not add much value since they are trying to capture something very specific.

On the other hand if we don’t write a test for it, it may go through again. That’s something no one would want on their conscious.

Big Bang Integration

Test your code with everyone’s code. Do not merge directly to some master code base, merge to a release code base and test it. If your release code works, put it in master.

A very simple approach to stopping bugs going to production is to pretend it did not happen, one way to achieve this is with multiple code bases. At any point in time, the production code that is running will be the latest version of master. In an ideal world, the master version is deemed stable and functionally working. When pushing new code to production, it is better to push a release version instead.

Pushing a release version somewhat reduces bugs in production. If the bug is found, you can quickly change back to a version of your code which is deemed better.

Process Failure, Not People

The biggest and most important thing to identify is this:

Bugs in production is not a result of a person’s failure, its the fault of a Process

Sadly at some point, most likely during a blue moon, you will push a bug. You are human, you will make mistakes or more likely you will miss things.

It’s is far better (and perhaps more healthy) to remedy ‘preventing bugs in production’ by putting in place a process which can help to prevent it.

Processes may include:

  • Writing automated tests
  • CI jobs and pipelines
  • Release processes
  • In closing, in an ever growing Software Industry, trying to prevent bugs in production is pretty much impossible.

    But we can give it our best.

Agile Pairing Power

Agile pairing, takes two to tango!

Once upon a time, I too did not see the benefits of pair programming. I saw work duplication, invasion of privacy and moments of broken concentration. And then something happened, I saw the light!

Why did I suddenly change my mind?

Benefits of Agile Pairing

Let me tell you about my sudden ‘Change of Heart’.

Is Team Work Better?

Why have two developers working on a task when one would get it done faster? This is how I used to think.

I had just joined a new company and was ‘encouraged’ to speak to developers instead of reading introductory documents. Being the new guy, I did not have much choice. I decided to sit down and ask questions.

I thought this would hamper the developer, to my surprise it did not. In fact, anyone that I spoke to or pair programmed with was more than happy to help. Going further, without realizing it at first I was actually introdusing myself to the entire team in a more ‘intimate’ fashion.

I found that I was picking up things a lot quicker, having my worries and doubts resolved quicker but more importantly I felt part of the team on day one! Why have two developers working on a task when one would get it done faster? Not sure how valid this statement was anymore.

Clearly this was taking time, I may have slowed others down. However, was my introduction to the team a really big time impact? I felt it was quicker for me to be a productive part of the team by pairing. I started to see Pair Programming as a way of on-boarding.

Are Code Reviews faster?

My way of programming as always worked. Books, blogs and conferences helped influence how I once programmed. I suddenly found myself speaking to developers and writing code with them, in the process learning a great deal more than books and blogs. This wasn’t entirely surprising but I did find myself asking why I had considered books and blogs a ‘better source of learning’ when compared to a fellow colleague.

Going further, I started to revisit ‘my way of writing code’. I started to write code which felt easier to read, to understand and to manage. The interesting thing about this particular evolution of my coding standards was that it was not imposed on me. In fact I saw the change and a need to ‘upgrade’ my standards.

Did I self improve because I started to talk to others?

Is Velocity impacted?

Going back to when I was not the biggest fan of pair programming, my biggest concern was the impact on team Velocity. This goes back to the notion of one task by one developer vs one task by two developers.

Let’s assume that a developer is stuck, what do they do? The developer can’t ask another developers since everybody is in the ‘one person one task’ mindframe. Most likely if your stuck, you go and get a coffee, take a walk, come back the next day and tackle it again. Failing this you ask someone else.

Now let’s assume a pair were working on the same task. The probability of one developer getting stuck is significantly less since there are two developers. Pair programming in this instance can help to solve problems quicker.

Before I adopted pair programming, I searched online for solutions every time I got stuck. I tended to ask colleagues as a last resort. I guess I did not ask, I thought it would slow down someone else. Not sure why, it toke me some time to realize that being stuck is the same as not adding towards the velocity.

In a very round about way I discovered that pairing actually increased velocity.

Is it worth it?

The big question, is it worth Pair Programming?

Let’s list the possible disadvantages of Pair Programming:

  • More man hours to get a task done
  • Ego and attitude play a part – this can result in enforced code vs quality code
  • The idea of a ‘driver’ and ‘passenger’ does not breed creativity

And now the advantages:

  • Better learning
  • Higher code quality
  • Problems resolved quicker

What do you think, do the advantages outweigh the disadvantages?

I thought so!

Automation QA Interview Questions

Making the jump from a Manual and into a Technical QA role can be difficult and challenging. Here are some potential automation QA interview questions which you may be asked during an interview.

Automation QA Interview Questions

What are the core positive features of an Automation Framework?

Building an automation framework can become a dangerious journey if key features are not considered before putting pen to paper. Before buliding a framework, some of the most important factors to consider include:

  • Speed
  • Maintenance
  • Modular
  • Debug / Error
  • Configurable

It is important that you are able to run all your tests quickly. Some solutions include running tests in parallel or running tests against different browsers.

Being able to maintain a framework can mean the difference between extending it or removing it. If it becomes difficult to maintain a framework, it then has the potential to become an overhead instead of adding value.

Switching out technologies and replacing them in a framework provides the flexibility to update frameworks more easily. For instance, being able to switch out testing libraries makes a framework more stable. Other examples include being able to change reporting of results.

Debug / Error
A automation framework is next to useless if you are not able to debug the code or tell what the errors are if a test fails. It help debug, writing clean and understandable code helps. Writing meaningful assertions also helps to identify sources for failed tests.

A given test becomes more versatile if it is possible to run a given test against different environments. However, the control of where the test run’s should not be governed in the test itself. Being able to change the test run location, the host to talk to etc via configurations helps to configure tests. This also can helps to scale an automation framework.

Can you name any disadvantages to E2E Automation Testing?

E2E Automation testing is great to check functionality. It is however poor in the following areas:

  • UI changes
  • Exploratory Cases

UI Changes
An automated test will not be able to test to see that the color of a button is correct, the placement of a field is correct, animations are correct etc. Features such as this can not be tested through traditional E2E Automate.

Exploratory Cases
This is a given, an automated test will only run the scenario which you have written. This means that it will not be able to explore your application and randomly test scenarios. This is where Manual Testing plays a big part. I mention this as there are a number of people who assume automated tests are the replacements to Manual testing.

How do you decide what manual test to automate?

The answer to this can be simple. A manual test becomes a candidate for automation when:

  • It does not have any external dependencies
  • It needs to run very often

Is Automation a replacements for Manual Testing?

No. An automated test simply replaces a scenario which would have been executed manually. An automated test however does not have the ability to explore an application and find bugs outside of automated scenarios. For this reason, automated tests are not a replacement for manual testing.

What tests should not be automated?

Here is a list of tests which should not be automated:

  • Test’s which only run once
  • UI based tests to check for colors, element placements, element size etc

How do you mark the success of an Automated test?

In order to mark an automated test as success, you can apply the following metrics:

  • High success rate of passing (95%+), low failure rate
  • Captured valid bugs

WebDriverJS Dropdown

Do you know how to use WebDriverJS to interact with a Dropdown field? Let’s use WebDriverJS dropdown to select a value?

It is important to be able to select a value from a dropdown box. Let’s have a look at how we can use WebDriverJS to select an item from a dropdown box.

WebDriverJS Dropdown

In the code snippet below, we navigate to a test page which contains a dropdown box. Examine the code below:

var webdriver = require('selenium-webdriver');
var driver = new webdriver.Builder().withCapabilities(;

The code above navigates to, goes to the test site (webapp) and then clicks on the ‘Adoption’ link. Now let’s try to see how we can interact with the dropdown box on that page.

Select from Dropdown field

The code below introduces a selectFromDropdown function.

SelectFromDropdown Function
In order to select a value from the dropdown field, we will introduce a new function.

function selectFromDropdown(value){const valueSelected = webdriver.By.css('[id="start_select"]' + ' option[value="' + value + '"]');

In the ‘selectFromDropdown’ function, we firstly identify the id of the dropdown field as well as capturing a possible value from the dropdown. We then assign this to a constant variable called ‘valueSelected’.

Finally we click on the dropdown field itself which displays all the options. This then allows us to see all possible options which we are then able to click on.

Let’s have a look at how the script now looks:

var webdriver = require('selenium-webdriver');
var driver = new webdriver.Builder().withCapabilities(;
function selectFromDropdown(value){const valueSelected = webdriver.By.css('[id="start_select"]' + ' option[value="' + value + '"]');

Using the function above, you should now be able to change it to help select a value from a dropdown box.

WebDriverJS Switching Windows

When writing an automated test, you may encounter scenarios where you might have to switch browser windows. In this post we will look at how we can switch windows.

WebDriverJS Switching Windows

Firstly, let’s write out in comments what we would like to achieve.

// Save location to parent window
// Print parent window title
// Switch to new window
// Print text in newly switched window
// Switch back to parent window
// Print parent window title

Assuming we are able to achieve the above scenario, we should be able to figure out how to switch windows.

Switching Windows

In order to switch windows, we need to use the ‘getAllWindowHandles()’ command. Let’s have a look below:

driver.getAllWindowHandles().then(function gotWindowHandles(allhandles) {
    // Save location to parent window
    // Print parent window title
    // Switch to new window
    // Print text in newly switched window
    // Switch back to parent window
    // Print parent window title

Since ‘getAllWindowHandles()’ returns a promise, we need to wrap it in a ‘then’.

Further Switching Windows

Let’s take this a step further and try to address each of the comments:

driver.getAllWindowHandles().then(function gotWindowHandles(allhandles) {
    // Save location to parent window
    var parent = driver.getWindowHandle();
    // Print parent window title
    driver.getTitle().then(function (text) {
        console.log('Parrent Windows: ' + text);
    // Switch to new window
    driver.switchTo().window(allhandles[allhandles.length - 1]);
    // Print text in newly switched window
    driver.findElement(webdriver.By.css('h1')).then(function (heading) {
        heading.getText().then(function (text) {
            console.log('Child Windows: ' + text);
    // Switch back to parent window
    // Print parent window title
    driver.getTitle().then(function (text) {
        console.log('Parrent Windows: ' + text);

The main things to note here are the variable to capture the parent window and how we switch back and forth between the parent and child windows. It is also important to note that when switching windows, the driver simple gains control over eachwindow. We do not need to use a different driver instance.

Full Example


var webdriver = require('selenium-webdriver');
var driver = new webdriver.Builder().withCapabilities(;
driver.getAllWindowHandles().then(function gotWindowHandles(allhandles) {
    // Save location to parent window
    var parent = driver.getWindowHandle();
    // Print parent window title
    driver.getTitle().then(function (text) {
        console.log('Parrent Windows: ' + text);
    // Switch to new window
    driver.switchTo().window(allhandles[allhandles.length - 1]);
    // Print text in newly switched window
    driver.findElement(webdriver.By.css('h1')).then(function (heading) {
        heading.getText().then(function (text) {
            console.log('Child Windows: ' + text);
    // Switch back to parent window
    // Print parent window title
    driver.getTitle().then(function (text) {
        console.log('Parrent Windows: ' + text);

The should output the following:

Expected Output

Parrent Windows: Zoo Adoption | Home
Child Windows: Terms of the site
Parrent Windows: Zoo Adoption | Home