Running webpagetest from CLI

Sometimes you have a need to run web page load speed test without an UI. And of course, as per usual, there’s a node module for that.

I’ve been checking out https://www.webpagetest.org/ and they do provide a web interface, and an api, as well https://sites.google.com/a/webpagetest.org/docs/advanced-features/webpagetest-restful-apis.

Besides those two sources, there’s also a node module for running the tests:

https://github.com/marcelduran/webpagetest-api

Here’s how to get it working (running on macOS at the moment).

  1. git clone git@github.com:marcelduran/webpagetest-api.git
  2. cd webpagetest-api
  3. docker build -t webpagetest-api .
  4. Get the API Key from webpagetest.org/getkey.php
  5. Run the test: docker run -it –rm webpagetest-api -k YOURAPIKEY test https://twitter.com/marcelduran
{
  "statusCode": 200,
  "statusText": "Ok",
  "data": {
    "testId": "190206_19_f4ed62b215aa61ed44085cdf0cac1779",
    "ownerKey": "c65d1fd5da5233aada1c4b1064bf39d05b4a81c4",
    "jsonUrl": "https://www.webpagetest.org/jsonResult.php?test=190206_19_f4ed62b215aa61ed44085cdf0cac1779",
    "xmlUrl": "https://www.webpagetest.org/xmlResult/190206_19_f4ed62b215aa61ed44085cdf0cac1779/",
    "userUrl": "https://www.webpagetest.org/result/190206_19_f4ed62b215aa61ed44085cdf0cac1779/",
    "summaryCSV": "https://www.webpagetest.org/result/190206_19_f4ed62b215aa61ed44085cdf0cac1779/page_data.csv",
    "detailCSV": "https://www.webpagetest.org/result/190206_19_f4ed62b215aa61ed44085cdf0cac1779/requests.csv"
  }

Report Portal Installation

Introduction

We do have a need to analyse the stability and usability of our tests, too. We do monitor our systems from here and there, check the code coverage of /development code/. Funny when you think about it, but test automation is part of development process and should be addressed as such. Even more if you’re developer who runs the code.
I have been running all sort of analytics based on test executions in Jenkins, written parsers in python and building dashboards on ELK -stack. And boy it has been fun 😀
Then I heard about this tool, Report Portal (http://reportportal.io) from a podcast from Joe Colantonio and decided to take a look. I am nowhere near to make any conclusions, but after a brief usage it does look promising.

Running locally

Report Portal has a demo environment you can try with your tests, but it really comes in handy if you host it yourself. And they provide instructions to that in http://reportportal.io/download. I have followed the instructions and listing them down in here. To be honest, I do think they do brilliant job already and my notes here are more for myself. To recall the process in a better way and sure, and to get some clicks on my blog, too 😀
First of all, you’ll need to have `docker`installed. After that everything should be easy.
NOTE:  In MacOs (at least) you should allocate at least 5 GB memory to the docker process. I had only 2 GB and everything was looking good from the process side, except that I could not log in. I do recall running the same in Linux without changing anything and it just worked.
  •  mkdir ~/reportportal
  • cd ~/reportportal
  • Download the docker-compose -file:wget https://github.com/reportportal/reportportal/raw/master/docker-compose.yml
  • mkdir -p data/elasticsearch 
  • chmod g+rwx data/elasticsearch
  • sudo chgrp 1000 data/elasticsearch (here’s a difference. I had to run the chgrp in MacOS as sudo)
  • docker-compose -p reportportal up -d --force-recreate
When the compose is ready, you should be able to browse to the Report Portal UI: http://localhost:8080/ui/
Log in using default/1q2w3e.

Robot Framework integration

In order to get the Robot Framework results to report portal, you need to use a separate library.  GitHub – reportportal/agent-Python-RobotFramework. I will create a new blog post on this and add more information there.

jmeter/Blazemeter integration

Basically all we have to do is to generate a junit.xml -report from the test run, zip it and then send it to the report portal API. I will create a new blog post on this and add more information there.

jest-puppeteer integration

GitHub – reportportal/agent-js-jest: ReportPortal agent for the Javascript Jest unit test framework. I will create a new blog post on this and add more information there.

Day 4 (of 30 Days of Automation in Testing)

Day 4: What kind of testing can automation support you with?

Unit testing comes to my mind as the first one.It helps me as a tester in a way that I let developers do the deeds and learn to trust they do things right. Even reviewing the unit test code is actually a neat learning experience, once you get to understand the unit test logic.

Functional testing during or right after the build, can also be done by same unit testing approaches, which is also a neat way to verify the functionality. The benefits on that one is that the code is readable by the developer who wrote it and (in case it’s not made with Perl) even with other members of the team or company. To have the tests usable and readable in the same IDE developers use, leads also to easier debugging. What usually lacks is decent reporting, but then again, all we need to know that it fails when it should and passes when everything really is OK.

Mocking the test environment and harnessing the SUT. They walk hand in hand. There’s plenty of nice mocking tools, wiremock for example. One might also re-invent the wheel here. I mean the mock can be just a file you fetch from another system or write yourself. Does not sound too much automating, though 😀

Load testing is also one of the standard ones to be used with automation. Given the powers of the servers, new container technologies and distributed load testing services, you can build your own solution or use a ready made service, like blazemeter or octoperf.

Repetitive functionality tests, regression tests and release tests in any step of the development process are good to automate, given that you are going to use the automation more than few times.

Then the whole world of Continuous Delivery and Continuous Integration. It will not happen properly if you do not have the right tests put in right places. Well it might be OK to let the users test the product, but that would mean that you should have an automated monitoring system that gathers the data you will need. That’s also one way of automation that will help.

And of course all of the test data generating tools, self-made or otherwise, bash- or python -scripts for setting up the environments together with containers and their managing tools (docker, docker-compose and kubernetes to start with).

I most likely am missing something here, still. I mean where do you draw the line when it comes to automation in testing? Is it only the testing tools (like jMeter, Robot Framework etc.) or the tools that let you yourself automate mundane tasks to ease your testing process.

 

 

30 Days of Automation in Testing

Once again it is summer, once again Ministry of Testing comes up with interesting 30 days challenge.
This year I spent my vacation already in May, so that excuse for not doing this won’t do; I’ll have to tackle this one.
The challenge is about test automation, sponsored by SmartBear (I do not like their products, but what can you do except not to use them 😉 ).

Day 1: Look up some definitions for ‘Automation’, compare them against definitions for ‘Test Automation’

Whereas automation definition in Wikipedia (the source of the sources) is actually handling a wide range of different mechanical and programmatical approaches, Test Automation is considered only to be software related and listed as part of software development. I do consider that one could test things mechanically and control the checkers, tools and results by machine, at least when it comes to simple checks. Wherever you’ll need human interpretation, it is actually easier to get a fellow human to make a judgement. Machines are good to make repetitive tasks easy, but they are also well capable to repeat an erroneus step several times automatically, unless someone controls the situation.
But anyhow, the biggest difference between automation and test automation according to wikipedia is the narrowing of test automation on something that’s done with software.

Day 2: Begin reading an automation related book and share something you’ve learnt by day 30.

Agile Automation and Unified Functional Testing by Rajeev Gupta

I’m also trying to make it through this course:
REST API Automation testing from scratch-(REST Assured java)

Day 3: Explore the automation thread on The Club and contribute to the conversation

Added my contribution to https://club.ministryoftesting.com/t/when-to-start-automation/11743/10

JMeter and HiDPI -displays

It does bug the hell out of me that in Windows 10 jMeter 4 seems to be working just nicely, regardless on the display -resolution. That’s just plain wrong. I mean, Linux and MacOs are superior and advanced operating systems, or?
Anyhow, when I run jMeter 4 (or the earlier ones, too) in Linux – haven’t touched that in MacOs in ages, but I assume the situation has not changed a bit – the display and the fonts are so tiny that it makes the back of my head hurt from the tension. It is no good.

Apparently, there’s a bug (or 2) in jMeter:
https://bz.apache.org/bugzilla/show_bug.cgi?id=58426
https://bz.apache.org/bugzilla/show_bug.cgi?id=59168

Luckily there is stackoverflow. I managed to find the cure from there and from jMeter manual:
https://jmeter.apache.org/usermanual/hints_and_tips.html#hidpi

How to do it?

  1. Open the apache-jmeter-4.0/bin/user.properties
  2. Add the following lines in the end of the file
jmeter.hidpi.mode=true
 jmeter.hidpi.scale.factor=2.0
 jmeter.toolbar.icons.size=48x48
 jmeter.tree.icons.size=32x32
 jsyntaxtextarea.font.family=Hack
 jsyntaxtextarea.font.size=28

Voilá. You’re done. All you need to do now is to start jmeter.

There has been Robots (TM)

 

We did have the (I suppose it was) first Robot Framework -related MeetUp in Sweden yesterday evening. It was held at the premises of Fareoffice Car Rental Solutions Ab in Kungsholmen.

There was not plenty of participants, but there was enough. The company and the office are small, so it was actually a good thing to have a ‘lagom’ crowd. Which in this case was 9 from outside the company, me, Pekka Klärck and 4 from Fareoffice.

First Pekka gave an introduction and background talk about Robot Framework. It was actually good to watch (for me), for I learned a few new things, once again. Even though he had held almost the same speech during the day before, while having a Robot Framework Workshop/training to Fareoffice, there still was few new issues to cover. Besides that we were talking about general usage of plug-ins on IDEs, RoboCon and running the tests with different setups.

The second was my trial of fire. I had a presentation about Robots in Containers. It went surprisingly smoothly. I had few technical glitches, but I knew they were there so the ghost of a demo-god did not ruin my presentation.

Of course there were few things I’d do differently. First of all, it was too quick. Secondly, I could’ve concentrated more on practical execution of the steps I was describing with  pictures; a live work is always better than preserved slide. Even if the deck of slides are be done with Prezi.

So it goes. I was tense, nervous and did all the typical flaws a Finn can do when representing and reflecting my MeetUp arrangements and presentation; I picked up all the mistakes I thought I had made. That is pretty much a built-in feature for us grown up in (the 80’s at least) Finland. Luckily, you can always trust a Swede to be there and comfort you. Empathy in Sweden is a strong and positive thing. Thank you for all participants for being there and for the support.

The best part of the MeetUp was the people and the discussions we had. It was great to see that there were others using Robot Framework here in Sweden.

I was also asked about running Selenium tests on IE/Edge, and we ended up showing the tests the way we do it; running them from Jenkins and in Browserstack. But that is not running on premise. Which meant I could not give a straight answer, which bugged me a bit, as usually. It started to feel kind of a challenge and I might want to pick it up on next creative Friday (once a month tradition at Fareoffice). So to say, spin up a Windows server and install Zalenium in it. Working with Windows would be a worthy challenge for me, an avid Linux -user as I am, and could serve as a good reminder on the fact that even the operating systems should be seen as tools. And every tool has its purpose.

In the end, we decided to create a MeetUp group and have the next meeting at Eficode’s premises in Stockholm. There was also few ideas about where to host RoboCon in 2019. All in all I am really happy I decided to push this one through, believe me, I had my doubts beforehand 😀

 

Logstash filter for Robot Framework

We are currently working on CI/CD -setup at work. As part of that, the tests need to be able to be implemented as a part of the pipeline.
Generally, the pipeline consists of steps/stages done with jenkins pipeline. The benefit on this is that the whole process and definition of the stages (Deploy, test etc) will be done by the developer team and stored in the teams own repository and is therefore controlled by the team also. Which is definitely a great step towards for the teams having more freedom and more responsibility when it comes to deliver the applications/solutions to the production. Needless to say it will also affect to the visibility of the quality and to the need of tests.

Plus that it will definitely keep the test team on their toes. Keeping ahead becomes a really neat challenge 😀

Now that does add more requirements also on the testing tools. First of all, the tools we use should be able to be used from containers. Which means that everything is dockerized. Well, the test code itself is in the repository, but the engines running the tests are in the containers.
We use, whenever we can, a general docker images from dockerhub.
Sometimes it won’t work like that. So we end up re-inventing the wheel.

That was the case with logstash. We will need to be able to filter the Robot Framework’s output.xml and send it to elasticsearch. There was two possibilities to do that; logstash filtering or xml parsing. The xml-parsing remains to be done still (I am going to do it), but I did manage to create the logstash -filter. It is not completely flawless, not even the most elegant, but at the moment it seems to be working as it should. To be honest, I was aiming to have a one more blunt instrument for our test needs.

The filter:

robot-results.conf

input {
 file {
 path => [ "/output.xml"]
 }
}

filter {
 xml
 {
 source => "message"
 store_xml => true
 target => "doc"
 xpath =>
 [

"msg", "doc.msg",
 "arguments", "doc.args",
 "kw", "doc.keyword",
 "status", "doc.status",
 "status/@status", "doc.test.status",
 "robot", "doc.robot",
 "errors", "doc.errors",
 "statistics", "doc.statistics",
 "suite", "doc.suite",
 "tag", "doc.tag",
 "total", "doc.total",
 "/kw", "leftovers",
 "/arguments", "leftovers"

]



}
}



output {
 elasticsearch {
 hosts => ["elastic"]
 index => "logstash-%{+YYYY.MM.dd}"
 }
}

Dockerfile:

FROM logstash

ADD robot-results.conf /etc/logstash/conf.d/robot/results.conf
CMD logstash -f /etc/logstash/conf.d/robot/

Running the container:

docker run --add-host=elastic:127.0.0.1 janmat/logstash-robot

 

You pick the right tool

 

As you can see, it is sometimes crucial to select a right tool. Even to stick to it, regardless on how awkward and painful it might feel. I just had to open with this scene, it is anyhow from one of my all time favorite movies. The book it is based on, is definitely one of my top 5:s.

We’ve all been there. It’s late night, we’re out in the park, having fun and all we have left is bottle of wine. And of course the corkscrew is nowhere to be found. So you start using your imagination. You might have a normal screw and a screwdriver, maybe a pair of tongs, too, you might be carrying a multi-tool, for what I know. Or not. The cork stays in the bottle.

You go through your pockets again, ask your friends, someone says that all he’g got is a pen, other one offers you a rock.

You see where I’m going here? A pen is mightier than a rock? Well, at least now it is.

Now you could open the bottle by smashing the head to a rock. Or smashing the rock to the head of the bottle. That might work, too. In the other hand, there’s always risks of getting bottle broken so, that the glass gets inside the bottle. Besides, that will create a mess in the grass and I a devoted dog owner and animal lover hate when people break bottles or other glass and leave the stuff there. Besides, people can get hurt too, for real.

So that leaves you the pen, right. You could write a letter – I know, it’s old school, but it’s nice sometimes, for real – to someone with a corkscrew to drop by. What’s there to loose? You got the whole weekend ahead of you (Did I mention it is a Friday night?) Or you could rob a corkscrew store with it, not the world’s best idea, though, giving it to be late night and the stores are all closed.

You could also take the pen and push the cork inside the bottle. That actually does work. You might get to spill some, but then again, at least there isn’t going to be shattered glass anywhere for the paws of the two to four legged friends. Notice I left a place for three legged dogs or cats, even squirrels.

So, you take the pen and grab the bottle. Your hands are getting a bit sweaty so you what your sleeve around the bottle. It keeps it in its place. Not completely, but firm enough. You take a breath.

You push the pen against the cork and push. Nothing happens, except the veins in your temples seems to be exploding, your face turns to red and the pen hurts your palm. A lot. You let go for awhile, and try again. No change to the situation. Cork is till on and you seem to be screwed.

A friend of yours, the one that has taken one more than you, mumbles something and offers you the stone from his hand. You look at him and smile and are about to shake your head, but change your mind and take the stone.

It is smooth on the other side, the side agains your palms has some edges and it feels, if not cold, then at least cool. You take the stone, push the bottle against the ground and hold it between your feet and hold the pen on your other hand against the cork. Then you slowly but firmly hammer the pen inside the bottle with the stone and finally, you’re done. Everything’s fine again, you drink the wine, get in to the night and wake up next morning with a hangover and some blurry memories. You might even end up having fun, who knows.

What I mean here is that you should choose your tools, for real. First of all you need to know that you have a need for a tool, then you need to check what requirements you have for it, then you need to find it. Thanks to the interwebs, it is fairly easy nowadays. After finding the tools, take several, and use them for awhile in the situation needed. So to say, evaluate them.

If you run into problems with the tool (you should, for real, even a sledgehammer needs some maintenance), try to find out if anybody has had the same issues. Most likely you’re not alone.

Check the maintenance costs. If you use more time maintaining the tool than the flaky tests, you probably have the wrong tool. Regardless on how good it looks, sounds or feels.

And once and for all; don’t get stuck with the first evaluation, don’t get stuck with your evaluation choice, either. In case the tool loses its focus and usability, make sure you can move away from it.

I myself are at the moment in that kind of situation: using a multitool with a gentle learning curve, but the maintenance and the license is starting to feel bad. It was a tool I was familiar with, a tool I’ve used for years in the previous companies, and it used to be an open source tool. They ended the open source path last year (if I remember correctly) and otherwise turned the usability a bit more worse, too.

So I’m considering moving the tests to another multitool, an open source based tool with steeper learning curve, but a considerably larger user group. Actually, I’ve done my consideration, all I need to do now is to transfer and modify the current tests from the first tool to the second one.

Some days of testing

Well, of course everything always goes as planned. Or then again, of course not. And when they don’t go the way you thought, planned or wanted, you might get a temptation to just let it go. But letting go would let you only quit, not finish. Determination or stubbornness – call it what you will – you need it. Especially when handling things that are voluntary and not always easy to squeeze in to your day.

That being said, I’ve been struggling. Anyhow, here’s a small report on things I’ve managed to accomplish so far.

Day 7: Find an accessibility bug.

I suppose it was this one that broke my flow. First of all, I came in a day late, dollar short. Second thing was that I’ve never done any accessibility testing. That, me being in the case, leads some  issues.

I have always been ‘try first, stumble and read the manual to get to know what did I do wrong’ -type of guy. This time was no exception. I ended up reading few short sentences on the  W3 accessibility testing wiki and rushed my way to turn on accessibility features on my notebook. After fooling around for awhile I got nowhere, if not to the land of frustration. The laptop is old and slow and it had difficulties to read the web pages in Finnish so that I would actually understand. That was due to the lack of memory (most likely) and bad/lacking support of the chipset. I’m running CloudReady/Chromebook OS on Asus EeePC with Intel Atom chipset. It fails to work on most of the OS I’ve tried.

So I gave up.

You see, testing is my profession and therefore it actually is my passion. But not on my spare time. I have divided my days between work and non-work, and it suits me fine. It just don’t help doing test related tasks (regardless how fun they are :D) on my spare time. It’s not that I wouldn’t like, but as I have my priorities at work, I also have them when I’m at home. And in that kind of issues, it actually is really easy to quit. Which I did.

But now I went and read a bit more on accessibility testing and noticed that there is few semi-automated tools listed on the page. I suppose I’ll give them a try at work on some of our interfaces. Semi automation is still partly automation (which I do like a lot) and I might also find something worthwhile. You never know where you end up when you start testing without a decent specification. And even with a spec you might find yourself in between rock and a weird place.

 

My plan was to write about the other tests I did (but did not write about), but this post starts to get long enough, I’ll have to fill the other blanks later on.

Features of a (good) test environment

Easy to deliver

The test environment should be able to be delivered by request with as little input as humanly possible. A click of a button, a SMS sent, a commit to VCS should be able to act as a trigger.

Steady

The test environment should be as stead and as reliable as possible so that we can rely on that the failing tests are not caused by faults in the test environment

Open Source

I do see that the benefits of open source tools and projects are way more beneficiary than what you get from plain commercial tools. Even though you might end up paying for the support and building in the knowledge, it still pays off in the end.

Easy to Set-up

The test environment should be able to be set up by just pressing a button. If external information is needed a set of variables should be able to entered automatically.

Easy to Reset

You should be able to reset the test environment to a desired level of functionality at any point of time in order to re-execute the failed tests. Furthermore, it would be great to have a possibility to automatically run deeper analytical tests automatically in case of failure.

Easy to Monitor

Test environment should provide an interface where you can easily see the status of the tests, historical metrics and also the status of the test environment.

Provides test data

Test environment should contain test data generator which could by request fill in the databases with relevant test data. It should contain a simple interface in order to receive and response with the requested test data. The test data generator should not affect to the performance of the actually tested item.

Provides test results and metrics

Test environment should be able to provide the status of itself. And since it consists of the whole system plus the underlying parts, it should be able to deliver the status as effortless to the users and stackholders as possible.

You could, for example have a status interface. An interface that provides the status of the test environment in a single view.

There should be an interface – a web interface would nowadays be enough – that gives you all the relevant information about the tested items. And all this in a glimpse.

For the event monitoring, you could use ELK (Elasticsearch, Logstash & Kibana).

For the test monitoring, you could use the wall display on Jenkins. That at least shows the status of the executed tests. What I am missing from there is the status of individual test cases instead. One way to get them would be to build the tests in Jenkins per test case and add separate views per test suite.

But even that would tell the status only per test suite. What if you had several test suites in the project and 4/5 of them would be executed, 1/5 would be skipped and 10% of the executed test cases would have failed. How to display that?

Above those you would need to have to know the other metrics; load test results, combined result of different test suites, status of the all available test suites and test cases combined with the execution of the test cases today. The list seems to be endless here.

And all in a single look.

Or would it be enough to just have one page that indicates the status of the test environment together with the status of the test results. With two different indicators.

But what should the indicators then be? Traffic lights? Metrics? Curves? Flowcharts? Or combination of them?

What I’d like to know here is if there already exists such a system, or should I start to create that myself? Not that I haven’t been reinventing the wheel before (trust me, I have created my share of 3-sided ones), but it might help if I’d knew I wouldn’t have to.