Automation challenges

Hello guys !!

I thought about sharing something that we all have gone through at some point of our career. Some of these challenges are related to lack of standards, knowledge and processes, but some others are related to company’s culture and people’s mindset (this is the biggest challenge and most difficult to change).

I have posted about the difference between a growth mindset and a fixed mindset some years ago, after joining  a workshop where Joanna Chwastowska (Engineering Lead at Google) explains how she learned to have a growth mindset, this picture below summarizes it:


Basically, we are always learning and you shouldn’t feel ashamed to admit that 🙂



What scenarios should I have for this layer of tests ? What type of tests should I be responsible for ? These should be the questions that you first ask when deciding the scope of your tests. For each layer you need to have a different scope otherwise you are not only going to duplicate scenarios, but also have an extensive pipeline that is hard/impossible to maintain.  

Decide what are the layers that you are going to cover: Unit, Integration, E2E Tests… then decide what scenarios for each layer. So, for the Unit tests you need to have an extensive number of scenarios covering edge cases (special characters, etc), then integration between components and finally e2e tests on top with a reduced scope and no mocks. You should also consider UI tests comparing snapshots if you have a frontend as well.  


Team collaboration

Make sure you have a team that is working towards the same goal, improve the communication as much as possible. Do workshops, demos, pair-programming, code reviews, get feedback so you can continue to improve until you find the best way to work and at the same time make the business happy.

Understand the expectations and align them, there is nothing better than having a nice bunch of people to spend ~8 hours together for 5 days a week and achieving something together.


Time constraints

How many releases do you have per day ? How many projects are you allocated in ? How many developers do you have in your team ? You might have noticed that you usually have more than one developer for each QA in a team, and this is okay, as long as you manage what you are going to test, you can’t save the world, don’t test everything, focus on the end-user flow above everything else as this is the front door of the product.

Something you need to take into account is the scope of the regression pack, you probably want to have automation for that, right ? I am completely against having manual tests for the regression pack, unless there is a strong reason why.


Finding elements

Do you remember when you couldn’t click on that element because there was a div on top of it ? This is one of the problems you might have faced already, or maybe was a bad structured xpath ? or too many elements with the same css-selector ?

If you are testing react apps, here is something that helped when doing the tests, I’ve asked the developers to add one a data-test attribute: data-test, data-test-id, data-testid or data-cy to the elements. Adding this kind of attribute is considered a best practice since makes the automation resilient to change and it is dedicated for tests.


Flaky tests

Yeah… we all know the struggle is REAL !

I’ve faced this issue recently when doing tests with Espresso on android apps, instead of using waits remember to use idling resources which synchronizes the subsequent operations in a UI test.

For the react apps you can use frameworks like Cypress, Testcafe and Detox that runs in the same run-loop as the application being tested and can automatically wait for assertions and commands before moving ahead.

These are some of the reasons you can have flaky tests, but there are some other reasons like:

  • Environment/server is not stable
  • 3rd party system integration is not stable
  • Concurrency tests
  • Caching
  • Setup/teardown tests
  • Dynamic content

Identify the reason first to be able to take the correct action, but definitely tag this test as soon as possible since you won’t be able to trust on it until it has been fixed.



How to make automation tests more effective

As a QA Engineer you often need to do regression tests and you know this is a really waste of time since every time is the same test. Then, you keep in mind that you need to automate the regression tests in order to save time with the old things that could be broken with the introduction of the new features.

The development of the automation is usually done by the developers in test, people who has QA  and programming knowledge. One completes the other, so you know how to automate the right scenarios with the right prioritisation. Don’t spending time automating scenarios with no or small value or with wrong prioritisation for the regression pack.

You need to include the repetitive scenarios, the critical ones and the happy path but try to avoid the edge cases. Why ? Because edge cases are often scenarios with minimum or no value, where it is a specific flow that should be test once when developing the feature not every time when doing the regression. Regression pack ensures the happy path is working and the end user will be able to do what he needs to do. When you spend time implementing automated edge cases, you actually waste your valuable time implementing scenarios without real business value.

Although the product owners may be able to immediately suggest points to automate, it also depends on developers working on the detailed code. So, for this reason you need to have a good analyse before about the scenarios that should be implemented and if they will change very often.

Here some tips about how to create your automation tests more effectively:


Developing Automation

Automation code is quite similar to the development code, but it should be more simple and readable. Automation is not meant to be complex. The business rules should be implemented as part of the BDD scenarios, so the code is clean and doesn’t have anchors of complexity.

ROI (Return of Investment), you need to guarantee the value of the scenarios when automating them. For example, a scenario that tests the function of a feature is far more important and valuable than a scenario that tests if the buttons have the expected colour. Layouts are important, but you will spend more time implementing a scenario asserting the colour than opening the page and manually checking in milliseconds, also it is not a critical issue, the user will be able to finish the scenario despite the colour of the button. Measure the time before and after the automation is implemented, so you can have an idea of the time and effort saved.

Optimizing time

We have a common problem in the agile environment, when we rush to finish the sprint and forget quality. This is because we close the tickets, but we create a backlog of bugs every time and it keeps growing every sprint. These sprint backlogs make it difficult to devote time for the development, debugging and testing of each iteration.

For this reason it is really important to save a good amount of time for testing. To help saving time with the test, you can run the automation in parallel to the development, so any regression bug would be caught as soon as it is merged in a master branch. This gives more scope to the QA engineers to develop efficient tests through exploratory search.

Client Test Coverage

The ideas that come just after the brainstorming help testers to identify different scenarios and create a better test coverage for the feature. So you need to have this time to mature the idea of the feature and think about the flow and possibilities.

It is important to think more broadly when talking about test automation and not think only about the test cases. The planning and brainstorming can lead to breakthroughs that change the testing pattern altogether.

Regression Pack

When you implement the automated regression tests you need to keep well maintained with the development of the features. If not, your regression will be not up to date and you will not be able to trust on your automation anymore. Make sure your regression pack guarantee the functionality of the system and monitor the performance of the tests so as soon as you have some failure you can identify if it was a bug on the system or if is something you need to update with the current development code.

Regression tests should run smoothly and without human intervention. The only thing you need to worry is adding new features to the package.


As I have described before, you need to keep it simple. This is the key to have a smooth automation. You need to be sure the stakeholders will understand what is being tested. Show the statistics of how long is taking to run the regression pack, how much time you are saving, the percentage of tests coverage vs time before and after automation, the overall quality improved.

Sharing this data will show a positive thinking about automation and how much you have improved automating the tests. This makes it simpler to frequently update test scripts, and guarantees collaborative effort through mutual cooperation.

Stay well aligned with Developers

It is essential to be aligned with the development work. Understand all the flow and how something they have changed could impact on another completely different, for example. This will help you to anticipate and be one step ahead when maintaining the scenarios. Also, it is good all the teams work with the same environment, using the most similar tools when it is possible.

Understand the functionality of the current environment, in order to successfully perform root-cause analysis that yields in constructive solutions. This will help you to find bugs more efficiently and build your automation focusing on your actual environment. Remember you need to align your needs with your project and the current development cycle. Companies/projects/teams are not equal and there is no formula, but some tips of how can you take the best for your situation.


Open different browsers with C# and Selenium

Hey guys, I am going to post some snippets to run a test in different browsers with C# and selenium.


using System;
using OpenQA.Selenium;
using OpenQA.Selenium.Chrome;
using OpenQA.Selenium.Firefox;
using OpenQA.Selenium.IE;
using OpenQA.Selenium.PhantomJS;
using Microsoft.VisualStudio.TestTools.UnitTesting;
using NUnit.Framework;
using OpenQA.Selenium.Support.PageObjects;
using Assert = NUnit.Framework.Assert;


Driver Utils class: 

Just the beginning of the class declaring the WebDriver and the TxtSearch field, which will be used for all the below functions to open a specific browser.

namespace Helpers
 public class DriverUtils
 IWebDriver webDriver;

 //Declaring search element
 [FindsBy(How = How.Name, Using = "q")]
 public IWebElement TxtSearch { get; set; }


Open Chrome:

 public void Chrome_Browser()
 webDriver = new ChromeDriver();


