See also - Web testing: features, kinds and sequence

Это окончание невероятной информации про web-тестирование.

...

database was repeated due to events not caused by user actions, for example, recovery after loss of the Internet connection, or database recovery

Possible causes:

• The order processing transaction was not completed or committed due to user intervention
• The order processing transaction was not completed or committed due to loss of the Internet connection
• The user entered incorrect data

Possible causes:

• Incorrect search or selection criterion
• Incorrect SQL statement
• Data corruption in the database
• Incorrect data in the database

Probability

Risk assessment by probability makes it possible to determine the probability of failure of a use case or component. Probability is usually calculated based on external factors such as:

• Failure frequency
• Rate of change
• Complexity
• Source / author

Note that when working with this risk projection, the risk factor indicators are related to the probability of failure, rather than to the consequences of failure, as was the case when assessing risk by cause and consequence.

These factors and the probability of failure are related to each other as shown below:

Example:

• Installing new software
• "Flaws were found in the components used to implement use cases 1, 10 and 12, and our customers requested many changes in use cases 14 and 19."

The corresponding table is given below:

Defining the Operational Profile

Next it is necessary to define the operational profile, in order to assess risks and set test priorities.

Start by describing the level of the operational profile, using the following notations:

• H - very frequent use, many times within a given time interval or by many subjects or use cases.
• M - frequent use, several times within a given time interval or by several subjects or use cases.
• L - infrequent use, a small number of subjects or use cases.

The operational profile indicator should be chosen based on the frequency of use of the use case or component:

• the number of times that ONE subject (or use case) applies the use case (or component) within a given time
• the number of subjects (or use cases) working with the use case (or component)

Generally, the more frequently a use case or component is used, the higher its operational profile.

After this, compile a list of all the use cases and components of the test target. Determine the operational profile for each item in the list and justify this value. The Work Product: Workload Analysis Document can help with the assessment.

Examples:

• Installing new software
• Ordering items from an electronic catalog
• Customer inquiry about the status of their electronic order
• Item selection window

Determining Test Priority

Finally, it is necessary to determine the test priorities.

Start by describing the degree of test priority, using the following notations:

• H - testing is required
• M - testing should be performed, but after all H items have been performed
• L - testing may be performed, but only after testing all H and M items

After this, compile a list of all the use cases and components of the test target. Determine the priority for each item in the list and justify this value. Below are some recommendations for determining the test priority indicator.

When determining test priority, take the following into account:

• the risk indicator specified earlier
• the operational profile specified earlier
• descriptions of subjects (do they have experience, are they ready to fix errors)
• contractual obligations (will the test target be accepted if some use case or component is not delivered)

Below are the basic principles for determining priorities:

• Use the highest factor (risk, operational profile, etc.) for the overall priority.
• Determine the most significant factor (risk, operational profile, etc.) and use it to indicate priority.
• Use a combination of all factors to indicate priority.
• To account for all factors, a weighted priority can be calculated taking into account the weights of the factors.

Examples:

• Installing new software
• Ordering items from an electronic catalog
• Customer inquiry about the status of their electronic order
• Item selection window

If the highest value is used to indicate priority:

If the highest value of some single factor (risk) is used to indicate priority:

If the weight of the factors is taken into account when determining priority:

In the table H = 5, M = 3, L = 1. A total weighted value above 30 is a test item with high priority, from 20 to 30 inclusive is medium priority, and below 20 is low priority.

Test Strategy

The test strategy describes the general approaches and goals for some aspect of testing.

A good test strategy includes the following:

• the types of tests to be implemented and their goals
• the stage at which the test will be implemented
• the technique
• the methods of measurement and the criteria used in evaluating test results
• other considerations that may affect the test described in the strategy

Test Type and Goals

Clearly formulate the test type and its goal. If this information is stated explicitly, there is no confusion or misunderstanding, especially when there are very similar tests. The goal should clearly define why this test is being performed.

Examples:

"Functional test. A functional test devoted to verifying the execution of the specified use cases implemented in the test target, in its user interface."

"Performance test. A system performance test devoted to measuring the system's response time in use cases 2, 4 and 8 through 10. In these tests, the load is created by a single subject performing these use cases, and no other load is placed on the test system."

"Configuration test. Configuration testing devoted to verifying and evaluating the behavior of the test target in order to compare performance in three different configurations with the performance in the reference configuration."

Test Stage

Clearly indicate the stage during which testing will be performed. Below are the stages during which common tests are performed:

Technique

The methodology describes how the test will be implemented and executed. Include in the description what will be tested, the main actions that need to be performed during the test, and the ways of evaluating the results.

Example:

Functional test:

• For each event flow in the use case, a representative set of transactions is defined, each of which corresponds to actions performed by the actor while working with the use case.
• For each transaction, at least two test sets will be developed, the first of which will reflect the positive condition, and the second - the negative (unacceptable) condition.
• In the first iteration, use cases 1 through 4 and 12 will be tested, namely:
  • Use case 1:
    • Use case 1 begins with the actor already logged into the system and working with the main window, and ends when the user selects the Save action.
    • Each test set will be implemented and executed using Rational Robot.
    • Execution verification and result evaluation for each test set will be performed as follows:
      • Test scenario execution - were all test scenarios executed completely and successfully?
      • Methods for checking the display of windows and object data will need to verify that the system's main windows are shown, and that data is written and displayed by the test target during the test.
      • The test target's database (Microsoft Access) will be examined, first before the test, then after the test, during which the correctness of the data changed during the test will be verified.

Performance test:

• For each use case, a representative set of transactions specified in the workload analysis document will be implemented and executed in Rational Suite PerformanceStudio (vu scripts) and Rational Robot (GUI scripts).
• The tests and the execution plan will implement at least three loads, including the following:
  • Peak load: 750 users (15% management, 50% sales department, 35% marketing department)
  • Elevated load: 350 users (10% management, 60% sales department, 30% marketing department)
  • Estimated load: 150 users (2% management, 75% sales department, 23% marketing department)
• The test scenarios provide appropriate timers for executing all transactions, which measure response time, for example the total transaction time (as specified in the workload analysis document) and the times of the main stages of the transaction or process.
• The duration of the workload generated by the test scenarios is one hour (unless otherwise specified in the workload analysis document).
• Execution verification and result evaluation for each test run (with the specified load) will be performed as follows:
  • Test execution will be tracked by state histograms (to verify the required load is correctly provided during the test)
  • Test scenario execution - were all test scenarios executed completely and successfully?
  • Response time recording and evaluation will be presented in the following reports:
    • Performance percentage ratios
    • Response time

Exit criteria

Exit criteria are formulated for two purposes:

• to determine whether the product's quality meets the stated requirements
• to determine whether the test program was successfully completed

The wording of exit criteria should include the following elements:

• the measurable function, behavior or condition
• the method of measurement
• the criteria or degree of compliance with the measurement

Example 1

• All planned test sets have been executed
• All identified defects have been resolved to the extent necessary
• All planned test sets have been re-executed, with all identified defects resolved to the extent necessary, and no new defects were found

Example 2

• All priority test sets have been executed.
• All identified defects have been resolved to the extent necessary.
• All severity 1 or 2 defects have been resolved (with a status of resolved or deferred).
• All priority test sets have been re-executed, with all identified defects resolved to the extent necessary, and no new defects were found.

Example 3

• All planned test sets have been executed.
• All identified defects have been resolved to the extent necessary.
• All severity 1 or 2 defects have been resolved (with a status of confirmed or deferred).
• All priority test sets have been re-executed, with all identified defects resolved to the extent necessary, and no new defects were found.

Special considerations

This section should indicate all factors or dependencies that may affect the test program described in the test strategy. These may include:

• staffing resources (e.g., availability of or the need for additional resources to support or participate in the test)
• constraints, e.g., availability or limitations of equipment, or the need for special equipment
• special requirements, e.g., test schedules or access to systems

Examples:

• Working with the database requires the help of a database administrator or designer to create and update test data.
• Performance testing must be performed with servers on the existing network (on which there may also be data traffic unrelated to the test). Testing should be scheduled for off-hours to exclude this extraneous network traffic.
• To perform full-featured testing, the test target must be synchronized with the live system (or the synchronization must be simulated)

See also

• [[b5192]]
• [[b766]]
• [[b7769]]
• [[b5187]]
• [[b6142]]
• QA profession, tester
• [[b6086]]
• [[b6087]]
• [[b6103]]
• [[b6108]]
• [[b6117]]

• Monkey testing

• Whittaker's testing tours technique
• [[b4]]
• [[b5]]
• [[b7]]

Продолжение:

Часть 1 Web testing: features, kinds and sequence
Часть 2 See also - Web testing: features, kinds and sequence

See also

• Mobile testing: features and stages. Mobile application architecture
• 9.5 Bug and programming errors
• Methods to ensure the high quality of the developed software
• Types and kinds of software testing. Testing levels and testing methods
• Test-driven development, TDD
• Functional Testing or Functional Testing
• Security Testing or Security and Access Control Testing
• Testing process
• How to start quality assurance?
• QA Interview
• 1.1. The Internet. Internet structure. Internet services, types and classification of sites
• 1.2. Site. His life cycle. Specifications. Domain statuses
• 1.4. IP interworking protocol, connection ports, polling , web socket