Testing strategies – conclusion

Yesterday I wrote about the pros and cons for having separate people/teams do development and testing. I promised to tell you about my opinion on this matter.

Before I do that, I want to admit something. I did not write one of the biggest cons that I have on this idea. But I will share it now.

If you do not write your own tests, you are missing not only a safety net, but a crucial feedback loop. Tests can help you understand the problem you are trying to solve. Tests show you whether you forgot something in your initial design. (You most likely did. Happens to me all the time.)

If someone else is writing these tests, after you've written your code it takes a very long time until you get feedback on your initial idea. I would not want to miss that feedback element in my development work.

Last week, as I wrote the code for the testing workshop that I will give at my client, it happened again. I was clear in my head about what I wanted to write, how I would structure it. This repository deals with mocks and stubs and how/why/when to use them. Still, as I wrote the tests and then the code, a better design emerged and I felt joy in the process.

That's it. This is my opinion: Developers should write tests for the code they write. Ideally, they do their development test-driven. And in a big project, with enough money and a proper timeline, I would advocate for external testers who augment the developer-tests with a test plan and test cases of their own. This way you reach a higher quality, pair the best ideas of both worlds and live happily ever after.

This ideal project almost never exists. I certainly have never seen it. But don't stop believing.

See you next week.

PS: For all the weekly subscribers, I did a series on testing strategies this week. You can find the articles on my website https://www.holgerfrohloff.de. Next week I will provide them as a compilation for your reading pleasure.

Similar Posts:

Leave a Reply