Monday, April 4, 2016

A Tester's Letter to The Developer

Hi Mr. Developer,
I hope you are doing fine.
You may know me very well. I am Mr. Tester.

I know you don't like me much and I can understand that. You create something and I normally point out defects in your creation. It is natural to not feel good about that.

I am not here to convince you to like me. I am not discussing either about Tester vs. Developer debate here. It has been discussed time and again and I know you get that point and you now treat me as a fellow and partner and not an enemy. And.... thank you for that. I treat you as my partner as well.

I am writing this letter for something else.

I know you are very knowledgeable and what I am about to tell you, you probably heard it many times as well. So I probably will not increase your knowledge.

There are 2 types of testing. 

White-box testing and Black-box testing. (I know you know that)

When I was a fresh graduate, I was told Black Box testing was done by Testers and White Box was done by ....ahem ahem ...Developers.

Let me rephrase testing types again for you.

There are two types of testing. 

Testing from the code side and Testing from the user side.

We, as testers take care of the user side of the testing. There are many stakeholders in the project and each one, to some extent, tests the application from the user side. No other stakeholder will test from the code side except for one which is you. The Developer. Everybody assumes (and rightly assumes) that unit testing will be done by you.

Not every developer ignores Testing from the Code Side.

I found out that this testing is routinely done by other developers in big organizations like Google, Microsoft and Facebook.  

You can object that these are big organizations and their developers can do it. But even developers who develop open source software, they are doing it.

I was reading a tutorial on Django Framework and that paragraph got my attention:

“You might have created a brilliant piece of software, but you will find that many other developers will simply refuse to look at it because it lacks tests; without tests, they won’t trust it.”

Jacob Kaplan-Moss, one of Django’s original developers, says “Code without tests is broken by design."

So then why you are not doing it?

Maybe you are unaware of the benefits. (I am making good assumptions about you)

So let me state some benefits of Unit Testing for you.

Tests will save you time.

Your first objection on not doing unit testing can be the lack of time. You have so many features to develop, tasks to do and bugs to fix. Adding another weight of writing unit tests may seem time-consuming. But, in reality, Tests will save you time.

You develop sophisticated applications. (Yeah) You might have dozens of complex interactions between components. A change in any of those components could have unexpected consequences (read bugs) on the application's behavior. If a problem occurs, you will spend hours manually trying to identify the cause. 

If you have written unit tests, these tests could execute in seconds and quickly point out which piece of code is the real culprit. (Before release)

Sometimes it may seem boring to tear yourself away from your productive and creative programming work to face the unglamorous and unexciting business of writing tests, particularly when you know your code is working properly. But once you accept its benefit, it will save you a whole lot of time in debugging. (And also, a lot of time of testers who have to test the defected build and then find the bug for you which could have been identified in unit tests.)

Tests will just not identify the problem, they will prevent them.

The presence of unit tests makes sure that any new change does not bring any regression to existing code. If any test case fails, you can know before release that where the actual problem lies. Bugs which are found earlier in the process are lot easier to fix. Also, it gives confidence that major functionalities are still working after new changes. When you develop a feature and write unit tests for it, you will feel a lot more confidence about this feature because you know that this feature will not break in the future due to other code changes.

Tests will make your code more maintainable.

When you begin to write tests, you will feel that much of your code is not testable at a unit level. This will force to break the existing functions into smaller functions which are more modular and generalized in nature. This automatically makes your code more maintainable. 

Tests help teams code together seamlessly.

The previous points are written from the point of view of a single developer maintaining an application. Complex applications will be maintained by teams. Tests guarantee that colleagues don’t inadvertently break your code (and that you don’t break theirs without knowing). 

By now you must have been convinced that you should write unit tests. But I will not stop there. I would like you to show some strategies to start doing unit testing right now. After all, I am your friend Right?


1. Sometimes it’s difficult to figure out where to get started with writing tests. If you have already written several thousand lines of code, choosing something to test might not be easy. In such a case, it’s fruitful to write your first test the next time you make a change, either when you add a new feature or fix a bug.

2. Some programmers follow a discipline called “test-driven development”; they actually write their tests before they write their code. But if you are not comfortable with that, you can code first and then write tests for it later.

3. It might seem that your tests will grow out of control. At this rate there will soon be more code in your tests than in your application.
It doesn’t matter.
Let them grow. For the most part, you can write a test once and then forget about it. It will continue performing its useful function as you continue to develop your program. At worst, as you continue developing, you might find that you have some tests that are now redundant. Even that’s not a problem; in testing redundancy is a good thing.

