Home     RSSRSS

Archives: Project Management

Oops Error and Java Error/Exception Handling

April 4, 2014 by kiranbadi1991 | Comments Off on Oops Error and Java Error/Exception Handling | Filed in Development, Environment, Performance Engineering, Project Management, Web Server

Very Often during the testing for java based application, I come across the generic Oops error message which looks something like below screenshot,

image

Lot many developers who are building the java based application  or are new to development use these techniques to display error or exception message. It’s a good technique and even I have this technique in my application which I have coded.The code to display Oops error which I have in my application is something like below,

<%@page contentType="text/html" pageEncoding="UTF-8"%>
<!DOCTYPE html>
<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>
<%@page isErrorPage="true" %>
<html>
    <head>
        <title>Show Error Page</title>
    </head>
    <body>
        <h1>Oops...</h1>
        <table width="100%" border="1">
            <tr valign="top">
                <td width="40%"><b>Error:</b></td>
                <td>${pageContext.exception}</td>
            </tr>
            <tr valign="top">
                <td><b>URI:</b></td>
                <td>${pageContext.errorData.requestURI}</td>
            </tr>
            <tr valign="top">
                <td><b>Status code:</b></td>
                <td>${pageContext.errorData.statusCode}</td>
            </tr>
            <tr valign="top">
                <td><b>Stack trace:</b></td>
                <td>
                    <c:forEach var="trace" 
                               items="${pageContext.exception.stackTrace}">
                        <p>${trace}</p>
                    </c:forEach>
                </td>
            </tr>
        </table>
    </body>
</html>

The code above uses the JSTL tag and EL to display the error page.It works perfectly fine and it does display most of the exception which is thrown by the application.

However drawback of this approach  is that it shows error or exception directly to the end user and it means that we are leaking information to the outside world about our code base. Its not good. Some of the reasons as why its not good can be found here.

Most of the sites display catchy error screens when something goes wrong with site. They look so good and in fact  appeal the users. Great number of examples  can be found here.

Now changing from that Generic Oops page to some thing catchy and stylish is also very easy. It involves creating one static page with funny image in it and steps for the user to go to other section of the site or report the error message to site administrator or something which you want your users do when they see error page. However to implement this change some knowledge as how java handles error/exception is required. Below links are probably worth the read  to understand the science of java errors or exception,

http://docs.oracle.com/javase/7/docs/api/java/lang/Throwable.html

http://www.artima.com/intv/solidP.html

http://www.onjava.com/pub/a/onjava/2003/11/19/exceptions.html?page=2

http://docs.oracle.com/javase/6/docs/technotes/guides/logging/overview.html

Now changing from Generic Oops page to some catchy page is also quite easy. Build the static JSP or HTML page and edit the web xml error page section. It looks something like below in Netbean editor,sorry I use netbean for development so I have screenshot based on it. Web xml can also edited in notepad or any other IDE.Editing via IDE is recommended since its heart of the application.

image

We can also write the exception handler servlet and build the page dynamically using the throwable class. The important thing to be considered here is that we are not leaking information and at the same time we are also informing users that something went wrong and they can follow some other path to their work. Once you have implemented the change, we can immediately test this change by triggering the error condition to see that in fact we are redirecting to error page correctly.

If you are QA  and if you see Oops Page, then probably you want to log the defect for this irrespective of the condition/data as what triggered the error.However you also need to make sure that exception stack trace is correctly logged in the logs and it has all the information that is required to debug the condition. If you are using any logging framework like Log4j ,it should not take more time to redirect the error to appender and verify the completeness of the message.

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: ,

Mobile Performance Testing- Requirements Gathering Process

November 30, 2011 by kiranbadi1991 | Comments Off on Mobile Performance Testing- Requirements Gathering Process | Filed in Performance Engineering, Process, Project Management

As per the research done by Morgan Stanley, mobile internet will soon be overtaking fixed internet and we can see and feel the same trend now given that smartphones and tablets sales are overtaking PC sales,so all these changes compels us to go with a market demand.

http://gigaom.com/2010/04/12/mary-meeker-mobile-internet-will-soon-overtake-fixed-internet/

http://www.pcmag.com/article2/0,2817,2379665,00.asp

So I thought let me share some of my thoughts based on my exposure to mobile world.I did poke around with WAP/Openwave emulator back in 2006/07 with both Silk Performer and LoadRunner.I do remember they have a protocol bundle for testing mobile traffic back then.I faintly remember it was more of an open source emulator support which these tools were supporting.Now the scenario is different, WAP is dead and now plain HTTP rules the mobile world.So we have some old rules which I believe still applies to mobile world and then there are also some rules which are totally new when we think in terms of Performance Engineering.

The strategy for designing for the mobile web site differs drastically compare to the desktop based web application given that applications works in the mobile context with limited amount of resources like screen size,network capacity,Hardware resources etc.The site needs to be lean in design and be accessible on the smallest mobile device with the exact functionality as offered on desktop based web applications.So the end to end strategy for testing mobile based application also differs compare to the desktop based web applications at times throwing unique challenges to the testing team.

It is also important to know and understand the capabilities of the various types of phones available in the market so that we have some idea as what is happening in the client side of the device.Some phones have Cursor based navigation, some phones have focus based navigations and some have touch and some multi touch based navigation.Low end devices normally have cursor or focus based navigation,so users using this focus or cursor based type of device will not normally prefer to have navigation depth of more than 3 links while browsing the site.The same user might browse a little longer in your site with either the tablet of smartphone.So it is fair to expect that page depth of the browsing in case of smartphones and tablets will be somewhat higher compare to Low end devices.This will help us in designing appropriate work load modelling for performance testing.

In this writing, I will try to summarize as what all things needs to be known and collected as part of requirement gathering for performance testing of the mobile web applications.

  • Know your site along with its business domain and benefits it brings to users who are using your site.
  • Know your users and how they use your application in mobile environment.
  • Know the type of mobile device or handset your users uses to access the application.
  • Know the network bandwidth your users uses in their device to access your application.
  • Know the carrier your user uses to access your application.
  • Know how long your users browses your site in the mobile space and collect the page depth of their browsing experiences.
  • Know the type of the mobile browser your users use to access your application in the mobile environment.
  • Know the user’s device’s screen size.
  • Do not trust the web server logs to design the scenario as user behavior is not the same as compare to desktop users.If your business grows ,users multiply exponentially compare to desktop users given that users will be using your site on the move.
  • There is very little or absolutely zero think time concept in Mobile space.Users are not going to wait to click the links unless they are verifying the some information before doing submit.

Sometimes it might happen that we do not have information on these points,in that I would suggest follow the mobile web standards and test taking those standards as your requirements.

Tags: ,