Do You Need to Test Your Cloud Applications?

Software accessed via the "Cloud" is a deployment model that provides access to software remotely. It may also be referred to simply as SaaS or as hosted applications. Since the software is vendor-hosted remotely, it removes the need for organizations to program, install, buy a lot of hardware for and regularly maintain the software. Even though the implementation is a cloud-based, do you still to test the software? Yes, and here's why...

Risk Management
Testing verifies that the software and its delivery meet all of your requirements including functional, performance, security, integration and so on. This verification is done to ensure that you, along with the cloud vendor, have implemented the system correctly and as expected. In addition, testing validates that the system is what the user needs. In the end, validation is performed to help with risk management.

Meets User Needs

Functional testing is the most apparent tool you will have to validate that the product meets your corporate needs. The requirements are the foundation in effective functional testing. Using the original requirements, you can plan and manage tests that are focused on your specific business and user functional needs. Involve the user, either by them directly performing the tests or have them review and sign-off on the test results.

Performance Meets Service Level Agreement (SLA)

Load and Stress testing are a methods used to simulate real life scenario of a given system. It involves testing in real time beyond normal operational capacity in order to observe the results. Have anticipated metrics in place (e.g. maximum number of simultaneous users/connections, number of transaction per second, internet throughput, etc.). Then, measure your test results against the agreed upon performance. Work with the vendor to optimize performance that does not meet your specifications.

Meet's Security Requirements

Mitigating eternal security threats is a huge concern with cloud based software applications. You will rely on the security measures put in place by the vendor, which are largely outside of your control. You need to validate that the product meets the same password change control and user level security that your organization has set for itself. In addition, you need to continually monitor that the vendor is adhering to its own security protection (virus and malware protection, etc.). The level and types of security that you expect from the vendor must be put in the SLA and reviewed regularly by you.

Data Integration with Other Systems

If one of your requirements is data integration with other systems within your inventory, you need to validate that the input and/or output work as agreed. Don't assume that when cloud-based applications use standard data interface files (e.g. CSV, XML, etc.) that the field formats delivered will match those of the other systems. Testing of standard files must be done with the same level of diligence as for or custom interfaces. If you requested custom interface files for your implementation, be sure your contract with the vendor specifies that they will maintain the interface format for as long as you are a customer, and not just the length of the current contract.

David Schuchman

Not Everything that is Important is Actually Urgent

Some tasks and projects require more urgency than others. However, if we consider everything to be urgent, we clog our work queue and confuse trivialities with important priorities. Sometimes the challenge we face as a manager is to distinguish between what is actually urgent and what is not. Consider these tips to help you determine what truly is urgent.

Don’t assume that “Urgent” means “Immediately”

Explore with the person that made the request of you what they are really trying to accomplish and when it’s actually needed. Sometimes the sense of urgency is just a way of conveying a person’s importance and power, or even a reflection of personal anxiety. Giving that person a little bit of your time before starting on their request may be sufficient for them to be assured you understand their request and its urgency. Then, you will have the opportunity to determine when you will actually need to address the request.

Distinguish between an urgent crisis and an urgent request

There are times when people making a request have issues that need to be resolved right away, and diving in immediately is the right thing to do. But depending on your business, this may actually be the exception rather than the norm. Probe the person that made the request of you about what would happen if you got back to them in a couple of days or the next week. Often, as long as you commit to a specific completion time, that will be sufficient.

Be prepared to say "No"

Good customer service doesn’t necessarily mean doing everything that the person requests. More importantly it means doing what is best for them, even when they may not realize it. Talk through the implications and outcomes of what the requester is asking for and make sure it’s the right thing to do. Explain your reason why in order to get them to understand and agree.


The PICK chart illustrated at the top of this post is a tool used for organizing and categorizing process improvement ideas in a Lean Six Sigma project. The acronym stands for Possible, Implement, Challenge, Kill.

David Schuchman