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?

Explain Object Oriented Testing Stretergy.

Object-Oriented Test Strategies

·         Unit Testing – components being tested are classes not modules

·         Integration Testing – as classes are integrated into the architecture regression tests are run to uncover communication and collaboration errors between objects

·         Systems Testing – the system as a whole is tested to uncover requirement errors

Object-Oriented Unit Testing

·         smallest testable unit is the encapsulated class or object

·         similar to system testing of conventional software

·         do not test operations in isolation from one another

·         driven by class operations and state behavior, not algorithmic detail and data flow across module interface

Object-Oriented Integration Testing

·         focuses on groups of classes that collaborate or communicate in some manner

·         integration of operations one at a time into classes is often meaningless

·         thread-based testing – testing all classes required to respond to one system input or event

·         use-based testing – begins by testing independent classes (classes that use very few server classes) first and the dependent classes that make use of them

·         cluster testing – groups of collaborating classes are tested for interaction errors

·         regression testing is important as each thread, cluster, or subsystem is added to the system.

Write a note on object oriented paradigm.

Object-Oriented Paradigm is where we focus real life objects while programming any solution. By focusing real life objects we mean that over solutions revolves around different objects, which represent respective objects in real life situation.

The objective of this section is to provide a thorough understanding of the principles of object-oriented paradigm.

Data Abstraction

Data abstraction is the reduction of a particular body of data to a simplified representation of the whole. Abstraction, in general, is the process of taking away or removing characteristics from something in order to reduce it to a set of essential characteristics.

Encapsulation

In object-oriented programming, objects interact with each other by messages. The only thing that an object knows about another object is the object's interface. Each object's data and logic is hidden from other objects. In other words, the interface encapsulates the object's code and data.

This allow the developer to separate an object's implementation from its behaviour. This separation creates a "black-box" affect where the user is isolated from implementation changes. As long as the interface remains the same, any changes to the internal implementation is transparent to the user. For example, if the name message is sent to the Student object, it does not matter to the user how the developer implemented the code to handle this message. All the sending object needs is the correct protocol for interacting with the Student object. The developer can change the implementation at any time, but the name message would still work because the interface is the same.

Polymorphism

Another benefit of separating implementation from behaviour is polymorphism. Polymorphism allows two or more objects respond to the same message. A method called name could also be implemented for an object of the class Course. Even though the implementation of this name message may return a course number and a course title, its protocol is the same as the name message to the Student object. Polymorphism allows a sending object to communicate with different objects in a consistent manner without worrying about how many different implementations of a message.

An analogy of polymorphism to daily life is how students response to a school bell. Every student knows the significant of the bell. When the bell (message) rings, however, it has its own meaning to different students (objects). Some students go home, some go to the library, and some go to other classes. Every student responds to the bell, but how they response to it might be different.

Another example of polymorphism is the function of printing. Every printable object must know how to print itself. The message is the same to all the different objects: print, but the actual implementation of what they must do to print themselves varies.

The sending object does not have to know how the receiving object implement the message. Only the receiving objects worries about that. Assume that there is a print Page method in a Document object that has the responsibility of printing a page. To print the page, the print Page method sends the print message to each object on the page. The Document does not need to know what types of objects are on the page, only that each object supports the behaviour of printing.

New objects can be added to the page without affecting the print Page method. This method still sends the print message and the new object provides its own print method in response to that message.

Polymorphism allows the sending object to communicate with receiving objects without having to understand what type of object it is, as long as the receiving objects support the messages.

Inheritance

Another important concept of object-oriented programming is inheritance. Inheritance allows a class to have the same behaviour as another class and extend or tailor that behaviour to provide special action for specific needs.

Let's use the following application as an example. Both Graduate class and Undergraduate class have similar behaviour such as managing a name, an address, a major, and a GPA. Rather than put this behaviour in both of these classes, the behaviour is placed in a new class called Student. Both Graduate and Undergraduate become subclass of the Student class, and both inherit the Student behaviour.

Both Graduate and Undergraduate classes can then add additional behaviour that is unique to them. For example, Graduate can be either Master's program or phD program. On the other hand, Undergraduate class might want to keep track of either the student is Freshman, Sophomores, Junior or Senior.

Classes that inherit from a class are called subclasses. The class a subclass inherits from are called super class. In the example, Student is a super class for Graduate and Undergraduate. Graduate and Undergraduate are subclasses of Student.

What is Domain ? Explain Domain Analysis With Example.

ANSWER: In software engineering, domain analysis, or product line analysis, is the process of analyzing related software systems in a domain to find their common and variable parts. It is a model of wider business context for the system.

In software engineering, domain analysis, or product line analysis, is the process of analyzing related software systems in a domain to find their common and variable parts. It is a model of wider business context for the system. The term was coined in the early 1980s by James Neighbors. Domain analysis is the first phase of domain engineering. It is a key method for realizing systematic software reuse.

Domain analysis produces domain models using methodologies such as domain specific languages, feature tables, facet tables, facet templates, and generic architectures, which describe all of the systems in a domain. Several methodologies for domain analysis have been proposed.

The products, or "artifacts", of a domain analysis are sometimes object-oriented models (e.g. represented with the Unified Modeling Language (UML)) or data models represented with entity-relationship diagrams (ERD). Software developers can use these models as a basis for the implementation of software architectures and applications. This approach to domain analysis is sometimes called model-driven engineering.