Waterfall Vs. V Model

S. No.	Waterfall Model	V-Model
1.	In Waterfall Model the tester role will take place only in the test phase.	In V-Model role will take place right from the requirement phase itself.
2.	Waterfall model is a fixed process that u can't make any changes in the requirement or in any phase.	In V-Model u can make any change in the requirements.
3.	Waterfall model is a continuous process.	V-model is the simultaneous process.
4.	Waterfall model used only after the requirements are fixed.	V-model can be used for any type of requirement (Uncertain requirement).
5.	Any mistake in Requirement phase can't be recognized in water fall model until near the end when customer gets to see the product. This leads to huge cost of correctiveness in terms of economy. So it is time consuming too.	Here for each and every phase of the software life cycle there is a review. Reduce the probability of occurring a mistake or defect. Hence saves the cost. It saves time.
6.	Emphasizes the development cycle and ignores the testing cycle. Testing merely get time as development phase takes almost 98% of project time.	Gives equal importance to the testing phase as development.
7.	Waterfall model stages: 1.User Requirement 2.System Requirement 3.Global Design 4.Detailed Design 5.Implementation 6.Testing	V model stages: 1.Component testing 2.Integration Testing 3.System Testing 4.Acceptance Testing

Testing types

Black Box Testing -Testing of a function without knowing internal structure of the program.
White Box Testing -Testing of a function with knowing internal structure of the program.

Regression Testing -To ensure that the code changes have not had an adverse affect to the other modules or on existing functions.

Functional Testing:
Functional system testing will be conducted both in a positive perception and also in a negative perception.

Positive Testing (+ve ): Testing conducted on the application in a positive approach to determine what system suppose to do is called positive testing.
Positive testing is helpful to check whether the customer requirements are justifying by the application or not.

Negative Testing (-ve): Testing a software application with a negative perception to check what system not supposed to do is called negative testing.
Negative testing is helpful to find defects from the software.

Unit Testing:

    The most 'micro' scale of testing to test particular functions or code modules. Typically done by the programmer and not by testers .
    Unit - smallest testable piece of software.
    A unit can be compiled/ assembled/ linked/ loaded; and put under a test harness.
    Unit testing done to show that the unit does not satisfy the functional specification and/ or its implemented structure does not match the intended design structure.

Integration Testing:

    Integration is a systematic approach to build the complete software structure specified in the design from unit-tested modules. There are two ways integration performed. It is called Pre-test and Pro-test.
    Pre-test: the testing performed in Module development area is called Pre-test. The Pre-test is required only if the development is done in module development area.

Alpha Testing:

    Testing of an application when development is nearing completion minor design changes may still be made as a result of such testing. Typically done by end-users or others, not by programmers or testers.

Beta Testing:

    Testing when development and testing are essentially completed and final bugs and problems need to be found before final release. Typically done by end-users or others, not by programmers.

System Testing:
            A system is the big component.
            System testing is aimed at revealing bugs that cannot be attributed to a component as such, to inconsistencies between components or planned interactions between components.
            Concern: issues, behaviors that can only be exposed by testing the entire integrated system (e.g., performance, security, recovery).

Volume Testing:
            The purpose of Volume Testing is to find weaknesses in the system with respect to its handling of large amounts of data during short time periods. For example, this kind of testing ensures that the system will process data across physical and logical boundaries such as across servers and across disk partitions on one server.

Stress Testing:
            This refers to testing system functionality while the system is under unusually heavy or peak load; it's similar to the validation testing mentioned previously but is carried out in a "high-stress" environment. This requires that you make some predictions about expected load levels of your Web site.

Usability Testing:
            Usability means that systems are easy and fast to learn, efficient to use, easy to remember, cause no operating errors and offer a high degree of satisfaction for the user. Usability means bringing the usage perspective into focus, the side towards the user.

 Security Testing:
            If your site requires firewalls, encryption, user authentication, financial transactions, or access to databases with sensitive data, you may need to test these and also test your site's overall protection against unauthorized internal or external access.

Security testing of the login page:

1. Authentication testing
Here we enter the different combination of user names and passwords and check whether only the authorized people are accessing the application or not. Also in some cases check account lock-out happens after few unsuccessful attempts.
 
2. Direct URL testing
Here we enter the direct URL'S of secured pages and check whether they are able to access or not.

3. Firewall leakage testing
Here we enter into the application as one level of user and will try to access the pages (features) beyond his limits in order to confirm whether they can be accessible or not.

4. Account access check
After signing out, if we do browser back or press back button (if any on the page) then a login screen should be displayed in front of the users.

Agile Testing

Agile as the name refers implies something to do very quickly. Hence Agile Testing refers to validate the client requirements as soon as possible and make it customer friendly. As soon as the build is out, testing is expected to get started and report the bugs quickly if any found. As a Tester, you need to provide your thoughts on the client requirements rather than just being the audience at the other end. Your feedback will be implemented in the code which will avoid the defects coming from the end user.

With the quicker development, testing and constant feedback from the user, the Agile methodology becomes the appropriate approach for the projects to be delivered in a short span of time.

The very first advantage that the company got to see with the Agile Methodology is the saving of time and money. There is less documentation required. This approach leads to focus more on the application rather than documenting the things.
 Another advantage that Agile Methodology offers to other approaches available is that in case there is any Change request or enhancements come in between any phase, it can be implemented without any budget constraint though there needs to be some adjustment in the already allotted time frame which will not be a difficult task for the projects following Agile tactics.

Short feedback loop between team members and Product Owner replaces sending official emails and talking to business and developers via the Test Manager.

When participating in Agile Testing, keep your feedback loop short. If you find a bug, talk about it with developers. If you need some clarification about the requirements Agile Testing, talk to the Product Owner.  Be active on Planning Meetings and Retrospective Meetings.

Agile Testing Needs Automation

To test every change in the system, you need to do regression testing to make sure that there are no defects introduced into previously developed features. Agile Testers are constantly busy with testing new Stories for current Sprint and planning regression testing is to difficult and means less features development. A better solution is to have automated tests for previous Sprints checked into the source repository.

Daily meetings and discussions for the project following Agile approach can help to determine the issues well in advance and work on it accordingly. Quick coding and Testing makes the management aware of the gaps existing in either requirements or technology used.

Flash interface testing

There are four practices that you should follow when testing a Flash-based interface: 

Step 1: Test over multiple connection speeds

Testing over multiple connection speeds is the most important practice to follow when testing Flash interfaces. If you test only from your local hard drive—or a web server on your local network—you are in danger of masking problems that might occur only under real-world connection conditions. When you test locally, things like server communication, image loading, and SWF streaming happen almost instantaneously.

An example helps illustrate this concept. If you use the statement gotoAndPlay(20) on the first frame of your movie's timeline, it will most likely work as expected when testing locally or even over broadband. However, if you test the same file over a modem connection, your movie will probably behave incorrectly.

One very helpful way around this problem is to make frequent use of the built-in Simulate Download feature in Flash, which you can find in the View menu of the SWF window that appears after choosing Control > Test Movie. Because the Simulate Download feature allows you to preview the performance of your movie over various connection speeds, it is a good way to spot speed-related problems early.   

Step 2: Test across browsers

This step exposes the following:

• Problems with embedding Flash Player
• Problems with relative URLs
• Problems with Flash-to-browser communication

 Testing across various browsers confirms that Flash content has been embedded properly on the page and that all URLs embedded in the Flash file are working consistently across all browsers. 

Step 3: Test across Flash Player versions

This step exposes the following:

• Publishing mistakes
• Flash detection problems

Because Flash Player handles nearly all aspects of the display and functionality of a Flash-based interface, you will need to test your interface in various versions of Flash Player. It is usually adequate to test in just two versions: the version of the player which you've defined as your minimum required version and the version of the player that preceded the required version.

For example, if your interface requires Flash Player 6, then you should test in the earliest release of that version (Flash Player 6r21) and in any release of the previous version (Flash Player 5r30). If your interface requires a specific later release of a particular version—for example, Flash Player 6r65—then you should still test in the versions mentioned previously as well as the required release.

Step 4: Test on "weak" machines

This step exposes the following:

• Issues with playback performance
• "This script appears to be running slowly" alerts

The user's hardware—processor, RAM, and video card—impacts the experience significantly.

VBScript

VBScript is a lightweight programming scripting language. VBScript is Microsoft's Visual Basic Scripting Edition. It is a simplified version of the Visual Basic and Visual Basic for Applications family of programming languages. It is also considered to be closely related to the BASIC programming language.

It is a case insensitive scripting language. It runs on both Client and server side. Only in Internet Explorer it can also be used as a browser language

VBScript has only one data type and it's called a ‘Variant’. Variant - A Variant is a special kind of data type that can contain different kinds of information, depending on how it's used. VBScript is the default language of Active Server Pages (ASP). For many Web-application developers, VBScript may very well be the most important programming language.

Smoke Testing Vs. Sanity Testing

Smoke Testing

• All features are tested without going into deep.
• This testing is shallow & wide and also known as Build Acceptance(Verification) Test.
• It is done to ensure the stability of newly received (interim) build and can be considered for further testing.
• It is done before release by unit testers or developers. Smoke testing can be executed for platform qualification tests. 
• A subset of test cases that cover the most important functionality of a component or system are selected and run, to ascertain if the most crucial functions of a program work correctly.
  
• It is usually scripted.

Sanity Testing

• High level features are tested.
• It offers quick, deep and narrow tests, so also known as Narrow Regression Test. Once a new build is obtained with minor revisions, instead of doing a through regression, sanity is performed.
• It is actually a subset of regression testing and performed on the builds with minor revisions to assure that build has rectified the issues & no further issue has been introduced by fixes. 
• A group of test cases are executed that are related with the changes made to the application.
• It is done after release by testers. 
• It is unscripted.

Difference between QTP and WINRUNNER?

S. No.	Winrunner	QTP
1	Use TSL	Use VB script
2	It doesn't support the OOPS concept, multimedia, XML, .Net.	It supports.
3	It supports only interpreter.	Supports compiler
4	Uses GUI spy	Uses Object Spy
5	GUI Map editor is used to store the physical descriptions	Object Repository is used to store the physical descriptions of the objects
6	Here analog and context sensitive recording modes are there.	Here 3 recording types are there (1) Normal (2) Analog (3) Low level
7	Here 4 types of checkpoints	Here 9 types of checkpoints
	1) GUI checkpoint	1) Standard check point
	2) Bitmap checkpoint	2) Bitmap checkpoint
	3) Database checkpoint	3) Database checkpoint
	4) Text checkpoint	4) Text/Text area checkpoint
		5) Image checkpoint
		6) Table checkpoint
		7) Page checkpoint
		8) Accessibility checkpoint
		9) XML checkpoint
8	Here 3 types of running modes	In QTP only 2 types of running Modes
	1) Verify	1) Standard
	2) Debug	2) Update
	3) Update
9	Exception Handling method used to avoid the runtime errors . In WR 3 types	Here the name is Recovery Scenario and here 4 types of exceptions :
	1) Popup	1) Pop-up Window
	2) TSL	2) Object state
	3) Object	3) Test run error
		4) Application Crash
10	WR add-ins are :	QTP add-ins are :
	1) ActiveX	1) ActiveX
	2) Power Builder	2) Visual Basic
	3) Visual Basic	3) Java
	4) Web	4) Web
	5) Java	5) Multi-media ( 6.5 version )
	6) C
	7) C++ etc
11	In WR only One View	Here in QTP 2 Views
	1) Normal Mode	1) Expert View
		2) Keyword View
12	Only One Sheet in data Table if we want to add another sheet then another new data table to be opened	In QTP 2 sheets in Data Table
		1) Global
		2) Action
		In action sheet we can add no of sheets
13	Here 2 types of GUI map editor	Here only one type
	1) Global	1) Global
	2) Per test
14	Running methods	Running Methods in QTP are :
	1) Step	1) Step into
	2) Step into	2) Step over
	3) Step out	3) Step out
15	Only One window i.e. Form Window	Here five types of Window
		1) Tree View or Keyword view
		2) Expert View
		3) Data Table
		4) Active Screen
		5) Debug Viewer