How Functionize Stimulates Developer Driven Testing

Developer Driven Testing (DDT) is a method that gives control of the testing process to developers. Check out the article for more!

Developer Driven Testing (DDT) is a method that gives control of the testing process to developers. Check out the article for more!

October 15, 2018
Tamas Cser

Elevate Your Testing Career to a New Level with a Free, Self-Paced Functionize Intelligent Certification

Learn more
Developer Driven Testing (DDT) is a method that gives control of the testing process to developers. Check out the article for more!

Testing is a critical part of the process for any development project. However, there are many different ways you can approach testing. Knowing what’s best for your team comes down to understanding the many different testing options, how they work, and what they’re best suited for. Developer Driven Testing is one of those options.

Developer Driven Testing can be a great choice in the right scenarios. For companies who want to stay lean and speed up the testing process, Developer Driven Testing (DDT) is ideal. It allows development teams to handle their own QA and become more efficient.  

In this blog, we will explore what Developer Driven Testing is. We'll also cover how it can be used, and when this approach is the right choice for companies and their developers.

What is developer driven testing?

Simply put, Developer Driven Testing is a method that gives control of the testing process to developers. DDT enables developers to test their work. In turn, this gives developers more responsibility for the code they’ve written and how it’s expected to function.

What are the benefits of developer-driven testing?

One benefit that comes with this type of testing is that usually, fewer tests need to be done and passing results happen more quickly. This is because the developer that wrote the code, knows it best. When DDT is used, developers base their tests on the code they’re working on. During this process, they often find bugs on their own before they become an issue.

Generally, testing would bounce back and forth between the developer(s) and the tester(s). This slows down the entire process of testing code. In contrast, DDT is done by the developer who wrote the code when they believe that it’s ready to be tested. When developer-driven testing is used, the developer responsible for their code working the way it’s supposed to. This leads to more accountability for the developers and the end result is a better product. 

This type of testing also works past the common hurdle of poor communication between development teams and QA teams. Why? In many cases, developers may end up making necessary changes before they get feedback from the QA team. This can lead to multiple versions of the code being evaluated by the QA team. With DDT, testing only happens when the developers have finalized the code they’ve written. Another benefit is that when Developer Driven Testing is being used, QA becomes a part of the developers’ workflow. This can make the development cycle more effective.  

Developer Driven Testing also forces developers to be very disciplined in the way that they code. They aren’t relying on a dedicated QA team to do their testing for them. This means that they need to become hyper-aware of how their code will work and what the goals are.  

Bugs are also less of a concern because developers aren’t testing until they feel certain that their code is ready and will do what they want it to do. This gives developers the opportunity to work confidently with their code and ultimately, write better code more quickly.

What developer-driven testing isn't

Developer Driven Testing can sometimes get confused with Test Driven Development (TDD). However, these two methods are very different. When you choose TDD, the code being written by developers is based on the tests they write first. Developer Driven Testing is the exact opposite.

In DDT, the code informs what testing will look like. This is an important distinction because DDT is not about writing code to pass a test. The process of DDT is designed to allow developers to write the best, bug-free code they can, and then write tests that prove the quality of their work. These types of tests are only written when the developer is finished. 

How does this change the process for the company overall? It can speed up the development process quite a bit. This is because Developer Driven Testing doesn’t include a dedicated QA team and developer team feedback loop. That could be seen as a pro or a con depending on your team. 

In non-developer driven testing situations, development teams "submit" their completed code to a QA team. It then becomes that team’s job to look for bugs or scenarios where requirements aren’t being met. The result of this traditional process is a working feedback loop that you don’t get with DDT.

What else do you need to consider to implement developer-driven testing?

Developer driven testing does have its drawbacks. However, you can avoid these pitfalls when you know what they are. First, you need to take into account that the developers you’re working with aren’t likely to have much experience with testing themselves. This is especially true if they’ve worked with QA teams in the past.

For this reason, if you want to use this testing method, there needs to be clear requirements in place. (More on that in the next section). You should also be cautious about using Developer Driven Testing in environments with real, active users. This type of testing is best used in early development stages, or in scenarios where internal feedback is required.

Planning for developer-driven testing

Planning for this type of testing isn’t as complicated as it may seem. However, there are a few important aspects that go into it. One is a consideration for the developers. The other involves the team overseeing the project as a whole. Let’s take a look at some of the necessary steps:

To plan for developer-driven testing, developers must have a good understanding of requirements. They can’t test their code if they aren’t 100% clear on what the requirements are. Once they are aware of their requirements, they can write tests for what they’ve developed.  

In this case, since developers aren’t sending their work off the QA team, they take on a new role as they become their own QA tester. There’s a certain mindset that has to come along with that as well. It’s critical that developers using the Developer Driven Testing method are focused on the quality of their work. 

Your team should also set testing standards so that developers have guidelines and are able to write tests that are in line with your goals. Finally, you should come to a conclusion about the things that should be tested as each milestone is completed.  

This might sound complex, but it doesn’t have to be. Once the details are sorted out, developers will be on the right path. Then, they can choose to test manually or with an automated testing suite.

Automating developer-driven testing

Developer Driven Testing can be even more efficient with the use of testing automation. There are many different testing solutions that you can choose from, but the process and features available with Functionize make it a stand out choice.

To automate test creation with Functionize, developers can upload a test plan through the UI or via Command Line Interface. Functionize creates a repeatable, functional test case, that is ready for end-to-end integration testing. If tests fail, Functionize will identify the root cause of the failure. Then, a recommendation system will allow developers to update test cases in one click.  

This adds even more speed to the process of Developer Driven Testing. Using this method, developers no longer need to dig through scripts, find the bugs, and re-script. Instead, they can simply rely on Functionize's Adaptive Event Analysis engine to find issues and resolve them. This reduces the amount of time (and headaches) associated with making these changes manually. They’re able to resolve problems and move on without getting bogged down by any errors that might come up.  

While bugs are still found with this testing method, it happens much less frequently. Overall, it's a win-win for developers. This is because developers don’t test until they feel they’ve met all the requirements and that they’ll see passing results. However, if something does happen to slip through the cracks, it won’t take them hours or days to locate the problem. Instead, these issues can be fixed in mere seconds with 1 click updates.

Conclusion

Developer Driven Testing is a good choice when you’re working with developers who have committed the quality of their own work. It also allows you and your team to complete the QA process more quickly.

The truth is, there will always be debates over what the best testing method is. However, there are many positive aspects to doing this type of testing. All things considered, this is a great approach if you're focused on efficiency. This is especially true when you’re using the right tool to automate testing.  

Automating developer-driven testing with Functionize's AI platform empowers developers in the work that they do. It also frees up more time to concentrate on other aspects of a project. Once you complete the process of planning for DDT and invest in the right testing suite, the rest is simple.  

This blog explored what Developer Driven Testing is and the reasons why you should consider testing with the DDT method. We hope that it inspires you to explore the best testing options for your projects. We know that using the right testing method can have a big impact on your development cycle.