Sunday, October 12, 2014

Explain WebApp Testing Strategies


1.    WebApp content model is reviewed to uncover errors.
2.    Interface model is reviewed to ensure all use-cases are accommodated.
3.    Design model for WebApp is reviewed to uncover navigation errors.
4.    User interface is tested to uncover presentation errors and/or navigation mechanics problems.
5.    Selected functional components are unit tested.
6.    Navigation throughout the architecture is tested.
7.    WebApp is implemented in a variety of different environmental configurations and the compatibility of WebApp with each is assessed.
8.    Security tests are conducted.
9.    Performance tests are conducted.
10. WebApp is tested by a controlled and monitored group of end-users (looking for content errors, navigation errors, usability concerns, compatibility issues, reliability, and performance).
Validation Testing

·         Focuses on visible user actions and user recognizable outputs from the system
·         Validation tests are based on the use-case scenarios, the behavior model, and the event flow diagram created in the analysis model
  • Must ensure that each function or performance characteristic conforms to its specification.
  • Deviations (deficiencies) must be negotiated with the customer to establish a means for resolving the errors.
·         Configuration review or audit is used to ensure that all elements of the software configuration have been properly developed, cataloged, and documented to allow its support during its maintenance phase.
Acceptance Testing
·         Making sure the software works correctly for intended user in his or her normal work environment.
·         Alpha test – version of the complete software is tested by customer under the supervision of the developer at the developer’s site
·         Beta test – version of the complete software is tested by customer at his or her own site without the developer being present
 System Testing
·         Series of tests whose purpose is to exercise a computer-based system
·         The focus of these system tests cases identify interfacing errors
·         Recovery testing – checks the system’s ability to recover from failures
·         Security testing – verifies that system protection mechanism prevent improper penetration or data alteration
·         Stress testing – program is checked to see how well it deals with abnormal resource demands (i.e. quantity, frequency, or volume)
·         Performance testing – designed to test the run-time performance of software, especially real-time software
·         Deployment (or configuration) testing – exercises the software in each of the environment in which it is to operate
Bug Causes
·         The symptom and the cause may be geographically remote (symptom may appear in one part of a program).
·         The symptom may disappear (temporarily) when another error is corrected.
·         The symptom may actually be caused by non-errors (e.g., round-off inaccuracies).
·         The symptom may be caused by human error that is not easily traced.
·         The symptom may be a result of timing problems, rather than processing problems.
·         It may be difficult to accurately reproduce input conditions (e.g., a real-time application in which input ordering is indeterminate).
·         The symptom may be intermittent. This is particularly common in embedded systems that couple hardware and software inextricably.
·         The symptom may be due to causes that are distributed across a number of tasks running on different processors.     
Debugging Strategies
·         Debugging (removal of a defect) occurs as a consequence of successful testing.
·         Some people are better at debugging than others.
·         Common approaches (may be partially automated with debugging tools):
·         Brute force – memory dumps and run-time traces are examined for clues to error causes
·         Backtracking – source code is examined by looking backwards from symptom to potential causes of errors
·         Cause elimination – uses binary partitioning to reduce the number of locations potential where errors can exist)
Bug Removal Considerations
·         Is the cause of the bug reproduced in another part of the program?
·         What “next bug” might be introduced by the fix that is being proposed?
·         What could have been done to prevent this bug in the first place?

No comments: