The Facile Agile Manifesto

Geert Bossuyt

Agile is a mindset.  It comes with certain behaviour and a certain culture.  As with many things most people and organisations have to go through some serious change before they can actually be successful within an Agile setting. Change is hard, and it takes time.  I strongly believe that it helps when you simply understand what you're trying to achieve.

'Agile' is no buzzword or a complex management theory, it's natural behaviour for millions of people;  It's not for managers.  It's for everyone and it's easy to understand as long as you acknowledge that 'being Agile' has nothing to do with the process you follow or the tools you use.  'Being Agile' is about culture, behaviour and mindset.

This post intends to reword the Agile Manifesto in a way that makes its meaning obvious.  Understanding something,  doesn't mean you're immediately capable of doing it, but it's a very good first step and it will help you on your way.

 Read more

Agile Testing in Offshoring Software Development

Sjors Grijpink

During the last 15 years modern communication means have taken a giant leap. The world is becoming smaller and smaller; working closely together with colleagues around the world on a daily basis is a reality for many people. This is particularly true in offshoring IT. The benefits are clear: more qualified people and lower costs, but there are also challenges.

In this blog I will show how offshore software development can be improved by using Agile principles and best practices. I will show you how the Agile Tester and Agile Testing practice play an important role in this approach. I assume that the reader is familiar with Agile Software Development and Scrum.

 Read more

The "Performance Series" Part 1. Test Driven Performance.

Wilco Koorn

A number of my colleagues and myself recently decided to share our knowledge regarding "performance" on this medium. You are now reading the first blog in a series in which I present a test-driven approach to ensuring proper performance when we deliver our project.

Test driven

First of all note that "test-driven" is (or should be 😉 common in the java coding world. It is, however, applied to the unit-test level only: one writes a unit test that shows a particular feature is not (properly) implemented yet. The test result is "red". Then one writes the code that "fixes" the test, so now the test succeeds and shows "green". Finally, one looks at the code and "refactors" the code to ensure aspects like maintainability and readability are met. This software development approach is known as "test driven development" and is sometimes also referred to as "red-green-refactor". Read more

Conditionally Running Tests in TestNG

Jeroen van Erp

In this post, my colleague Barend showed how one can conditionally ignore certain tests in JUnit. In this post we will take a look at how this can be solved in TestNG, another popular testing framework.  Read more

Conditionally ignoring JUnit tests

Barend Garvelink

A useful technique that I reinvent every once in a while is conditionally ignoring JUnit tests. Unit tests are supposed to be isolated, but occasionally you hit something that makes assumptions about the environment, such as code that executes a platform-specific shell command or (more commonly) an integration test that assumes the presence of a database. To keep such a test from breaking unsuspecting builds, you can @Ignore it, but that means you have to edit the code to run the test in a supported environment.

Proper Maven projects put their integration tests in a separate source folder called src/it/java and put an extra execution of the maven-surefire-plugin into their pom.xml, tied to the integration-test phase of the Maven build lifecycle. This is Maven's recommended way of setting these up. It ties in beautifully with the pre-integration-test and post-integration-test phases that can be used to set up and tear down the environmental dependencies of the integration test suite, such as initializing a database to a known state. There is nothing wrong with this approach, but it's a bit heavy handed for the simplest of cases.

In these simple situations it's easier to just keep the integration tests in the src/test/java directory and run them along with all your other tests. However, you still need a way to trigger them only when the right environment is present. This is easily dealt with by writing your own JUnit TestRunner and some custom annotations, as shown below.

 Read more

Testing Akka with Specs2

Age Mooij

This year I have been working on several systems based on Akka, usually in combination with the excellent Spray framework to build fully asynchronous actor-driven REST servers. All in all this has been going very well but recently I had to reinvent a certain wheel for the third time (on the third project) so I thought it might be good to blog about it so others can benefit from it too.

The problem is very simple: Akka has great unit test support but unfortunately (for me) that support is based on ScalaTest. Now there is nothing wrong with ScalaTest but personally I prefer to write my tests using Specs2 and it turns out that mixing Akka TestKit with Specs2 is a little tricky. The Akka documentation does mention these problems and it gives a brief overview of ways to work around them, but I could not find any current example code online.
 Read more

Dealing with bad news

Kishen Simbhoedatpanday

Couple of weeks ago I realised something. As an Agile tester it’s really hard to communicate bugs! Testers are known for bringing bad news, but it is not easy to do it correctly. Specially when you’re in a Scrum Team and the heat is really on with bugs or issues flying all around.

 Read more

Come on, vagrant up! Saving Vagrant images that don't get a NAT address

Andrew Phillips

As part of testing and demonstrating our advanced deployment automation1 platform Deployit, we at XebiaLabs use a lot of cloud and Devops tooling to be able to handle all the different types of middleware we support and build, CI and Ops tooling with which we integrate2.

I was recently setting up a Vagrant3 environment to demonstrate Deployit's Puppet module, which automatically registers new Puppet-provisioned middleware with your deployment automation platform to enable application-tier deployments to it, and ended up wrestling for quite some time with a tricky VirtualBox problem.
 Read more

We are not Testers

Cirilo Wortel

In 2009 Steward Reid predicted that within 10 years 70% of all software development would be done with some form of Agile methodology.  Due to the growing need for ‘’hands’’ this would result in having to employ also the less qualified testers on these projects. The first point he made is absolutely valid, the second point is only valid looking at it as a commercial opportunity (you don’t need hands if you work with qualified people), maybe he only said it to comfort the people who fear loosing their jobs because of this shift. It’s obvious that now Agile is becoming main stream there is a growing demand for qualified testers. Read more

How to improve your TDD skills

Arjan Wulder

Do you think that you do TDD well because you have been doing it for years now? That is what I thought until I did an exercise called “TDD as if you mean it” and it put my feet back on the ground!

At two different TDD workshops I have tried to build an application following the rules of “TDD as if you mean it”. The first time was in Amsterdam at a Coderetreat and the second time at an XKE session at Xebia. Although I am practicing TDD for a while now, the result of the exercises in both sessions were that I had few tests, even less production code and an application that did not work.

 Read more