Web Application Testing Guidelines. What do we actually see, an error or a symptom? Types of web application testing

As an automated tester, you have to catch various bugs every day, even in your own framework. This doesn't say anything about your competence or that the company isn't putting enough resources into testing. Most of the problems lie in loosely coupled code, complex processes and integrations. Additionally, the continuous integration process requires a lot of effort and time to ensure that the application works correctly in different environments. In turn, with the use of new technologies in development, writing automated tests for web applications becomes more complicated.

All this requires some experience and practice.

Listed below are 7 life hacks that are used to automate web tests, and which should justify the investment made in it.

Executing Real Scenarios

It is very important to know the real scenario in order to automate the test case correctly. If possible, you should avoid mocking and do everything on a “live” application. In this case, you can be confident in the results of the autotest and that the test went as expected.

Run autotests daily after the last commit

There is a twofold situation here. On some projects, commits are merged throughout the day. And there is no such thing as a “day commit”. In this case, you should select a time to run autotests. On the one hand it seems tedious, but on the other hand it is very useful for frequent updates applications. Bugs are caught in the early stages, when problem areas have not yet taken root.

Reduce test execution time and increase test coverage

Sometimes this is difficult to achieve; it requires certain experience and technical knowledge. At correct use testing methodologies and optimal use software tools It is possible, if not to reduce the test run time to a minimum, then at least to somehow reduce it. The type of testing also plays an important role: API and end-to-end testing are much faster than UI testing.

Check browser and platform compatibility

The environment in which autotests test a web application must be able to quickly be modified so that we can check its functionality on all potential platforms where the application can be used. The application must also be compatible with major browsers.

Make a report on the bugs found at the very beginning

Bugs need to be documented as soon as they are discovered. In this case, the profit from using autotests will not be lost. Information about the presence of defects in the application, provided immediately when bugs are detected, is very valuable, because allows you to save enough resources to fix errors.

Reusing Test Methods and Scripts

Reused test methods (meaning scripts and components of classes in a language) are the basis for optimizing investments made in automated testing. In this case, the time and effort required to write automated tests is gradually reduced. The resulting tests are very flexible and easily modified.

Regular reporting

Finally, it is also important to communicate with stakeholders about the progress of test automation, identification of critical areas and a plan to overcome the current situation. This applies not only to the bugs found, but also to the process of writing and running automated tests and the interaction of automated tests with the application under test.

7 Automated Web Application Testing Hacks You Should Know

http://site/wp-content/uploads/2017/04/website-test-automation-150x150.jpg

In this article we will look at site testing(web applications) using test suites. It is quite long, so make sure you sit comfortably.

Main types of website testing (web applications)

Functionality testing;
Usability testing;
Interface testing;
Compatibility testing;
Testing website performance and loading speed;
Security testing.

1. Functionality testing

Check all links

Check the links coming from all pages to a specific domain.
Internal links.
Links to other elements located within pages.
Submission links Email administrator or other users of web pages.
Check for links to isolated pages.

Check the forms

Forms are used to obtain information from users and interact with them.

Things to check in forms:

Validation works correctly in each form field.
Default field values.
Options for creating forms, deleting, viewing and editing forms ( if there are any).

Let's look at an example of a search engine project I'm currently working on. The project has stages of registering advertisers and partners. Each registration step is different from the others, but depends on the other steps. Therefore, the entire registration process must be carried out correctly.

There are various types of validation, such as checking the user's email, financial information, etc. All fields with validation must be tested manually or automatically.

Cookie testing

Cookies are small files stored on the user's computer. They are most often used to support authenticated sessions. Test the application by turning cookies off and on in your browser options.

Check whether Cookies are encrypted before being stored on your computer. Test login sessions and user statistics when the site session ends. Check to see if deleting cookies affects your app's security.

Check HTML/CSS

If you are optimizing your site for search engines, then HTML/CSS validation is especially important. First of all, check the site for availability syntax errors in HTML code. Check if the site is accessible to various search engines.

Database testing

