Always at the cutting edge of IT, Silicon Valley in California is now the epicentre for using the cloud for load and performance testing for today’s Web and mobile world. SOASTA’s Fred Beringer reports.

The Internet has revolutionized the way we conduct business, consume information and interact with each other. For some businesses, the Internet has become the primary source of revenue and the main customer-facing outlet for communicating, advertising and brand management. Applications have become an aggregation of content, information, data, and media, while the architecture has become more complex, and more dependent on external third parties. The Web and the mobile Web have forever changed the application landscape requiring a new emphasis on load and performance testing.

These changes can be seen everywhere today. Massive amounts of data are being stored and accessed, and online applications have to adapt to this growth. In parallel, the behaviour of Internet users is becoming increasingly event-driven. Applications will often need to serve a much larger than normal customer base for perhaps a few weeks or sometimes just a few critical hours. We’re seeing an increasing unpredictability in traffic patterns as social media outlets, such as Facebook and Twitter, can drive more traffic to a web site than it’s prepared to handle. A company will spend millions of dollars creating engaging content and running promotional campaigns to draw users to its site. But if the site crashes, or response time crawls, all that energy and money will be wasted. Even public perception of the company could be seriously downgraded.

This unpredictability must be taken into consideration when shaping up a performance testing strategy.

Four key requirements for effective performance testing

1. Scale: The test must simulate a realistic volume of user traffic. Optimally, simulating at minimum the average number of users expected to use the application on a daily basis. But not only the average! There is also a need to test for unexpected traffic spikes. If the web site or application is accessed from all parts of the world, the test must replicate global traffic. Businesses need to understand the local performance of their website, as some parts of the world might generate more revenue than others. In general, they want to optimise some of those high revenue locations.

To generate a high volume of concurrent users with traditional performance testing tools requires a substantial investment in hardware. To reduce costs, often the testing is diverted to a small subset of the production environment. Tests are done on a small scale and the results are extrapolated to peak production numbers. This is problematic for a number of reasons. The lab is significantly different from production in terms of hardware, scale, configuration, and activity at any given time (batch jobs, shared services, etc). Perhaps more critical is the fact that real users come from outside of the firewall where latency is an important factor in the customer experience.

While important for extracting some type of results, testing in the lab cannot answer questions about production performance or capacity with a high degree of accuracy and confidence.

2. Speed: Websites can change every day, and even hourly for the largest e-commerce outlets, and all have an effect on performance. Software development builds happen multiple times per day, releases to customers happen frequently and the rate of change is high. Without agile test practices and the right tools, applications may leave development without being tested, or worse, the testing itself will slow down the release process. All processes and tools need to be able to adapt to this fast paced software development lifecycle.

Lack of speed and reactivity is the main inhibitor to agility.

3. Real-time results for actionable intelligence: The first objective of performance testing is to gather relevant data from every component involved in the overall performance the application under test. This is raw and dumb data.

A performance test will end up with LOTS of data, easily generating terabytes of data. But it’s USELESS data if there is no mechanism to transform the data into actionable information. In order to deal with this “big data” problem, results need to be aggregated and displayed in real-time. Performance engineers want to be able to answer questions such as:

•              What is the relationship between the number of virtual users and the memory consumed by the application server?

•              How much server capacity is left with when reaching 10,000 concurrent users during the test?

•              What is the correlation between the numbers of process counts on the database server and the overall throughput?

•              At what stage during the test is there a drop in overall response time? Is it possible to correlate this drop with other data to understand this behaviour?

•              What is the correlation between an increase in response time and the number of errors coming from the SSL Server?

•              Why is 90 percent of response time for the overall homepage taken by this particular file? Where does it come from? Why does it take longer than the other page assets?

Traditional performance testing approaches have always struggled with analytics. To combine, aggregate, and correlate these performance results requires high computing power. Performance engineers are typically left doing their analysis offline and manually with a high potential for human error and ultimately low confidence with the result.

4. Cost: This is a key inhibitor for performance testing excellence. Initial hardware investment is very high, as is the subsequent maintenance cost. Testing organisations have to deal with memory and CPU upgrades, and operating system and disk maintenance. Investment in dedicated and skilled IT people to handle the environment is not cheap. Plus three years after the initial investment, hardware is obsolete, and the requirement for load has become so much higher.

What’s the answer?

Cloud testing – performance testing for today’s world

Cloud testing was born based on cloud computing’s promises, and today means a fast, scalable and affordable approach to test web or mobile applications using cloud computing

Specifically, leveraging the Cloud to do this type of testing yields a number of benefits:

•              Tests can be achieved at a level only observed on production systems. Typically companies will want to test at 100 percent of typical traffic levels but cloud testing allows them to test at 150, 300, 500 percent! Using cloud resources, they’re able to generate from hundreds to millions of users.

•              It is possible to generate a realistic and geographically dispersed load. Today’s online world requires real-world traffic.

•              It is possible to test both inside and outside the firewall, which brings the most efficient and effective results.

•              The cost of tests is definitely lower because businesses can rent the hardware and only pay for actual usage.

•              It allows testers to respond to fast development cycle times by making agile performance testing a reality.

•              For the first time, performance tests can run in production. This is the only way to gain full confidence in the application.

Continuity between testing in the performance lab, in a staging environment and in production

Historically, because of scale and lack of real-time results, companies were always testing at a fraction of the expected load in a dedicated performance lab, and then extrapolating results to gain confidence that their live site would be able to handle the load. Not a very good practice, but they had no other choice. They have an alternative today as cloud testing brings them everything they need to test in production.

Scale introduces the potential for chaos. The number of elements, from hardware to software to network, that can impact performance grows exponentially as an application scales and the inter-dependencies between the various components grow increasingly complex. Testing at scale and in production requires an infrastructure to support the traffic, a means to manage the deployment and execution of the test, and analytics that can massage the massive amounts of data and deliver actionable information. Of course, performance engineers with the experience to navigate through complex environments are required as well.

Testing in the performance lab

Ongoing performance testing in a lab allows engineering teams to assess performance degradation or improvement over time, and helps catch any show-stopping performance bugs before they reach production. The issues found are inherent to the application itself such as:

•              Memory leaks;

•              Inefficient database schema or queries;

•              Garbage collection issues;

•              Bad CPU consumption;

•              Slow pages.

Tests in the lab are absolutely necessary and don’t require a large load to identify issues and bottlenecks within the application itself.

Testing in a staging environment

A staging environment brings you closer to production-like circumstances and allows you to perform important tests such as verifying capacity, establishing correct configuration, stressing available resources and verifying performance expectations.

The issues you’ll find and fix are a level higher and cross the application and the infrastructure. It will allow you to find issues such as:

•              Bad configuration settings;

•              Slow third-party plug-ins;

•              Auto-scaling failures;

•              Security bottlenecks;

•              Inadequate server resources;

•              Low database thread counts.

There are still limitations such as availability of the environment and exclusion of key components, but it tests closer to full scale.

Testing in production

Testing in production is the best way to get a true picture of capacity and performance in the real world. Testing in production is the only way to ensure that online applications will perform as expected and certify them in normal and extreme conditions by testing them beyond expected limits. There are many issues you will catch that cannot be found when testing in a lab or in a staging environment:

•              Latency between systems;

•              Bad network configuration;

•              Low network bandwidth;

•              Bad load balancer configuration settings;

•              Firewall max capacity;

•              Bad CDN file placement;

•              Wrong DNS routing;

•              Unbalanced web servers;

•              The effect of batch jobs running in the background.

Cloud testing is meant for the agile world

Performance engineering organisations have struggled in the past due to the inertia created by their dependence on a fixed hardware environment. It is difficult to rapidly deploy a reasonable number of servers. Without real-time results, it’s impossible to provide quick turn-around of information. Cloud testing changes the game because it is so flexible, scalable and adaptable that you can run your tests for every build, every change in your store inventory, every change in your operational infrastructure, at any time, at any scale.

Test performance through the whole application life cycle

All the various types of performance tests are feasible and they can be run in the development stage where low volume testing is needed, all the way to production at full scale. Here are just a few types that you can run:

Baseline: the most common type of performance test. Its purpose is to achieve a certain level of peak load on a pre-defined ramp-up and sustain it while meeting a set of success criteria – usually acceptable response times with no errors.

Spike: simulates steeper ramps of load, and is critical to ensuring that an application can withstand unplanned surges in traffic, such as users flooding into a site after a commercial or email campaign. A spike test might ramp to the baseline peak load in half of the time, or you may initiate a spike in the middle of steady state of load.

Endurance: helps ensure that there are no memory leaks or stability problems over time. These types of tests typically ramp up to baseline load levels, and then run for anywhere from two hours to 72 hours to assess stability over time.

Failure: ramps up to peak load while the team simulates the failure of critical components such as the web, application, and database tiers. A typical failure scenario would be to ramp up to a certain load level, say 25,000 concurrent users, and while at steady state the team would pull a network cable out of a database server to simulate one node failing over to the other. This would ensure that failover took place, and would measure the customer experience during the event.

Stress: finds the breaking point for each individual tier of the application, or for isolated pieces of functionality. A stress test may focus on hitting only the home page until the breaking point is observed, or it may focus on having concurrent users logging in as often as possible to discover the tipping point of the login code.

Diagnostic: designed to troubleshoot a specific issue or code change. These tests typically use a specially designed scenario outside of the normal library of test scripts to hit an area of the application under load and reproduce an issue, or verify issue resolution.

Real-time performance analysis

Not only does cloud computing help generate load, it also brings enough computer power to be able to compute performance results in real-time. By receiving, absorbing and understanding the data, it is possible to make decisions and take actions. For example, if the environment is experiencing a surge of traffic going into one web server, the performance engineer is able to see the full performance picture coming not only from the application but also from the whole infrastructure. He is able to identify quickly any bottlenecks. In that particular case, it could be a misconfiguration in a load balancer sending too much traffic to one particular web server.

Continuous performance testing

One of the challenges with continuous testing, whether it is for functional or performance testing, is to have a suitable environment of the right size, ready to run tests at all times. The investment is difficult to justify. Tests won’t consume 100 percent of the hardware capacity, and spare cycles are difficult to use for other purposes as the environment needs to remain clean. Cloud computing offers a fresh environment every time a test is run. As soon as the setup is performed there is no need to worry about it for a very long time!

Test from all locations

Relying on a central data centre to generate load doesn’t account for true global traffic. Leveraging a grid provided by a cloud computing vendor with a global presence reflects global deployment. If the application is accessed from the US, Europe and Asia, generation of user load coming from all these locations will give a true and realistic picture of performance. This is an increasingly important factor for companies doing business on the Internet, as they want to understand the impact of distributed traffic on their application.

Encourage collaboration between teams

The fact that organisations are able to get results in real-time and take action, allows the test to be run in a very collaboratively way. Imagine having developers, testers, DBAs, IT people, all in the same room watching a test run, being able to discuss results, and making changes in real time. That’s the real way of doing performance testing.

With traditional performance testing, companies had to wait days to get a fairly accurate picture of the application’s performance. There was a gap in the discussion. And the usual question from developers or operation people was: “Go run the test again, it can’t be right.” By having a way to test and get results in real-time, the discussion keeps going. DBAs can make changes to their database queues on the fly, IT can make change to their load balancer in real-time as the test is running. Real-time results are conversation enablers, which is the cornerstone of any Agile organisation.

Fred Beringer

Vice president business development

SOASTA

www.soasta.com

CITE will reflect an ordinary mid-sized American city including urban, suburban and rural areas with all the necessary roads, buildings, water, telecommunications and operating systems required. It will cover 15 square miles with the initial investment of around $400m (£249m) expected to rise to $1bn. Pegasus expects the project to create 350 new direct jobs and around 3,500 indirect jobs in the region. Building work is expected to start on june 30 this year.

The city will be used to run large-scale tests on new technology well away from the general public . Projects so far mooted include next generation wireless networks, which can be tested and assessed without monopolising the public’s valuable bandwidth, and self-driving cars… The reasons for testing them well away from the public don’t need explaining!

There was no information about whether – or indeed how many – software testers would be needed for the project, but we aren’t predicting a software testers’ gold rush just yet.

Matt Bailey

Editor

The TLS security protocol is the current Internet standard for encrypting and authenticating application traffic. TLS is used by millions of people every day in online banking, e-commerce, email, and Voice-over-IP applications. The OpenSSL is an open-source implementation of TLS and is employed in standard operating systems, web browsers, email clients, and network devices ranging from WiFi access points and DSL modems to industrial-strength core routers.

“Cloud-based security testing is the future of outsourced penetration tests, and this is clear proof of the success of Fuzz-o-Matic”, said Antti Häyrynen, senior security reseacher and the lead developer of the Fuzz-o-Matic platform.

OpenSSL team issued acknowledgements to Codenomicon for discovering this issue using Fuzz-o-Matic fuzzing as a service testing platform.

Fuzz-o-Matic is a platform that can run both Codenomicon Defensics and a wide range of other fuzzing tools and platforms available in the industry. The users of Fuzz-o-Matic upload their software to the cloud-based service, where the leading experts of the industry choose and configure all tools and start the tests. Fuzz-o-Matic customers will get email notifications on all found vulnerabilities, and can login into the system to download test results.

It goes without saying that society as it is these days is heavily dependent upon the current IT infrastructure and IT in general. Large networks such as the internet and all the interconnected devices forming these became part of the critical infrastructure, on which even lives are dependent. Not surprisingly, security has been a big point for decades.

Traditionally, the focus of IT security has been on protecting the network infrastructure and the operating system itself, on a kernel level that is. Attackers would try to inject their own messages in lower level protocol communication or initiate these themselves, and thus effectively ‘control’ the network traffic.

A game changer was the introduction of cryptography in the 90s, which could now provide data confidentiality, data integrity, and authentication. Basic security was hereby provided by the network and transport layer of the OSI model, and later by the application layer though the use of SSL/TLS.

Introducing the web applications

However, the global internet made rapid growth in both size and technological perspective and was not just used for exchanging data anymore, but now offering services through web-based applications. A browser engine will use client side technologies such as (D)HTML, Java, JavaScript, Flash, Silverlight to render static content and on the webserver server side technologies like ASP, ASP.NET, CGI, ColdFusion, JSP/Java, PHP, Perl, Python and so on will be used to render dynamic content and perform tasks a normal desktop application would do as well.

Modern web applications store, edit and retrieve dynamic content, and use databases and/or fileservers for these purposes. A browser sends the request to the server side technology in use, the application processes it, queries a database and if needed returns information to the end user. Large web applications usually consist out of multiple webservers, database clusters, web application firewalls and interact with huge data storage facilities.

New attack vector

After years of extensive testing the network infrastructure and the devices connected to these have become more resilient to lower protocol attacks, and it requires more resources to find new vulnerabilities. The focus has shifted towards the application layer, which has proven to be a very effective attack vector in recent times. Desktop applications have been the target for a long time, but it seems as if web applications have taken over the stick.

Web applications inherit the same weaknesses as desktop applications, the effects bad coding practices can have need no further explanation. However, a whole new range of possible attack vectors have been introduced. Normally the handling of sessions between users are serviced by the operation system, but in the case of web application these have to be initiated and destroyed by the server side technology in use. The same goes for authentication to services, in web applications usually done against databases or services similar to LDAP.

One of the reasons for the immense popularity of web applications as a target among attackers is the fact that these are usually permanently online and reachable from any computer connected to the Internet. The servers which these applications run on and talk to are not uncommonly connected to internal networks, and thus an easy way to evade firewalls, IDSs and IPSs. Traffic originating from webservers towards a database server is usually trusted, since it’s assumed to be controlled by the web application.

Web application vulnerabilities

Numerous articles have been written about typical web application vulnerabilities, such as code injection techniques. In SQL injection, for example, an attacker would try to input SQL statements in a web form to have the web application perform operations on the database other than the ones intended by the designer. Another example is cross-site scripting, which allows attackers to bypass client-side security mechanisms normally imposed on web content by modern web browsers and thus directly attack another user of the same application by stealing session cookies, or performing operations in the name of the victim, more commonly known as cross-site request forgery.

These techniques are built upon knowledge of client and server side technologies in use, and exploit known flaws in application logic.

Fuzz testing web applications

