Web Testing

How can I tell if a web page is secure?

Pavankumar Pothuraju — Thu, 23 Aug 2007 09:29:57 GMT

The below takes you ssl.com aritcle on web page secure. This brilliantly written article answers almost everything you need to know bout how to tell if a website is secure.

http://info.ssl.com/Article.aspx?id=10068

Also read the below releated articles on subject:

http://www.iisfaq.com/default.aspx?View=P20&P=145

http://www.lloydstsb.com/security/web_page_security.asp [click 'check a site certificate' link at the end of description]

Below article explains the process of procuring and installing a SSL server certificate [article focus on SSL.com products, but worth to read as the process should be common to all vendors]

http://info.ssl.com/article.aspx?id=10694

Cheers

HTTP Error Codes

Pavankumar Pothuraju — Thu, 06 Oct 2005 14:39:00 GMT

HTTP Error Codes
Information Codes
Error #	Error Code	Description
100	Continue	The request was successful. The process can now continue.
101	Switching Protocols	The request for the server to switch protocols was accepted, such as a switch from ftp to http.

Success Codes
Error #	Error Code	Description
200	OK	The item requested of the server is available (keep in mind, available, not accepted or completed).
201	Created	A new address has been created through the use of form posting, perl, cgi, etc.
202	Accepted	The request has been accepted (keep in mind that the request has been accepted, not completed)
203	Non-Authoritative Information	The information received is not from the server that the information was requested from, but from another source.
204	No Content	There was no content to be given for the request. For instance if you click on a hyperlink, imagemap, or button that isn't linked to anything or doesn't do anything.
205	Reset Content	A script has reset the displayed content.
206	Partial Content	Only partial content has been displayed. This could be due to bandwidth, poor caching, bad html, or other reasons.

Redirection Codes
Error #	Error Code	Description
300	Multiple choices	You will either get a choice of pages or an error message when this occurs. The address is actually pointing to two multiple files and/or locations.
301	Moved Permanently	The requested page has been permanently moved. The server will automatically redirect you to the new location.
302	Found	The requested page has been temporarily moved. The server will automatically redirect you to the new location.
303	See Other	The requested data is stored in an alternate location and the GET method will be used to retrieve the data. If the actual error is returned then this may be due to a web server misconfiguration.
304	Not Modified	The requested data has not been modified since the last request.
305	Use Proxy	The requested data may only be accessed via the use of a proxy server.
307	Temporary Redirect	The requested page has been moved. The server will automatically redirect you to the new location. Unlike Error 301 and 302 however, the server has not specified whether the move is temporary or permanent.

Client Error Codes
Error #	Error Code	Description
400	Bad Request	The request was denied due to a syntax error in the request.
401	Unauthorized	Your IP address or the username/password you entered were not correct. Your request was denied as you have no permission to access the data.
402	Payment Required	The data is not accessible at the time. The owner of the space has not yet payed their service provider.
403	Forbidden	Your IP address or the username/password you entered were not correct. Your request was denied as you have no permission to access the data. OR The server was unable to serve the data that was requested.
404	Not Found	The document that has been requested either no longer exists, or has never existed on the server.
405	Method Not Allowed	The document that has been requested either no longer exists, or has never existed on the server.
406	Not Acceptable	The client (webbrowser) does not accept the document format. The formats that may be specified not to accept are charset, encoding, certain file types, languages, or ranges.
407	Proxy Authentication Required	The browser has not been authenticated on the required proxy server to access the data. This error is probably most commonly returned by content filters/parental controls.
408	Request Timeout	The server has closed the socket due to communications between the client and server taking too long. This could be due to server load, bandwidth issues, the client being disconnected from the internet, etc.
409	Conflict	Too many requests for the same file at one time. OR There is a conflict with an established software rule. (ie: you are trying to copy over a file with an older version, or you do not have permissions to delete a file) OR This could be caused by a DNS issue
410	Gone	This is like a 404 error in that the document requested is not on the server, however this differs in that the server 'knows' that the file used to be there and 'believes' that the file may be back, so it returns 410 rather 404.
411	Length Required	When trying to send a document to the server the server did not recieve a Content-Length specification in the header.
412	Precondition Failed	A precondition setting required by the client or server has not been met.
413	Request Entity Too Large	The process is too large to process. (ie: a file you are trying to upload is too large to fit on the server, or a webpage you are trying to download is too large for the server to process)
414	Request-URI Too Large	The URL requested is simply too long. It is most likely more than 1024, 2048, or 4096 characters in length.
415	Unsupported Media Type	This usually occurs if the server does not support the type of media the client is requesting. (ie: the server does not support streaming media, but streaming media is on the server and the client is attempting to access it)
416	Requested Range Not Satisfiable	The client request included a range for acceptable file size, however the document requested did not fit into that range.
417	Expectation Failed	The client's expect header requested certain server behaviors that the server could not perform.

Server Error Codes
Error #	Error Code	Description
500	Internal Server Error	The server encountered an error. This is most often caused by a scripting problem, a failed database access attempt, or other similar reasons.
501	Not Implemented	The method you are using to access the document can not be performed by the server. Possible methods include: CONNECT DELETE GET HEAD OPTIONS POST PUT TRACE
502	Bad Gateway	The document requested resides on a 3rd party server and the original server received an error from the 3rd party server.
503	Service Unavailable	The server is overloaded or down for maintenance and due to this was unable to process the client request.
504	Gateway Timeout	Most likely the client has lost connectivity (disconnected from the internet) or the cleint's host is having technical difficulties. This could also mean that a server that allows access to the requested server is down, having bandwidth/load issues, or otherwise unavailable.
505	HTTP version not supported	The server does not support the HTTP version used by the client. (This usually occurs if the server is using an OLDER version of HTTP than the client.)

Guidelines and Checklist for Website Testing

Pavankumar Pothuraju — Wed, 22 Dec 2004 21:55:00 GMT

1. Functionality:

1.1 Links

Objective is to check for all the links in the website.

1.1.1 All Internal Links

1.1.2 All External Links

1.1.3 All mail to links

1.1.4 Check for orphan Pages

1.1.5 Check for Broken Links

1.2 Forms

Test for the integrity of submission of all forms.

1.2.1 All Field Level Checks

1.2.2 All Field Level Validations.

1.2.3 Functionality of Create, Modify, Delete & View.

1.2.4 Handling of Wrong inputs (Both client & Server)

1.2.5 Default Values if any

1.2.6 Optional versus Mandatory fields.

1.3 Cookies

Check for the cookies that has to be enabled and how it has to be expired.

1.4 Web Indexing

Depending on how the site is designed using Meta tags, frames, HTML syntax, dynamically created pages, passwords or different languages, our site will be searchable in different ways.

1.4.1 Meta Tags

1.4.2 Frames

1.4.3 HTML syntax.

1.5 Database

Two types of errors that may occur in Web applications:

A. Data Integrity:

Missing or wrong data in table.

B. Output Error:

Errors in writing, editing or reading operations in the tables.

The issue is to test the functionality of the database, not the content and the focus here is therefore on output errors. Verify that queries, writing, retrieving or editing in the database is performed in a correct way.

2. Usability:

2.1 Navigation

Navigation describes the way users navigate within a page, between different user interface controls (buttons, boxes, lists, windows etc.), or between pages via e.g. links.

2.1.1 Application navigation is proper through tab

2.1.2 Navigation through Mouse

2.1.3 Main features accessible from the main/home page.

2.1.4 Any hot keys, control keys to access menus.

2.2 Content

Correctness is whether the information is truthful or contains misinformation. The accuracy of the information is whether it is without grammatical or spelling errors. Remove irrelevant information from your site. This may otherwise cause misunderstandings or confusion.

2.2.1 Spellings and Grammars

2.2.2 Updated information

2.3 General Appearance

2.3.1 Page appearance

2.3.2 Color, font and size

2.3.3 Frames

2.3.4 Consistent design

3. Server Side Interfaces:

3.1 Server Interface

3.1.1 Verify that communication is done correctly, Web server-application server, application server-database server and vice versa.

3.1.2 Compatibility of server software, hardware, network connections.

3.1.3 Database compatibility (SQL, Oracle etc.)

3.2 External Interface (if any)

4. Client Side Compatibility:

4.1 Platform

Check for the compatibility of

a. Windows (95, 98, 2000, NT)

b. Unix (different sets)

c. Macintosh (If applicable)

d. Linux

e. Solaris (If applicable)

4.2 Browsers

Check for the various combinations:

Internet Explorer (3.X 4.X, 5.X)

Netscape Navigator (3.X, 4.X, 6.X)

AOL

Browser settings (security settings, graphics, Java etc.)

Frames and Cascade Style sheets

Applets, ActiveX controls, DHTML, client side scripting

HTML specifications.

