The ASPHelp system offers numerous benefits to ASP developers, QA professionals, report writers, and information architects. It can be used to ensure that a quality web application is developed by documenting the interface to each page in the system.
The information architect is generally charged with defining the flow of the web application. They will describe each page, where the page transitions are, and the information that is collected and displayed on each page. The challenge is transferring the architecture to the actual developers building the application.
Enter ASPHelp. With ASPHelp, the information architect can place stub documentation for the entire interface to the page into an empty ASP file that the developer can build out. The IA can describe each page transition of the flow, including error conditions. They can define the anchors on the pages, the various forms that may be present, even the expected means of accessing data across pages. They can define all the input variables, including what they mean, and if they are part of a form, or are a query parameter. Repeat this process for each page in the application, and you have the flow of the web application completely defined before a single line of code is written. All the ASP developer needs to do is transfer the interface into ASP, then marry the ASP to HTML for display.
With the enhanced annotation tags present in version 1.5 and above, information architects and system designers are able to completely describe the interactions and data flow between pages. Version 1.5 includes the ability to assign the following items:
- Default values for Form and Query String data
- Default actions for Forms
- Communication methods for Forms
QA professionals provide an incredibly valuable service to the web application development effort, but are frequently operating with less than ideal levels of information as to the desired behavior of the site they are working with. To help deal with this strain, they often resort to using tools to characterize the site and hopefully glean this missing information.
One of the most common tools used is the spider. This tool literally crawls the site listing out the various links encountered. Unfortunately, the spider can only look at one possible representation of a site. If the site is personalized, and that personalization extends to the actual pages displayed to the user, the spider will not be able to list all paths of execution. There is no way for the spider to actually know the intent behind the page, or for it to know if all the expected parameters are being passed to any given page. It merely documents what is. How then can the QA professional determine if they have spent sufficient attention to a given page?
Enter ASPHelp again. By taking the interface contract defined by the information architect, the QA professional can determine the intent behind each page, and each parameter in the page. If the information architect documented everything prior to development, then the QA professional can be developing their test cases and determining effective coverage plans before the application is even close to being completed.
Once the web application is delivered to QA, the QA professional can run ASPHelp against the delivered code and can compare the defined interface to the implemented interface, perhaps uncovering missing parameters, new parameters, or new pages.
Report writers are often working to determine how a site is being used. They have tools that pour through the web logs generated by the web application looking for trends that can be used to the site owners advantage. This task is made easier if the interface to the pages is defined. Things like the use of cookies or parameters passed by querystring (GET), are important. The interface contract established by the information architect is invaluable to a report writer, but often the interface contract is defined as an after thought.
ASPHelp can resolve this inconsistency by allowing the report writer to run ASPHelp against the web application and using it to determine those parameters expected by a given page. They then can use this information to minimally define the list of expected parameters, but additionally to inquire from the web developer as to each unknown parameters' meaning.
© 2001 - 2009 Pikauba Software. All rights reserved.