Posted by: ahmedashfaque | May 19, 2015

practical considerations for software testing – 3

In my previous post we had considered the challenges of unit testing where databases are involved. In this post we will see how to overcome those challenges.

The first challenge is about the fact that a database is an external entity. You can only manipulate a database if you have a connection with the databaase. For any reason if the connection with the database gets broken then you can not do anything with the database. This means the first thing you need to do is to test if a connection with the database is available and it is working. This kind of testing is essentially an integration testing and not a unit testing. Once your database connection test passes then you can write a query which will do some data manipulation in the database. This query will actually change data in the database. On a software project, lot of database testing is performed. This may result in lots of testing data will be created and manipulated in the database. This is not a good practice.

A better approach will be to create a record containing test data in the database and then delete this test data once your testing is complete.

When you follow these principles then you can do your unit teesting with database comfortably.

 

Posted by: ahmedashfaque | May 17, 2015

practical considerations for software testing – 2

In my last post I had promised I will discuss testing techniques. Today I will discuss testing database manipulation if it iss part of a class and you are doing a unit testing of this class.

When you test a business logic, you test if the computation done inside a class through some method, the computation is correct. For example, if you need to compute correct interest rate for a fixed deposit in a bank in your class using a method then you store values for the principal amount and given interest rate and then do your computation and find out the accrued amount after the interest calculation is done.

If you are testing this class and its method then you will give various values for principal amount and interest rate and find out if the class is doing correct computation and giving you correct results. Suppose the interest rate to be calculated comes from values stored in a database table then what kind of challenges you will face and what kind of strategies you will have to make to overcome those challenges?

If you ever have done a database testing stuff for your classes then you must be aware of the challenges. For novice testers, let me stress that there are indeed many stiff challenges in this task. Some of these challenges include:

  • To manipulate a database, you first need to have a connection and only then you can do any database manipulation. This means that you will first need to do an integration test in form of testing the connection with a database and only then you can perform a unit test.
  • Database is a separate entity and not part of the software system you are testing. This fact again implies that what you are going to perform is actually not a unit test but some sort of an extended test. When you are testing business logic for your class, you are also testing the database structure at the same time.
  • Databases carry a permanent data structure and thus have a different behavior compared to the software component your class belongs to. During execution, data inside a data structure of the software component (e.g. the data structure of the class itself) experience value changes. But after execution, data inside these data structures get reset. For example, suppose you have a variable ‘a’ in your method and you assign it a value 5 during execution. After the source code execution completes, value of this variable will become NULL as the object which was carrying this variable will be destroyed. But if you change value of a field in a database during testing then this change will be permanent. For example if you changed first name of an employee from ‘Alan’ to ‘Keith’ in a database table then this change is permanent. Now if you query the database to find first name as ‘Alan’ then you will get an error because the name is ‘Keith’ and not ‘Alan’. This fact has a profound impact on the way you do unit testing.

In my next post I will show you how to tackle these challenges.

Posted by: ahmedashfaque | May 16, 2015

practical considerations for software testing – 1

As people in the software industry realize the importance of testing, there is no way, testing functions can be minimized on software projects. However unnecessary testing will lead to only waste of time and money. So how to ensure that the software product is tested effectively in least time and yet achieve good results?

Most project managers find it difficult to allot resources for testing at early stage of the project. They think that first they should have something developed so that it can be shown to customers and feel satisfied that they have been doing something worthwhile and the effort is visible. How wrong is this thinking?

Off course people are always hard pressed to show results as early as possible. This is only possible when they have something to show. If the project manager first thinks about testing, allots resources and tries to ensure no defects are injected in the software product being developed then he/she has something less to show to the customer as development will be lot slower. This is one factor which goes against early software testing.

But smart and experienced project managers know better. They are able to justify their early deployment of testing functions using charts to show if they don’t go this way then what bad effects will be expected later on. They will be able to convince the management and the customers that the overall time required for completion of the project will be much less if they deploy testing early in the project. It is because fixing defects later results in more defects enteering in the software product due to multplying effect of one defect passed on from say a defective design into many defects developed in the construction later.