Research conducted in our labs has shown that it is time to take a step back and look at web applications for what they actually are: just applications with an interface to the Internet. While it is very important to perform static code analysis and traditional web application pen testing to root out any known flaws, new vulnerabilities will never be found by these tools and techniques. To root out unknown bugs, we have found that fuzzing does the job.

Contrary to traditional web application penetration testing, fuzz testing is not aware (and does not care much) for application logic, and does not try to exploit any known vulnerabilities. It just feeds the system with malformed input to find abnormal responses that indicate a possibly exploitable vulnerability in software.

Fuzzing web application has proven to be much harder than traditional robustness testing which we have been conducting for more than ten years. Instead of just one attack interface which we target using one protocol, we now face multiple interfaces with an almost infinite combination of client and server side technologies used, talking to a very wide variety of databases and file servers all using their own specific (query) language

What to fuzz?

The first challenge when fuzzing a web application is to decide what to fuzz. Since there is no specification or existing model of the messages used by the application, each session will be different depending upon how the user interacts with the application. What we can do is record a session using a browser, and base our models on the message sequences found therein. These messages can be fuzzed and replayed back to the application just as we would do in a normal fuzzing session. The effectiveness of this approach will unfortunately always be limited to the data recorded while browsing through the web application, any vulnerability outside the recorded session is not found during the fuzz tests.

In the beginning of 2011 Google released their “HTTP Archive” tool (HAR) as part of the Google Chrome developer tools, used to record browsing sessions. Included in these packages are all the requests to and from the web application, including cookie information. The idea behind this is to allow effective processing and analysing data coming from various sources by external tools, such as WebApp fuzzer. The information saved in these HAR files proved to be perfect to base fuzz test models upon.

After walking through a web application in Chrome, the HAR file can be exported and imported in the WebApp sequence creator which will show all the sequences found. The more interesting messages are automatically selected as candidates for fuzzing and replaying. Interesting messages would be requests and replies containing query parameters, cookies, POST payload. These fields will be anomalised, together with all the HTTP header fields present in the request. In the picture below we can see the HTTP request indicated with the red arrow which will be used for anomalisation, and the blue arrow indicating the matching HTTP response. The less interesting requests, greyed out, are requests for CSS files, pictures and the like.

The WebApp suite starts sending the malformed requests and broken sequences to the web application. The following screenshot shows an example of a malformed POST message; the malformed part of the message is marked red.

Once the anomalies are sent to the system under test, we try look for unexpected replies, which would indicate that our injected packet triggered a malfunction and thus found a vulnerability. This brings us to the second challenge of fuzzing web applications.

Detecting faults

Detecting problems is not always self-evident. A test case which triggers a crash-level bug is easy to identify due to the discontinuation of a service or process, but a test case which causes the application to overwrite database records or configuration files on the webserver is less obvious.

This obstacle can be overcome by using external instrumentation. Before, during and after each test case there is the option to use external scripts to determine what exactly happened on the application, database and fileservers. All of these components can be loaded in a memory and I/O profiler, effectively monitoring syscalls for suspicious writes. Apart from that, log files can be read after each test case checking for interesting lines.

Based on the findings, vulnerable code can now be patched, or sent to the appropriate vendors for patching.

Conclusion

Fuzz testing is a new, unique way to approach web application testing. It is more focused on DoS level problems and it suits particularly well in finding previously unknown vulnerabilities in software.

However compared to the traditional protocol fuzzing, web application fuzzing is more challenging. Since there is no existing model or specification, the test cases have to be created based on recordings. Walking through larger web application can create HAR files with thousands of unique requests, and with 30.000 test cases per request as it is now, this might be very time and resource consuming to test. The crawling through web applications can be automated, similar to what bots currently do to index pages for search engines. Nevertheless, vulnerability outside the recorded session will not be discovered.

Despite the challenges and limitations, we have already found numerous flaws from large applications. We have every reason to believe that fuzz testing complemented with traditional penetration testing and static code analysis will be the future of web application testing.

Rikke Kuipers

Security Specialist

Codenomicon

www.Codenomicon.com

Miia Vuontisjärvi

Security analyst

Codenomicon

www.codenomicon.com

About Rikke Kuipers

Rikke Kuipers is a Dutch native with a background as a senior network engineer at several large ISPs. Since joining Codenomicon, Rikke has conducted security audits and done security research in the field of network and web application security.

