Software: Developer or Tester?


As a software developer, you are expected to write lines and lines of code, spending long hours writing big chunks of code and then delivering the chunks to be tested. This is a big job but now, just part of your job. In the last decade things changed dramatically for us developers. We have lots of tasks that didn't necessarily exist ten years ago. For example, we now write code and then write programs that test the items we’re developing. This is what I’d like to briefly discuss here, displaying my personal experience on this issue.

For every line of code that ends up in the final product, I write 3-4 lines of code that test the functionality. I know this seems like a lot. Working in a product like Microsoft CRM poses a huge advantage for me to write test programs because CRM has such a rich extensibility store. For instance, if I change or add a feature in Workflow, I can develop a test that runs the following sequence:

1. Create a workflow rule, such as “Account on create”.
2. Add workflow steps, for instance, send email with a unique title (use a GUID in the title, for instance).
3. Activate workflow rule.
4. Then create and account.
5. See if the email was created, by checking if there’s an email with the unique title given at step.

The usual questions that we hear about “developers writing test code” are:

   a. Why should I do this if I can test it manually in 1/10th of the time?

Maybe testing manually once takes 1/10th of the time.  But if we test repeatedly and across multiple platforms and scenarios having a programmatic test ends up allowing us to test both faster more completely. Also, other people can run the test programs and the time savings will be multiplied by the number of developers.

   b. If I do the test program, what will testers do then?

Testers will test everything else that is not covered in our test programs. Be it performance, security, extensive code coverage, or simply check if the implementation actually followed the spec. It is a basic notion of quality: the person that does something cannot be the same person that validates it. And Microsoft values adhoc testing to find those pesky situation that a test code normally will not find.

   c. But I don’t have time to do this!

I can say for sure that when we do not test our code thoroughly before delivering to test, everything can and will be used against you. The time we save by not testing will bite you later with a vengeance when testers start to bang the app or, even worse, when found by the customer!

So whatever you code, consider the benefits of writing a testing procedure too. And make sure it works!

Lucidio Mayer Kuhn Filho


Comments (3)

  1. MSDN Archive says:

    I love this 🙂 I can confirm that:

    "I can say for sure that when we do not test our code thoroughly before delivering to test, everything can and will be used against you. The time we save by not testing will bite you later with a vengeance when testers start to bang the app or, even worse, when found by the customer! "

  2. Peter says:

    "Test driven development" is a good technique which I used when a was a developer.

    I am now a tester working at a medium size company where the developers do no form of testing before it goes under the hammer of the QA.

    Developers should have certain confidence in their code before they sign off that they have completed the work. For example it not just one code fix/enhancement that get implemented in a software release.  If the fix causes a fault at QA it costs a lot more $$$ to repair.

    Developers here don’t even compile there code before they commit, and hence no confidence.

    Being a developer is not just about writing the code but providing the functionality with a level of quality is what makes a proper developer.

    They say a developer has a positive view where as a tester has a negative.  I think this comes to light as the company employs cowboy developers and hence at QA negative feelings are felt – as the most basic faults are found.

Skip to main content