In test driven development, business logic is tested first using unit testing before a class to implement that logic is written. This ensures that the business logic will be correctly implemented and chances of defects due to faulty business logic will be much less. Imagine if you have not done any testing at unit level and built your components. Surely at system level you are going to find defects which will be lot more. When you did testing at unit level, you ensure that chances of defects at system level will be lot less. At system level, many untested classes developed by developers will lead to so many defects that testing and removing them will take lot more time compared to when each class was tested and defects removed at unit level.

In my next post I will delve on benefits of testing techniques.

Posted by: ahmedashfaque | May 12, 2015

How to create data model for your application

In the good old days, creating an Entity Relationship (ER) Diagrams used to be a cake walk. You get your data requirements from end users and lo and behold you had everything to design your database using ER diagrams. Not any more. The reasons are too many. But the most important one is that your data model can not be converted into an ER diagram easily.

In 1980s and even up to 2000 or so, most software projects involved developing a database management system. These systems were also used to be known as Electronic data processing (EDP). These systems primarily were driven by a relational database at the back and some front end which would show and manage data in user forms. Most often there used to be a direct relationship between the user forms and the database entities like tables. Thus it was easy to take your ER diagram and build a system based mostly on your ER diagram.

Cut to present! Most software applications being developed today have sophisticated user interfaces. These applications are web based. These applications show many things at the user interface. They also do many things for the user. But all these things are not directly related to what is stored in your database. For example, a social media website allows its users to chat with friends, like a post, make friends, unfriend a friend etc. None of these features are driven solely by a database. There is something more involved apart from a database here.

This translates to a single fact that your fromt end is not directly related to your database. Thus your ER diagram alone is not sufficient to design your application.

The best approach to these kinds of software products is to use a data model which is a mix of databases and temporal data. Databases will hold the permanent data and temporal data will be present in short memory storage like RAM. The temporal data is managed by creating objects which hold their data till it is saved in the database.

 

Posted by: ahmedashfaque | May 9, 2015

database table joins

We all have heard about relational databases but do not understand from where they get their power. Let us understand why relational databases are so powwerful.

Everybody uses spreadsheets. They are neat and allow you to store information in a structured way. You use them to store customer information. You use them to store contact details of friends. In fact spreadsheets are so common and popular that they are used for many purposes by many people.

Spreadsheets are good for storing small amount of data. Imagine if you need to store data which is in the range of millions of records. Can you do it on a spreadsheet? Definitely not. A spreadsheet can store information as much as some few thousand records but not more than that. What are some other limitations of a spreadsheet?

  • searching records through a spreadsheet is difficult
  • searching records through a spreadsheet takes time
  • retrieving data from a spreadsheet and using it in some other application is difficult

When it comes to storing, retrieving and managing huge amount of data then relational databases have no match. The power of relational databases comes from their ability to store data kept into many places and when required then retrieve this data at ultra fast speeds. When you store your data in a spreadsheet, you are storing your data in a flat file. But when you store your data in a relational database you are storing your data in a 3 dimensional space.

A relational database is known as relational because it allows to create relationship among tables and entities. Storing data in the most minutest level and then aggregating them when retrieved allows a relational database to make powerful information processing.

It is the ability to create relationships which allows a relational database to store vast amounts of data in a single database. These relationships also allow data to be stored in such a manner that the data integrity and referential relationships are always intact. No redundant data and no inconsistent data is possible when a relational database is designed carefully. So for instance a large company can store all its mission critical data in a relational database no matter how large this data can be. And yet all this data is safe and when required, any data can be retrieved at ultra fast speed.

Indeed there is no match for a relational database when number crunching matters.

Posted by: ahmedashfaque | May 8, 2015

What is a model-view-controller architecture?

You may have heard about model-view-controller (MVC) architecture but may not have idea about what it is or what it does. Let us understand MVC architecture.

Suppose you are using a software application (e.g. a website). On a web page or this website you need to fill out a form and then submit it. After you submit this form, the database attached to the website will store the information you submitted. Later when you want to see the information stored in the database you can go an edit page and you can see your information and you can even edit it.