About Codenomicon

Codenomicon develops proactive software security testing and situation awareness tools which find software bugs. Defensics is a fully automatic security testing bundle for over 200 communication interfaces. Situation awareness tools collect, filter, and visualise network and abuse information concurrently. Governments, leading software companies, operators, and manufacturers use Codenomicon’s solutions.

The idea for a tiny and cheap computer for kids came in 2006, when Eben Upton and his colleagues at the University of Cambridge’s Computer Laboratory, became concerned about the year-on-year decline in the numbers and skills levels of the A Level students applying to read Computer Science. “From a situation in the 1990s where most of the kids applying were coming to interview as experienced hobbyist programmers, the landscape in the 2000s was very different; a typical applicant might only have done a little web design,” he commented.

The Cambridge colleagues observed that something had changed the way that kids were interacting with computers. A number of problems were identified: the colonisation of the ICT curriculum with lessons on using Word and Excel, or writing webpages; the end of the dot-com boom; and the rise of the home PC and games console to replace the Amigas, BBC Micros, Spectrum ZX and Commodore 64 machines that people of an earlier generation learned to program on.

The makers describe the Raspberry Pi as “a capable little PC which can be used for many of the things that your desktop PC does, like spreadsheets, word-processing and games. It also plays high-definition video.”

As for the OS and programming language: “We’ll be using Fedora as our recommended distribution. It’s straightforward to replace the root partition on the SD card with another ARM Linux distro if you want to use something else. The OS is stored on the SD card. By default, we’ll be supporting Python as the educational language. Any language which will compile for ARMv6 can be used with the Raspberry Pi, though; so you’re not limited to using Python.”

Computing at School is writing the user guide and programming manual, but others are already seeing the potential of the Raspberry Pi. “We’re aware of a few books being planned and written around the Raspberry Pi,” says the maker, “and others have already started to produce some excellent tutorials including video. We’re also working with partners to use it as a teaching platform for other subjects, including languages, maths and so on. Once we launch, we hope that the community will help bodies like Computing at School put together teaching material such as lesson plans and resources and push this into schools. In due course, the foundation hopes to provide a system of prizes to give young people something to work towards.”

Mackintosh commented: “Being recognised for this award is great news for TestPlant, especially given the calibre of the other finalists. As well as promoting and supporting our export drive, this is also a huge stamp of approval for eggPlant in the UK – a core market for software innovation and design. The help from UKTI and sponsors HSBC and PwC will be used to accelerate our expansion into India and China. The whole process has been of real business benefit to us.”

Parveen Thornhill, regional director for UKTI London, added: “The standard of entries was incredibly high and the creativity and innovation of the ideas was fantastic.”

Since it was founded in 2008, TestPlant has seen year-on-year success with an average compound annual revenue growth rate of over 80 percent. In the last year alone it has achieved a 104 percent growth rate. Today 85 percent of its sales are to export markets, including America, Canada, China and India. This latest recognition complements existing awards and plaudits from the British Venture Capital Association and the London Export Awards. The company’s other market-firsts include becoming the only company in its market niche with a patented technology, secured in 2011 from the US Patent and Trademark Office for eggPlant, its intelligent robotic software testing tool.

“The recognition of this UKTI Export for Growth prize reinforces our position as a market leader and innovator, and also reflects the global demand for automated software testing and validation,” concludes Mackintosh. “TestPlant is the fastest-growing business in this sector which is driven by the increasing software complexity and the diversity of devices such as smartphones and tablets, which are making the testing of business critical applications fast-paced, consumer-facing and ever more important.”

According to the report, in general, Finland is thought to be ‘mostly harmless’ in terms of cyber security: thanks to a collaboration between security community, CERT-FIs and Finnish ISPs, there are relatively few attacks originating in Finland. CERT-FI and other similar actors handle vast volumes of incident report data information with AbuseHelper. Codenomicon has expanded the toolset to Abuse Situation Awareness, gaining fully automated sharing of actionable incident data and situational awareness over malicious activity.

As a long-standing homeland for internationally acclaimed security companies, Finland has a strong cyber security culture which shows in the recent studies. Cyber threats are taken seriously, which has resulted in R&D efforts to create better security. This has ultimately led to the creation of many international companies working with cyber security software.