Graphics:

Loading of images, graphics, etc.,

4.3 Printing

Despite the paperless society the web was to introduce, printing is done more than ever. Verify that pages are printable with considerations on:

a. Text and image alignment

b. Colours of text, foreground and background

c. Scalability to fit paper size

d. Tables and borders

5. Performance:

5.1 Connection speed

a. Try with Connection speed: 14.4, 28.8, 33.6, 56.6, ISDN, cable, DSL, T1, T3

b. Time-out

5.2 Load

Check/Measure the following:

What is the estimated number of users per time period and how will it be divided over the period?
Will there be peak loads and how will the system react?
Can your site handle a large amount of users requesting a certain page?
Large amount of data from users.

5.3 Stress

Stress testing is done in order to actually break a site or a certain feature to determine how the system reacts. Stress tests are designed to push and test system limitations and determine whether the system recovers gracefully from crashes. Hackers often stress systems by providing loads of wrong in-data until it crash and then gain access to it during start-up.

a. Typical areas to test are forms, logins or other information transaction components.

b. Performance of memory, CPU, file handling etc.

c. Error in software, hardware, memory errors (leakage, overwrite or pointers)

5.4 Continuous use

Is the application or certain features going to be used only during certain periods of time or will it be used continuously 24 hours a day 7 days a week?
Will downtime be allowed or is that out of the question?
Verify that the application is able to meet the requirements and does not run out of memory or disk space.

6. Security:

6.1 Valid and Invalid Login

6.2 Limit defined for the number of tries.

6.3 Can it be bypassed by typing URL to a page inside directly in the browser?

6.4 Verify Log files are maintained to store the information for traceability.

6.5 Verify encryption is done correctly if SSL is used (If applicable)

6.6 No access to edit scripts on the server without authorization.

Checklist before hosting a website:

** Enter “Not Applicable” whichever test not carried out.

Test Carried out	Expected	Actual	Remarks	Ticket Reference
1. Functionality
1.1 Links
Internal Links	Should be present
External Links	Should be present
Mail to links	Should open mailbox
Orphan pages	Should not be present
Broken links	Should not be present

1.2 Forms
Field Level checks	Checked for length, special characters, numerical characters etc.,
Field Level Validation	Checked Unique records, Date validation
Functional checks	Create, modify, view and delete are working.
Error Handling for wrong inputs or actions.	Appropriate error messages to be displayed.
Optional and mandatory fields.	Mandatory field should not be left blank. Optional should allow the user to skip the field.

1.3 Cookies
Check whether cookies are enabled.	**Depends on project

1.4 Web Indexing
Meta tags	Should be present.
Html Syntax	Should be valid
Frames	To be found ok

1.5 Database
Data Integrity	Should not be any missing or wrong data in the database
Output Errors	Errors in writing, reading or editing operations should not be present

2. Usability
2.1 Navigation
Navigation through Mouse	Should be proper
Navigation through Tab	Should be proper
Main features access	Should be accessed from home/Main page
Hot Keys, Control Keys for menu or action	Should be present

2.2 Content
Spelling and Grammar	To be proper
Updated information’s.	Past events/ information’s to be removed.

2.3 General Appearance
Page Appearance	Should not be any overlapping, missing etc.,
Colour, font and size	Should be as per standard
Frames	All frames to be appeared
Consistent Design	Everywhere in the website consistent layout and design should be carried out.

3. Server Side Interface
3.1 Server Interface	Communication should be correct with respect to Web server, App server and DB server
Compatibility with server hardware, Sw, network connections	Should be proper.
Database compatibility[s1]	Should be easily portable to other database.

4. Client side Compatibility
4.1 Platform
Windows2000, NT	Should be working
Unix	Should be working
Linux	Should be working
Solaris	Should be working
Macintosh	Should be working

4.2 Browsers
I.E	Should work in all versions above 4.x
Netscape Navigator	Should work in all versions above 3.x
AOL
Any ActiveX controls

Graphics	Load of images, graphics should be proper

4.3 Printing

Text and alignment	Should be proper
Colours of text, foreground and background	Should be readable.
Scalability to fit paper size.	Should print in A4, Letter size.
Tables and borders.	Should be proper.

5. Performance
5.1 Connection speed
Should be measured in 14.4, 28.8, 33.6, 56.6, ISDN, Cable and DSL
Timeout	Should give appropriate time to search. Incorrect message, data loss should not be present.