What happened in that scenario is that the of the website had collected the information from the user interface (browser) and sent it directly to the database and the data was saved in the database. Simle and straight!

Now imagine you had gone to a website where there was a webpage where you need to make some selection (using radio buttons or selection boxes for instance). From that page you navigate to another webpage and do some more stuff. Now you want to go back to the previous page and see if the selection you made were correct. As a general rule, once you move away from a webpage, any changes made by you on that page should be lost. But you are surprized that the information you selected on that wwebpaage is still there even after you had moved away from that page. The information you selected on this wwebpage was also not saved in the database either. So how this information was still available on that page?

The magic done here is by using MVC. MVC architecture consists of a model, a view and a controller. When a user makes some selection on a webpage then a controller component of the software application stores this information. As long as the user does not submit any information (using a submit button for example), any user selection done on any webpage is saved in the memory through the controller component. Only when a user submits the information using a submit button then the controller directs the model to do computation and also to save information in the database. When the model does this part of computation, it informs the controller. The controller then creates a view and then sends it to the user interface. The user will see the processing for the information he/she submitted.

MVC is used extensively for wewbsites. Using MVC, websites are able to provide persistent user selections even when the users keep browsing a website.

Software designers often wonder how to create the software design so that the software product built on this design looks all zazzed up and works wonderfully.

Even though software designers get full idea about the overall software architecture from the requirement specifications. They fully understand how the software product will look like at this stage. The problem arises when they have to drill down and find out how many classes they have to build to capture all aspects of requirement specifications. So here is a discussion on this topic which may help software designers to build great software products.

When I think to design a software product, obviously my first inspiration comes from requirement specifications. Requirements specifications give me all the details to build the software design. Generally I first think about what data I need to keep in my database. So I first design my database tables and their relationships. Entity Relationship diagrams (ER Diagram) come handy here. So I build my ER diagrams and my database. Only when I am confident about my database, I think about other aspects.

If the software product does not has a Model View Controller (MVC) Architecture requirement then I will create my classes directly related to my ER diagram. Thus my ER diagram is good for both building my database as well as my middle tier components.

But suppose your software archiecture has to be MVC based architecture then what you will do to create your classes for your middle tier? Well in this case, I will find out where and what are the differences between views and models in my MVC architecture. For example suppose the user has clicked a navigation button on the user interface and some user selected entries have to be memorized which were done prior to the navigation then a difference will occur between the view and the model when user wants to see selected entries later. Afterall the selected entries were not saved in the database and you have to provide a mechanism to store them in a temporary memory. This is where your ER diagram will differ from your class diagrams.

To take care of this difference, you need to build your classes accordingly.

Posted by: ahmedashfaque | May 5, 2015

integration testing for software products

software products are composed of many components. All these components are made of classes in an object orietned programming language. These classes are linked with each other through method calls. Each class provides an interface through which these methods can make or receive calls. Through these calls classes are integrated with each other.

It is important to make sure that integration of classes works otherwise the software product itself will not work. So you ensure that integration of classes are done properly?

Integration of classes is checked using integration testing. Design documents depict relationships of classes with each other. Each method call with paramters and datatype of each parameter is defined in a design document. Even object diagrams are also provided which determine the sequence of these method calls. When you do integration testing then you ensure that these method calls work correctly and thus classes interact with each other without any problems.

Strictly speaking, integration testing is not done explicitly. When you integrate your code with the main build of the software product and you find that there are compile issues only then you know that there are integration issues with your code. Integration of classes with each other is mostly about the method calls. If a class which receives a method call does not provide a proper interface then you will have integration issues and your code will not compile with the main build. The problem could be wrong parameter data type, wrong data type size etc. So such types of integration issues are essentially due to interface problems.

In some cases where a class has many method calls, it becomes difficult to find integration issues if they arise. In those cases, the class can be broken down into smaller classes. Each class can then have one method to test and thus it becomes easier to do testing.

