Saturday, April 4, 2015

Software Bugs - The programmer side


Software Bugs - The programmer side
Overview
As a software testers we all familiar with the basic equation “Programmers create bugs -> Software testers supposed to find them”, this equation is very simple and well known (I have written thousands of words that investigate and explain this issue). 

In this article, I want to talk about the programmer side, and explain the three main types of programing errors that the programmer can cause (and fix J) during the software development life Cycle or after changing any part of the code (Fixing bugs, Add new function Etc.).

The programmer side

As said, programmers can and will cause software bugs, from the programmer side, those bugs are divided into three main categories (Logical, Syntax and semantic) that I will review in this article. 
But before that, let’s try to answer the basic question of “Can programmers write programs that are totally free from software errors?” the answer is NO!

I want to believe that every programmer that start a new project, will write the code with the state of mind that the code should be free from bugs and not the state of mind that says, that he can do a lousy job because he have software testers that should find is mistakes (Believe me that I used to work with some developers that actually work with this state of mind…).

Now, let’s continue with the programmers that actually cares about their code, those programmers no matter how hard they try, will never write the a code that is free from bugs (you know that joke that says that “The easiest way to remove software bugs is to write the code so there are no bugs in the first Place”), but he has the power to write is code without a basic bug that can affect the entire SDLC process when those bugs are found in the customer site or in the last cycle of the testing process.

Based on my experience, and after working with many types of software programmers, the number of coding bugs is reduced when the code is written based on this grocery list:

1.    There code is written based on the requirements and specifications.

2.    There is a valid and suitable coding design.

3.   The state of mind of the programmer, is to write the best code as possible (ignoring the fact that there is a testing cycle that will cover is!#!@$). 

4.   The programmer as the experience to write the code (its most basic, a programmer that as the skill and the experience, will write a  better and efficient code -> Reduce the logical errors -> Deliver a more resilience software for testing).

5.   The code is inspected and contain a good effort of “UNIT” testing. 

As you can see from this list, the programmer has a huge responsibility due to is involvement in almost every bullet that I just described

Note!
One statement for the testers, Remember, software will always contain defects, that’s one of the basic assumption that we have in the testing world, as a tester you must understand this fact, otherwise your state of mind will not allow you to find the real logical bugs that need some further and deeper investigation. 

Types of Program Errors

When a software tester finds a new bug, he will report it in the bug tracking systems (TFS, Bugzila, Etc.), those systems will allow the tester to categorize the bug with more than 100 values (Usability, GUI Performance, Functionality Etc.). 

From the second side of the coin, when a programmer fined a bug (And fix it) during the development process, he can categorize the problem using three main types of program errors: 

Category 1: Semantic Failures
A semantic failures occur when the programmer writes is code based on the programing language rules, but create a statement that is out of context. Example: a method that uses a variable that created outside the method scope, the syntax is accurate, but the code will fail to be compiled because the method will fail to access the variable data. 

Example: 

In the following code we declare variables correctly, but the method that we use will fail to access the variable data because it’s located in unreachable scope.

namespace My_First_Application
{
    class Program
    {
        int a;
        int b;

        static void Main(string[] args)
        {          
              Console.WriteLine("Please insert two numbers");        
int c = (a = int.Parse(Console.ReadLine()) / (b = int.Parse(Console.ReadLine())));
              Console.WriteLine(c);
        }
    }
}

Category 2: Syntax Failures

Syntax failures are the most basic errors that a programmer can find, in most cases, those failures are created when the programmer failed to follow the language syntax rules that he use during the application development.

Example:
Declaring variable without following the language syntax (C# in our case):

int a;   //Valid
t int ; //Invalid

Category 3: Logical Failures

Logical errors are those errors that you hope to find soon as possible, in most cases this kind of errors will cause the highest damage during the SDLC process. Logical errors are most likely to be found when the programmer has removed all failures that related to the Semantic and Syntax categories. 

In this type of failures, the software is producing a result that is not expected based on the predefined requirements. This is the reason that both the programmer and the tester will have difficulties to find and remove this such error, the best way that the programmer can remove such errors, is when he succeeds to consistently reproduce the problem, only then he can isolate each part of the code that involves in the process, and find the exact line that cause this invalid result.




No comments:

Post a Comment

My Presentations