Rakesh Rajan's blog

Thoughts on .NET, software and a few trivial things...

Bugs, developers and testers

Developers usually develop applications with the objective of getting the functionality up and running as quick as possible. After the functionality is complete, they would proceed to test their code.
Unfortunately, many developers are neither inclined to find bugs in their own code (for, that just means more work), nor would most have that special 'testing' knack to do so. That's where testers come in.

However, many testers I have seen weren't into hard-code development in their career; they were just testers from the very beginnings. There are good and bad points to this. Being completely ignorant about how an application is coded, the tester might be able to test things that would be extremely random and 'creative' – something a developer would have never thought.
For instance, I recently chanced to see such a tester testing an ASP.NET web form page which had several text-input boxes, one of which had a validation criterion of accepting (while typing) only numbers. After testing them by typing values into text boxes directly, this guy opened up an instance of notepad, typed in several words, copied them into the clipboard, and pasted it into the text box. The text box happily accepted the input without validating! These are things routine developers wouldn't think about.

However, testers who weren't developers before could miss out finding serious bugs. For example, some time back I was involved in an ASP.NET project for a short period of time. The project had a screen for displaying and editing information of a user, and the user ids were passed in the query string. Obviously, a user is supposed to view only his own information.
Now, the tester who was assigned this screen wasn't concerned about those "queer set of strings" in the address bar. Needless to say, he missed this very obvious but critical bug - a user could change the value passed in the query string to access information of any other user! Sadly though, the developer who coded the screen never thought of this bug either!

This brings us to this point – we need both non-dev 'creative' testers and the dev testers to test applications. Skipping over one of these can result in a product of inferior quality. We can't be sure that a developer would find bugs in his own code, unless he has a high degree of professionalism.

In my opinion, I feel a solution like follows could help ensure that both kinds of tests happen.

  • Make the technical lead of the project test the code of his team members, for he would (hopefully) have a greater deal of responsibility on product quality than his subordinates.
  • Assign a non-techie tester to test the application, so that he could find out the remaining 'creative' bugs.
  • And if you find the rare breed of developer/tester who can do both, hire him!

More importantly, flaws in the design and structure of the application are more critical (in magnitudes), and will have to be caught as early as possible. However, this will require a different kind of approach. More on this later...

Posted: Jul 28 2005, 08:29 PM by rakeshrajan | with 6 comment(s)

Comments

rakeshrajan said:

"These are things routine developers wouldn't think about."
that's the major problem, "routine developers" that just want to get stuff to "work", developers that don't use exceptions, developers that don't stress out facts (if something should be this way, what to do if is not?) developers that assume way too many things and when the bugs arise they have to spend so many hours just to find out where the problem is, unfortunately a lot of the good new things that come out, just make programmers even lazier than ever and they can't learn how to write good robust code, and on top of everything they just blame it on MS, Windows, SQL, whatever but their code

if you ask me, most of the times when there is an error in a program I wrote (properly catched in an exception), I know almost exactly what line of code is causing the problem, that's what good exception handling gives you, that and the fact that I always stress out facts, whenever they give me a condition that something should always be in a particular way, I always reply, so what do you want the program to do if is not that way?
# July 28, 2005 11:16 PM

rakeshrajan said:

What about automatic testing (like nunit, nunitasp)?
# July 29, 2005 3:47 PM

rakeshrajan said:

Hi BTX,

> "These are things routine...
Hmm…it is sad that even if the intention of tools is it to make programming easier and increase productivity, negative effects also exists. Too many people just use tools blindly without finding out what it does. In fact, ASP.NET postback itself is a great example – I have seen many people who fail to realize that the postback is simply a form action (available for a long long time) set to post to itself – and that it’s nothing magic to ASP.NET. This is especially true for developers who are starting out on a new version of an existing technology – they wouldn’t know how things were before with the old version and what updates the new version has over them.

>if you ask me, most of the times when there...
One quick question on exceptions - what generally is your approach to handling exceptions? Different people have different approaches to handling exceptions and I was just curious.

- Rakesh Rajan
# July 29, 2005 8:08 PM

rakeshrajan said:

Hi Andrei,

Hmm...that is a very different genre.

IMHO developers are the people who should write unit test code, because it's just another sort of coding! Moreover, code in nunit is tightly coupled with the actual code, which could undergo frequent updates in the future as it matures.
In short, testers won't fit the bill. Sadly, this means that in addition to hoping our developers will write good code, we would also have to trust our developers to write good testing code too!

Unfortunately, this is slightly risky for many reasons:
1. More code to write for developers = more effort = more time
2. As soon as actual code changes, test code will also have to be changed
3. Same old reason - can't trust all developers to test well
4. Bugs in actual code is natural...but bugs in testing code - that's too much! (Who will test the code that is supposed to test code?)

Once again, having a tech lead to shoulder the responsiblity of writing nunit code might solve this problem to an extent.

Hmm...it's tough to create good software

- Rakesh Rajan
# July 29, 2005 9:04 PM

rakeshrajan said:

"what generally is your approach to handling exceptions? Different people have different approaches to handling exceptions and I was just curious. "
my approach is quite simple, but very effective:

everytime I start a new method, the first thing in there is:

try try
except
on E:Exception do
raise Exception.Create('Error in method X:'+E.Message)
end finally
//release any resources
end

of course, this is a very generic example, and the code is written in Delphi, but that's the idea, in addition to that of course you want to check for specific exceptions depending on what your code is doing instead of just E:Exception
the other thing to do is when there is code that can potentially create an exception, I always surround that in a try..except

try try
try
//process something that may raise an exception
except
on E:Exception do
raise Exception.Create('Error processing X:'+E.Message)
end;
// some more code here...
except
on E:Exception do
raise Exception.Create('Error in method X:'+E.Message)
end finally
//release any resources
end

again, the code is generic. Many people might think that this is way too much exception handling code, but it actually saves you TONS of time, both debugging and finding any errors or bugs because you are actually writing the cases for when the code fails

and so, with this code, if there's something unexpected, I get something like:
Error in method X:Error processing X: (error description here)

that's very complete information to tell you where to actually go and fix the problem, of course there are always third party tools to give you all this information, but this is simple and works almost just as good

the last things to do with the exceptions are,
- trap the exception at the highest level, before it hits the user
- always log the exceptions
- and what to do with the exception depends on the type of application
# July 30, 2005 6:00 AM

rakeshrajan said:

Hi BTX,

That's interesting - and again, it's yet another exception handling mechanism. I will be writing on the different styles I have gathered shortly. Thanks a lot for sharing!

Warm regards,
Rakesh Rajan

# August 3, 2005 10:08 AM
Leave a Comment

(required) 

(required) 

(optional)

(required)