This is the second post in a series that will address some of the problems and questions surrounding the usage of the Robot Framework (RF), that I encounter frequently in the field. Click here to take a look at the first of these posts. As I have stated in the introduction to that post, I will sometimes use these treatments also as an opportunity to make small digressions, so as to shed some light on the internals of the RF.

This post will show you how to implement a simple and yet very efficient mechanism for resource sharing within the framework. Actually, I will use three separate posts to do so. The post you’re reading now, will be the first of these.

Robot Framework provides an out-of-the-box mechanism for sharing, i.e. re-using, various types of resources. However, depending on the size and complexity of your test automation project, this mechanism can sometimes entail quite some maintenance work in and of itself. In three posts I will describe a setup for sharing, that will virtually eliminate the involved maintenance effort. Additionally, this setup will provide you with a few, very fundamental, abstraction layers that you will have to apply in any given test project.

So, let’s first have a look at the main types of RF resources and at how these resources can be reused within the RF (first post). Then we will describe the problem surrounding this native mechanism (second post). Finally, we’ll be providing a solution to this problem (third and final post).

Read more →

Deze blog post is de eerste in een reeks van posts ter wegneming van misvattingen rondom het thema testautomatisering. Zie hier voor het inleidende artikel.

Misvatting

“Testautomatisering is de oplossing voor al onze problemen rondom testen en kwaliteit.”

Toelichting

Dit is helaas nog steeds een gangbare opvatting onder voornamelijk, doch zeker niet uitsluitend, ongeïnformeerde stakeholders op (lijn-) managementniveau. Daarbij blijft deze misvatting ook vaak onuitgesproken. Vanwege dit impliciete karakter, blijft deze zienswijze doorgaans lang bestaan, omdat zij niet (of te laat) onderkend en daarmee ook niet (tijdig) gecorrigeerd wordt.

Read more →

De geschiedenis van testautomatisering beslaat inmiddels een periode van enkele tientallen jaren. Deze discipline is echter pas de laatste jaren écht in een stroomversnelling geraakt en ze lijkt nu voor het eerst ook definitief door te breken en zich te bestendigen, als een relatief volwassen vakgebied.

Deze ontwikkeling is een gevolg van onder andere de maturatie van tooling en frameworks, de adoptie door grote spelers zoals Google en de succesvolle opkomst van software development methodologieën die testautomatisering als randvoorwaarde hebben of waarvan testautomatisering een logisch gevolg is.

Omdat testautomatisering in deze zin genomen nog maar een relatief jong vakgebied is, bestaan er binnen dat vakgebied nog steeds een hoop misvattingen (en daarmee valkuilen). Zelfs ten aanzien van allerlei fundamentele thema’s. Deze misvattingen bestaan in een organisatie vaak niet alleen binnen allerlei (hogere) managementlagen en groepen van (meer direct betrokken) business stakeholders (zoals product owners), maar zelfs binnen allerlei groepen van practitioners (zoals developers en testers).

Read more →

Since joining the test automation unit of Xebia (June 2015), I have written some blog posts, all revolving around the topic of …, well, … test automation. However, there are a lot of other topics, across various domains, that have my interest and with regard of which I hold pretty strong, sometimes even passionate, views and opinions. These domains and topics are partially technical and partially non-technical in nature.

To be able to express my views and opinions as pertaining to the latter, that is non-technical, domains, I am launching a series of posts under the moniker of ‘something (not quite completely) different’. The qualification of ‘not quite completely’ is in place to indicate that, although these posts will address non-technical topics, they are nevertheless relevant to the world of (test automation) consultancy.

This post will be the first of these and in it I will be riding one of my all-time favourite hobby horses, namely fighting a commonly held and, as is my opinion, untenable and quite dangerous post-modern notion. It is a misconception that I have to deal with (and even struggle with) on an almost daily basis.

It is the fallacy that there is no truth in discourse (or anywhere else, for that matter), but for the multitude of subjectively held opinions that are all equally and to the same extent true and valuable. Sometimes a variation on this is, that an opinion may be true for whomever holds that opinion, while, at the same time, it may be untrue for anybody else (since we all ‘create’ our own truths which do not necessarily need to be in coherence with each other). A popular adage to summarize this view, is the often used phrase ‘perception is truth’ (or ‘perception is reality’). Most often people simply state that ‘all truth is relative’ or ‘there is no absolute truth’. Lots of people also (albeit mostly unbeknownst to them) quote his Dudeness (you may also address him as ‘Duder’ or ‘El Duderino’):

In more technical terms, this fashionable belief is often designated by the phrase ‘cognitive relativism’.

Employment of cognitive relativism is typically opportunistic in intent and, as such, bears all the hallmarks of a deus ex machina. It is a cheap, lazy, shallow, cowardly, uninformed/thoughtless and ultimately hysterical pseudo-intellectual stance, as will become apparent in the remainder of this post. Moreover, it is the ultimate discussion killer. But above all: it is absurd! Therefore, as we will see, it can be formally proven to be untrue by way of reductio ad absurdum.

Read more →

In the aftermath of my Robot Framework workshop at the Xebia 2015 TestWorks Conf, I received several e-mails from people who had attended the workshop. They were asking questions and describing (smaller and larger) problems surrounding various aspects of their test automation efforts with the Robot Framework. Some of these questions and problems are identical to those that, as a consultant, I encounter in the field. Since the involved topics may thus be of interest to a broader public, I decided to dedicate a series of blog posts to them. Better (very) late than never, right?

The first of these posts will show you how to use the Java Database Library while running RF on Python and also elaborate on why you may want to do so. As an extra, we will be putting the library into actual use as well, by connecting to an IBM DB2 database and, subsequently, running some keywords.

Please note that I will use these treatments also as an opportunity to shed some extra light on various aspects of the RF that we will encounter and that I feel may be of interest to those that would like a somewhat better understanding of RF’s internals. So, for some readers this will feel like a mild and acceptable (and maybe even welcome) digression, while for the practically inclined it may constitute an inexcusable transgression. You can’t win ’em all, I guess. 🙂

Read more →

In part 1 of our three-part post on the keyword-driven approach, we looked at the position of this approach within the history of test automation frameworks. We elaborated on the differences, similarities and interdependencies between the various types of test automation frameworks. This provided a first impression of the nature and advantages of the keyword-driven approach to test automation.

In this post, we will zoom in on the concept of a ‘keyword’.

What are keywords? What is their purpose? And what are the advantages of utilizing keywords in your test automation projects? And are there any disadvantages or risks involved?Read more →

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 →

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 →