Testing Services provides a platform for QA professionals to discuss and gain insights in to the business value delivered by testing, the best practices and processes that drive it and the emergence of new technologies that will shape the future of this profession.

« November 2011 | Main | January 2012 »

December 14, 2011

Testing for cloud security- What is the infrastructure focus of QA teams (Part 1/3)

One of the biggest barriers to cloud adoption is security concerns. Any enterprise that wants to migrate on to cloud based environments needs to ensure comprehensive cloud testing, encompassing infrastructure, software and the platform, in order to validate the security of the cloud, cloud related application and data.  I believe that cloud adoption is a radical change for any enterprise to make and the move from physical to virtual accessibilities poses several challenges from a security standpoint. To start, let us take a look at what security testing would need to focus on at an infrastructure level, since this is the first step on the path towards successful cloud adoption.


Any enterprise subscribing to the cloud cannot completely depend on the cloud service provider's contract for the security of the cloud infrastructure, the QA teams would also be needed to validate the security of the cloud from the infrastructure layer itself. Once the desired computing power is allocated along with the software, QA teams need to scan cloud instances for existing security vulnerabilities, malware and threats. This would help detect security flaws such as unpatched operating systems at the infrastructure layer.  Also, it's important to check if there are adequate security measures in place like user access control, privilege based access and security policies for governing the QA infrastructure itself. Lastly, the encryption of cloud instances need to be validated since there are security threats involved with recovering previously deleted data in case of unencrypted cloud instances.

December 13, 2011

What to expect from Test Automation of Oracle Applications?

I just finished putting together a response for a client trying to understand the value of automation during testing of Oracle Applications. Essentially the client was trying to evaluate whether automation is a worthwhile investment and evaluate the returns expected. I figured this topic to be a subject of much discussion, given widespread implementation of Oracle Applications.

Here are a few points one might want to keep in mind while considering functional automation in their strategy to test the implementation of your Oracle Applications

  • Level of Customization: In a plain vanilla implementation more than 85% of the testing can be automated. As the customization of the Oracle packages increases, the extent to which automation can and should be implemented drops significantly. Customizations are in the form of RICEF components - Reports, Interfaces, Configurations, Extensions and Forms. As such they are not natural candidates for automation and limit automation feasibility.

  • Maintenance of test scripts: As part of application/ IT maintenance, constant changes are made to the customizations. Attempts to keep automation suites up to date can prove expensive than initially thought to be. The size of the maintenance test case repository is also decided by the cost of maintaining the repository itself. At times it may make financial sense to limit the size of the automation suite.
  • Test Data: One of the prime reasons to consider automation of packaged applications is the presence of "Global Processes" which are tested across multiple countries/entities. Automation test scripts created once for global processes are executed for several countries. Availability of test data specific to each country eventually determines the automation coverage.
  • Test types for automation: Automation of System Testing type test cases are easier but lesser return on investment when compared to automation of System Integration type flows, which are uneconomical but provide higher returns.
  • Extent of Reuse: It helps if the automation team is aware of and can identify country specific deviations or rather the common elements across countries. This information can lead to increased reuse during automation of country specific test scenarios.
  • Granularity of test cases: Test cases written to cover business processes are more effective to automate than those written at a more granular level. It is so not only because they simulate real life scenarios better but also because they help enhance test coverage

Paying close attention to the above mentioned points will definitely help you gauge what to expect from your automation endeavors. 

December 6, 2011

Looking for the First Step on the Cloud Adoption Path?- Cloud Based QA Environment

Some of the prime features of cloud such as on demand provisioning, elasticity, resource sharing, constant availability and security help address a lot of challenges related to QA environments; such as poor utilization of environments, unavailability, lack of environment oriented skill sets, budgets constraints for QA infrastructure setup and multi-vendor coordination situations. Overcoming these challenges with the cloud helps improve the efficiency of the QA teams which eventually has a positive impact on an organization's business outcome, with higher quality of applications at lower risks.


I believe that QA environment is the perfect place for an organization to begin its cloud journey before actually moving live applications on the cloud. By moving the QA environment to the cloud, organizations can see immediate advantages such as increased asset utilization, reduced proliferation, greater agility in servicing requests and faster release cycle times.


To find out more about the detailed benefits associated with Cloud based QA environments...read my latest POV at http://www.infosys.com/IT-services/independent-validation-testing-services/white-papers/Documents/begin-cloud-adoption.pdf. Do share your comments and feedback, I look forward to them.