Home     RSSRSS

Posts Tagged ‘Testing’

Unit Testing–What to Test

October 9, 2013 by kiranbadi1991 | Comments Off on Unit Testing–What to Test | Filed in Development, Others, Quality, Testing

One of the frequent discussions I often get into with developers especially in agile projects is how to write the test case for the class or method and what should we be testing in the unit tests.

There seems to be difference in opinion among folks as what unit test case needs to cover? Or what should we be testing with unit tests?

Should we write the test for both positive and negative input values or should we write the test that shows the code is just enough working? Or should we write the test case for all the possibilities that the code is going to fail or it’s going to be used?

All of these questions seems to be perfectly valid and there isn’t a single right answers to it. However based on my experience and little bit of wisdom, I can say that if you are working with experienced veteran programmer, then probably he will suggest that we write test cases for all possibilities and if you are part of team where everyone is young or most of them are in their midlife, then probably they will not be bothered and will ask you to write tests that shows the code is working as expected. I don’t think there is anything wrong with this approach either, however I feel it’s good that more unit tests we write, better the shape of project in the downstream phases, however this needs to be done correctly and results should be obviously visible. It does not make sense that we do unit testing for every piece of code flow and there are thousands of defects logged by the QA in the later phase. This just don’t make sense economically nor from the management prospective.

So probably I will focus on areas which I feel developers need to focus in their unit testing in this post without getting themselves buried in the art of functional testing,

There are infinite number of ways the code might fail, it might fail due to environmental changes, code might fail due to data changes or it might fail due to real bug in it. All these conditions happens all the time in various environment. So it’s practically not possible to know the failure mode beforehand. However being the developer of the code, we do assume that our code will be working will be working certain fixed environment with certain fixed perquisites for it to run. So it’s always better that we do some assumption and use our time judiciously for writing tests which reflects real time behavior.

I would suggest each of the unit tests exercised on the code under test should minimum show that.

  • The output given the code is correct and it does give us expected results.
  • Extreme boundary conditions for the input values are handled correctly.
  • Error handling is done appropriately by the code.
  • Tests should exercise the performance of the code under test

Maybe in next post I will come up with proper example to show as how to prepare test cases for each of the above conditions. We need to ensure that our unit tests are lean and thin in nature and we need to test just enough code.

Technorati Tags: ,

Tags: , ,

My Thoughts on “Customer sues Epicor after ERP software project attempt ends in ‘big mess”

March 11, 2012 by kiranbadi1991 | Comments Off on My Thoughts on “Customer sues Epicor after ERP software project attempt ends in ‘big mess” | Filed in Process, Project Management, Small Businesses

This is an interesting case where in the customer sues the vendor for failing to implement the ERP Project as per the agreed timelines and probably budget.ERP projects has their own challenges with regard to implementation and requirements gathering process. I do fully agree with ParknPool that it does impact the bottom line of the company when ever the key systems goes off line for some reasons.I have seen the mess that happens specially if you are multi million dollar company having sales/order booking partners located  in various locations across the country. Given that most of the key information about the clients like credit limit/ account balance/banking details etc are often interdependent and located in the same systems in ERP, it becomes a kind of challenge of the company officials to work without this information.Manually taking orders and updating the payment is just impossible given that during peak seasons there exists lot of chances of human errors or creating intentional gaps by sales team. Remember no matter how high your position is in the company or no matter how close or deep relationship you have with your clients or customers, there always exists a risk that you might go beyond the credit limit allocated to the customer if you are super busy sales guy and has bonus attached to your monthly targets.

So why this case is interesting , there are number of reasons for this ,

  • Implementer failed to read the requirements correctly.”Because we’re a drop-ship business, we need to invoice our client after the last item ships, because they could ship from multiple locations,” Fonner said. “The Epicor system couldn’t deal with that.”. Though the requirements looks 4 lines statements, I am sure it takes at least 2 weeks to get more clarity on this requirements and at least minimum 4 weeks to implement this.(This is based on my experience).
  • There was also an attempt to change scope  which we often see in some projects due to various reasons.”Epicor also performed something of a bait-and-switch with ParknPool, initially saying that the company’s need would be met with a specific set of software modules, but then saying that more were required after the project started, Fonner said.”. Most service providers tries to do this indirectly in cases where they feel the client can provide still more business.This is just an immature and terrible thought  that is surely going to backfire on you.
  • Software implemented was untested.If you are deploying in production any software which is untested, there exists a risk that you are going to do a  business in loss at least this is true for Software which are as complex as ERP systems. These systems often has lot of information with regard to inventory, finance ,rates and client information etc. I can go on writing as how various departments in the company sees an ERP systems. Its just a very high risk decision to implement an ERP in actual usage without testing for validity of business rules implemented.
  • Its just not easy to sue the seller here for the simple reason that during the implementation phase,I feel there wasn’t any legal check points or milestones to measure percent completion of work.If there were check points, ParknPool could have seen the red flags right after some days of execution start.Checkpoints are must in any projects to see where we stand.
  • This should be interesting case to follow as I have seen many companies changing vendors due to bad quality of management, improper execution or  just operational loopholes or lack of quality for the work done. Suing the vendor for bad quality or incorrect or incomplete implementation is something I feel should have some impact on the way IT Industry works and the way outsourcing works.In all, this case should definitely benefit IT industry in some way specially at least in defining the legal definition of “DONE”.

         

Technorati Tags: ,

Tags: ,

Know your user-Agent String

February 3, 2012 by kiranbadi1991 | Comments Off on Know your user-Agent String | Filed in Browser, Development

Sometimes during performance testing it becomes necessary our script send the correct user-agent string to the server so that server identifies and responds correctly to the script.Most of the load testing tools available in market today provide a way to customize the user-agent string. So in case if you want to know and customize the user-agent string, then below JavaScript function can help you in getting this information. All you need to do is copy and paste the below piece of code in your browser and press enter key. Modal window box will be displayed showing you the user agent string of that browser.

javascript: alert (navigator.userAgent);

In fact with this function, you can get lot of information like version of framework involved, type of platforms, OS version etc. etc. Most browsers today send around at least 2 to 3 lines of information as part of user agent string and they send it voluntarily and send it for every request they serve.

Sometimes I really think is it necessary and correct for browsers to attach unnecessary information on every request they serve? Isn’t there any other better way to track the browser’s usage/OS Penetration rather than choking the network with extra characters that very few people care about?

Technorati Tags: ,

Tags: