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