The interaction of a web application with a database is very important point. Check data integrity and perform testing the site for errors when editing, deleting, changing forms or other actions related to the database.

Check that all database queries are executed correctly and data is retrieved and updated as expected.

When testing the functionality of sites, you need to check:

Forms

Field validation;
Error messages for incorrect input;
Required and optional fields.

Database

The integrity of the database should be checked.

2. Usability testing (website usability)

Usability testing is the analysis of interaction between the user and the site, finding errors and eliminating them.

This checks:

Ease of learning;
Navigation;
Subjective user satisfaction;
General form.

Checking navigation

Navigation refers to the means for the user to view pages. These are buttons, blocks. And also how a site visitor uses links to other pages.

Usability check:

The site should be easy to use;
The instructions must be very clear;
Check whether the instructions provided achieve their intended purpose;
The main menu should be available on every page;
The main menu should be built in a logical sequence.

Content verification

Content should be logical and easy to understand. Check the text for errors. Application dark colors annoying to users, there is no need to use them in the theme.

For the content and background of the page, it is better to use generally accepted standards so that the color of the font, frames, etc. did not irritate users.

Content should be meaningful, links should work properly, images should be of appropriate size. These are the basic standards followed in web development. Your task is to check everything as part of testing user interface.

Other information for users

Search options, site map, reference materials etc. Check that all links in the site map work. The “Site Search” function should help you easily find the content you need.

3. Interface testing

You need to check whether communication with the server is carried out correctly. You should check the server's compatibility with the software, hardware, network, and database you are using.

Main interfaces:

Web server and application interfaces.
Database server and application server interfaces.

If the database or web server returns an error message for any request coming from the application server, the application server must capture it and display it to the user.

Check what happens when the user interrupts an action. And also what happens when reconnection to the server during the execution of any operation.

4. Compatibility check

Need to check:

Browser compatibility;
Operating system compatibility;
View on mobile devices Oh;
Printing options.

Browser compatibility

Some web applications may vary depending on your browser type. The site must be compatible with different configurations and settings of various browsers.

The site layout must be cross-browser compatible. When using Java scripts and AJAX to provide user interface functionality, security checks or validations are created heavy load on the system.

Check the web application in browsers Internet Explorer, Firefox, Netscape Navigator, AOL, Safari, Opera of different versions.

Operating system compatibility

Some features of the web application may not be compatible with certain operating systems. Not all of them support new technologies used in web development. So check the application running on Windows, Unix, MAC, Linux, Solaris and their various versions.

View on mobile devices

Swipe testing the site on mobile devices and check how web pages are viewed using mobile browsers. Compatibility issues can also arise due to mobile devices. Also don't forget about testing the site at different resolutions.

Printing options

If you plan to print the page, make sure that fonts, alignment, graphics, etc. appear properly on the paper. Pages must fit the dimensions set in the print options.

5. Website performance testing

Testing the performance of a site or web application should include:

Stress Testing.
Stress testing.

Check application performance on different speed Internet.

Site load testing(web applications) is testing in which a large number of users simultaneously make a request to the same page. Can the system handle peak loads?

Stress testing - system load that goes beyond established limits. Stress testing is performed with the goal of achieving failure in the operation of a website or web application by increasing the load. And also check how the system reacts to stress and how it recovers from failures. Fields for entering information, logging in and registering are subject to stress.

ab functionality testing also includes checking for errors related to RAM.

A performance test can be used to test site scalability or evaluate productivity when using a third-party software.

Connection speed

Split site testing using various options Internet connections: via modem, ISDN, etc.

Load

The number of users simultaneously visiting the site;
Check the system operation when peak loads;
The user accesses a large amount of data.

Stress load

Performance of memory, processor, file processing, etc.

6. Security testing

Below are some web security testing suites:

