The "Gut Feeling"

When information is incomplete and maybe even contradictory, but taking a decision is of the utmost urgency, you can ultimately rely on your gut feeling. Trust it, you might even save the world!

Leaders Eat Last by Simon Sinek

 A good and inspiring read from Simon Sinek.

Parallel Automated Testing with Selenium Docker Hub

Test automation - all well and good, but what happens when the product you are testing is UI heavy and your test suite increases to hundreds of tests and takes hours to fully execute? Each extra minute of runtime takes you one inch away from the Holy Grail, namely CI/CD.

The answer is test parallelisation. Executing the tests in parallel can exponentially decrease runtime, thus allowing you to get the test results faster and release quicker into Production.

Opening multiple browser instances simultaneously may not work perfect each time, but luckily we have a bulletproof solution in Docker's Selenium Hub. 

This article will present a Frontend test automation framework built with Serenity and Java and the steps for configuring its parallel test execution in a Selenium Docker Hub.

1. Setup the Docker Hub

Depending on the machine's OS, Docker is installed in different ways. In this case, the operating system was MacOS so Docker Desktop was initially installed.

Now, using a Docker Compose .yml file that contains all the setup info, you can start the grid as per your requirements (the required Docker images will be downloaded automatically). In the terminal, go to the folder where the .yml file is located and run the following command, specifying the number of Firefox and Chrome containers (2 in this case):

$ docker-compose up -d --scale firefoxnode=2 --scale chromenode=2

The debug versions of the Firefox and Chrome images will allow you to connect to them using VNC Viewer in order to see realtime the test execution.

Access http://localhost:4445/grid/console and the up and running grid is shown.

2. Configure the automation framework for parallel test execution in the newly create grid

Update the serenity.properties file with the type and new location for the webdriver:

webdriver.remote.url = http://localhost:4445/wd/hub
webdriver.remote.driver = chrome
webdriver.remote.os = LINUX

Update in the pom.xml file the Maven Failsafe plugin configuration, plugin responsible in this case for test execution, to run the tests in parallel in the new grid setup:

<configuration>
    <includes>
        <include>**/*TestSuite.java</include>
    </includes>
    <reuseForks>true</reuseForks>
    <argLine>-Xmx512m</argLine>
    <parallel>classes</parallel>
    <threadCount>2</threadCount>
    <forkCount>2</forkCount>
</configuration>
3. Run the tests
In the terminal call the Failsafe plugin, which will execute all the TestSuite classes:
$ mvn clean verify
During runtime you will see the nodes that are in use as faded out:





Check the summary results in the console and the detailed HTML report:

Upgrading a Test Automation Framework with Security Testing Capabilities

This article will cover the steps for adding security testing capabilities to an automated testing framework (designed for Backend & Frontend testing) built with JUnit5, Selenide and REST Assured.

The OWASP Zed Attack Proxy (ZAP) is a widely used web app scanner, free and open source. It comes in a wide array of setups and for this tutorial we will use the Docker version, running it headless mode in a Docker container.

Depending on the machine's OS, Docker is installed in different ways. In this case, the operating system was MacOS so Docker Desktop was initially installed.

Setting up ZAP Docker

1. Get the ZAP Docker image by running in terminal:

docker pull owasp/zap2docker-stable

2. Run the image:

docker run -u root -p 8090:8090 -i owasp/zap2docker-stable zap-x.sh -daemon -host 0.0.0.0 -port 8090 -config api.addrs.addr.name=.\* -config api.addrs.addr.regex=true -config api.disablekey=true -config scanner.attackOnStart=true -config view.mode=attack

3. Check the newly started ZAP scanner at http://localhost:8090/.

Refactoring the test automation framework so that the ZAP proxy will intercept the traffic

The test automation framework showcased in this article can be checked here. It has 3 main test classes:

- UiTest.java, built with Selenide for Frontend testing;

- RestAPITest.java, built with REST Assured for Backend testing (REST service);

- GraphQLTest.java, built with REST Assured and an additional GraphQL helper library for Backend testing (GraphQL service).

1. For the Backend tests, being built with REST Assured, this refactoring only means setting the proxy variable to the ZAP location with one simple line of code:

RestAssured.proxy("0.0.0.0", 8090, "http");

2. For the Frontend test, this refactoring is similar and implies adding the ZAP proxy when instantiating the WebDriver:

ChromeOptions options = new ChromeOptions();
Proxy proxy = new Proxy();
proxy.setHttpProxy("0.0.0.0:8090");
options.setCapability("proxy", proxy);
ChromeDriver chromeDriver = new ChromeDriver(options);

3. Run the tests and now ZAP will intercept the traffic at each test execution and identify security vulnerabilities.

Checking the results

Go to http://localhost:8090/OTHER/core/other/htmlreport and check the discovered vulnerabilities. They also come with a short description and additional resources for information.

As seen in this article, with minimum effort you can improve your test automation giving it basic security testing capabilities, thus security vulnerabilities can be discovered early on in the development process when it's a lot faster and cheaper to fix them. 

Building secure products is a shared responsibility.

Marginal Gains in Practice

What do 5 minutes mean?

Nothing.

What do 5 minutes per day for an entire year mean?

A lot!

Automated Test for Measuring a Website's Performance using Google PageSpeed Insights

PageSpeed Insights and Lighthouse are two free Google tools that we can use to measure a website's performance. Although with a common purpose, they are different by the fact that Lighthouse uses lab data only and measures more than performance data, while PageSpeed Insights focuses on performance metrics by analysing both lab and real-world data (the lab data being actually provided by Lighthouse).

This article will present an automated test built with Maven and two Java libraries - JUnit and RestAssured, that audits the performance of websites by using the features of the PageSpeed Insights tool.

First of all, PageSpeed Insights can also be used manually, simply go to its' homepage and check the metrics for your desired website:

The scores come also with a detailed explanation, a summary being:

The metrics scores and the perf score are colored according to these ranges:

• 0 to 49 (red): Poor
• 50 to 89 (orange): Needs Improvement
• 90 to 100 (green): Good

To provide a good user experience, sites should strive to have a good score (90-100). A "perfect" score of 100 is extremely challenging to achieve and not expected. For example, taking a score from 99 to 100 needs about the same amount of metric improvement that would take a 90 to 94.

For the automated test we will use the PageSpeed Insights API which returns the audit results as a JSON object. To check it, simply: 

curl https://www.googleapis.com/pagespeedonline/v5/runPagespeed?url=${desiredWebsite}

With the general performance score being displayed in the categories section of the returned JSON:

"categories": {
      "performance": {
        "id": "performance",
        "title": "Performance",
        "score": 0.85

The implementation of the automated test can be found here, with:

• JUnit being used to execute the tests, perform the @before and @after steps and load the websites list as a .csv file;

• RestAssured performing the GET request and parsing the returned JSON;

• And the actual test method asserting that the performance score is greater than or equal to 90 being:

@ParameterizedTest
@CsvFileSource(resources = "/pagespeedonline/websites.csv")
void testWebsite(String website) {
    RestAssured.baseURI = "https://www.googleapis.com";
    Double performanceScore;
    Response response = given().log().uri().
    when().get("/pagespeedonline/v5/runPagespeed?url=" + website).
    then().extract().response();
    assertThat(website, response.getStatusCode(), equalTo(200));
    performanceScore = Double.valueOf(response.path("lighthouseResult.categories.performance.score").toString());
    websiteScores.put(website, performanceScore);
    assertThat(performanceScore, greaterThanOrEqualTo(0.9));
}

Being a Java project built with Maven, this test can be easily added in a Jenkins job and executed periodically as a performance healthcheck.