Over a million developers have joined DZone.

What Devs Need to Know About Automated Testing

DZone 's Guide to

What Devs Need to Know About Automated Testing

Automated testing requires three primary skills: test scripting; understanding the use case; and, shifting left.

· DevOps Zone ·
Free Resource

To gather insights for the current and future state of automated testing, we asked 31 executives from 27 companies, "What skills do developers need to ensure their code and applications perform well with automated testing?" Here's what they told us:

Test Scripting Skills

  • Basics have to be there with the architecture of the app itself. Definitions of architecture – decisions that matter and can’t change over time. Hone test scripting skills. Write small simple tests. Look for good books, literature, blogs for reference. 
  • Recognize the different types of tests I will run at different points in the process. May write automation for the test team for user acceptance. Need to be aware of how the process works. Still needs to be an appreciation for the testers in the organization. Offer value and coaching. Product managers for quality – respect that. Write failure cases. Quality folks protect you from the Netflix chaos monkeys – randomly shut down servers, degrade performance to see how resilient the code is to handle. 
  • Do a model level of coding using well-defined interface programmatically or UI level visual testing. Learn to write a model type of code from mentors and previous products. Interaction between developer and QA to match coding skills with how testing will be done. Use the same APIs for our code in our software when UI is integrating with the backend. 
  • 1) Ability to write unit tests. 2) Familiarity with automation systems. 3) Analytical skills so they can read the reports and understand the impact. 
  • 1) As moving to DevOps not doing a lot of testing. Helpful if developers could find the time to write own unit tests and regression tests to understand what it’s like on the other side and where responsibility is between QA, testers, and developers. Communicate across all groups. 
  • One thing that has changed over the past five years is the idea that continuous delivery has pushed much more of the onus onto back onto individual developers. They now need to understand what their code needs to accomplish and write tests that go along with that code. Many long-time developers were either not involved or had delegated the responsibility of test development onto QA or QE teams. These developers moving to this modern application development style need to reacquire those skills of how to write their own tests and how to make sure their tests are actually validating the use cases they are trying to build for. Developers who started within the past five years are more likely to have acquired these skills. And it's also much more commonplace depending on the code bases you're using. If you started developing and writing in Ruby or Node, this is part of how you've always developed software. But if you started your career writing in C or Java, this might be something where you're thinking, "Ugh, this is another thing that I need to do." The nice part about the way continuous integration testing is done now is that you can look at these tests as being highly leverageable–you write them once and you can use them again and again. That's the whole purpose of automated testing. Automated testing is phenomenal for tracking human error. It's extraordinarily powerful to really validate your code is functioning the way that you want it to.

Understand the Use Case/Application

  • Golang has built-in benchmark tests. See what change in code will do to performance. Understand performance at a conceptual level. Being able to write a benchmark test to determine performance is important. Developers need a level of discipline and patience to test well. It’s an important investment. Have a mindset for different layers of testing. Think about use cases first what is the purpose of the code. I can write a test that measures that behavior – test-driven-development. Tools are making it easier to write tests, so people are writing more tests and doing more testing. Have a mindset for writing a test first. 
  • Don’t change how you write code to be testable. Make the best product you can. Testers need to make products that adapt. Stop asking why a customer would do that. Understand users, domains, who they are, what problem trying to address.
  • It's not a development skillset it’s the view of an application. Crack into a user story and the code you are managing you to myopic. When it comes to testing the impact of changing code, the developer needs a wider-angle view of what they’re doing and how does that impact APIs and services. Have the customer and user perspective.

Shift Left

  • Get rid of simple, recurring problems. Move testing left. Get rid of unplanned work. Find problems to reliably eliminate false positives. 
  • How do you embrace some of the key disciplines around testing? Don’t wait for QA team. Leverage testing methodology from the planning phase. Build richer code earlier in the SDLC.


  •  How to architect the system to be tested well from the beginning. Take accountability for the quality and passing the tests. It's not optional, it's part of their job. Up-level those skills. Make system testable from the very beginning, know what tools you’ll use, how you will measure.
  • Stay curious and up to date. Frameworks, tooling, abstraction frameworks are things developers need to think about. Actually, take some time out to read articles on DZone and other sources. Learn from the people that come before you. Barriers to entry are going down every day. Barriers to be a great developer are very high.
  • Adopt the tendency to look at quality as a tax that has to be paid. Quality is a core piece of professionalism. Drive quality into how you code.
  • Learn the best practices for automated testing. Be involved in the process. Developers may be completely responsible for test creation. The most popular framework is test-driven-development. Write test code first then start writing the app. Behavioral driven development is letting business people write the tests. Another popular model if QA is still in the organization but they’re acting more like consultants and maintaining the test infrastructure.
  • Developers, particularly the build engineer, must work closely with security teams to understand how to on-board an application for security testing. Security teams typically manage this process, but they are not well suited for this task – especially when scanning source code. Developers must be able to communicate, either to the security team or the automated service UI, those code artifacts that comprise their software and where those code artifacts live.
  • 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 non-developers to isolate issues.
  • From a UI testing perspective, developers should understand that using certain automation IDs can be very helpful to not only generate automated tests quicker but also to keep these tests more stable against design changes on the front end of a user interface. In addition, testers benefit from certain APIs they can use to get the system into the desired state much more quickly, such as restoring a database file to a point in time or adding products to a cart in an online store.
  • Keep with the best practices with platforms and environments – each has its own source or found on Stack Overflow.
  • Modular application design. Microservices. The fewer the dependencies the better. Automation testing becomes easier with fewer dependencies. Awareness and mindset that automation is important and not just QA’s responsibility.
  • On the technical side when developing code, have additional constraints in mind. Think about it up front. Same with security. Same for testability. Design code in the right way to be tested automatically. Be conscious about the design choices you are making. It’s a state of mind. Some languages and environments lend themselves to being automated – the more virtualized the better it is. Java is easier to write unit tests in than C++. It allows you to test in a much more efficient way. Tools that you use to automate become really important. On the Java side JUnit, Maketo, Go and Ruby have the same set of tools. Learn up front and see how it affects how you view the code.
  • Think about the responsibility to develop a specific routine needed to add extensions to collaborate, keep in source control, make it testable. More tools are being created helping developers do that and help them develop. AI was not accessible in the past. Now it’s everyone’s job.
  • Understand the API approach to systems design. Basic coding languages. Python. Have a mindset of not committing to vendors. More sophisticated understanding that we’ll have many different vendors need know how to code and work with APIs.
  • Software developers engineering and programming need to be able to translate from whiteboard to production. Ability to use new frameworks. Don’t reinvent when you can use pre-existing tools for optimization and deep learning. If you have one and not the other, you will get mixed results.
  • Know how automated tests are going to be written and put hooks into code to make automated testing effective.


automated testing ,devops ,software testing ,test automation

Opinions expressed by DZone contributors are their own.

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

{{ parent.tldr }}

{{ parent.urlSource.name }}