Automation & Development – Why It’s Worth Investing in This Relationship

Good relationships will be stable whenever something goes wrong. But, if you don’t invest in your relationships, they won’t last long. Let’s take, for example, a little crisis that could happen – a bug is found in the field! … by a customer!
“How did we miss it?” will be the question asked all through the hallways. This is obviously a serious problem, but who do you think is usually held responsible for such a fault?

If you blame the other team (Development / Automation), it looks like you’re in a bad relationship.

So, instead of looking at who’s to blame, let’s talk about:

• How easy it will be for you to tell what the existing relevant regression tests are for this feature
• The best way for Development and Testing/Automation teams to work together and create better preventative measures

Both sides should try hard to familiarise ourselves with the current relevant tests, and get the best out of the Dev-Automation relationship – and of any other relationship.

Where should we begin?

First, Automation and Developers, as with any other couple, should live together under the same roof. Working together in the same team, such as R&D, for example, will lead to them sharing the same goals and interests.

Secondly, we should understand what the responsibilities of each team are regarding feature testing.

Developer side:

• Their responsibilities don’t end when a feature is released.
• They’re responsible for any “missed bugs” in the production environment.
• They should be familiar with any automated test that verifies his/her features.

Automation side:

• Their responsibility starts long before a feature is released (we will get to this later)
• They can create end-to-end tests. This is one of their biggest advantages – due to their importance, these kinds of tests are always expected to be implemented.

Next, let’s focus on the collaboration between Development and Automation with regard to creating the best possible preventative measures. This will require a process that starts at the feature-design stage.

A new feature is planned? Great!

Whenever a new design is produced, a member of the Automation team should be invited to review it. Having reviewed the design, the Automation engineer will:

• Know what he/she needs in order to build an automation test for this new feature, and will be able to start working on it immediately.
• Start planning the test flows

Planned tests review

At this point, Automation and Development should sit together and go over the planned flows.

Development should:

• Suggest the flows they think should be added
• Agree on priorities
• In some cases (and it should always be more) – the Development Team takes responsibility for the Component Tests, in order to have more coverage in a shorter time.

Both teams should leave the meeting with:

• An understanding of how much of the feature can be covered
• An estimated ETA for those tests with the highest priority
• An estimated ETA for all other planned tests
• Each team knows what will, and what won’t be covered.

Collaboration process between the teams

Important to remember

• Don’t expect features to be 100% automatically covered – this never happens.
• Component tests shouldn’t necessarily be the sole responsibility of the Testing/Automation team. Development teams can write the component tests for their features.

If you ask managers from our Development team about their experience of working together with Automation, you’ll regularly hear the following main points:

• “There are no surprises” – we know exactly what’s covered and what’s not by the automation tests.
• We help to put the focus on the “risky” areas, and utilize our limited resources to address these

Here at Imperva, we’ve productized our automation environment so Dev teams have another option to build, test, and run their components.

I learned the hard way, and am here to tell the story, that it’s all about transparency. This is the magic word that should always be guiding us – both through Automation with Development and through Development with Automation. Either way, it’s a win-win relationship.