Many things can, and will, go wrong during the development of an enterprise application. These issues underscore the importance of using test cycles to detect potential performance-robbing defects before the application is moved into production. To combat the myriad problems waiting to plague the application lifecycle, developers need to equip themselves with items they can employ to troubleshoot such issues when they arise.

User Acceptance Testing, in theory, is used to utilize the end-user to test the application before it moves on to other stages of the application lifecycle and give their approval, but rarely does an application become exposed to the variety of situations it will experience in production.

Too often, the underlying middleware message layer is often regarded as a “black-box” during this process. And that’s ok, as long as there are no problems. Testers know how long a message or transaction took to transit that layer or the architecture. But if that took too long or was routed to the wrong location, they don’t know why.

This lack of visibility can make it rather difficult to reproduce and then resolve a production problem. Lack of visibility also forces development to manually contact the middleware administrator in shared services and request information about message contents. Certainly, this is an interruption to the middleware administrator and a very inefficient, costly and error-prone process.

As more firms move to a DevOps culture, cooperation in usage of tools across development and production is important. At the very least it gets the two teams speaking the same language, which means time spent in trying to reproduce a problem that is adequately specified can be reduced. At best it can help the joint teams rapidly identify a problem, reproduce it in the test cycle and then develop a resolution.

The following “no fail” best practices are designed for Independent Software Vendors to enforce consistent guidelines for application, middleware and transaction diagnostics in order to rapidly identify, trace, replicate and resolve issues that occur during production.

1. Visibility

Ensure that you have the most detailed visibility into the performance of your applications as possible. Synthetic transactions are not enough. Detailed diagnostics down to the message contents or method level are essential -- you need to see more than just what is being passed into and out of an application as if it were a “black box.”

Instead, ensure you have full visibility of each message and transaction. Use diagnostics at each juncture to proactively provide detailed information when an application’s behavior veers from the expected.

2. Traceability

Knowing when a metric has been breached is an important first step in optimizing application performance during test cycles. Knowing exactly what caused the problem is more challenging. Traditional testing methodologies treat the symptoms looking outside-in, not the root cause which often requires an inside-out viewpoint. Make certain that you can trace the message path in its entirety to uncover the precise moment and environment when the problem occurred.

3. Reproducibility

The key to any successful testing program is the ability to reproduce an error. It is the confirmation of a problem solved, and guarantees that the same problem will never need to be resolved twice.

4. Actionability

Once a problem and its trigger have been identified, and after it has been successfully isolated through replication, developers have all of the tools they need to confidently act on the information and permanently resolve application performance problems. This means they need the tools to -- on their own -- create new messages, re-route them and test their problem resolution.

The ability to identify problems sooner in the application lifecycle will yield better results when the need to remediate issues arises in production. This can only happen when development and production are working together as a team, utilizing a common tool set and when development is enabled with full visibility. This approach will save time and money, as well as helping organizations meet SLAs and drive ROI from these applications.

About Charley Rich

Charley Rich, Vice President of Product Management and Marketing at Nastel, is a software product management professional who brings over 20 years of experience working with large-scale customers to meet their application and systems management requirements. Earlier in his career he held positions in Worldwide Product Management at IBM, as Director of Product Management at EMC/SMARTS, and Vice President of Field Marketing for eCommerce firm InterWorld. Charley is a sought after speaker and a published author with a patent in the application management field.

Related Links:

www.nastel.com