Open Chrome Mobile Emulator:

 public void Chrome_Mobile_Emulator_Browser()
 ChromeOptions chromeCapabilities = new ChromeOptions();
 chromeCapabilities.EnableMobileEmulation("Google Nexus 5");
 webDriver = new ChromeDriver(chromeCapabilities);


Open Chrome Capabilities starts Maximized:

 public void Chrome_Capabiblities_Browser()
 ChromeOptions chromeCapabilities = new ChromeOptions();
 webDriver = new ChromeDriver(chromeCapabilities);


Open Firefox:

 public void Firefox_Browser()
 webDriver = new FirefoxDriver();


Open Firefox with Profile:

 public void Firefox_Profile_Browser()
 var profile = new FirefoxProfile();
 webDriver = new FirefoxDriver(profile);


Open PhantomJS:

 public void PhantomJS_Browser()
 webDriver = new PhantomJSDriver();


Open PhantomJS with Capabilities:

 public void PhantomJS_Capabilities_Browser()
 var options = new PhantomJSOptions();
"Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) 
Chrome/40.0.2214.94 Safari/537.36");
 webDriver = new PhantomJSDriver(options);


Open Internet Explorer:

 public void IE_Browser()
 webDriver = new InternetExplorerDriver();


Open Internet Explorer with Options:

 public void IE_Options_Browser()
 var options = new InternetExplorerOptions
 IgnoreZoomLevel = true 

 webDriver = new InternetExplorerDriver(options);


Assert Search Element is Displayed:

public void AssertSearchElement()

 PageFactory.InitElements(webDriver, this);


Close/Quit Browser and driver function:

public void CloseDriver(IWebDriver driver)


See you again in the end of this week, hopefully I will have the complete flow for a BDD scenario with C# and Selenium.


Pros and Cons of Robotium

Hi guys, I am writing just a summary about Robotium, because maybe I will start to work with it. So, if you have any tips or suggestion, please feel free to comment here.

Robotium is a popular Android automation framework for testing native and hybrid Android apps using the black box method. Licensed under an Apache 2.0 license and first released in 2010.

To use Robotium, you need either the source code or apk file for the app, Eclipse for building a test project, ADT (Android Development Tools), SDK (Software Development Kit), JDK (Java Development Kit), and the Robotium.jar file.

• You can develop powerful test cases, with minimal knowledge of the application under test.
• Allows user to test more flexible and convenient for analyzing results.
• Robotium allows us to take screenshots anywhere in the test (both for Emulator and Device) and save it to device internal memory or SD Card or Emulator
• The framework handles multiple Android activities automatically.
• Minimal time needed to write solid test cases.
• Readability of test cases is greatly improved, compared to standard instrumentation tests.
• Test cases are more robust due to the run-time binding to GUI components.
• Blazing fast test case execution.
• Automatic timing and delays.

Limitations of Robotium:
• Tied to JUnit 3 Instrumentation on device.
• Tied to one app process.
• It can’t work with different Applications in on test – if your application call another one (like Camera) – Robotium can’t “see” it and press any buttons there.

Parallel tests:

I’ve found this API:, but I believe that we can configure parallel tests with Jenkins too.


Thank you guys ! See you next week 🙂



How we can find a line in some table with Webdriver (Selenium) ?

Hi guys, I’m very occupied in the last months, but I will post a text about catch the lines and values in some table with Webdriver (selenium) in language java. Yes, I am changing a little the subjects, this time I will help the testers, who do automation of sites.

It’s easy if you use XPath.

This table:

Apples 44%
Bananas 23%
Oranges 13%
Other 10%


You catched the first line.

If you want catch the second line, just change the number:


It’s more easy than you expected, not ?

if you want catch all the text of all lines, just write the code:

WebElement listatable = driver.findElement(By.className(“reference”));

for (int i = 0; i < listatable.getLength(); i++) {

WebElement line = driver.findElement(By.xpath(“/html/body/div[1]/div/div[4]/div[2]/div[2]/table/tbody/tr[” + i + “]”));



Fine, now you can catch the text of each line in this table !

I hope has helped the initial testers in something.

Bye bye !