Dave Rigler, director of Central and Northern Region at SQS, said: “There is now widespread acceptance that quality testing is a necessary strategic investment in any IT project so choosing the right people to carry out this work is essential. At SQS, we deliver software quality services to a wide range of customers across the UK, including major financial institutions, telecommunications companies and Government bodies as well as high-tech and gaming organisations.

“Our 2012 recruitment drive across Central and North England is the result of business needs and the pipeline of activity that we are gearing up for in 2012. It will offer those seeking a new career in the software quality sector an amazing opportunity to work with the best consultants in the field. These latest jobs are specialist roles that will ideally suit professionals currently working in the sector or looking to transfer relevant skill sets into this growth industry.”

For more information on vacancies at SQS, and the application process, visit http://www.sqs.com.

By locating its platform at Interxion, Cloudgermany combines the performance of its native cloud software and state-of-the-art Infrastructure as a Service platform with the connectivity, high availability, and reliability of Interxion’s Frankfurt data centres. Cloudgermany.de offers its services in full compliance with German data protection rules.

Between 1 March and 30 April 2012, companies can try Software as a Service solution – including Microsoft Windows Server® – via a trial account in a secure environment in real time for free. Additionally, users can migrate their own applications onto cloudgermany.de’s infrastructure, such as CRM or ERP systems, and test the performance. The customer doesn’t even have to worry about basic parameters like memory, server capacity, data centre capacity, or data backup as all elements are provisioned as a service by cloudgermany.de. Instead, the enterprise customer can fully concentrate on its core business and allocate IT resources accordingly.

The cloudgermany.de platform can also be replicated at all of Interxion’s data centres across eleven European countries, which provide equally high-performance environments for enterprise applications. Interxion data centres do not only offer the highest safety and availability, but also direct access to other companies based within the data centre, including service providers, systems integrators, connectivity providers, and the Internet Exchange DE-CIX.

“With the establishment of the Cloud Testlab, we would like to make it easier for medium-sized companies in particular to take the first step toward cloud computing by offering them all the programs and applications they already use on a daily basis on the cloudgermany.de infrastructure platform. Thus we enable them to dynamically tailor IT infrastructure to fit fluctuations in demand and to avoid engineering to meet peak demands. We have been using Interxion’s infrastructure since May and have had no downtime so far,” commented Udo Würtz, advisor of the management board at cloudgermany.de.

Peter Knapp, German managing director at Interxion, added, “The rapid adoption of cloud computing has seen cloud-based services become a central part of business strategy. The launch of this Cloud Testlab reinforces our commitment to the cloud and offers both customers and prospects the opportunity to test and develop cloud services at high speed and with best-in-class performance guarantees.”

Having seen an increasing demand for testing products for business and safety-critical components and embedded systems, QA Systems says it saw an opportunity to combine IPL’s dynamic testing tools with its current portfolio of requirements engineering and static testing tools. In order to do so freely and determine the direction of research and development activities, QA Systems has purchased the entire Testing Products Business Unit from IPL and set up QA Systems as a result – an independent UK-based company with a global remit predominantly targeting the aerospace, defence, automotive, engineering and healthcare sectors.

Andreas Sczepansky, CEO and president of QA Systems, comments, “A historical focus on static testing has limited our market reach. However, having seen the market potential of IPL’s dynamic testing software products, we were keen to be able to combine these product lines with our own so that we could go to market with an all-encompassing proposition. In order to maintain control over the ongoing development so that it would suit our needs and ambitions, we decided that the most practical option would be to offer to purchase the business unit from IPL and establish a new UK-based company from the existing resource.”

The employees, intellectual property and assets previously held within IPL’s Testing Products Business Unit are being transferred to the newly-established QA Systems Ltd, which will also be based in Bath. All existing customers of AdaTEST and Cantata++ products will continue to be supported by the new entity and will benefit from the greater resources of the overall QA Systems group. Existing partners already reselling the two product lines will also continue to be supported by QA Systems Ltd. Indeed, as part of its global strategy, QA Systems Ltd. is actively seeking out further additional partners to assist in territorial and vertical market reach.