Web Application testing

Testing of web applications can be subdivided into the following sub-topics:

  1. Functional testing
  2. Usability Testing
  3. Interface Testing
  4. Compatibility Testing
  5. Performance Testing
  6. Security Testing (Penetration Testing)
Rocketlab - near shoring testing experts

1. Functional testing

The functional testing is the test set to check all existing links, the database connection, forms and input fields for the transmission or reception of information / data and last but not least cookies.

Testing existing links

Here, all links are checked, which go out of the application or website to the outside (external links) but also internal links, ie within the application or site. The goal here is to find any deadlines in order to clear them before going live.

Furthermore, links from e.g. Checking newsletters on the domain under test, target sites, landing pages from ad campaigns, teasers, etc. During operation, this can be done by appropriate monitoring and analysis tools.

Significantly more difficult is the finding of so-called orphan sites. These are sites that exist, but to which there are (at least internally) no link and which do not act as landing pages. Because these sites are not in the consciousness of the developers and testers, they represent potential danger areas, through which attackers could possibly get access to application, database or system.

Web forms testing

Forms are an integral part of most web applications. They serve as an exchange component of information between the website (client) and the application or web server (server). Forms can both record and accept and display information. Here an interaction between application and user takes place.

A few suggestions for tests related to forms:

  • Are entries in forms validated?
  •  Are there default values for all or certain input fields?
  •  What happens in case of incorrect entries (eg numbers in the e-mail field, etc.) or misuse? How do Entry Mask and Application handle it?
  •  Are there interactive forms that expand as you type?

Let me briefly illustrate this with the example of a search engine offering registration for both advertisers and affiliates. The registration process is multi-level for both groups, depending on the input previously entered. One group has more standard inputs, while the other group has vendor-dependent questions and related follow-up information.

The respective validations and follow-up questions can be checked well automated by means of filling lines (flows).

Cookie Testing

Cookies are small text files that are stored on the user’s computer. They serve primarily to support sessions. During the functional tests, the application should be tested both with cookie handling and without (enable / disable cookies under the Internet options). The behavior with cookies turned off should not lead to errors, especially since a new EU standard should put the user to the choice of whether or not to accept these cookies. That it can be assumed that there are a certain percentage of users who do not accept cookies. Nevertheless, the application must run error-free and in a predictable manner.

It should also be checked whether the cookie information is encrypted before it is written to the client machine. When testing with session cookies, the cookie content should be checked during and after a session in progress. This also includes the entry “cookie expires …”, a session cookie must therefore hold after logging out other information than during an active session.

The behavior during a session is interesting if the cookie is deleted (manually). What happens? Does it come to error messages, in particular to standard error messages? These can provide valuable information to potential attackers (file structure, operating system, etc.).

Valid HTML/ CSS

Search engines love valid code. That is why it is particularly important to have made all the necessary arrangements here. At least syntax and semantics errors should be checked (for example, with web tools). Also check if links have “nofollow” tags (rel = “nofollow”) which are supposed to prevent search engines from crawling sites. But this would lead to much worse search results and a bad ranking.

Database Testing

Data consistency is essential in web applications. This verifies the behavior when editing, deleting, or adding form items. How does the data consistency behave? Are the inputs validated and checked for completeness, dependencies, etc.? It is also necessary to check whether the SQL queries (SQL queries) are executed correctly. Here you will possibly find hints in the log files of the application and database. Also interesting is the high load behavior of the parallel request database. But this already belongs to the field of load and performance testing.

2. Usability Testing

Navigation Tests

This will track and walk through how users navigate the site. Both links and search queries, button clicks, etc. are taken into account. In the context of usability testing, it is just as important how easy and intuitive the user guidance is. If explanations are necessary or (direct) assistance offered, these should be readily apparent and included in e.g. pop up a pop up layer.

It also checks how easy to understand and contextual the help or guidance texts are. The main navigation should extend across all pages and be consistent. The currently visited area should be marked (for example, highlighted).

Content inspection

The content offered must be logical and easily comprehensible. Spelling or grammatical errors should be avoided. The use of dark colors (white text on a black background, for example) is a challenge for many users, as it is tedious when a site is not bright and light. Professional web designers basically follow the rules of visual design and content editing. Sampling tests according to the rules mentioned above are sufficient here, since design and content structure are almost always the same within an application.

Of course these are just a few examples of usability checks, which should all be done.

A few helpful hints that should be offered to the visitor are e.g. Search options (eg a facet search in the online shop), direct help (“i” icon, where after a click a layer pops up with text or other content that shows the user help) or a sitemap (of all main and subpages), the as XML at the same time search engines serves as an indexing aid.

