Using filter to find element within an element in Protractor

One of the challenges of test automation is minimising dependencies on test data. For most tests, you don’t care which specific data you use, it’s usually based on criteria. For example, take this list of users.

OWASP Dependency-Check Plugin on Jenkins CI

The OWASP Dependency-Check Plugin will locate npm, maven, php, jar packages and analysze them for known security vulnerabilities (full support list is on the website). To use, you need to create a build step on the app build job you have, after all dependencies installed, then publish the report in a post-build step.

OWASP ZAP on Jenkins CI

OWASP ZAP is a very established and useful test tool, and there is a Jenkins plugin ZAProxy to enable you to easily include it in CI.  You can add it as a step to an exiting job, and create a job specifically to run ZAP.  Instead of using a lot of screenshots, I have done it as a step-by-step text-only guide.

What did they mean?

  • October 2, 2016
  • Agile, BDD, ...


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

What do you mean?

  • October 2, 2016
  • Agile, BDD, ...

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. But perhaps you want to be more involved … So here is a guide aimed largely at Product Owners, on how to write requirements for not only BDD projects, but as alternative style to more traditional Agile user stories.