And now for something (not quite completely) different - Cognitive relativism in consultancy

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 →

The Robot Framework Remote Library Interface: using the Remote Database Library to connect to IBM DB2

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 →

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

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 →

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

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 →

Robot Framework - The unsung hero of test automation

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 →