Calling For A New Breed Of Testing Conferences

Viktor Clerc

The way in which testing is organized is changing heavily. And rightfully so. Testing should no longer be treated as a separate phase, but rather should be fully embedded within the software delivery life cycle. These developments significantly impact the role of automation in testing, the team collaboration, and how the testing discipline should be cherished and continuously improved.

C'mon, guys! GO GO GO!

Testing should be reinvented and, honestly, testers may need to reinvent themselves. The proper skill set of a tester is expanding towards the technical side in which hands-on knowledge is needed. This need may be covered by competence development through training programmes, but we all know that most knowledge and inspiration is obtained on the job. Yet, we are only at the beginning of making seminars and conferences address this need for practical experience. C'mon, guys! GO GO GO!

 Read more

Robot Framework and the keyword-driven approach to test automation - Part 1 of 3

Michael Hallik

Hans Buwalda is generally credited with the introduction of the keyword-driven paradigm of functional test automation, initially calling it the 'action word' approach.

This approach tackled certain fundamental problems pertaining to the efficiency of the process of creating test code (mainly the lack of reuse) and the maintainability, readability and robustness of that code. Problems surrounding these aspects frequently led to failed automation efforts. The keyword-driven framework therefore was (and is) a quantum leap forward, providing a solution to these problems by facilitating the application of modularity, abstraction and other design patterns to the automation code.

Robot Framework (RF) can be regarded as the epitome of this type of automation framework. Our first post on the RF concentrated on the high-level design of the platform. In this second of our three-part series of introductory-level posts, we will take a closer look at what the keyword-driven approach to test automation is all about.

 Read more

Learning about test automation with Lego

Maaike Brinkhof

“Hold on, did you say that I can learn about test automation by playing with Lego? Shut up and take my money!” Yes, I am indeed saying that you can. It will cost you a couple hundred Euro’s, because Lego isn’t cheap, especially the Mindstorm EV3 Lego. It turns out that Lego robots eat at a lot of AA batteries, so buy a couple of packs of these as well. On the software side you need to have a computer with a Java development environment and an IDE of your choice (the free edition of IntelliJ IDEA will do). 

“Okay, hold on a second. Why do you need Java? I thought Lego had its own programming language?”. Yes, that’s true. Orginally, Lego provides you with their own visual programming language. I mean, the audience for the EV3 is actually kids, but it will be our little secret. Because Lego is awesome, even for adults. Some hero made a Java library that can communicate with the EV3 hardware, LeJos, so you can do more awesome stuff with it. Another hero dedicated a whole website to his Mindstorm projects, including instructions on how to build them.

 Read more

Preparing hands-on conferences: to USB or not to USB

Erik Swets

On Friday, October 2nd, Xebia organized the inaugural edition of TestWorks Conf. The conference was born out of the apparent need for a hands-on test automation conference in the Netherlands. Early on, we decided that having a high level of engagement from the participants was key in achieving this. Thus, the idea of making everything hands-on was born. Not only did we have workshops throughout the day, people also should be enabled to code along with the speakers during talks.This however posed a challenge on the logistical side of things: How to make sure that everyone has the right tooling and code available on their laptops?

 Read more

Future of Testing and Automation: The role of the tester in 2020

Kishen Simbhoedatpanday

Last week, the first TestWorks Conf was held in Amsterdam. This hands-on conference featured a plethora of test automation tools and allowed the participants to gain practical experience with them. Since we feel and expect that all participants will take next steps towards improving their test automation practices, we decided to take a glance into the future and discuss the future of testing and automation together with Alan Richardson.

In a series of blogposts, we would like to share parts of our vision on testing and automation in the near future. First stop will be: the role of the tester in 2020.

 Read more

Robot Framework - The unsung hero of test automation

Michael Hallik

The open source Robot Framework (RF) is a generic, keyword- and data-driven test automation framework for acceptance test driven development (ATDD). As such it stands alongside similar, but more well-known frameworks, like FitNesse, Cucumber, et alia. The (relative) unfamiliarity of the testing community with the RF is undeserved, since the RF facilitates powerful and yet simple test automation against a variety of interfaces and features some distinct advantages when compared to those other frameworks.

In a series of blogposts, we would like to make a case for the Robot Framework, by showing its greatness through a number of hands-on examples from my upcoming workshop. Next to demonstrating its advantages and strengths we will also expose some of its drawbacks and limitations, as well as touch upon certain risks that flow from harnessing some of its unique features.

 Read more

Trying out the Serenity BDD framework; a report

Maaike Brinkhof

“Serenity, that feeling you know you can trust your tests.” Sounds great, but I was thinking of Firefly first when I heard the name ‘Serenity’. In this case, we are talking about a framework you can use to automate your tests.

The selling points of this framework are that it integrates your acceptance tests (BDD) with reporting and acts like living documentation. It can also integrate with JIRA and all that jazz. Hearing this, I wasn’t ‘wowed’ per se. There are many tools out there that can do that. But Serenity isn’t supporting just one approach. Although it is heavily favouring Webdriver/Selenium, you can also use JBehave, JUnit, Cucumber. That is really nice! 

 Read more

Testing UI changes in large web applications

Sannie Kwakman

When a web application starts to grow in terms of functionality, number of screens and amount of code, automated testing becomes a necessity. Not only will these tests prevent you from delivering bugs to your users but also help to maintain a high speed of development. This ensures that you'll be focusing on new and better features without having to fix bugs in the existing ones.

However even with all kinds of unit-, integration- and end-to-end tests in place,  you'll still end up with a huge blind spot: does your application still looks like it's supposed to?

Can we test for this as well? (hint: we can). Read more

Super fast unit test execution with WallabyJS

Frank van Wijk

Our current AngularJS project has been under development for about 2.5 years, so the number of unit tests has increased enormously. We tend to have a coverage percentage near 100%, which led to 4000+ unit tests. These include service specs and view specs. You may know that AngularJS - when abused a bit - is not suited for super large applications, but since we tamed the beast and have an application with more than 16,000 lines of high performing AngularJS code, we want to keep in charge about the total development process without any performance losses.

 Read more

5 Reasons why you should test your code

Frank van Wijk

It is just like in mathematics class when I had to make a proof for Thales’ theorem I wrote “Can’t you see that B has a right angle?! Q.E.D.”, but he still gave me an F grade.

You want to make things work, right? So you start programming until your feature is implemented. When it is implemented, it works, so you do not need any tests. You want to proceed and make more cool features.

Suddenly feature 1 breaks, because you did something weird in some service that is reused all over your application. Ok, let’s fix it, keep refreshing the page until everything is stable again. This is the point in time where you regret that you (or even better, your teammate) did not write tests.

In this article I give you 5 reasons why you should write them.

 Read more