What Skills Do Developers Need to Ensure Their Code Performs Well With Automated Testing?

DZone 's Guide to

What Skills Do Developers Need to Ensure Their Code Performs Well With Automated Testing?

Developers need the ability to write tests, understand automation, good coding skills, and broad vision to write code that will work with automated testing.

· DevOps Zone ·
Free Resource

To gather insights on the state of automated testing today, we spoke with twenty executives who are familiar with automated testing and asked, "What skills do developers need to ensure their code and applications perform well with automated testing?"

Four keys came through in the discussion: 1) know how to write tests; 2) understand automation; 3) good coding skills; and, 4) vision.

Know How to Write Tests

  • Don’t write bad tests. Write tests in the smallest and most elegant way possible. Don’t write a Spring-based test if you don’t have to. Start with the smallest, most compact, independent test you can. Get yourself to a green build. Don’t get used to heavy broken builds. They’re a huge risk.
  • Build the unit tests in.
  • Create test code and test cases defining what data to test. Do not write application code without test code, test cases, and the data needed for testing. Need to test closer to development. Less costly to fix errors earlier in the SDLC.
  • Separate QA teams with test plans and methodologies are changing. Developers writing code are the best people to direct the testing on the code. Make your code readable. Think about anyone looking at the code to be able to understand it from a logic perspective.

Understand Automation

  • Be aware of how quality engineers write automation. As you make code changes think about how the automation will need to change. This is an added burden on the developer of understanding the automation that needs to be done.
  • Know environments and consistencies and what you are excluding in tests. Processes and environments for tests take time and typically get underestimated. Put effort into getting automation right. Don’t repeat yourself. Attack changes. Cut out repetitive work – though it may not seem like much, it requires a lot of your time, over time.
  • You can do a lot to speed up the process. When the architecture is beginning to be discussed have a qualified test engineer in the discussion to discuss what it takes to provide automated testing. What kind of hook can you provide to help automated testing? It’s not a hard conversation to have. You need a hook wherever possible to facilitate automated testing.
  • Mostly soft skills. By that, I mean the ability to think objectively about their own code. Along with that is the openness to trust the automation by running it regularly during implementation.

Good Coding Skills

  • Write code so the next person will be able to see what you’ve done and make changes as necessary. Make code legible with proper commenting. Leave clues for yourself in the event you must go back and make changes. Think about testing as you are writing.
  • Don’t just think about the performance of the code and the network. Think about the design of the app. Think through the use cases. Code efficiently so you don’t waste someone’s battery. Test and manage.
  • Developers should follow coding standards: Modular Programming: Software function should be separated according to their functionality. Unit Testing: After making a new build the developer should perform testing to ensure that the newly introduced functionality is meeting the requirements. Exception Handling: Developers need to properly implement all error conditions properly, so if any error occurred, QA would be able to identify the issue quickly. Selenium & Appium: As a shortcut, it’s worth learning Selenium and Appium to perform tests cross-browser and cross-platform. This enables you to speed through testing without having to learn a test scripting language


  • 1) Basic development skills. 2) How does the organization adapt to be more successful testing in an automated way? Have an organizational vision that everyone is responsible for testing and give developers the automation equipment and tech tools to improve code quality and make fixes more quickly. Developers will develop the technical skill set of automation, best practices, and a tester's mindset coming at the solution from a user persona perspective.
  • We have a Unit Test environment and Building mock environments for our Unit Test environment can take time, and occasionally require new skills from the product engineers. Some of the obvious skills include Perl and Python development – most of our Developers are skilled in traditional product level code like C and C++, however, our automation environments are primarily based on Perl and Python. Enabling the developers to think in these terms is important. It is not only a technical skill but also a mindset. The product quality does not stop once the engineers are done coding.


  • Developers need the “DevOps” attitude – that testing is an extension of the development process and not a separate phase conducted by a separate team.  There are lots of features that can be added to the software to make it easier to capture diagnostics, or easier for a non-developer to isolate issues.
  • Don’t fear failure. It’s OK not to know something. Don’t cut corners to get things out fast. Understand how to fail and to iterate to get better.
  • Strive for CI/CD: Additionally, developers should strive towards CI/CD (continuous integration and deployment). To do this they should leverage services like Jenkins to connect and automate all tests every time code is checked into GitHub before being passed on to production. Understanding the bigger picture, getting company buy-in, and connecting systems to each other are all useful skill sets that should be developed over time.
  • The future of test automation is not going to focus just on the UI, but an emphasis on API testing. This can only be achieved when the developers provide a comprehensive set of APIs. We recommend to our customers that they put a development contract in place that has an integral part relating to provisioning APIs that are sufficient for testing the full business logic. When it comes to the UIs, there are rules that, when followed, make UI testing easier. In part, those rules point to the identification of objects, but this will be diminishing in the future because we will see optical recognition become more "present," which does not require those technical prerequisites anymore.
  • Teams need to collaborate, especially when the tests and code are being written by different parties. Expand TDD thinking to include UI automated tests, as well as unit tests – laying out how to test a feature at multiple levels from Unit to UI.
  • A change in QA mindset. As Agile practices mature, organizational ownership around designing & developing automated testing frameworks should fall squarely with QA to drive agile traits such as TDD, code coverage, and the continuous development model.

What do you think developers need to know about automated testing?

Here’s who we talked to:

  • Murali Palanisamy, EVP and Chief Product Officer, AppViewX
  • Yann Guernion, Director of Product Marketing, Automic
  • Eric Montagne, Technology PM, Barclaycard
  • Greg Luciano, Director of Services and Amit Pal, QA Manager, Built.io
  • Donovan Greeff, Head of QA, Currencycloud
  • Shahin Pirooz, CTO, DataEndure
  • Luke Gordon, Senior Solutions Engineer and Daniel Slatton, QA Manager, Dialexa
  • Anders Wallgren, CTO, ElectricCloud
  • Charles Kendrick, CTO, Isomorphic
  • Bryan Walsh, Principal Engineer, NetApp
  • Derek Choy, V.P. of Engineering, Rainforest QA
  • Subu Baskaran, Senior Product Manager, Sencha
  • Ryan Lloyd, V.P. Products, Testing and Development and Greg Lord, Director of Product Marketing, SmartBear
  • Christopher Dean, CEO, Swrve
  • Wolfgang Platz, Founder and Chief Product Officer, Tricentis
  • Pete Chestna, Director of Developer Engagement, Veracode
  • Harry Smith, Technology Evangelist, Zerto
automated testing ,devops ,unit testing

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}