3. API / Interface Testing

The main interfaces are the web server, interface to the application and an interface to the database.

Here it is necessary to test whether the interplay of the individual interfaces and protocols runs without errors. If errors occur, these must be intercepted at least programmatically. The error display with error code helps to fix errors faster. There are a variety of disturbances that the tester can deliberately provoke. What happens if a reset is performed on the web or database server during the run?

4. Compatibility Testing

A very important test aspect in the context of website testing is the compatibility of a website. The following basic compatibilities must be considered:

  • Browser compatibility
  • Compatibility of the operating system (s)
  • Mobile Browsing (Responsive Webdesign!)
  • Print option

Browser compatibility

This represents probably the largest block within compatibility testing. The most unplanned behavior and unpredictable consequences can occur here. Most applications depend on the browser and its behavior. Different browsers, different configurations and security settings challenge applications, which are the most common. In advance, the developer must already consider this, especially when working with AJAX, HTML5, CSS3, Rest, etc. This is also called cross-browser testing, so applications should be browser-independent (and always the same) to be functional.

Naturally things like security checks or validations are also important, which is why you should set one of your priorities in the area of compatibility. A solid test strategy includes cross-device testing (desktop, handheld, smartphone, etc.) as well as cross-browser testing.

Operating system compatibility

Some functionality could lead to certain operating systems (forget in this context, the operating system of the smartphone, tabs, etc.) to problems or the functionality is completely absent. Good and solid applications follow an architecture that runs on all operating systems.

In addition to the programmatic elements are also graphics (eg ran on the iPhone for a while no Flash), input masks, page layout (keyword “Responsive”) or use of native functions (eg Active X), which just are not available on every OS, to take into account. Of course, this should already be taken into account in the development, but you can rely on this only when you have completely covered everything by test scenarios and sufficiently tested.

 Mobile Surfing

As already mentioned, cross-browser testing is required in addition to cross-browser. The spread is still growing rapidly, some users use only mobile devices to access web content and applications. If your application is not equipped for this, you will lose a significant proportion of potential customers, especially in the Generation Y group.

 Print options

If a “print” function is offered within the application, it must be ensured that it not only works consistently but also prints correctly (without page sections).

5. Performance Testing

Applications are exposed to major attacks and attacks. This is also the so-called access load. During load and performance testing, it simulates how a large number of users perform a certain number of actions (per second or unit of time). Depending on the application, popularity, importance, a real scenario has to be simulated and the reactions of the server as well as the application and other components have to be checked.

Basically, one distinguishes the performance testing in

  • Web Load Testing
  • Web Stress Testing

When loadtesting a certain number (for example 1000) users are gradually directed to the web application, so that in the end all 1000 users access it in parallel and a certain (set) time remain on it and perform actions. Here you gain experience about how the application and server deal with peaks, how high the failure rates are and so on. An application must manage with parallels and synchronous accesses up to a certain number and the error and failure rate should be below one move the defined value.

In addition to the application, this also includes the exchange of data (queries, form input, output of PDF files, etc.), API and interface communication, memory (RAM), etc. Professional tools such as the HP Load Runner provide these indices.

In stress testing, the application and server are maxed out to the limit and so the finiteness is explored. Here you gain knowledge about expansion requirements and the basic performance of the site. The goal is to bring the application slowly to total failure, to see how the application responds and what behavior can occur. It is also possible to observe how the system recovers completely by itself and then reacts and runs. The concrete “stress” is mainly applied to input fields, login / logout features, and so on.

Performance tests are performed on different operating systems, different hardware (if necessary and available) with different configurations to test memory errors and failures.

6. Security Testing

Theme Security or Penetration Testing is a big topic in its own right, which can only be expertly carried out and assessed by experienced specialists. There are specialized companies that put their security-critical applications (such as banking, e-commerce, etc.) through their paces.

Some (easy to understand) examples are here ie.

  • Copying a URL of a password-protected area and inserting it in the non-logged-in state. Protected areas may not be accessible without access (login)
  • Manipulating the URL in the registered state. For example, changing the site ID or similar parameters, e.g. via a query string in the URL.
  • Abuse of the login mask, i. deliberately wrong entries and the observation of how the system responds.
  • Folder content listing on the Web server is not allowed (option indexes)
  • Is there a captcha field and can this be used via automation?
  • Is SSL used stringently for information-critical content?
  • All transactions, error messages, dropouts, warnings, etc. should be stored in log files and made visible to the server admin or operations manager