Test Areas for web page software testing

Functionality testing:

  1. Links

Links are maybe the main feature on web sites. They constitute the mean of transport between pages and guide the user to certain addresses without the user knowing the actual address itself. Linkage testing is divided into three sub areas.

First - check that the link takes you to the page it said it would.

Second – That the link isn’t broken i.e. that the page you’re linking to exists.

Third – Ensure that you have no orphan pages at your site. An orphan page is a page that has no links to it, and may therefore only be reached if you know the correct URL. Remember that to reduce redundant testing, there is no need to test a link more than once to a specific page if it appears on several pages; it needs only to be tested once.

Link testing should be done during integration testing, when connections between pages subsist.

  1. Forms

Forms are used to submit information from the user to the host, which in turn gets processed and acted upon in some way. Testing the integrity of the submitting operation should be done in order to verify that the information hits the server in correct form. If default values are used, verify the correctness of the value.

If the forms are designed to only accept certain values this should also be tested for. For example, if only certain characters should be accepted, try to override this when testing. These controls can be done both on the client side as well as the server side, depending on how the application is designed, for example using scripting languages such as Jscript, JavaScript or VBScript. Check that invalid inputs are detected and handled.

Check the following:

  1. Information hits the server in correct form
  2. Acceptance of invalid input
  3. Handling of wrong input (both client an server side)
  4. Optional versus mandatory fields
  5. Input longer than field allows
  6. Radio buttons
  7. Default values

  1. Cookies

Cookies are often used to store information about the user and his actions on a particular site. When a user accesses a site that uses cookies, the web server sends information about the user and stores it on the client computer in form of a cookie. These can be used to create more dynamic and custom-made pages or by storing, for example, login info. If you have designed your site to use cookies, they need to be checked.

Verify that the information that is to be retrieved is there. If login information is stored in cookies check for correct encryption of these. Does it still function or will the user get notified of the current situation. How will temporary cookies be handled? What will happen when cookies expire? Depending on what cookies are used for, one should examine the possibilities for other solutions.

Summary:

  1. Encryption of e.g. login info
  2. Users denying or accepting
  3. Temporary and expired cookies

  1. Web Indexing

There are a number of different techniques and algorithms used by different search engines to search the Internet. Depending on how the site is designed using Meta tags, frames, HTML syntax, dynamically created pages, passwords or different languages, your site will be searchable in different ways.

Summary:

  1. Meta tags
  2. Frames
  3. HTML syntax
  4. Passwords
  5. Dynamically created pages

  1. Programming Language

Differences in web programming language versions or specifications can cause serious problems on both client or server side. For example, which HTML specification will be used (for example 3.2 or 4.0)? How strictly? When HTML is generated dynamically it is important to know how it is generated.

Summary:

  1. Language specifications
  2. Language syntax (HTML, C++, Java, Scripting languages, SQL etc.)

  1. Dynamic Interface Components

Web pages are not just presented in static HTML anymore. Demands for more dynamic features, custom made sites and high interactivity have made the Internet a more vivid place than before. Dynamic Interface Components reside and operate both on server

and client side of the web, depending on the application. The most important include Java applets, Java Servlets, ActiveX controls, JavaScript, VBScript, CGI, ASP, CSS and third-party plug-ins (QuickTime, ShockWave or RealPlayer). The issue here is to test and verify the function of the components, not compatibility issues. An example of what to test can be a Java applet constructing and displaying a chart of company statistics, where the information first have to be retrieved and then interpreted and displayed on the screen. Since server-side components don’t have user interface, event logging (logfiles) can be used to record events by applications on the server side in order to determine functionality.

Resources: Java Specific tools: JavaSpec and JavaStar.

Summary:

  1. Do client side components (applets, ActiveX controls, JavaScript, CSS etc.) function as intended (i.e. do the components perform the right tasks in a correct way)
  2. User disabling features (Java-applets, ActiveX, scripts etc.)
  3. Do server side components (ASP, Java-Servlets, server-side scripting etc.) function as intended (i.e. do the components perform the right tasks in a correct way)

  1. Databases

Databases play an important role in web application technology, housing the content that the web application manages, running queries and fulfilling user requests for data storage. The most commonly used type of database in web applications is the relational database and it’s managed by SQL to write, retrieve and editing of information.

In general, there are two types of errors that may occur, data integrity errors and output errors. Data integrity errors refer to missing or wrong data in tables and output errors are 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.

Issues to test are:

  1. Creation of tables
  2. Indexing of data
  3. Writing and editing in tables (for example valid numbers or characters, input longer than field etc.)
  4. Reading from tables

RELATED POST

UNIT TESTING PART ONE

UNIT TESTING PART TWO

UNIT TESTING PART THREE

GUI TESTING

WINDOWS COMPLIANCE GUI TESTING PART ONE

WINDOWS COMPLIANCE GUI TESTING PART TWO

WINDOWS COMPLIANCE GUI TESTING PART THREE

WINDOWS COMPLIANCE GUI TESTING PART FOUR VALIDATION TESTING

WINDOWS COMPLIANCE GUI TESTING PART FIVE CONDITION TESTING

WINDOWS COMPLIANCE GUI TESTING PART SIX GENERAL CONDITION TESTING

CONDITION TESTING

TESTING CONDITIONS PART ONE

TESTING CONDITIONS PART TWO

TESTING CONDITIONS PART THREE

TESTING CONDITIONS PART FOUR

SPECIFIC FIELD TESTING

USABILITY TESTING

INTEGRATION TESTING

INTEGRATION TESTING PART ONE

INTEGRATION TESTING PART TWO

INTEGRATION TESTING PART THREE

INTEGRATION TESTING PART FOUR

INTEGRATION TESTING PART FIVE

INTEGRATION TEST STANDARDS

INTEGRATION TEST STANDARDS PART TWO

Labels:

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)