5.2 Load
Estimated users.	Per requirements
Peak load	Should withstand
Large amount of data from users	Should accept

5.3 Stress
System Crash	Should not be present
Error in Sw, HW, Memory	Leakage, overwrite should not happen.

5.4 Continuous use
Estimate whether available for 24 Hrs, 7 days a week	Try with various timings.
Downtime	Measure the downtime
Memory or disk space	Should not run out of memory or disk space.

6. Security
6.1 Valid and Invalid	Should not enter with Invalid login
Number of tries	Should not be more than 3 times for invalid try.
Enter url directly without logging in.	Should not display information.
Log files	Should be maintained
Access to server scripts	Authenticated.

[s1]Depends on project type

Top 10 most critical Web application security problems

Pavankumar Pothuraju — Fri, 06 Aug 2004 21:14:00 GMT

A list of the top 10 most critical Web application security problems is available from the Open Web Application Security Project (OWASP), an open Source community project that develops tools and documentation to help organizations secure Web applications and Web services.

The groups says the list combines its members' collective knowledge and should help organizations focus on the most serious vulnerabilities. They represent equal risks to network security, and you should give them the same degree of attention.

OWASP stresses that none of the issues are new; many have been well-known for decades. However, it says major software developers continue to make the same mistakes, placing customers and even the entire Internet at risk.

The flaws are common, and unsophisticated attackers can exploit them with readily available tools. As OWASP explains, organizations in effect invite the world to send them HTTP requests when they deploy a Web application. Attacks buried in these requests sneak past firewalls, filters, SSL, and intrusion detection systems (IDSs) undetected because they're inside legal HTTP requests. For this reason, Web application code is part of the security perimeter and can't be ignored.

The list includes the following:

Unvalidated parameters: In this scenario, information from Web requests isn't validated before the Web application uses it. Attackers can use these flaws to attack backside components through a Web application.
Broken access control: Organizations fail to enforce restrictions on what authenticated users are allowed to do. Attackers can exploit these flaws to access other users' accounts, view sensitive files, or use unauthorized functions.
Broken account and session management: Account credentials and session tokens aren't properly protected. Attackers that can compromise passwords, keys, session cookies, or other tokens can defeat authentication restrictions and assume other users' identities.
Cross-site scripting (XSS) flaws: An attacker can use the Web application as a mechanism to transport himself to a user's browser. A successful attack can disclose the user's session token, attack the local machine, or spoof content to fool the user.
Buffer overflows: Attackers can crash Web application components in some languages that don't properly validate input and, in some cases, use those components to take control of a process. These components can include CGI, libraries, drivers, and Web application server components.
Command injection flaws: Web applications pass parameters when they access external systems or the local operating system. If an attacker can embed malicious commands in these parameters, the external system might execute them on behalf of the Web application.
Error handling problems: Some Web applications don't properly handle error conditions that occur during normal operation. If an attacker can cause errors to occur that the web application does not handle, they can gain detailed system information, deny service, cause security mechanisms to fail, or crash the server.
Insecure use of cryptography: Web applications frequently use cryptographic functions to protect information and credentials. These functions and the code to integrate them have proven difficult to code properly, frequently resulting in weak protection.
Remote administration flaws: Many Web applications let administrators access the site using a Web interface. If these administrative functions aren't carefully protected, an attacker can gain full access to all aspects of a site.
Web and application server misconfiguration: Having a strong server configuration standard is critical to a secure Web application. Web and application server have many configuration options that affect security; they aren't secure "out of the box."

"[The list] will educate vendors to avoid the same mistakes that have been repeated countless times in other Web applications," says Stephen Christey, an editor with Mitre CVE, which works to standardize the names for all known vulnerabilities and security exposures. "But it also gives consumers a way of asking vendors to follow a minimum set of expectations for Web application security and, just as importantly, to identify which vendors are not living up to those expectations"

Testing Your Web Application

Pavankumar Pothuraju — Fri, 11 Jun 2004 17:15:00 GMT

Testing Your Web Application

A Quick 10-Step Guide

by Krishen Kota

Interested in a quick checklist for testing a web application? The following 10 steps cover the most critical items that I have found important in making sure a web application is ready to be deployed. Depending on size, complexity, and corporate policies, modify the following steps to meet your specific testing needs.

Step 1 - Objectives

Make sure to establish your testing objectives up front and make sure they are measurable. It will make your life a lot easier by having written objectives that your whole team can understand and rally around. In addition to documenting your objectives, make sure your objectives are prioritized. Ask yourself questions like “What is most important: minimal defects or time-to-market?”

