7 Ways To Be Good Developer from Tester Point of View

Try to identify points that are important for the developer from tester but also the quality assurance point of view. There are hundreds of articles about becoming a good developer, I have hope that these few following thoughts will help programmers to better collaborate with testers.

1. Do not Test the Tester !
Even if you have very bad relations with the tester or the entire quality department, never code artificial bugs to demonstrate the poor quality of the tester! Fraud sooner or later comes to light. Testers also have a great ways to show your low skills, a fight between the persons/departments always ends with the customer’s critical exceptions.

2. Do Your own acceptance tests
In a time of the unit testing code cover it seems to be more important usability or GUI testing, especially if we look at the developers work. Unfortunately, the GUI unit testing, which is closely linked with the usability is not very effective. Carry out each time a short acceptance test, though the developer often subconsciously avoids reefs.

3. Do not repeat bugs
One bad thing that you may experience being a tester, is developer which repeats the same errors. Comes up to the fact that the tester is able to predict how the error occurs in a functional change. This illustrates the carelessness of the programmer and a his lack of progress in learning this difficult skill. Man learns from mistakes, therefore the developer should.

4. They do not want to hurt you
Developers usually think that the main tester task is to demonstrate that the code writer is feeble by detecting as many bugs as it is possible. Developers often are afraid to give the code for testing but should rather seek the assistance in order to ensure doing good job. If the tester comes and says “You are poor because I detected 29 errors in Your code” - ask “And how many left?” Someone said, “The more errors we find the more is still there” - do not forget about it.

5. Do not move the whole responsibility to tester
Another negative thing that often have place is the situation when a developer does not feel the responsibility for the error found at the client. Shift it to quality assurance, of course, which is responsible but we must remember that product is created with the collaboration and accountability of the entire company. Try to make the best possible code, omit thinking like “I will write this piece of code, testers will find all mistakes, if not that will be they fault” - very bad approach.

6. Write comments and human readable code
In times of auto comments available in Visual Studio but also in other development tools, developers forget to include something from inside. Something which usually proves to be very helpful in a crisis, and necessary for code review. In parallel, write code that explains a lot without reading the comments, function and variable names are no longer restrictions on the number of characters!

7. Provide descriptive error alerts.
I think that one of the most arduous and time-consuming activities performed by the tester is looking for a path access to the bug. Submit error to bugtracker and get the response “Can not reproduce”, it usually ends with a call to developer for demo or send him screencast. Through the provision of good error messages tester can provides ready information with a bug. It is great if you have log engine, because the client log file in an bug attachment is very helpful.

Summary
These are just a few loose observations resulting from my experience as a developer and tester. If you have other proposals please comment.