A cloud on the horizon: How Cloud Computing will change requirements management and testing

This article originally appeared on Konsultbolag1

All around the world, the media is abuzz about the arrival of the “cloud” – the ‘place’ where the systems and services we use daily will be found in the future. However, not everyone is clear on exactly what cloud computing is, much less how it will affect those of us who work in the field of requirements management and testing. This article will explain how the cloud will change our everyday lives, so get prepared for its arrival.

What is “Cloud Computing”?

To understand how the cloud will transform our working lives, you need to understand what said “Cloud” is. Unfortunately, there’s no simple answer, because the concept encompasses many others, such as:

• Software as a Service, or SaaS
• Platform as a Service, or PaaS (a development platform as a service for development of cloud services)
• Infrastructure as a Service, or IaaS

The term “cloud” covers all the areas above, and even more that are used more rarely, at least presently

Development environments for cloud services

The past few years have seen the introduction of cloud-based development tools for the development of new cloud services, an example of which is Salesforce’s Force.com, in which one can build cloud services which run within their operating environment. There are countless other cloud-based development tools, including Windows Azure, Google App Engine and Amazon Web Services, and which are all examples of PaaS.

Developers who use PaaS tools don’t have to worry about the production environment’s hardware, networks or operating systems, so they can develop new features and apps in a lot less time. That also means that requirements gathering and testing teams can see prototypes much faster. Developers don’t need worry about scalability, since PaaS takes care of that, too. Whenever your app needs more processing power, the PaaS provider’s data center can provide it instantaneously.

This is not to say that PaaS is not without its downsides. Foremost is that you don’t have complete control over your information, since the company providing the platform has both the data and the service in its ‘possession’. The data may not be stored in the country where the customer has its operations, which may be a legal problem or create security issues (real or perceived). Shorter development times can give the customer the expectation that requirements and testing work will be sped up in a similar way, which is not necessarily the case as the total lead time might end up being the same, due to increased time for requirements and testing work.

Requirements management for cloud services

A customer who wants a new cloud service has three main approaches to choose from:

• Subscribing to an existing SaaS service in the cloud.
• Developing the cloud service in-house using a PaaS development environment.
• Outsourcing development of the cloud service using a PaaS development environment.

Requirements work will be much the same with a SaaS subscription as it would be by purchasing a COTS (commercial off the shelf) system.

However, there are some clear differences. Just like when buying a COTS system, you need requirements that define the functions the system needs to have. The difference is that you don’t need to specify requirements for the environment, version control, or other similar features since the service won’t be running in your environment.

Although you’re a client, you have very little or no say in when a new version of the service gets installed, and the company providing the service will do what their own needs dictate, whether it suits you or not. Likewise, you have little or no control over where they host the service. If your business needs to have control over the physical location of your data or software, you should stipulate that in the requirements and base your choice of provider on it.

For services that you develop through PaaS, it’s slightly easier to define the requirements for where information is stored and maintained, since some PaaS providers let you choose whether to use your company’s own “cloud” or the global “cloud”.

When you develop services with PaaS, you have to write more detailed requirements about what needs to be developed than you would when using a subscription service. Since development proceeds faster in PaaS than in a traditional environment, you can take advantage of prototyping to a much greater degree. Prototypes are always good for gathering requirements, but in PaaS, they become one of your most important tools – both to gather requirements and to have the opportunity to test at an earlier stage.

If you’re buying cloud services, you need to give special consideration to which PaaS you want the developers to use. If you don’t make an explicit choice, you may end up with custom-made services that all reside in the various providers’ own clouds, so you have to specify in which “clouds” your services are allowed to live if you want them all in one place. This is usually a minor problem if you do your development in-house, assuming your company has settled on a standard PaaS option. When you choose a PaaS provider, you should also specify uptime/availability requirements, performance, and security – all of which are known for any given PaaS provider, and which should guide your supplier selection.

With an external provider, you also have to specify what will happen to your cloud data and service in the event that your PaaS provider is acquired or goes bankrupt. Look for a supplier with an escrow plan that ensures they can continue operations for a given time period after bankruptcy. ‘Escrow’ is storing your source code with a legal representative or equivalent entity. If the supplier has an escrow agreement, customers retain access to their source code and can continue development on their own if the supplier goes bankrupt.

You should also ensure that you own your information, not the supplier or its creditors. Every major PaaS provider has an insurance policy in its contracts, but if you choose another supplier, you should take extra care to ensure that your assets are protected. Review the contract and ask tough questions!

Testing in cloud-based development

Just as in requirements management, the most obvious differences in cloud-based testing depend on whether you are testing existing services or custom-developed ones.

When testing custom-developed cloud services, you have all the opportunity in the world to test the service thoroughly. You can test prototypes to verify general solutions and specific functionality. Since development times are much shorter in cloud-based development, you may need to adjust your test plan.

To ensure you set aside enough time for testing, you should begin testing work as early as possible, and an easy way to get started is by testing using the prototypes generated in requirements gathering. One way of doing so is by putting users in front of the prototypes to ensure that they understand how they’re expected to perform a required task.

Agile methodologies will make your work easier throughout development, and in testing, Exploratory Testing techniques come in handy. Exploratory Testing helps you learn while you test, and is a natural consequence of using prototypes for testing your new service. Another alternative is to write your cloud-based services using test-driven development.

If you’re subscribing to a finished SaaS application, a trial subscription is the only way you can conduct a “proof of concept” test, which can be thought of as an acceptance test. The point of the trial is to ensure that cloud service meets your company’s operational needs.

If your prospective provider won’t allow you to trial the service free of charge, it will be impossible for you to know what you’re buying – which itself constitutes a form of acceptance test that the stubborn supplier has failed. If they won’t let you thoroughly test the service in advance, the supplier probably won’t be responsive to your customer needs in the future, either.

Next steps

Start thinking about how the “cloud” affects requirements and testing work for your organization.