Tag Archives: testing

Testing Requires Its Own Transformation

As new technologies like mobile are used and the need for agility and speed rises, so does the need for new testing techniques; otherwise, testing will hold implementations and organizations back. Just as today’s systems are modernizing, new testing methods and tools are rapidly advancing the quality and speed of development and implementation.

To assess the current state of testing and reassess the need for insurance-specific testing, Majesco recently reviewed modern testing processes. What we found makes a case for modernizing enterprise-wide testing.

Moving from static to dynamic

Insurers need to have core systems that will be able to add capabilities, products, workflows and more through configuration. They will need an overall approach to system quality that will allow for continuous updates. Robustness and stability will need to be tested to bolster quality assurance (QA), and a whole new world of testing will arise to cover the various software areas that will be added to the enterprise. Not only will testing needs grow, but also a dynamic framework for understanding enterprise-wide testing will be mandatory.

See also: Baseline Testing Provides a Win

Minimizing risk

Many organizations are worried about the risks involved in transformation and their inability to have clarity around operations, development, migration and the investments involved. Insurers are realizing that they need a well-designed QA process. Three key components are coming to light:

  • Previously tried-and-true approaches are no longer best practices in testing. (For example, the waterfall approach to development and testing will no longer provide the results needed.)
  • A single testing partner with a framework and methodology and domain expertise is vital.
  • The end goal is to employ a single platform that works with a variety of approaches and tools in a way that enables agility and speed.

Reaping the benefits

As digital enhancements grow and system touchpoints and channels are on the rise, test types are also becoming broader. Manual testing is still needed. Automated testing is more frequently employed. Performance testing and digital testing are more important than ever. To cover all types of testing, insurers need an automation framework that is structured, simplified and process-based. They need a system that “learns” and provides long-term efficiency by allowing for the repeatability of tests while increasing the speed with which tests can be executed.

See also: Inventing Your Future: A 3 X 3 Approach

A modern testing framework will give insurers prompt developer feedback and will support agile development. Testers will have the capability to build automation in parallel to application development. They will give users the ability to conduct continuous and recurring regression tests. Business analysts will be able to get more involved in testing. Scriptless automation techniques will provide business users with their own test automation capabilities. These are just a few of the ways that a modern testing platform will bring insurers into the future and give them a competitive edge.

To dig more deeply into the benefits of expert testing in the transformation process and beyond, download Majesco’s recently released white paper, Putting Insurance Testing to the Test. In addition to Majesco’s testing overview, supplemented with industry perspectives from the research firm Novarica, readers will find a valuable example of an agile-friendly test automation approach as well as a helpful list of distinct service elements that should be taken into consideration when picking an IT testing partner.

This article was written by Dan Mets.

Why Pilot Projects Can Be Catastrophic

Many companies think they are staying nimble during product innovation by setting up pilot projects to validate concepts before they’re rolled out at scale. But pilots aren’t the answer, either, at least not on their own.

Once something gets anointed as a “pilot,” it’s no longer an option—it’s the destination. There are typically no graceful ways to kill a pilot, and even course corrections are too hard to make. Systems such as software have all been done at the production level, with the assumption that the pilot will work and will need to be quickly rolled out at scale. Changes are seen as a sign of defeat, and digging into production code can be complicated.

Besides, problems at the pilot stage often get hidden. A pilot is very public, and some senior people have a strong interest in success, so they may work behind the scenes and use their connections to make it successful.

I once watched a client be all over a pilot in a single state, so thoroughly covering the pilot with senior-management attention that the client learned little before initiating a national roll-out. The executives knew what they were doing, but they couldn’t help themselves. They were so invested in the success of the pilot.

The solution is to rephrase the issue. There needs to be less planning and more testing. The only way to accomplish that is to defer the pilot stage and stay in the prototyping phase much longer than most companies do.

The difference between a prototype and a pilot is that there’s no possibility or expectation that a prototype will turn into the final version of the product or service. Prototypes are just tests to explore key questions, such as whether the technology will work, whether the product concept will meet customer needs or whether customers will prefer it over the competitive alternatives.

The early prototypes should be all chewing gum and baling wire. They shouldn’t have hardened processes or the people required to go live. Yet they should provide real insight that informs further development. Each stage of prototyping should minimize costs and maximize flexibility. To borrow a term from computer programming, new products and services should be explored using “late binding”; they should take final form as late as possible, based on the most up-to-date learnings that can be generated.

Pixar has made a religion of prototyping through what the company calls “story reels.” The company doesn’t just write a script; it creates storyboards that provide a sort of comic-book version of a prospective movie, then adds dialogue and music. The story reels cost almost nothing, compared with the fully animated versions of Pixar’s movies, yet provide a great sense of how a story will flow and allow for problems to be spotted. The story reels can also be changed easily.

Here’s a fascinating video in which the creators of Toy Story describe their storyboarding process:

https://www.youtube.com/watch?v=QOeaC8kcxH0#action=share

Every regular review of progress on the prototypes should begin with a demo, much like what Pixar does with its storyboards. My old friend Gordon Bell, who designed the first minicomputer while at Digital Equipment, likes to say that “one demo is worth a thousand pages of a business plan,” and that notion applies to every stage of prototyping. It’s easy to get lost in talk of value propositions, competencies and market segments. A demo makes an idea tangible in a way that no business plan ever will.

At Charles Schwab, in the lead-in to the company’s great, early successes with the Internet, executives talked about a hamster on a wheel. Schwab would test potential services by having people working behind the scenes answering questions, looking up information, and so on, running just as fast as their little (metaphorical) legs could go. Anything that didn’t work or didn’t resonate with customers was easily set aside. Only once Schwab had a sense of what customers truly wanted would it start building the capabilities into software.

Prototypes and demos are part of what has made Apple products so successful. Steve Jobs always used prototypes of products to drive his thinking. For example, early in the process of figuring out the right screen size for the iPad, Jobs had Jonathan Ive make 20 models in slightly varying sizes. These were laid out on a table in Ive’s design studio, and the two men and their fellow designers would play with the models. “That’s how we nailed what the screen size was,” Ive told Walter Isaacson in his biography of Jobs.

Admittedly, it helps when you have a genius like Jobs playing with the devices, but even he couldn’t envision everything. He needed many alternatives of something tangible. As Isaacson quoted him as saying, “You have to show me some stuff, and I’ll know it when I see it.”

If Steve Jobs thought it was critical to prototype, shouldn’t you?