All testing results correct!

and we are ready to deploy the application.  I hate to play devil’s advocate but system development is more than just getting the correct results.  In order to have a manageable, robust, and scalable system that have maximum life expectancy; there are many important things that we have to take care before we can deploy the system.  The first thing I want to visit is actually testing. 

“Did I just tell you that all testing results were correct?”

Software Testing

Software testing is a huge subject by itself and I won’t be able to cover everything but there are a few common issues that I would like to share:

• Testing plan / scripts should be properly documented – you may not believe it but most people could not be able to reproduce the test that they did.
• Every code / condition / exception must be covered – I hardly found testing that would cover more than 60% of the codes.
• Non functional testing such as scalability, performance, and security should be carefully planned – the system may work well for single tester and a few hundred test cases.  Would it still work in production environment that have million of records and hundred concurrent users?
• User Compatibility – you may be testing your application on Internet Explorer 9 / Office 2010 when your users still use Internet Explorer 6 / Office 2003.  Good luck when you deploy the application to your users’ computer.
• Tools – Do you have any tool to automate testing, measure code coverage and defects tracking systems?  One reason that system is not thoroughly tested, is because we don’t have enough resources.  Appropriate testing tools would automate testing, compare results and report any defect; we can do more testing with lesser resources.

I only cover the bare minimum of testing and I haven’t covered any details about unit testing, integration testing, system testing, regression testing and many more.  Wikipedia has a good article about software testing.  You may want to go over it and see if you have done all necessary testing yet.

The rule of thumb is to find and fix problems as soon as possible!

Code Refactor

All testing results are correct, are we ready to deploy the application? Not quite yet if you want to deploy an application that is easy to extend and maintain!  Let’s review the code and see if we find some of the common code smells:

• Copy and paste – I recently fixed a very small bug, but I have to go through nearly 100 different places.  The same piece of code exists in over 20 different place and I also found similar code in another 50+ different places.
• Jumbo functions – have you ever read functions that have over 1,000 lines?  It tries to do too much.  By the time you go through half of it, you already forgot what it is supposed to do.  You are lost in the functions. Simple and small function is much easier to fix and extend.
• God object is similar to Jumbo function and it violates virtually every object-oriented principle that promotes faster development.
• Global Variables – they are difficult to trace and understand because they can be read / modified in any part of the application.  Sometime, you may not even know that you are using one.
• Morse Code / mystery variables – A1, B1, C1, Xn, Yn, Zn and to make it worse, there is no comment.  It can take you hours to understand a simple if statement.
• You can visit Martin Fowler’s website to get a more comprehensive list of refactorings.

The bottom-line is that code refactor would allow the application to produce the same results but run faster, easier to fix bugs and extend.

Security

It may sound obvious that any sensitive / critical data must be secured; however, a lot of business applications’ security is nothing more than illusion.  The application may require user login but the data is not secured or its security would require minimum effort to bypass.

Google “Excel Password” and you would not believe how many Excel password removal utilities are available;  most of them are even free.  How about Microsoft Access?  Why don’t you Google again?  Does your application store data on Excel?Apart from data; there may be situations that you also want to secure the code, your intellectual property.  If you develop a financial model that can price products 10 times faster and 10 times accurate; I strongly recommend that you should not deploy your model on Excel / VBA.

Let’s deploy it now?

I am going to cover software deployment in my next blog but I would like share some of my own experience in the last couple years.

1. It was supposed to be a short project.  According to the project manager, everything was ready; I just had to migrate the application to production environment.  My first problem was that I could not even compile the programs successfully.
2. Again, another simple deployment job.  The challenge was the job took over 10 hours when the users only had 1 hour window.
3. We ran a stress test on a server that had only 2 cores and 4 GB RAM; it could support more than 200 concurrent users within 2 seconds.  We ordered 3 servers, each has 8 cores and 32 GB RAM; the web server crashed after 20 concurrent users.
4. We tested the application on development server and integration server; our users tested it on users acceptance test server.  Everything was fine.  When the application finally deployed to production server, nothing worked.
5. Our power users developed a sophisticated financial model that was going to distributed to their business partners.  It is ready to deploy; they just want to secure the model, so that their business partners would not be able to trace the logic and data.  It was developed on Excel.

Deployment is very important and no matter how well the application is developed and tested.  A poor deployment can still produce terrible users experience.