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.
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? “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? 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? 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.