Validation by inserting internal URL into address bar browser without authorization. The internal pages should not be opened.
After authorization using your login and password, as well as viewing internal pages try changing the URL. For example, you check some site statistics under ID= 123. Try changing the URL ID to a different site ID that is not related to the authorized user. In any case, this user's access to viewing other indicators should be denied.
Try entering incorrect data into the login form fields. Find out how the system reacts to invalid data input.
Directories or files should not be directly accessible unless they are downloadable.
Check the operation of the captcha to protect against automatic login using program code.
Check if SSL is used for security purposes. If so, a message should be displayed when the user navigates from unsecured to secure HTTP pages and vice versa.
All operations, error messages, security violations should be recorded in a log file on the web server.

The main reason for website security testing is to find potential vulnerabilities and then eliminate them.

Network scanning;
Vulnerability scanning;
Possibility of potential password hacking;
Magazine Review;
Integrity checking tools;
Virus detection.

Points to consider when testing a site

You should pay attention to the interaction of HTML pages, Internet connection, firewalls, applications running on web pages ( applets, JavaScript, modular applications ), as well as applications running on the server side (scripts CGI, database interfaces, dynamic web page generators).

There are many types of servers and browsers different versions. There are small but significant differences between them.

Example site testing scripts

Additional factors to consider when testing your site:

What is the expected load on the server ( for example, the number of requests per unit of time)?
What performance is required for various types load ( web server response time, database response time to a request)?
What tools are needed for performance testing?
Who is target audience? What browsers will users use? What is the connection speed? Is the site intended for use within the organization or will it be available on the Internet to a wide range of users?
What performance does the client expect to receive ( how quickly pages should load, how animations, applets, load and launch should behave)?
Will server downtime and maintenance and content updates be allowed? If yes, in what quantity?
What security measures are required ( firewalls, encryption, passwords, etc.), and what kind of work will they do? How can they be checked?
How reliable should your Internet connection be? How will it affect backup systems?
How will site content updates be managed?
Requirements for Maintenance, tracking and monitoring the content of web pages, graphic elements, links, etc.
Which HTML specification will be followed? How accurate?
How will internal and external links? How often?
How will CGI applets be managed and verified? JavaScript scripts , ActiveX components etc.?
The maximum web page size should not exceed 3-5 screens, unless the content is focused on a single topic. If the web page is larger, provide internal links to navigate it.
Web page layout and design elements should be consistent and logically connected.
Web pages should be displayed regardless of browser type.
Each page should include a contact link.

Translation of the article “ Web Testing Complete Guide (Web Application Testing Tips and Scenarios)” was prepared by the friendly project team

Web application testing is the process of testing client-server products made available over the web, often involving support for many interdependent elements. Efficiency, cost-effectiveness and overall user satisfaction information systems largely depends on the quality of their development. Software error can lead to financial losses for the company, and, conversely, the use of generally accepted standards, convenient functional and design requirements and solutions - to an increase in the number of active users.

Testing takes into account a wide range of distributed system components that interact with the application. If an error occurs in network environment it is often impossible to determine the place of its occurrence without the participation of a qualified specialist, since it can occur in any part client-server application. In the process of testing web applications, QA engineers take into account the features of the project's architecture and the mechanics of interaction between the database, the server part of the application, web services, third-party components and the user interface.

Webmart QA approach to testing web applications

As part of testing web applications, our team carries out:

Functionality testing(checking the implementation of the functional content of the application for compliance with requirements and generally accepted standards).
Cross-browser and cross-platform testing(identifying defects and differences in system behavior when the user interacts with the product in different operating systems, browsers and on different devices).
Testing web services (checking the correctness of services called by the web application for correct data processing, changing the status of objects, returning information from the database, etc.).
Integration testing, E2E (testing of end-to-end scenarios for a set of interacting subsystems, including validation of connections and connections, preparation of test data in certain components and verification of the results of business processes step by step for the entire system as a whole).
Usability testing(checking usability, detecting flaws in navigation and interface, as well as excessive or insufficient information content).
Load and stress testing ( testing the stability and resistance to system failures under normal operating conditions and peak loads over a long period of time).

A typical process for working with a web application submitted for testing is as follows. Our specialists conduct a full functional test and analysis of the system in order to identify all existing problems. In the future, they monitor the completeness of their correction at subsequent stages of development. For each project, a separate work schedule and test documentation format are developed.