Integration testing is purely technical in nature. It does not test for business logic. Business logic is always tested during unit testing.

Test Driven Development is a great environment for ensuring that your software product does suffer due to integration problems. We will cover test driven development in our next post.

Posted by: ahmedashfaque | May 4, 2015

Unit testing for software products

Testing during software development is very important as it will ensure a defect free software product. A defective software product can lead to many problems to the users as well as the software product vendor as well. Most people understand problems of using a software product.

So how to ensure a defect free software product? Software product should be tested from the very beginning when the software product starts getting developed to the very end when the software product is ready to be shipped. Any defect found during this entire spaan of time when the software product is under development, should be fixed immediately.

To ensure that defects are not getting injected in the software product, testing should start even before developers start writing their source code. In object oriented programming, when a developer writes a class, a test case should be written to test this class and its methods. This level of testing is known as unit testing as this testing is done at a unit (class) of source code. Only when all unit testing is done and all these tests pass successfully, a developer should integrate this piece of source code with the software build where all fresh source code is integrated.

A unit test should check the business logic implemented in methods inside the classes. A method does some computation and provides some output based on the inputs it receives either from the user or from any other software program unit. In unit tests, input values from boundary conditions should be provided and output values should be checked to verify if the method is doing right computation. For example suppose a method is created to compute sum of 2 integers and these integers should have values within the range of 1 to 100. Then in unit testing you should create test cases which will provide inputs in the range of less than 1 (e.g. -1) and more than 100 (e.g. 101). These 2 test cases will give negative results (the tests will fail) when they are run against the method which you are testing. So these test cases are known as negative test cases.

You should also create a test case which will provide values within the range (e.g. 50). This test case should pass as it will meet the criteria for business logic. This test case is known as positive test case. When you run this test case and if this test case passes then you business logic implemented in your method is fine. If this test case fails then your business logic implementation is wrong and you need to fix it.

You can write your test case manually. But writing and maintaining manual test cases is a laborious task. Now a days good tools are available which help you in creating, maintaining and automatically running test cases. When you maintain your source code later (refactoring for example) then you can again use the suite of test cases written to do regression testing.

In Java there are 2 powerful ways to implement different interfaces to work with the same class. This prevents creation of too many unnecessary classes and thus improves code reuse. These techniques include method overloading and method overriding. Let us see them in action.

Let us have an example of method overloading first.

public class rectangle {

private integer length;

private integer height;

private integer x;

private integer y;

 

public rectangle() {

this.x = 15;

this.y = 20;

this.length = 20;

this.height = 25;

}

 

public rectangle (integer length1, integer height1) {

this.length = length1;

this.height = height1;

}

 

public rectangle (integer length2, integer height2, integer x, integer y) {

this.length = length2;

this.height = height2;

this.x = x;

this.y = y;

}

}

Using this technique you can create many different objects from the same class.

Rectangle rectangle1 = new rectangle();

Rectangle rectangle2 = new rectangle(25,30);

Rectangle rectangle3 = new rectangle(30, 35, 5, 10);

You can see that we have created 3 objects which do different computations even though the base class is the same.

When you test your code, you will see that 3 objects will be created. A rectangle1 will be created with a length of 20 and a height of 25 with a center on (15, 20) coordinates, rectangle2 will be created with length of 25 and height of 30 with a center on (15, 20) coordinates and a rectangle3 will be created with a length of 30 and a height of 35 and center of the rectangle will be at (5, 10) coordinates.

Now let us see method overriding:

class Animal{

void run(){System.out.println(“Animal is eating”);}

}

class Cat extends Animal{

void run(){System.out.println(“Cat is eating mouse”);}

 

public static void main(String args[]){

Cat obj = new Cat();

obj.run();

}

 

When you run your code, you will see that you will get a different result than what is defined in the parent class. You can see that method overriding works at class level and it completely suppresses methods defined in the parent class. In contrast method overloading works at method level and depending on usage, one method will be used and other similar methods will be overlooked.

Older Posts »

Categories

Follow

Get every new post delivered to your Inbox.

Join 106,433 other followers