Thoroughly Modern: Speed Up Application Development With Au... - Jonathan Cartu Internet, Mobile & Application Software Corporation
post-template-default,single,single-post,postid-1389,single-format-standard,qode-quick-links-1.0,ajax_fade,page_not_loaded,,qode_grid_1300,qode-theme-ver-11.2,qode-theme-bridge,wpb-js-composer js-comp-ver-5.2.1,vc_responsive

Thoroughly Modern: Speed Up Application Development With Au…

Thoroughly Modern: Speed Up Application Development With Au…

October 12, 2020

(Sponsored Content) Starting with the System/38 and even more so with the AS/400 and its progeny, the hallmark of the system, at least according to IBM, was its ease of use. This is not exactly the right idea. While the integrated nature of the platform means it is easy to deploy, and the self-management nature of tech support, database administration, and even system administration yields an ease of management, and the tight coupling of the relational database management system with the high-level compilers has definitely yielded an ease of programming.

It is that last bit that is the hallmark of the system, really. But just because programs are easy to create does not mean the logic of those programs, or their security, is up to snuff. Applications, however good they are, need to be tested as programmers tweak and tune the code. That’s why we sat down with Ray Everhart, senior product manager of X-Analysis at Fresche Solutions, which is adding some new tools to the application development toolbox to automate the testing of applications, which is a big headache for a lot of IBM i shops.

Timothy Prickett Morgan: Every market has its niche and every niche has interesting stuff going on. So what’s happing with programmers in general in the IBM i space and specifically with regard to application testing?

Ray Everhart: For IBM i programmers, the platform lends itself to an amazing amount of productivity. I can crank out a lot of code in a very short amount of time. But it hasn’t always been the most disciplined approach toward development. The code that we see has been out there for quite some time, it was written for something very specific, and may or may not have been improved over time. It may be modified, but the core structure of the program is probably not what it originally was meant to do.

As a result, logic gets inserted in different places in the program that wasn’t the optimal approach. If you were designing it today, you would probably do it differently. The challenge is that when the code was originally developed, the developer tested it the way they used it. Very rarely did they test something outside of how they intended it to be used.

There’s a whole discipline around testing that wasn’t utilized as much as it should have been in the development of IBM i applications. Most applications were developed quickly, written by someone who knew the business and could change it at will. Over time, other people might have added to it, and they might not be aware the original intent or ins and outs of the original code. Testing becomes complicated because these applications have grown to a size where all of the functional aspects of it are wrapped up into one bit of logic. That means that a test plan has to include all of the different ways someone might use that application, creating a complex and difficult application to test.

TPM: Knowing people as I do, and how busy they have become this year in particular, I suspect that a lot of companies pretty much have their testing processes documented on a Post-it note attached to their screen. Testing happens by the seat of their pants, both for new development as well for managing and maintaining existing applications – that’s my guess.

Ray Everhart: Exactly. To give you a little background, I joined Fresche six years ago after working as an independent consultant, doing RPG development and coding. Before that, I worked for an IBM business partner for about ten years. So altogether I’d say I’ve probably seen 300 or 400 different companies, and I have worked for them in different vertical industries, helping them with their IBM i midrange systems. I’ve seen a lot of different testing processes and strategies – and the lack thereof.

Earlier in my career, I worked for a place here in Dallas as a contractor. We were required to test and document it for Sarbanes-Oxley. The level of documentation that I saw depended on the developer. One developer had huge stacks of printed documentation, which made it easy to reproduce what he did. Another guy could fit his testing script fits on a napkin. It can really vary depending on the person or the organization.

TPM: It is my understanding that red tape makes application testing complicated, and you have to expect that given the historical big bang way that people used to do code releases. They were quite literally bet the company events.

Ray Everhart: For some, an hour of code changes could mean three months of testing because they have to go through all of the functional areas of the business before putting a change into production. In that case, having an automated testing process could drastically reduce the time to market. On the flip side, a developer might have a loose testing strategy and the organization might not realize that testing isn’t happening. That developer could make a change and put it live right away without testing.

TPM: What different types of testing are typical IBM i shops dealing with?

Ray Everhart: The approach depends on how disciplined they are with testing. If you don’t have a testing strategy, chances are the developer is accustomed to testing what they think they changed.

If a company has a more disciplined approach, they might use test-driven development as a methodology. In that case, you would design your code to be tested before it works. In that scenario you would write small bits of logic (units) that can be tested independently. Unit testing is all about testing one specific aspect at a time. You want to make sure that that happens the same way every time you execute it. You would then put all of the different pieces of functionality together and create an integration test to ensure everything works together.

User acceptance testing is where an end-user confirms that the application works the way they expect it to. There’s also stress or load testing, if you want to see how the application is going to work with a high volume of transactions.

TPM: Is there a difference in how you might test if you are modernizing your systems versus developing new applications?

Ray Everhart: If I’m modernizing existing code, the testing process depends on the quality of the code and how it was constructed. If I have a monolithic…


Computer Network Development CEO Jonathan Cartu

Source link

No Comments

Post A Comment