However, Webmart QA specialists prefer to be sure that application fixes do not lead to the emergence of new defects. Therefore, as a rule, our work ends regression testing– checking that the improved system works as it should: the implemented improvements did not introduce errors in related functionality, and the corrected defects did not lead to the emergence of new ones.

Only suitable combinations

Our team never offers everything: we implement only those approaches that are truly appropriate and applicable in each specific case:

The simplest applications will be recommended standard procedures, which will allow you to achieve the desired quality without extra costs.
For applications with more serious functionality, an expanded testing strategy will be developed, and an iteration and work schedule will be prepared. For such projects, employees of the analytical department will be involved.
In turn, representatives of expert teams and development department employees will be involved in working on complex projects, on the results of in-depth research of which a unique testing strategy will be built and life cycle project with the distribution of work and types of testing to achieve the goals within the specified time frame.

To find out which approach we consider optimal for you, contact us in any convenient way. the above methods or leave a request in one of the proposed forms.

Course Description:

Rarely nowadays modern application works without API. This is true both for a simple site and for highly loaded ones. distributed systems. API testing is one of the main tasks in the quality assurance process. It is not surprising that the demand for testers who know how to test APIs is increasing day by day. On this course you will gain an understanding of methods, tools and approaches in API testing, acquire necessary knowledge, which will undoubtedly have a positive effect on your cost as a testing specialist.

This course will be useful for students familiar with the basics of software testing who want to grow further and improve their skills.

Course program:

Lesson 1. Introductory. SOAP protocol

Briefly about the lecturer;
Course objectives;
What is API, WS and why are they needed;
The role of API testing in the quality assurance process;
Review of WS testing tools;
Methods used in WS testing;
History of SOAP;
Terminology and main concepts (XML, XSD, Endpoint, WSDL).

Lesson 2: SOAP Protocol. REST architecture

Terminology and main concepts (UDDI, XSLT, XPath, XQuery, HTTP methods, HTTP statuses);
Structure and main components of SOAP;
Scope of application;
Features of work;
Advantages and disadvantages;
Features of REST architecture;
Terminology and main concepts (WADL, RESTful, JSON, JSONPath);
REST principles;
Status code and main statuses;
CRUD verbs;
Advantages and disadvantages.

Lesson 3. Introducing SoapUI. Working with a REST project

Java installation;
Installing SoapUI;
Overview of the main interface elements;
Connecting an educational project;
Review of project methods;
Sending a request and analyzing the received response;
Studying the available web services of the project;
Drawing up a test plan;
Writing test cases;
Elements “TestSuite”, “TestCase”, “TestSteps”.

Lesson 4. Working with REST project (XML)

“Assertions” block;
Running tests at various levels;
Element “Properties”, main capabilities;
Working with Properties;
“Property Transfer” element;
Working with Assertions.

Lesson 5. Working with REST project (JSON)

Conditions and branches;
Working with Assertions;
TestRunner, features of work;
Launch TS, TC from the command line;
Working with Test runner;
Working with Groovy scripts.

Lesson 6. Working with Groovy scripts

Working with static and dynamic data;
Generating test data;
We get data from “Properties”;
Data recording and transfer;
Conditions and branches;
Script Assertion.

Lesson 7. Additional features

Connecting external libraries and custom classes;
Mock services;
Why Mock services are needed;
An example of working with a Mock service;
What about CI?
Install Jenkins;
Launching a project on Jenkins.

Testing web applications has much in common with testing operating systems for desktop computers. You need to test standard functionality, configuration and compatibility, and all other standard types tests. But testing web applications is more difficult process, because the difficulties are multiplied by all the distributed components of the system interacting with the application. When we see an error in a network environment, it is often difficult to pinpoint exactly where it occurred, and therefore the behavior or error message we receive may be the result of errors that occurred in different parts network system. In this case, correcting the error will be problematic. So how should we analyze errors within a system based on Internet technology, and what research should be carried out to correct these types of errors?