Here are two examples of how to determine priorities:

If you are building a medical web application that will assist in diagnosing illnesses, and someone could potentially die based on how correctly the application functions, you may want to make testing the correctness of the business functionality a higher priority than testing for navigational consistency throughout the application.

If you are testing an application that will be used to solicit external funding, you may want to put testing the aspects of the application that impact the visual appeal as the highest testing priority.

Your web application doesn't have to be perfect; it just needs to meet your intended customer's requirements and expectations.

Step 2 – Process and Reporting

Make sure that everyone on your testing team knows his or her role. Who should report what to whom and when? In other words, define your testing process. Use the following questions to help you get started:

How will issues be reported?
Who can assign issues?
How will issues be categorized?
Who needs what report and when do they need it?
Are team meetings scheduled in advance or scheduled as needed?

You may define your testing process and reporting requirements formally or informally, depending on your particular needs. The main point to keep in mind is to organize your team in a way that supports your testing objectives and takes into account the individual personalities on your team. One size never fits all when dealing with people.

Step 3 - Tracking Results

Once you start executing your test plans, you will probably generate a large number of bugs, issues, defects, etc. You will want a way to easily store, organize, and distribute this information to the appropriate technical team members. You will also need a way to keep management informed on the status of your testing efforts. If your company already has a system in place to track this type of information, don't try to reinvent the wheel. Take advantage of what's already in place.

If your company doesn't already have something in place, spend a little time investigating some of the easy-to-setup online systems such as the one found at http://www.adminitrack.com. By using an online system, you can make it much easier on yourself by eliminating the need to install and maintain an off-the-shelf package.

Step 4 - Test Environment

Set up a test environment that is separate from your development and production environment. This includes a separate web server, database server, and application server if applicable. You may or may not be able to utilize existing computers to setup a separate test environment.

Create an explicitly defined procedure for moving code to and from your test environment and make sure the procedure is followed. Also, work with your development team to make sure each new version of source code to be tested is uniquely identified.

Step 5 - Usability Testing

In usability testing, you'll be looking at aspects of your web application that affect the user's experience, such as:

How easy is it to navigate through your web application?

Is it obvious to the user which actions are available to him or her?

Is the look-and-feel of your web application consistent from page to page, including font sizes and colors?

The book, "Don't Make Me Think! A Common Sense Approach to Web Usability" by Steve Krug and Roger Black, provides a practical approach to the topic of usability. I refer to it often, and recommend it highly.

In addition to the traditional navigation and look-and-feel issues, Section 508 compliance is another area of importance. The 1998 Amendment to Section 508 of the Rehabilitation Act spells out accessibility requirements for individuals with certain disabilities.

For instance, if a user forgets to fill in a required field, you might think it is a good idea to present the user with a friendly error message and change the color of the field label to red or some other conspicuous color. However, changing the color of the field label would not really help a user who has difficulty deciphering colors. The use of color may help most users, but you would want to use an additional visual clue, such as placing an asterisk beside the field in question or additionally making the text bold.

For more details, refer to http://www.section508.gov. Another great resource that can help analyze your HTML pages for Section 508 compliance can be found at http://www.cast.org/bobby/. If you are working with the United States federal government, Section 508 compliance is not only good design, it most likely is a legal requirement. You may want to utilize the following information regarding techniques for accessibility evaluation and repair tools, which can be found at http://www.w3.org/TR/AERT.

Step 6 – Unit Testing

Unit testing is focused on verifying small portions of functionality. For example, an individual unit test case might focus on verifying that the correct data has been saved to the database when the Submit button on a particular page is clicked.

An important subset of unit testing that is often overlooked is range checking. That is, making sure all the fields that collect information from the user, can gracefully handle any value that is entered. Most people think of range checking as making sure that a numeric field only accepts numbers. In addition to traditional range checking make sure you also check for less common, but just as problematic exceptions. For example, what happens when a user enters his or her last name and the last name contains an apostrophe, such as O’Brien? Different combinations of databases and database drivers handle the apostrophe differently, sometimes with unexpected results. Proper unit testing will help rid your web application of obvious errors that your users should never have to encounter.

Step 7 - Verifying the HTML

