| HOME More Articles |
|
Web applications are plain old HTML pages, search engines, complex cgi forms and other applications both consumers and professional find ubiquitous on the Internet. In a way, a Web application is analogous to sales rep, a cashier or clerk in the real world – only this one is purely composed of digital bits. Web application architecture usually consists of Web browser on the client end; this, via the Internet, connects to a Web server which consists of a relational database, transaction server and application server. Due to this complexity, Web applications are far more than the graphical front-end most of us are used to seeing. Such systems, therefore, require traditional (back end) testing plus the special front-end tests. This would seem to imply that the developers of such systems employ strict and precise procedures to work all the bugs out of these applications before they are released to the public. This, for the most part, is not the case when it comes to most Web application projects. LIFECYCLETraditional software engineering projects follow a well-planned and methodical life-cycle. Web applications usually follow a life cycle, too, with similar phases (requirements, planning, analysis, etc). These phases, however, are carried out a bit differently. Here’s a comparison: Requirements Typical software project -- based on detailed requirements specs. Questions asked: What are we going to build? How does it compare to products currently available? Web application project – based on discussions, notes, ideas. Questions asked: What will be offered to visitors/customers? What’s the best navigation? What are the hottest trends? Planning Typical software project – estimates based on experience. Questions
asked: With the given resources, how long will it take? How will we test
this product? Analysis and Design Typical software project – based mostly on well known technologies and design methods. This phase is usually finished before implementation. Web application project – short, iterative cycles of design done concurrently with implementation. Questions asked: How should the look – graphics, art, etc? Who is our typical customer? How can the site be made usable? What technologies will we use? Implementation Typical software project – sequential development of design components. Web application project – iterative prototyping and storyboarding. The prototype is slowly transitioned into the production site. This is unlike the typical software project in which the prototype is usually thrown away (i.e., not shipped). Integration Typical software project – components are brought together for assembly to the design specifications. Questions asked: Are the requirements being met? Is this the project we set out to create? Web application project – this phase usually does not exist. Prototyping stops; the site goes live. Testing Typical software project – functionality is systematically tested against specs. Questions asked: Has the product been tested in a reproducible manner? Has everything been tested? Are all serious problems resolved? Web application project – implied features are tested based on a general ideas of “desired functionality.” Questions asked: It’s only a Website – the developers will test it as they develop it, right? How does one test a Website? Do all the links work? Release Typical software project – build the release version and, from it, create CD-ROM versions. Questions asked: Have all the acceptance criteria been met? Has QA authorized the product for release? Have control versions been implemented so that the source code for this release is always retrievable? Web application project – Immediate transfer of the development site to the live server -- must go live ASAP. The rest of the features can be added later. Maintenance Typical software project – Periodic updates based on technological enhancements and user feedback. Questions asked: What features can be added for a future release? How should user defects be handled? Web application project – part of the development life cycle. New material is published immediately; changes made on the fly since no installation is required. Any changes should be transparent to user. Timeframe Typical software project – one to three years Web application project – 4 mos. As can be seen from the two lifecycles, the biggest difference between the two approaches is the time pressure under which web application systems are developed. This means an approach different than the traditional cycle must be taken. This approach limits the scope of the first release and forces many of the feature additions into iterations that come in subsequent releases. From the requirements phase (described above) it can be seen that Web application projects are based on “fuzzy” specs – they are more in line with marketing and art than true hard-core functionality specs found in normal software engineering projects. Requirements are a crucial part of the critical infrastructure for all rest planning. How can tests be adequately planned if the requirements are not specific or are subject to constant change throughout the life-cycle? Further, the time pressure element doesn’t allow for requirements documentation (as well as other types of documentation) to be written thoroughly. Therefore, as stated by Macintosh and Strigel, “serious testing is impossible….” QUALITYProper QA can make or break a website. Quality issues such as security, reliability, recoverability, usability and performance are what customers and visitors are looking for. If they don’t find what they are looking for, another site is just a few mouse clicks away. Therefore, websites are simply not allowed to “mess up.” The QA criteria must be tested vigorously to make sure quality issues are not compromised. For example, security may be the most important criteria for web applications. Security measures often rely upon third-party products (certificates, SSL software, web server software, etc). All these products have to be thoroughly tested so it can be proven that they work together harmoniously and, most importantly, don’t compromise visitors’ security. WEB TESTINGWhat kind of tests should be conducted for websites and web applications? How thorough should these tests be? These issues depend on the size and complexity of the site: for example, is the site based on frames, use forms, plug-ins, style-sheets, JavaScript, require constant interface with the RDBMS? According to Macintosh and Strigel, one major weakness of web application projects are inadequate technical expertise or ability: testers have to be knowledgeable about a wide variety of topics such as scripting, databases, web servers and networking protocols. Web testers cannot simply test the functionality of the UI front end; if they do, they will overlook important issues such as security and database integrity. Another weakness of web testing is the “lack of mature test tools” that are used to automate the web testing procedure (Macintosh, 2000). Such tools need to be developed – and they must constantly be evolved to keep up with web technology. THE NEED FOR A TEST ENVIRONMENT FOR WEB APPLICATIONSA factor critical for the software engineering test environment is the ability to roll back or revert to a “known state” or previous version. If a previous state did not exist, testing for the sake of isolating and analyzing problems is far more difficult as the environment grows continuously more and more complex. Another problem with web application testing is the common problem of “migrating defect fixes and new functionality” to a live server prior to proving reliability – i.e., testing on the live server itself! This has the potential for bringing down the site. A separate “test server” should be delegated this task. Macintosh and Strigel suggest the following environment for a web-testing team (it consists of three separate servers): -- development server (for development team) PLATFORMS AND BROWSERSThere are a handful of browsers out there as well as a few popular OS platforms — all with several multiple versions. In addition, standards for HTML are constantly changing and new mark-up languages (such as XML) are on the horizon. Compliance with multiple browsers and/or OS platforms are a cornerstone of web application testing. In view of these multiple combinations, Macintosh and Strigel suggest that application configuration be split into two separate groups: a core set of “primary” configurations, on which most of the testing should be focused; and a “secondary” configuration on which security, performance, functionality, system and acceptance testing will be performed (based on how much time is available). THE DRAWING BOARD: STRATEGIES FOR WEB TESTING IN A CRAZY WORLDYes, the typical Web application life-cycle is a crazy, sub- or non-standard world filed with time pressures and ultra-high-performance demands. What can we do and how can we test given these conditions? Since back-end application tests are more like traditional software projects/applications tests (i.e., involving databases, transaction servers, etc.) we can separate them from the front end tests (browser compatibility, link validity, etc.). Given the fact that we have very little time, risks must be prioritized so that the most critical components of the system get prompt attention. Macintosh and Strigel suggest the following: - develop a test plan as complete as possible This essay is a synthesis of the following two articles: More Software Testing information:
|