Testing Web Applications Part 1: Priming the Team
Web Applications vs. Web Pages
Your company has decided it’s time to add that little “e” to the front of your service or product. A team of web developers has been assembled to offer these services and/or products from your company’s website. You and your team are charged with testing this new beast, this web application. You’ve been testing enterprise applications, database applications, whatever the flavor is at your company. So this should be pretty simple, right? It’s just a bunch of web pages, maybe some JavaScript, right? Wrong.
What do we mean by “web application”? There is an incredible range of sophistication in web applications from a simple company website with some order fulfillment to sites like Yahoo or Amazon. One way to look at the web application architecture is to take the model of a traditional business transaction application and to replace the user front end by the website. A customer acquires goods and/or services from your company in exchange for money. Mechanisms are in place to facilitate that transaction between client and company. But instead of a sales rep, a clerk, or a cashier, you have a browser pointing at a website. The company is never closed! Customers can serve themselves!
Think of a vending machine. This machine fills orders based on input from users, verifies transfer of funds, and has a basic user interface. Now add some complexity. Make the UI a browser-based solution that must run in multiple browsers on multiple operating systems instead of a touchpad, oh, and have the machine fill orders directly from a warehouse, while tracking (real-time) inventory. And to top that off, people won't be putting coins in the machine, but swiping their credit cards in a reader – so you’ll need to have each transaction approved by the credit card companies. Hey, and another great idea would be to assign each customer a user name and a PIN to allow us to keep this information for them. This way they won’t have to keep swiping their cards and entering shipping information. And I guess that information should be really secure too.
Considering this picture, it’s now becoming clear that web applications are not simply websites with some artwork and some HTML or JavaScript. They are similar to traditional transaction systems with additional complexity at the front end. The testing effort required for such a system is considerably larger than for applications without a web interface.
The Development Life Cycle and Its Impact on Testing
Most of us have been exposed to a few software development life cycle models, such as the Spiral model, the Waterfall model, and so forth. The typical software project includes phases such as planning, requirements gathering, analysis and design, implementation (coding), integration, testing, release and maintenance. Your team needs to know how these phases match up for a web application project.
The phases are somewhat similar, but without the sometimes lengthy timeframes previously seen in the industry. Web applications are software and, as such, fall under the same rules as all software development projects: you need requirements, design, implementation, and testing as a bare minimum. And if you want to limit risk, you need sound planning and management like in any other software project. Even speed is similar in the sense that marketing always wanted the product yesterday. Only now “yesterday” is even earlier.
The best way to reduce the risks when testing a web application is to add formal test planning and analysis to the beginning of the project lifecycle. Every project has testing at the end of the project life cycle. When the development schedule slips, testing time is almost always reduced to make release or “go-live” dates. Adding test planning to the beginning of the project life cycle will allow testers to prioritize their testing efforts based on risk, schedule constraints, and testers' abilities and aptitudes. This will be crucial to managing the test effort when the time crunch hits prior to going live.
Five Ways to Prepare Now
Testing a web page with relatively static content and few to no forms will take very little time. Testing a web application will require much more sophisticated testing strategies and thus more time. Due to the nature of web development, your team probably won't get more time and maybe even less than for a traditional development project. You can save time at the end of the project by using “downtime” in the beginning to prepare your test team for the task ahead.
1. Learn more about the environment in which you’ll be working.
Testers should familiarize themselves with subtle browser, operating system, web server, and database differences. The more they know about scripting (ASP, XML, HTML, etc.), databases (Oracle, SQL, etc.), web servers (IIS, Apache, etc.), and the data transfer behind the UI, the more effective they are. Testers simply can’t just test the functionality by exercising the UI (in this case, the browser). They will miss all the other kinds of testing required for web applications (such as performance, security, database integrity). Remember, crackers don't use browsers to crack sites; they use scripts.
2. Find or create appropriate test tools.
The lack of mature test tools makes automation difficult. Remember when Java first hit the scene? Developers and project managers alike wanted to use this new technology. Testers suddenly had their workloads doubled, tripled, or more, simply because of the number of configurations and the lack of any mature testing and automation tools available. More test tools are available now, but it will still take time to source an appropriate tool, learn its ins and outs, and even customize it to your environment. If a tool is not available, you'll want to find out sooner rather than later and build some test apps of your own.
3. Create a matrix of operating systems vs. browser versions.
Grossly large amounts of browser and operating system compatibility testing are required. If you create a matrix of operating systems vs. browser versions, you’ll have a method of attacking all the variations.
4. Define your development and test environment with version control and other configuration management efforts.
If you are testing web applications without defining your environment, you’ll face issues such as:
- How do you roll back code changes when you have no previous build?
- How do new functionality and defect fixes get migrated into each build?
- Does the term “build” mean anything in the web-space?
Test personnel cannot revert back to a “known state” if the source code is not being archived or not being labeled or branched in the version control repository. Not having a previous release to revert to for testing purposes makes isolating and analyzing defects more difficult, as the environment continually becomes more complex. If you set up a test friendly environment, you won't have to face the problems arising from these questions.
5. Set up a separate test server.
A common (and dangerous) practices of web testers is migrating defect fixes and new functionality to a live server prior to testing, and testing on live servers. Your test team shouldn't bring down your site; they should bring down a separate test server.
These five steps should help prepare your team for the challenging task ahead. In a future article, I will outline a series of specific questions you should be asking when beginning your test planning, and how the answers to these questions can be used to define and focus your testing strategy.
Originally published by Software Productivity Center in their March 22, 2000 (Issue 15) edition of E-SSENTIALS! newsletter.
Back to Resources.
