We are developing an e-commerce application in-house and have been approached several times by software testing suppliers who keep going on about the importance of application testing. How much of our development time should realistically be taken up by testing?
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
Wise up and buy the simulation test software
UK general manager
Testing Web applications should be an integral part of the development process, not an afterthought, but automated testing tools can minimise testing time by making it an on-going part of the development process.
The biggest problem with Web applications - and what separates them from ordinary software applications is scalability. Web applications must be able to withstand wide swings and peaks in load and errors can mean real damage to a company's reputation, stock price and future.
The "normal" QA process involves testing at the end of an application's development phase, when most coding has been completed. But for Web applications, to minimise risk of structural problems being discovered too late, you should perform scalability testing well before this to find all the issues in each application tier or component well before final integration takes place. Systems tested this way are more likely to scale successfully, since individual components will have already passed their own tests. The traditional test method of gathering five people in a room to click on a Web site is not viable. Even so, many firms rationalise this as more economical than buying new testing tools.
But a two-day load test using five people could cost £8,000 per test if each person's time is valued at a reasonable £800 per day. Moreover, this test is not scalable, repeatable or robust.
But performance testing tools generating 100 "simulated users" cost much less, can be up and running quickly, and work year-round. Problems found earlier are easier and cheaper to solve. Without test automation and realistic load testing, the Web application will not only fail but the debugging and diagnosis of the reasons for the error become almost impossible.
My company has expanded its global operation over the past year with several acquisitions overseas. As we get bigger, I must come up with an IT/e-business strategy that sits as comfortably in the UK as it does in Thailand and Spain, for example. Can you suggest areas that I should concentrate on?
Make your company relevant to the market
Scala Business Solutions
Senior vice-president marketing,
The answer to this question lies in working out how to allow businesses to compete in the global marketplace, while providing support on a local basis, and a worldwide network that will sustain international growth. I firmly believe that localisation in IT and e-business does not centre on language translation alone, it is about applying successful processes in a locally acceptable way. A global business that wants to be successful locally should decide what it is that makes it successful in the first place, and then support these processes so that they can be replicated wherever they are implemented.
For example, it is vitally important that an American company does not operate as an American company in other countries, as being legally compliant in the US does not make a company legally compliant in China, for example. Any IT or e-business strategy operating on a global level should take on board local legislation and culture, allowing a company with headquarters in the US to operate as a Chinese company.
A business cannot impose its operational methods on a global basis, it should extract the processes that make it a successful company and then apply them to local business practice.
Although not the sole concern, language is still an important consideration. However, just translating the information between languages verbatim often leads to misunderstandings. Rather than providing mere translations of IT or e-business systems, the key to success lies in transliterations, ie taking the idea and expressing it in the language of choice so that it is relevant to the market.
Last year my IT department spent a large part of our budget on Y2K compliance. Now, we are being told of the importance of euro compliance and how we must be prepared for the changeover - is this a real problem to look out for or just another money-spinner for IT services companies?
Euro compliance is an unavoidable issue
AMS Francesco Burelli Principal e-business strategy consultant
The adoption of the euro is a real IT and business change issue. Last year, Y2K compliance pressure was necessary to prevent possible malfunctions on and after 31 December, forcing companies to take preventative efforts to avoid these problems. Y2K was not a storm in a teacup as some problems did arise with various degrees of severity.
Unlike Y2K, the euro will definitely happen and is already affecting companies outside the financial sector. Until 1 January 2002, cash and payment operations will be conducted both in euros and local Economic and Monetary Union (Emu) member currencies. Twin systems of accounting will have to convert and settle figures in both euros and Emu currencies. In worldwide money markets it is already compulsory for country bonds and all intra-banking transactions to be settled in euros for Emu zone-originated operations.
After this date, all Emu transactions will be processed in euros only, while all local Emu currencies will physically disappear. Despite uncertainty over UK participation in the single European currency, companies will have to be capable of handling euros for even the most simple Emu transactions. Not only will euros have to be added to systems, administrative books and price lists, but all current Emu currency accounts will have to be converted into euros, thereby zeroing local currency accounts and transferring them accordingly to the euro. The conversion rates were fixed by the European Central Bank in December 1999.