Testing times: How to deliver apps in hours, not months

Our modern world is characterised by 24x7 living, short attention spans and “grazing” on information. Presumably that makes you a minority individual, for reading thus far. Yet this characterisation is, quite bluntly, true for many organisations: The delivery of apps and updates must be both rapid and of high quality.

 

Successful businesses use their ability to be flexible—reacting to situations as they develop—as a significant differentiator. And given that many organisations are fundamentally reliant upon software, the ability to modify and develop new apps in a short space of time is critical.

 

Quality vs. velocity

I know that if I wash the car in a hurry, it will look worse than when I started. The same principle applies to software—we need to be able to achieve a working balance between getting the right level of quality and delivering apps in a useful timeframe.

 

I may need to deliver an app that will enable the sales team to take advantage of recent events, but if the app is hard to use or unreliable, then I’ve wasted everybody’s time. However, the gold-plated app rolled out after months of testing is of no use if the world has already moved on.

 

According to Gartner, the likelihood of a shiny new consumer app being a financial success is less than 0.01 percent. This kind of forecast should certainly be considered when deciding on the cost of developing an app.

What gets in the way?

 

For some years, software development methodologies have been seen as the overall answer to achieving a good quality vs. velocity balance. “Get the right methodology and it’ll sort itself out,” seemed to be the message.

However, as Jason Taylor of Specsavers says, it doesn’t matter what methodology you use. It’s all about getting it right first time.

 

Three inhibitors get in the way of getting it right first time while achieving the quality/velocity balance: siloed teams, technology inhibitors and inefficient processes.

 

Siloed teams

In an environment with the usual analyst, developer and tester teams—performing different parts of the work in separate locations, sometimes in different countries—it’s easy to find cultural battles between teams. The developer/tester friction springs to mind immediately!

 

Indeed, the more traditional methodologies such as waterfall actually encourage this silo effect. The strict requirements -> design -> build -> test cycle means that big chunks of effort are required, each fulfilled by a different team. Each group wants to keep on schedule, so there is pressure to deliver to the next stage on time, leading to the temptation to delay thorough testing.

 

When it’s time for the testing stage there’s even more pressure to complete on time, which itself often leads to compromises on quality. The easy fix to a slipping schedule is to cut back on testing, leading to lower quality software deliveries. Low-quality apps will lose customers in no time—and they won’t come back.

 

Errors in or changes to requirements, combined with software faults, require complete re-runs of the whole cycle. For today’s need for software releases in time-scales of days, this approach is simply not fast enough.

 

Technology inhibitors

There’s no longer just a single piece of software used to perform a business process. Looking up a customer’s credit score isn’t as simple as doing a database query—it might involve multiple internal systems as well as an online check to a credit-scoring agency.

 

This in itself isn’t necessarily an inhibitor to speed of development. The difficulties start to arise when we need to test these overall systems and processes. Traditionally you’d schedule a time when the production systems could be taken offline and made available for testing. In our 24x7 world, this just isn’t possible.

 

Another current issue is that we have to test apps on multiple platforms. Not only is it “what version of Windows,” it’s now “which desktop, tablet and mobile device.” The range of different operating environments has grown dramatically, leading to a mobile testing nightmare.

 

Inefficient processes

By my own observation from visiting many different organisations in wide-ranging sectors, I find that a large percentage of development teams still rely on manual processes. Ironically, the drive to automate the rest of the business often doesn’t extend to the development team.

 

The loop from analysis through development, testing and deployment more often than not relies on emails and word of mouth, and maybe the odd spreadsheet. This kind of process tends to reinforce team silos, and work tends to be reactive rather than proactive.

 

There’s also a whole series of elements of the app development and testing process that could be re-used, increasing overall speed and quality. Without some form of automation, it’s difficult to have visibility of these assets, while repeatability and reporting are virtually impossible.

 

Getting uninhibited

Given that organisations are using technology to drive business agility for differentiation, for operational efficiency and for better customer service, getting apps delivered at the right level of quality and in a sensible timeframe is critical. IT is the business now. Tools are available across the whole design, development, quality and release cycles, all aimed at ensuring the optimum balance between quality and velocity.

 

The biggest and most difficult challenge, however, is moving the team from their comfortable process to a new, more iterative way of doing things. As noted in an article by Forrester, “It is also important to realise that you can lead a team to Agile, but culture can stop it dead in its tracks. Culture can propel or kill new ideas.”

 

To address all of these challenges, it’s important to handle the move to an iterative system as a project in its own right. This must be supported by a careful change management process so that team members are brought along, together with the supporting tools. With this approach, high quality with velocity is achievable.

 

You can find out how we are helping organisations to balance unprecedented velocity and uncompromised quality with HP Software’s Application Delivery Management tools by reading “Announcing Apps 12! Now you can balance unprecedented velocity and uncompromised quality.”

 

How uninhibited are you?

  • Do you already use automation extensively in your development processes?
  • How easy is it for you to perform comprehensive and full-scale testing?
  • How repeatable are your practices?
  • Do all members of your team have full visibility of the project?

Next time I’ll be examining the wisdom of worms—and how they foretold the development of IT security over time. Now that’s got you thinking…

 

For more insightful articles about app dev and critical trends in enterprise software, sign up for the Discover Performance e-newsletter.

 

AC.jpgRelated links:

Big Data, dark data and the Internet of Things: Making sense of the data deluge

2014: A game changing year for IT

Keeping the lights on in a competitive world

 

Alastair Corbett leads HP’s UK&I Software Business Unit and has responsibility for its strategy, the promotion and selling of the IT Performance Suite and related services. Prior to this role, Alastair was responsible for defining the new sales strategy and go-to Market models for Worldwide Software Sales, and before that, he successfully led the Worldwide Services Operations team for HP Software. Alastair joined HP from Peregrine as a result of the acquisition in 2005, where he held the role of VP International Operations and was responsible for all Finance and Operations activities in EMEA and APJ. He also led the integration activity for EMEA, as well as leading the Sales Operations function. Follow him on Twitter: @CorbettAlastair.

Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the Community Guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Search
Showing results for 
Search instead for 
Do you mean 
About the Author
This account is for guest bloggers. The blog post will identify the blogger.
Featured


Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.