BDD can work

“No tendency is quite so strong in human nature as the desire to lay down rules of conduct for other people.” ~William Howard Taft There are way more case studies about disasters than success. And I don’t believe, as I have worked on some projects that on the face of it, ran poorly but still managed to deliver. It is very easy to dissect a project negatively - there is always room for improvement.

You are always doing it wrong

I keep reading/hearing statements about the purpose of test automation, and it’s starting to grate. What grates is hearing the same soundbites, as 10+ years ago, by people who seem more interested in raising their own public profile, than making real change. I don’t want to be pointed about this, if possible. I am aware it is easy to get caught up in something, such as perception of testing for example.

TravisCI Matrix

TravisCI Matrix enables you to run two or more jobs concurrently. For example, it is prudent to separate out load tests and UI tests. The following travis.yml snippet illustrates how to use this approach to run two types of tests in parallel.

Tota11y accessibility checker

Adding the Tota11y Web Accessibility Tool to your site is just a matter of adding the script call to the Tota11y script, just above the tag in your template. Then you can do accessibility tests using the Tota11y feature from site UI. The following example is within context of webdriverio, but the javascript is similar for other JS test frameworks

Don't waste your time

One thing I do not like is wasting my time; and an area prone to time-wasting is test automation. Test automation needs the same continual improvement approach, as anything else on a project. Firstly you want to be a “Test Engineer”, not an “Automated Tester”, or should do. The wikepedia definition is not bad at all: “A test engineer is a professional who determines how to create a process that would best test a particular product”.

How much do we need to say?

how much do we need to say? “Every so often, we get the bungee jumps, but as a whole, life mostly floats along. We make our lives exciting in retrospect, but life is a lot of mundane moments, which isn’t bad” - Dr. Matthias Mehl While we may imagine we communicate in a clever complex manner, a lot of what we say that is actually useful is a lot smaller vocabulary than you would imagine.

What did they mean?

What did they mean? Let’s take the user story from previous post, and start with the granularity (i.e. the scenario steps). While specifying steps is an even better guide for developers to follow in their implementation, it’s important to remember anything we say can be misinterpreted! Feature: As a online shopper, I want to be able to add multiple items to my shopping cart, in order to progress through payment process quickly Scenario: Add single item to shopping cart Scenario: Add multiple items to shopping cart Scenario: Add multiple of same item to shopping cart Scenario: Remove items from shopping cart The first scenario is basic check that I am able to add a product to my shopping cart, so will use that as first example of how to make the scenario into an automated acceptance test.

What do you mean?

What do you mean? After working on several BDD (Behaviour Driven Development) projects, I was struck firstly by what a great development approach it is, if only from a test engineering viewpoint. While on the tech side, BDD is more clearly understood, clients may find the style of writing requirement commonly expected with this approach, more involved than they are used to. There is still value in defining user stories only, if you are happy with trusting team to take care of implementation, and ask relevant questions.