When we understand the device basic technology, we are much more able to increase testing efficiency by writing easier-to-reproduce crash and error notifications. In turn, this allows us to detect faults faster. But this is much easier to declare than to implement. Especially in the Internet environment. It is full of technological variables, in sufficient degree error prone. Here are 5 basic, fundamental judgments about testing Web applications:

When we see an error on the client side, we see a symptom of the error, but not the error itself.
Errors are environment dependent and may not occur in different environments.
Errors may be in the code or in the configuration.
Errors can reside at any of several levels.
Consideration of 2 classes of operating environments - static and dynamic - requires different approaches.

Let's look at these 5 statements in more detail:

1. What do we actually see, an error or a symptom?

Without environmental diagnostics, we cannot say with complete certainty what exactly is causing the symptom. If any of the specific environment variables on the client or server side is moved or changed, then there is a possibility that we will not be able to reproduce the problem.

Here's an example. I'm testing a web application for defect tracking and am in the process of creating a new bug report. When you click NEW, an error message appears that looks like this:

Microsoft OLE DB Provider for ODBC Drivers error "8004014".

After spending some time exploring the browser's hardware, I discover in the browser's preferences dialog that JavaScript is not enabled. Activating JavaScript resolves the error. The basic idea is that I add Additional information O setting up JavaScript regarding the problem message. In addition, the item “deactivating JavaScript” is included in my test set in the future, it will be added to all parts of the application so that everything is potentially related errors could have been discovered.

2. Is the error environment dependent?

To play environment dependent error, we need to perfectly duplicate both the exact sequence of actions and the conditions of the environment in which the application will work (operating system, browser version, additional components, database server, web server, tertiary components, server/client resources, network bandwidth, traffic, etc.). For example, if you try to log into your web application using a dial-up connection at a speed of 28.8 kbps, you will experience registration failures until the authorization process is interrupted due to the expiration of the time allocated for this purpose . However, registration on the network, carried out in the same manner, but using a T-1 connection at a speed of 1.54 Mb/s, will be successful. In this case you have an environment dependent error where the dependency is related to throughput networks.

On the other hand, environment-independent errors are comparatively easier to reproduce. No need to duplicate operating environment. For environment-independent errors, all that is needed is to duplicate the steps that will reproduce the error. For example, if the name of a company on all sites with its products is written incorrectly and looks like this - WebTesting.Con, then you Always You will see this error regardless of the hardware, software, or resource variables in your operating environment. In other words, we perceive environmentally independent errors as functionally specific.

3. Is this a coding error or a configuration problem?

Errors (or symptoms of suspected errors) can be corrected by using the coordinates of their location in the program (assuming that errors actually exist) or by reconfiguring the system (client, server, or network). You should not make hasty conclusions, believing that this is a mistake.

Microsoft OLE DB Provider for ODBC Drivers error "80004005"

Here is an example illustrating the difficulties in identification possible configuration issues versus real software problems. We see an error message, the reason for which is the inability to register ("failed login"). This message was generated by a web application. However, just by looking at this error message, it is impossible to determine whether it is actually an error or whether it is the result of a software failure, server-side configuration problems, incompatibility problems, browser configuration problems, or all of these to a greater or lesser extent.

After further analysis of the failure, I found several possible reasons which may have generated this error notification:

The web server (IIS) virtual directory was not installed properly.

When the virtual directory is not configured correctly, the requested files, scripts or data will not be found. Usually this is a server configuration issue. Although, if the installation program was unable to automatically configure the web server according to the specification, then this software error. If system administrator the web server cannot be properly configured according to the specification, then the error turns into user error.

The application directory was not configured properly to run scripts correctly.

The standard directory of the application server contains scripts that are executed when they are called by the web server at the request of the client. For security reasons, the web server can be configured to either allow or block the execution of scripts within individual directories. Therefore, if your application server is created in such a way that it contains scripts that must be executed, and the web server is configured to block their execution in this directory, then the application will not work. What is it then? software error or configuration problem?

The default web page was not installed properly.

The problem is similar to the problem described above.

SQL Server is inactive.

