Running Firefox on AMI-Linux in headless mode

Reading Time: 1 minute


If you need to run your webdriver tests in headless mode on AMI-Linux instance, you will first need to install Firefox on that instance. Xvfb server will do the headless trick. I will also explain how quickly check that firefox is running in headless mode.

AMI linux does not officially support Firefox.  In order to install Firefox using yum, Lambda linux provides all relevant information.

yum install xorg-x11-server-Xvfb.x86_64

will install xvfb server on AMI-Linux.

In order to avoid pain of checking Xvfb and Firefox integration using Jenkins job, use this instead:

In first terminal:

Xvfb :1 -screen 0 1280x768x24

In second terminal:

export DISPLAY=:1

If error is reported, Google for solution. In my case there was conflict regarding the versions of .so libraries.

In your cucumber project, use headless gem that will transparently handle starting and stopping of xvfb server.

This post was first published at zagorski software tester blog.

Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather

Advantages of Grinder load testing framework

Reading Time: 2 minutes

In this post, I will provide arguments that amplify Grinder advantages. I was provoked to write this post because I witnessed a lot of false facts that Grinder is the worst load testing tool.

First fact. Grinder is load testing framework. It is not a tool. It is a framework that enables you to tailor load testing tool according to your needs.

In computer programming, a software framework is an abstraction in which software providing generic functionality can be selectively changed by additional user-written code, thus providing application-specific software. [source]

What are the advantages of framework?

“Give a man a fish and you feed him for a day; teach a man to fish and you feed him for a lifetime”

On the other side, JMeter is a tool:

“The Apache JMeter™ application is open source software, a 100% pure Java application designed to load test functional behavior and measure performance.”

Software testers usually prefer JMeter over Grinder because with JMeter they can start first load test without any knowledge of programming. Let me be clear, this is not bad decision only if it is appropriate to you project. JMeter offers rudimentary “visual programming”, but if you need to load test scenario that involves logic, you will need to use Java.

Grinder programming language is Jython. This is Python that runs on Java Virtual Machine which means that you are using Java multithreading. Also, you can call any library written in Java. Grinder learning curve is not steppy, but this could be resolved if you ask your developers for help. Also, by writing your first load testing script you will learn not only Grinder, but also your product (for example business data involved in http interactions).

Once I heard that Grinder is obsolete and that project is dead. Which is wrong. Grinder do not pumps up new features, because current framework features are enough to load test any modern application.

During the Grinder learning, you will also learn about multithreading programming. In Grinder this is abstracted in framework, but you do need to use Grinder framework. For example, in order to have client multithreaded logging, you need to use Grinder logging method, do not reinvent the wheel and write your own.

Grinder has basic reporting out of the box which is often pointed out as its disadvantage. In combination with Grinder Analyzer, this issue is also resolved.

Grinder is not a hammer, but also it is not worst than JMeter or some fancy paid tools.

This post was first published at zagorski software tester blog.

Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather

Enter the Dragon

Reading Time: 3 minutes


I attended Czech Test conference in Prague from 25. – 26. June. In this post I would like to explain what I learned, what I did not learned, and why I have this analogy in post title.

First of all, if you have any level of ISTQB certificate, you had 20% discount on registration.
Enter the Dragon plot:

“A martial artist agrees to spy on a reclusive crime lord using his invitation to a tournament there as cover.”

This event is highly connected with ISTQB organization. But lets be open minded and provide some facts. I took notes for every session that I attended.

It seems that speaker of opening keynote, Quality control from 0 to 100,  was not prepared to do it. It was much shorter in length, but maybe this is the case because conference start was delayed because of registration issues. Nothing about how to do proper testing was mentioned, but classic ideas from last century such as bug counting metrics or that bug found in production is expensive. There was acronym DDE, defect detected by customer or qa team. My objection to this is that importance of detected issue was not put into equation.

Rethinking QA was presentation of Concur. It was based on heavy automation and CI in order to have feedback loop as short as possible. But feedback was only regarding broken code. They implemented company culture that quality is whole team responsibility, not just of testers.

Presentation about checklist main point was to use checklist in order not to forget something important. And it is important that those checklist are dynamic, and just general guidelines. They must not become general best practices.

Writing effective test cases was about testing ideas. But not as in Context driven school of testing, where every test is an experiment, but how to write instructions for other testers. Pairwise technique was mentioned in order to cope with combination of variables. It was not explained, but that PICT tool (BBST Test design has one exercise with that tool) could be used to implement pairwise testing.

ISTQB news was 20 minute session about ISTQB. Funny thing was that on last year conference, audience feedback was that this session was boring and too long, so they make it just 20 minute. They said that by the end of this year, they expect 400 000 ISTQB certificates (so far in history) to be issued. They announced Glossary site, and as I am not big fan of this organization, I must admit that I acknowledge this site. For example, If I would need to visit client that is ISTQB infected, I would prepare myself using this glossary in order enhance our communication flow.

Panel was missing the audience input. One reason for that was that it was not clearly communicated how to ask questions. 6 ISTQB testers in suits were talking about various topics: tomato technique, procrastination, mind maps, One thing book. It was also mentioned that Wikipedia is not relevant source of facts, which I disagree. It is edited by community, and english version is promptly corrected when not true information pops up.

Performance problems session provided 4 examples from real case how to cope with performance problems of typical web application. It was good presentation.

QE default to open was about open source projects and how to manage it. Also good session.

On this conference I met Mirjana Kolarov, one of the founders of Test’RS club. She held interesting presentation: Test cases and traffic lights, is it a traffic violation? As we were in dragons nest, this was very brave presentation. It drifts towards Contest driven testing by explaining that blindly following test case steps would make us miss important issues.

And in parallel track was Zeljko Filipin How software that runs Wikipedia is tested. I have already seen that presentation, but was enhanced one. It explains testing tools and infrastructure used at

Wikimedia foundations.

Should you visit next Czech test conference? My recommendation is yes, 40% of presentation were good and I learned something from them. Also, I still have not paid for that conference, because I have not received invoice for it.

And I successfully returned from ISTQB nest!

Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather