7.5. Useful Tools for Manual Testing

During the process of manually testing the application there are a number of tools which you can use to be more effective. An effective way to help manually test an application is application logging.

During execution, applications can log information to various sources. This information can be obtained to help you understand what is happening under the covers and ensure that the system is working as expected. There are a number of times when applications can appear to be working perfectly, however they are actually throwing different exceptions. Many people feel this isn't a problem because the user is not affected; however, there is a performance hit when every exception is thrown, while being bad practice to let exceptions be thrown without valid reasons.

One of the approaches to logging in ASP.NET is Web Events. Web Events capture a wide range of information about the website but fundamentally there are four main events which are of interest:

• Heartbeat. This is a regular event which captures the current state of the site with runtime information. This is useful when monitoring the site to verify how it is working during a long period of time.

• Audit. This event is based around security events, such as login failures.

• Errors. Unhandled errors which occur within your application are logged.

• Base Events. These base events allow you to write and develop custom events for your own application which can be logged with the main ASP.NET applications. To cause events to be logged you need to add the following section into your web.config for the site. The following snippet will log all the information into the Event Viewer for the site. This is good if you are expecting an internal operation team or support team to manage the server and the site; however, if it is on an external service and you don't have access to the event log then you can log events to SQL Server, WMI Providers, or send them via email as well as write your own custom endpoints:

  <healthMonitoring>
     <rules>
        <add name="All Events" eventName="All Events" provider="EventLogProvider"
  profile="Critical"  />
     </rules>
  </healthMonitoring>

  
  

After this has been configured you can use the event viewer as a source of information for identifying problems with your site. More information on web events can be found on the Microsoft support site (http://support.microsoft.com/kb/893664).

Other approaches are writing directly to a log file via a logging framework such as Log4Net (http://logging.apache.org/log4net/index.html). Best practice is that any exception or error which occurs during execution should be logged to help debug the issue at a later point. When testing you should monitor the log file to see what is being logged to the log file to aid testing. A useful approach is to use a program such as UltraEdit (http://www.ultraedit.com/) to tail the log file; every time information is written to the file then the application displaying the file updates the UI to show the contents, which will save you a lot of time and effort. As with the Event Viewer, you need to write the log file to a location which is accessible via the team, however, not viewable by the public.

Other services are starting to arrive to help with logging. An excellent tool is called Exceptioneer (http://exceptioneer.com/public/whatisexceptioneer.aspx) which helps you manage and resolve unhandled exceptions for you. When an exception occurs it is logged to the online service. You can then log in to the site and understand more about the exception and what types of exceptions are occurring.

Alongside logging, ASP.NET also has the concept of Trace. ASP.NET Trace allows you to view diagnostic information about a single request for an ASP.NET page. This allows you to write debug statements from your code which will appear in your output Trace. This allows you to write out variables, information, and any other information which you think you will need to debug any problems.