Acutest , the UK software testing solution provider, have announced the launch of their new load testing service: the Load Cannon. This is a performance testing service for web-enabled applications and websites. Hosted in the UK, it is a fusion of performance testing tools; load generators; monitors; structured testing methods; risk-based testing techniques and experienced
The load testing service is designed to be robust, quick to operate, capable of both onsite and offsite deployment and is also scalable. The pricing has been designed for the current economic climate. There are no testing tool license costs or restrictions such as rental periods. There are no additional costs for simulating high volumes of users, or transactions, in a test scenario. And you only pay for what you use.
A risk assessment is carried out at the start of the assignment and the testing is prioritised by business impact and likelihood of failure so organisations can match their budget with the level of risk they want to mitigate. This enables them to choose the level of performance testing they want, ranging from a simple benchmark load test to a comprehensive set of performance tests for a complex web-enabled system. So now organisations no longer have to live with the untested risk of performance failure.
|
|
We recently surveyed 224 IT professionals and asked them about their company's interest in a tool that could be used to test application performance throughout the application lifecycle - from application design through ongoing management. Roughly three quarters of the survey respondents indicated that, "If the tool worked well it would make a significant improvement to our ability to manage application performance." To dig deeper into this issue, we spoke with a consultant who is responsible for application testing at a Fortune 500 pharmaceutical company. Since one of the reasons why applications run well over a LAN and run poorly over the WAN is the use of chatty protocols, we asked The consultant if his company ever deploys chatty applications. The Consultant said that his company often deployed chatty applications and that in some instances the problem is so bad that "the application just can not be deployed." He added that in many cases there is not an easy way to improve application performance and that "there is just so much that you can do with caching." The discussion of chatty protocols demonstrates the need to be aware of the impact of the WAN on application performance during the application development lifecycle. In particular, it is important during application development to identify and eliminate any factor that could have a negative impact on application performance.
We asked an IT professional who is the manager of technology, architecture and engineering for a large international law firm for his opinion on this. He highlighted the importance of this approach when he stated, "It is much better to plan for the performance of an application during development than to scramble around after we develop it."
For the full article go to Network World
|
|
From Info World
"According to various sources, Microsoft last night pushed out another build of its forthcoming operating system, "Vista," build 5536, which the company is labelling "Pre-RC1" (Release Candidate 1). Reviews, at this early stage, have been positive, with improvements to the installation routine and a performance testing program that rates your system for use with Vista."
Software performance testing services
|
Webinar discussing Automated and Load Testing. You can register at the link below and you have plenty of time because its not until 16h and 17th May. Who amongst us can honestly say that they wouldn't benefit from more knowledge on automated testing and load testing (or even performance testing services for that matter)?
So register HERE to learn how to reduce software testing and quality assurance costs.
|
i Found this interesting paper on how to make the Decision to To Automate Your Software Testing by Danna Henderson:
Not every software testing project can or should be automated. Before your department accepts a new test automation project, you should establish a process by which projects are reviewed and either accepted or rejected. This can be done with a simple Test Automation Acceptance Checklist.
The true cost benefit of test automation is achieved only when the same scripts are executed multiple times. The first execution is very expensive because it includes the one-time cost of the automation tools and 100% of the Test Automation engineer’s time. When the scripts are executed again, the cost of test automation declines sharply. The tool has already been purchased and the scripts have already been coded. If there have been changes in the application, the scripts may require maintenance before being executed. Maintenance on minor software updates should be minimal.
Because test automation is only successful when the scripts can be executed multiple times, only application which require the same test cases to be executed with the same data are good candidates for automation. For example, a mortgage application that needs to be regression tested on a weekly basis could be a good candidate for test automation. Script maintenance is minimal and the scripts can enter a mortgage application using the same group of test data in a fraction of the time it would take a manual tester to test the same functionality...
For the full paper visit Testing automation white paper
Or alternatively you could be looking for aspects of automation such as performance testing or load testing.
|
Systems that work well during development, deployed on a small scale, can fail to meet performance goals when the deployment is scaled up to support real levels of use. An apposite example of this comes from a major blue chip company that recently outsourced the development of an innovative high technology platform. Though development was behind schedule this was deemed acceptable. The system gradually passed through functional elements of the user acceptance testing and eventually it looked like a deployment date could be set. But then the supplier started load testing and scalability testing. There followed a prolonged and costly period of architectural changes and changes to the system requirements. The supplier battled heroically to provide an acceptable system, until finally the project was mothballed.
This is not an isolated case. IT folklore abounds with similar tales. From ambulance dispatch systems to web-sites for the electronic submission of tax returns, systems fail as they scale and experience peak demands. All of these projects appear not to have identified and ordered the major risks they faced. This is a fundamental stage of risk based testing, and applies equally to scalability testing or load testing as it does to functionality testing or business continuity testing. With no risk assessment they did not recognise that scaling was amongst the biggest risks, far more so that delivering all the functionality Recent trends towards Service Oriented Architecture (SOA) attempt to address the issue of scalability but also introduce new issues. Incorporating externally provided services into your overall solution means that your ability to scale now depends upon these external system operate under load. Assuring this is a demanding task and sadly the load testing and stress testing here is often overlooked.
Better practice is to start the development of a large scale software system with its performance clearly in mind, particularly scalability testing, volume testing and load testing. To create this performance testing focus:
- Research and quantify the data volumes and transaction volumes the target market implies. Some of these figures can be eye openers and help the business users realise the full scale of the system. This alone can lead to reassessment of the priority of many features.
- Determine the way features could be presented to users and the system structured in order to make scaling of the system easier. Do not try and have the same functionality you would have for a single user desktop solution provide an appropriate scalable alternative.
- Recognise that an intrinsic part of the development process is load testing at representative scale on each incremental software release. This is continual testing, focusing on the biggest risk to the project: the ability to operate at full scale.
- Ensure load testing is adequate both in scope and rigour. Load testing is not just about measuring response times with a performance test. The load testing programme needs to include other types of load testing including stress testing, reliability testing, and endurance testing.
- Don’t forget that failures will occur. Large scale systems generally include server clusters with fail-over behaviour. Failure testing, fail-over testing and recovery testing carried out on representative scale systems operating under load should be included.
- Don’t forget catastrophic failure could occur. For large scale problems, disaster testing and disaster recovery testing should be carried out at representative scale and loads. These activities can be considered the technical layers of business continuity testing.
- Recognise external services if you use them. Where you are adopting an SOA approach and are dependent on external services you need to be certain that the throughput and turnaround time on these services will remain acceptable as your system scales and its demands increase. A smart system architecture will include a graceful response and fall-back operation should the external service behaviour deteriorate or fail.
Copyright Acutest 2005
About Acutest
Acutest is an, independent consultancy specialising in testing software, IT and technology-enabled change, including performance testing. For further information on Acutest contact:
Acutest Ltd
Blackwell House
Guildhall Yard
London
EC2V 5AE
Tel: +44 (0)20 7917 2838
Website: http://www.acutest.co.uk
|
|
![[info]](http://l-stat.livejournal.com/img/userinfo.gif){kind=small}
testingsoftware's journal