Can Developers Test?

re: Can Developers Test?

Kevin Daly — Wed, 13 Dec 2006 21:02:38 GMT

Developers have to do whatever testing they can...in my opinion that is *never* going to be enough however, because as developers we suffer from the singular disadvantage of knowing what we think the code is supposed to do and how it is supposed to work. This almost inevitably makes us blind to things that a normal user might try first off as a matter of course but which we would never think of. "But who would do that?" looms large over everything. It's very hard to get over the psychological barrier of prior knowledge.

Interesting Finds: December 13, 2006

Jason Haley — Thu, 14 Dec 2006 07:52:52 GMT

re: Can Developers Test?

Alfred Thompson — Thu, 14 Dec 2006 15:04:27 GMT

I don't understand needing testers for anything other than cross-feature integration-type bugs. I think that having too many testers (say more than one per 40-50 develoeprs) is going to cause more problems than solve. It makes developers lazy, careless and distroys any chance for getting reliable code in a reasonable time. You can't test quality in. It has to be designed in and that means starting with good program design, developers who do it right the first time, and verify their own work.

Admittidly it has been 25 years since I was an OS developer and operating systems have gotten a little more complicated but still I don't see anything fundimental that makes writing good quality code harder now than it was back then.

re: Can Developers Test?

Lothar — Thu, 14 Dec 2006 15:32:34 GMT

I'm developing server-based software primarily and I'm using JUnit for development all the time. In retrospect my way of programming has changed the last six years (when I started using JUnit) because as a developer who is writing the test-code himself the question I'm now not asking myself anymore is "what the code is supposed to do and how it is supposed to work" as stated by Kevin. Now I'm asking myself "what the code is supposed to do, how is it sopposed to work and how can I find out that this state is reached without testing it for myself all the time".

To be able to test functionality in an automated way, the way of programming a functionality changes. You break up things into smaller pieces (methods, classes, ...) automatically to reduce the number of combinations within one test, leading to a more clear source and more reusable code.

But - as Kevin already stated - a testing developer is not eliminating the need of a tester. With a different perspective (as a user) and a different goal: See the applicaiton break and not see it work.

Best regards, Lothar

re: Can Developers Test?

Ayaz — Fri, 15 Dec 2006 08:37:10 GMT

Thanx Michael for a great post :)

Well as I already said the need for testing at developer's end can never be ignored. The important point is to define the threshold. If developers test too much they will lose the focus of development and if they test too little they will never make a stable product instead they will keep on fixing the tester reported issues.

As for me I do the sanity testing and some regression testing at my end. Once I’m sure that I’ve implemented the required feature and its working properly for both positive and negative scenarios, I move on to the regression testing. Once I’m sure that there is no regression caused by my code, I submit it to the Quality Assurance team and my product goes through their testing cycle .....

This way I mostly find out any problems related to my code before submitting. It saves me some QA cycles and a lot of time :)

re: Can Developers Test?

Anu — Fri, 15 Dec 2006 13:17:39 GMT

Off topic: could you post an entry on when to resolve a bug as "Dupe" or "No repro". I've been following the rule of resolve a bug as dupe if and only if the repro steps of the 2 bugs are the same. If they are the same root cause, it totally depends on the context whether you can resolve them as dupe or not. Many times, I see devs mark 2 bugs as dupe because of a large root issue. Something like "nested classes not working fine in scenario A" causes 15 bugs on different nested classes scenarios to be resolved as "Dupe"!!! At that rate, we might as well have a giant bug called "Visual Studio not coded fully" and then resolve all bugs in the world as dupes of that!

Scenario #2. Bugs resolved as not repro because it does not repro on the dev's machine which has a build which is 10 days newer than the build that it was filed on. Errr - how is this not repro? The justification offered is, "I might have fixed this as part of a larger checkin for another bug fix...it is not reproing on a newer build now. So, no repro"!!! WTF?? How does that become a no repro?

I think this still happens because there are no clear guidelines on how to resolve bugs. I was hoping that you would either point me to a doc that outlines this or make a post yourself. THanks for listening to the rant! :-)

re: Can Developers Test?

micahel — Sat, 16 Dec 2006 00:53:01 GMT

Kevin: Yep, developers know how their code *should* work and so they know what it "*can't*" do. Which of course if often exactly what it does do! <g/> This is one reason I find checklists helpful: they list specific things to look for and so do an end-run around knowing what code can/'t do.

Anu: Thanks for the blog post entry! I'll discuss resolving bugs soon-like.

re: Can Developers Test?

Sanat Sharma — Wed, 03 Jan 2007 11:39:07 GMT

I agree that the developers can't test the application with the mindset that a tester have. I have an attitude of "TEST TO BREAK". Having an experience of around 6 yrs in Software testing, what I can suggest is, that the developers should write the code carefully and perform the unit testing throughly. If possible, perfomr the Integration testing also. And most important, make a document of all those test cases that have been performed while Unit testing or Integration testing. Pass those documents to testing team. These documents will definitely help the testing team to perform the testing further.

-- Sanat Sharma