The application server requires a connection to a database node located on SQL server to execute queries, save procedures, and access data. If the SQL service process is not running, then obviously the application will not run.

DLL/COM objects are missing or were not registered successfully.

Perhaps the installation program was unable to copy everything DLL file s used by the application server during installation. If any necessary for the operation of the server Application DLLs the file is missing, the application will not work.

It is possible that the installation program correctly copied all the required modules, but was unable to register one or more of them. For example, in OLE-based objects such as COM or DCOM, their class ID (CLSID) must be registered in the database system registry before they become available for use. If an application tries to access a COM object that has not been successfully registered, it will not work.

This problem often occurs as a result of errors during installation. On the other hand, if components have to be registered manually, then it becomes configuration problem.

JavaScript settings on the browser side have been disabled.

This is a browser-specific configuration issue that occurs as soon as an application requests the browser to enable JavaScript. Is this a software bug, a configuration issue, or a technical support issue?

4. What level is really causing the problem?

Often, errors in web systems are difficult to reproduce consistently, since a large number of variables are represented by the distributed nature of the client/server system structure. There are at least 3 "usual suspects" in the web environment. This client, server And net.

Both the client and the server are subject to configuration and compatibility inconsistencies that are similar to PC environments where all the components are in the same box. However, these inconsistencies are magnified within client/server systems because there may be many clients and servers connected to the network. Typical configuration and compatibility inconsistencies lead to confusion technical support and operating system (e.g., UNIX-based versus Windows-based units) and server-side software mix (web server packages, database server packages, firewalls, COM objects, CORBA objects, etc.) . Inconsistencies can also lead to client-side software mix-ups (TCP/IP queues, dialer software, help components, browser brands and versions). In addition, browser settings such as General settings, connection settings, security settings (including ActiveX controllers, additional software modules(plugins), Java, scripts, downloads, user authorization, etc.), content settings, software settings and other advanced settings (including viewing options, multimedia options, Java VM options, printing options, and HTTP options) provide many variables that should be tested and included in studies.

Networks offer a different set of variables. They affect web applications in several ways, including time-related problems(link status, operation, downtime, etc.) which we owe due to bandwidth and latency, possible configuration and compatibility issues of hardware such as gateways and routers, and side effects associated with the operation of the security service.

5. Static and dynamic operating environments are different from each other.

There are 2 classes of operating environments, each with its own unique test inclusions:

Static Environments in which incompatibility problems may exist regardless of variables such as processing speed and available memory.

Dynamic Environments. In them, the opposite is true - compatible components can detect errors according to memory-dependent errors and hidden conditions. (We'll discuss dynamic environments in more detail later in this section.)

Static Operating Environment: Configuration and Compatibility Variables.

Configuration and compatibility problems can occur at any point within the Web system: they can appear on the client, server, or network side.

Configuration issues affect various settings server software and hardware, browser settings, network connections and TCP settings/ IP queues. The browser and JavaScript example discussed earlier illustrated one type of configuration problem. Another type is shown in Scheme 1 And Scheme 2 . They are presented in two possible physical server configurations: one- and two-unit.

Scheme 1: Web server, application server and database server on one platform

Scheme 2: WEB server and application server on one platform, database server on another

Our sample application under test has some charting capabilities that allow the user to create metric reports such as bar and line charts. When a user requests a metric report, the application server pseudocode runs in the following sequence:

1. Connect to the database server and make a request.

2. Recording the result of the request in the form of a file with the name c:\temp\chart.val

3. Executing Chart Java Applet. Reading and using data from a file c:\temp\chart.val to be able to draw a graph.

4. Sending a Java Applet to the browser.

In the process of testing the application, I discovered that a feature in plotting the graph was that it only worked with one of the above configurations. Upon further review, it became clear that the problem was specific to the two-unit configuration. After checking the code, it turned out that the problem was in points 2 and 3. In the second point, the query result c:\temp\chart.val the local disk drive of the database server was written. In the third point, Chart Java Applet was launched on the application server, which was located on different blocks from the database server. When I try to open a file c:\temp\chart.val on the local disk drive of the application server it turns out that this file is simply not there.

In this case, I don't suggest you read the code every time you encounter an error. Let the developers do the work of fixing problems. I just want to point out the need to identify which server has configuration problems and include this information in problem reports. I would also run a shallow test suite on all distributed configurations supported by the application server under test.

Compliance issues are also important in static operating environments. As an example we can consider Scheme 3 , where we see the difference in compatibility between Netscape Navigator and Internet Explorer.

Diagram 3: Browser Compatibility Issue

This in no way means that the Internet Explorer is better than Netscape Navigator. This just means that there are inconsistency issues between browsers, and that the code may not be intended to work relative paths(to file) for all browsers. More importantly, this means that if you encounter a bug in one environment, in another environment it may not arise provided this is an environment dependent error.

Dynamic Operating Environment: Things don't stay the same.

When the value of a specific environment attribute does not remain constant during each test procedure, this results in the operating environment becoming dynamic. The attribute can be anything from resource-specific (available RAM, disk space, etc.) to timing-specific (network latency, order of user transactions, etc.)

When a test case depends on accurate playback as set of actions, so operating environment, and the environment cannot be reproduced (due to its dynamic nature), then the error becomes irreproducible or difficult to reproduce.

Incidentally, this is the reason why memory-related errors are often difficult to reproduce. When, for example, there is a memory overwrite error in the code, it will always create a corresponding problem. However, from a black box testing perspective, we will not be able to see the symptom of this error until the specific overwritten code byte(s) or data is executed or read. In this example, the collection of actions represents the exact set of black box functions. A memory overwrite error represents an actual error in the code. The condition under which the overwritten byte is executed or read indicates a dynamic operating environment or a condition necessary to reproduce the error.

Here is an example of a dynamic environment-dependent web application error in which we will consider a time-related error.

Specification Requirements:

Project names within the system must be unique.
Error detection and handling for potential client-side copying should be done using JavaScript.
Users can add or remove project names by requesting a page SettingUpProjects.
When the user creates a new project name, JavaScript on the browser side checks the entered name against a select list located on HTML page(as shown in Scheme 4 )

Look at the time related error shown in Scheme 5 . These are screenshots of the page Setting Up Projects made before And after, allow us to see that the application was unable to detect the duplicate title "Doomed". IN Scheme 4 provides an explanation for this time-related error that causes both users to add new project names to the same database.

Scheme 4: Java-script on the browser side checks the entered values

Diagram 5: Time related error

As shown in Table 1 , user A and user B create new projects, albeit simultaneously, but without knowledge of each other’s actions. According to point 3, user A adds a project called Another. But since such a name already exists, his browser's JavaScript displays a message telling him to use a different name.

Table 1: Activities of Users A and B
[open larger]

User B adds a project title Doomed. Her browser's JavaScript doesn't recognize it as pre-existing, so it adds the name to both the database and the return list. An updated list of project titles is sent back to User B.

Subsequently, user A adds the same name Doomed in project list. His browser's JavaScript doesn't detect it in HTML list, and therefore re-adds the name Doomed to the database and return list. An updated list of project titles is sent back to User A with two items included Doomed.

The result obtained does not meet the product specifications. While this situation is a well-illustrated test case, accidentally discovering this bug and trying to reproduce it is not an easy task. In this example, the error itself is that the application was unable to check and correct duplicate names on the server side (in addition to checking on the client side). The steps involve user A. Dynamic operating system created by actions of user B that are hidden from user A or simply unknown to him.

Conclusion

To be effective in analyzing and reproducing errors in a web environment, you need to have leverage over the operating environment. You also need to understand how environment-specific variables can affect your ability to reproduce errors. I hope that with some of the skills you can learn from this article, your web testing experience will be less frustrating and more enjoyable.

Remember that nothing can replace your testing skills and your ability to come up with good test cases. Don't be afraid to ask "What if...?", take detailed notes, and methodically investigate hard-to-reproduce bugs. These are exactly the skills that will help you not only in studying errors, but also in finding other problems associated with them.