Hyper Text Markup Language (HTML) is the computer language sent from your web server to the web browser on your users' computer to display the pages that make up your web application. The World Wide Web Consortium (www.w3.org) manages the HTML specification. One major objective of HTML is to provide the ability for anyone from anywhere to access information on the World Wide Web. This concept generally holds true if you conform strictly to the relevant version of the HTML specification that you will support. Unfortunately, in the real world, it is possible for a developer to inadvertently use a proprietary HTML tag that may not work for all of your intended users.

Verifying HTML is simple in concept but can be very time consuming in practice. A good place to start is with the World Wide Web Consortium's free HTML Validation Service (http://validator.w3.org). There are also other online and downloadable applications to help in this area such as Net Mechanic (http://www.netmechanic.com). There are two main aspects of verifying the validity of your HTML. First, you want to make sure that your syntax is correct, such as verifying that all opening and closing tags match, etc. Secondly, you want to verify how your pages look in different browsers, at different screen resolutions, and on different operating systems. Create a profile of your target audience and make some decisions on what browsers you will support, on which operating systems, and at what screen resolutions.

In general, the later versions of Microsoft Internet Explorer are very forgiving. If your development team has only been using Internet Explorer 5.5 on high-resolution monitors, you may be unpleasantly surprised when you see your web application on a typical user's computer. The sooner you start verifying your HTML, the better off your web application will be.

Step 8 - Load Testing

In performing load testing, you want to simulate how users will use your web application in the real world. The earlier you perform load testing the better. Simple design changes can often make a significant impact on the performance and scalability of your web application. A good overview of how to perform load testing can be found on Microsoft's Developer Network (MSDN) website.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnserv/html/server092799.asp

A topic closely related to load testing is performance tuning. Performance tuning should be tightly integrated with the design of your application. If you are using Microsoft technology, the following article is a great resource for understanding the specifics of tuning a web application.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnserv/html/server03272000.asp

People hate to wait for a web page to load. As general rule, try to make sure that all of your pages load in 15 seconds or less. This rule will of course depend on your particular application and the expectations of the people using it.

Step 9 - User Acceptance Testing

By performing user acceptance testing, you are making sure your web application fits the use for which it was intended. Simply stated, you are making sure your web application makes things easier for the user and not harder. One effective way to handle user acceptance testing is by setting up a beta test for your web application.

One article to help you get started planning an effective beta test is: Supercharged Beta Test by Joshua Grossnickle and Oliver Raskin, May 14, 2001 which can be found at: http://hotwired.lycos.com/webmonkey/01/20/index1a.html?tw=design. This article points out the critical aspects of setting up a beta test including how to identify beta testers and how to obtain their feedback. The main point to remember in user acceptance testing is to listen to what the people using your web application are saying. Their feedback will be critical to the ultimate success of your web application.

Step 10 - Testing Security

With the large number of highly skilled hackers in the world, security should be a huge concern for anyone building a web application. You need to test how secure your web application is from both external and internal threats. The security of your web application should be planned for and verified by qualified security specialists.

If you think security is a subject that is over-hyped, check out Steve Gibson's account of how a 13 year old hacker took his company's website down for an extended period of time at will. You can find this eye-opening security case study at:

http://grc.com/dos/grcdos.htm

Some additional online resources to help you stay up to date on the latest Internet security issues include:

CERT Coordination Center

http://www.cert.org/

Computer Security Resource Center

http://csrc.nist.gov/

After performing your initial security testing, make sure to also perform ongoing security audits to ensure your web application remains secure over time as people and technology change.

Testing a web application can be a totally overwhelming task. The best advice I can give you is to keep prioritizing and focusing on the most important aspects of your application and don’t forget to solicit help from your fellow team members.

By following the steps above coupled with your own expertise and knowledge, you will have a web application you can be proud of and that your users will love. You will also be giving your company the opportunity to deploy a web application that could become a run away success and possibly makes tons of money, saves millions of lives, or slashes customer support costs in half. Even better, because of your awesome web application, you may get profiled on CNN, which causes the killer job offers to start flooding in.

Proper testing is an integral part of creating a positive user experience, which can translate into the ultimate success of your web application. Even if your web application doesn’t get featured on CNN, CNBC, or Fox News, you can take great satisfaction in knowing how you and your team’s diligent testing efforts made all the difference in your successful deployment.

Krishen Kota is a 10-year veteran of the information technology consulting industry and is a Certified Project Management Professional. Krishen serves as President of AdminiTrack, Inc. (www.adminitrack.com), which provides a web-based issue and defect tracking application designed specifically for professional software development teams. Krishen can be contacted via email at kkota@adminitrack.com.