4. As long as your tests are sensibly arranged, they won’t become unmanageable. Good rules-of-thumb include having:
  • A separate TestClass for each module.
  • A separate test method for each set of conditions you want to test
  • Test method names that describe their function
5. Sometimes tests will need to be updated. In that case, many of our existing tests will fail - telling us exactly which tests need to be corrected to bring them up to date, so to that extent, tests help look after themselves.

Mr. Developer, I respect your work. The above is a friendly suggestion. This suggestion will not only benefit your organization but will also make you a better developer. After all, quality is not just a list of features, it is an attitude. 

I hope you will not take this letter as an offense on your development practice. Take it as a brotherly suggestion, given out in the love of quality.

Thanks for reading this letter.
Feel free to write me a reply (and telling me that you have started writing unit tests)

With Love and respect,
From your friend and partner, 
Mr. Tester. 

Credit: This letter would not be possible if I hadn't read the excellent tutorial on Django Website about unit testing. Full credit to their documentation team

If this letter can convince only 1 developer to start unit testing, I think the purpose will be fulfilled.


  1. Nice article !! Very impressive way to communicate the feelings with developers.

  2. A gud article About the importance\strategies of testing to Correspondent entities.

  3. Very well written (y). It may establish good understanding relationship between Testers and Developers.

  4. Sorry but I dont agree with pushing the blame to development! Dont blame the developers for a poor culture likely put in place by PMs who cant control the business. Of course devs are aware of TDD etc. You ask the question why dont they do it. Well ask yourself a question "Why do you accept the code if TDD and Unit testing hasnt been done?" Why dont you as the tester communicate to the PM and Business and be the defeneder/champion for the development team and sell "them" on TDD vs. acting like its the development teams issue alone.

    1. Thank You Jason for your comment. I respect your opinion. The purpose of this article is not to put "blame" on developers, it is a suggestion. You may or may not accept it, it is your choice. I have already said in this article that not all developers avoid unit testing. Some developers ignore it because of the time pressure. You can share this article with your PM or business people so that they can understand the unit testing is beneficial and time saver for whole organization.

    2. I agree with Jason on several of his points -- I would add, QA can only suggest unit testing, the ownership is on the development team. Once an application developer myself, I already knew 99% of what was introduced, its not new -- they(developers) know. If you want to be useful, introduce them to Uncle Bob Martin, if they don't already know who he is. And if they do -- and they still don't do unit testing -- its not getting done! It will require a push from the top to drive the importance of this type of testing.

    3. Jason, it is not the tester's job to make request to a manager that you do your job as a professional developer correctly. Your statement is the same as a truck driver saying that all of the cargo got crushed because he had to drive too fast because the manager gave him a schedule that was too short. The driver is accountable. The developer is accountable.
      - Development Manager

    4. It is even the wastage of time while communicating to PM and not accepting the build from a Tester.Developer should include the time cost for unit test when giving estimations before developing any feature.

  5. Good post Saad. Unit testing is essential.

    How about if there could be some way the automation team could write the unit tests for them (they wouldn't be called unit tests anymore then :) ). Off course there are a lot of obstacles there, firstly exposing code to QA, which usually folks don't agree with. Next agreeing on explaining the architecture / what's going on inside on a test module level. Nonetheless I hope might be a nice approach for automation and dev folks.

    1. In microsoft there are certain resources who help developers in writing unit tests. but these resources provide environment like creating mocks and stubs to ease the unit testing process. but they still don't write unit tests for developers. Writing unit tests is always a developer's responsibility. Managers need to provide a culture and demand that unit testing from them. Writing unit tests will always be developer's responsibility.

  6. Nice Article effort appreciated

  7. Loved the way, u have shared the viewpoint of Tester to Developers.

  8. I know it is the English standard, but it is tiresome to see a dialog that perpetuates the assumption that all developers are men. I would love this 10,000xs more if you wrote it without using Mr. and instead just referred to your fellow developer.

    1. Well I have written this letter to only 1 developer which I assume is male. I have never said or assumed that all developers are male.

  9. Helpful for freshers who are starting coding!!Learned a lot from unit testing.

  10. A good article that highlights the relationship between Developers and Testers. I agree with other comments about Business culture and Project Management. Sometimes the business focus will be on delivery and dates met, rather than quality.

  11. Unit Testing is the gateway to Quality of an application.
    Article written brilliantly. Keep it up.

  12. Loved it. Thanks for sharing Saad! :)

  13. Nice article Saad


Testing Challenge

Can you find more than 20 defects in the below image? Write your defects in the comments section.