Elena Polubochko, CTO of Godel explains how test automation ensures speed of software development without dispensing quality.

Can a piece of software ever be truly defect-free?

Increasingly, manual testing is becoming more difficult to schedule and so there is a growing need for automated testing. The perception is that the more you test, the better your products are, and who doesn’t want that? But repeating tests manually takes time and effort, especially as the product grows – and so extensive manual testing on each release is increasingly becoming a luxury.

Cue test automation.

What often happens is that code gets written, and by the time there has been a decision made to auto-test, reams of code already exist that doesn’t have automated tests to accompany it. The organisation is instantly playing catch-up. This provides an enormous challenge to rectify given the shortage of skills in the market to introduce automated testing into the project or process. Budgets have to be justified, complexities addressed, a skilled team implemented to work with to deliver on the strategy and share ideas, and to build a reliable process to track quality and reveal issues at the earliest opportunity.

Once the team is implemented, the journey begins and the typical scenarios that an organisation faces include:

  1. Development teams, that don’t really understand how to embed testing into their processes so that it delivers value – which consequently gets postponed. It can be viewed as a side activity and therefore it doesn’t bring enough improvements or value.
  2. Legacy systems in the business that have lots of dependencies built into them, making it complex and difficult to unpick in order to start with automation.
  3. An endless backlog of things that could be automated to improve the process & delivery with no clear ownership.

Once the right team with the correct mindset, skillset, and vision is implemented, the task of creating automated tests at and above user interface level isn’t as complex as it sounds – but it’s easy to get it wrong.

With test automation, there are four simple steps to stick to:

Write test scenarios to automate and make sure the coverage is adequate. You need to start somewhere, so start small –automate the smoke test, the bare minimum you run each day.

Build a Test Automation Framework. What basis would you use to script your tests with?

Script the tests.

Build in the practice of designing new and running existing tests into your development process so that it helps the team to track quality.

 

Test Automation

Only steps two and three actually require technical knowledge and programming skills. Step one doesn’t require any knowledge of automation, it’s purely a quality assurance issue, a mindset required to be able to design the test scenarios to execute on a system and build the assurance that it operates correctly. Step four is along the same lines – it covers off explaining and showing a team how to use auto-testing and build a discipline of an always green pipeline. These are much more focussed on managerial issues or processes.

Roles and Responsibilities

But who is placed best to pick up the techie bits: SDET Engineer or a developer? There are pros and cons for each of the options. The ideal scenario for every employer would be to have a person who is happy to do whatever is needed to bring value to the business and keep the organisation happy, i.e. code today, design test scenarios tomorrow, automate the scenarios the day after. Also, having developers responsible for owning the test suite builds commitment, as there is continuity in I built it, hence I support it. That works fine when there is already the basis to build on.

However, when developers are tasked with the goal to build test automation into existing project/solution from scratch, they shy away from it. They don’t see much value or a technical challenge in automating diverse test scenarios, and they struggle to invent and document the feature testing scenarios they haven’t designed themselves. It’s simply not the same challenge as coming up with a new way of loading big amounts of data without diminishing performance or tweaking the platform to support an entirely new architectural pattern for example.

Following the approach where test automation is fully built by developers, an organisation can arrive at the situation where they struggle to have the passion and motivation for it– even though they accept it must be done.

Another way is to build the operation in the team in a manner where everyone does a job they love and has a passion for it.

SDET Engineers should design the Test Automation Framework or at least take the lead on it. It will be faster and more efficient as they have experience of automating cases and know what needs to be built in for scalability and reliability.

BAs or manual QAs should help with the design of the test scenarios and help define the test strategy.

Developers should automate key scenarios (the “happy path”) of the story to build ownership of the testing process and allow the seamless bare minimum of automation within the development process.

SDET, or manual QAs who enjoy writing auto-tests should help with extending the test suite and coverage by automating trickier cases.

The Scrum Master or tech lead should help the team to build the process and culture of tracking quality with auto-tests and coach the team.

Test Automation

In this case, everyone does the job they like and can do in the most efficient and reliable way, reaching some compromises along the way, and building joint responsibility within the team to deliver software fast and without sacrificing quality.