Simple Concurrent Automated Testing Pattern

By Alex Yakyma

Many teams struggle to catch up their automated testing effort with fast moving development initiative. They may be able to deliver independent piece of value within a sprint (e.g.: “define – build – manually test” it) but it is only ok as long as it doesn’t touch the surface of automation. When you start automating your tests the delay becomes tremendous. Most of the teams either see failures at this point of lifecycle or just don’t know that soon they will fail epically, that’s the hard truth.

So what to do? How to succeed with automation? We will consider very simple pattern for test automation that will allow to see the bottlenecks in your test automation practice and apply it successfully.

The idea is very simple: if you can’t write automated tests for a user story before the implementation (that is another whole discussion) then do it concurrently with coding in a following way:

- Define a little vertical slice of a user story
- Implement and manually test it
- Start automating tests
- Define another slice
- Repeat…



In other words, instead of waiting until whole story is developed – take a slice and start automating it early.

It is important that team knows how to slice up stories. Otherwise they will fail in the very beginning of the process. Slicing up stories is essential. On one hand different approaches to splitting user stories will be very helpful (see examples of splitting user stories). On the other hand there is a number of additional nuances to consider which are specifically important with respect to automation. Here’s a couple of good advices:

1) If you’re slicing up user stories and try automating early slice by slice and still have big delays in the end – reconsider tooling or whole automation strategy. There can be one or few really deep problems with how you automate anything at all. For example, automating acceptance tests only at UI level can be very time consuming because UI testing is very fragile and possibly you have to either proceed with UI testing but using some smarter high-level tool (like Robot Framework) coupled with your current UI testing tool that would provide an ability of reuse of low-level test-code. Or you have to abandon UI testing at all or only use it for some quite limited cases only and concentrate upon testing business logic using FIT or JBehave or Cucumber or even JUnit (not for unit testing though!). There can be much more value if we can “remove” UI from the equation and rapidly automate testing of the “rest” of the system than trying to do 100% UI testing which may not be practically feasible.

2) In Slice 1 implement thin piece of functionality and define interfaces for a bit more. In other words, define somewhat more interfaces for future slices but only add “meat” for one. Those interfaces will be actual classes and methods but everything or almost everything there will be hardcoded. That way you will let automated tester start writing tests for much more functionality than you actually deliver within first slice. Those other tests will fail and serve you as further guidance for development. This way overall delay of automation will be even further minimized.

3) Don’t aim for high coverage in the beginning. Don’t get frustrated if you can’t cover everything. Take a slice of functionality, automate few (or maybe even just one) of the key tests and move on to another slice. Keep process lightweight and dynamic. Remember that collaboration over tests (between PO, developers and test engineers) is much more important than the test suite itself because it will allow you clarify requirements, save extra development effort and establish strong DBT teams.

4) If you already have a lot of non-covered code, don’t make it a separate life project to automate it but rather move from context to context. Work on your current story and automate “everything around it”. Take another story and also automate the test for functionality it “touches” and so on. As a team you need to have context of value, not just tests.

This model apparently will only work if and only if automated test engineer is a part of agile team, not part of separate “automation team” or whatever you call the people whose life mission is to constantly fail catching up with more and more functionality.

Start practicing now… starting lightweight is quite easy!