WEB TESTING
While testing a web application you need to consider following Cases:

• Functionality Testing
• Performance Testing
• Usability Testing
• Server Side Interface
• Client Side Compatibility
• Security

Functionality:
In testing the functionality of the web sites the following should be tested:
• Links
i. Internal Links
ii. External Links
iii. Mail Links
iv. Broken Links

• Forms
i. Field validation
ii. Error message for wrong input
iii. Optional and Mandatory fields

• Database
* Testing will be done on the database integrity.

• Cookies
* Testing will be done on the client system side, on the temporary Internet files.

Performance :
Performance testing can be applied to understand the web site’s scalability, or to benchmark the performance in the environment of third party products such as servers and middleware for potential purchase.

• Connection Speed:
Tested over various networks like Dial Up, ISDN etc
• Load:
i. What is the no. of users per time?
ii. Check for peak loads and how system behaves
iii. Large amount of data accessed by user
• Stress:
i. Continuous Load
ii. Performance of memory, CPU, file handling etc..

Usability:
Usability testing is the process by which the human-computer interaction characteristics of a system are measured, and weaknesses are identified for correction.
• Ease of learning
• Navigation
• Subjective user satisfaction
• General appearance

Server Side Interface:
In web testing the server side interface should be tested. This is done by verify that communication is done properly. Compatibility of server with software, hardware, network and database should be tested.

Client Side Compatibility:
The client side compatibility is also tested in various platforms, using various browsers etc.

Security:
The primary reason for testing the security of a web is to identify potential vulnerabilities and subsequently repair them.
• Network Scanning
• Vulnerability Scanning
• Password Cracking
• Log Review
• Integrity Checkers
• Virus Detection

Desktop application runs on personal computers and workstations, so when you test the desktop application you are focusing on a specific environment. You will test complete application broadly in categories like GUI, functionality, Load, and back end i.e DB.

In client server application you have two different components to test. Application is loaded on server machine while the application exe on every client machine. You will test broadly in categories like, GUI on both sides, functionality, Load, client-server interaction, backend. This environment is mostly used in Intranet networks. You are aware of number of clients and servers and their locations in the test scenario.

Web application is a bit different and complex to test as tester don’t have that much control over the application. Application is loaded on the server whose location may or may not be known and no exe is installed on the client machine, you have to test it on different web browsers. Web applications are supposed to be tested on different browsers and OS platforms so broadly Web application is tested mainly for browser compatibility and operating system compatibility, error handling, static pages, backend testing and load testing.

Desktop application runs on personal computers and workstations, so when you test the desktop application you are focusing on a specific environment. You will test complete application broadly in categories like GUI, functionality, Load, and backend i.e DB.

In client server application you have two different components to test. Application is loaded on server machine while the application exe on every client machine. You will test broadly in categories like, GUI on both sides, functionality, Load, client-server interaction, backend. This environment is mostly used in Intranet networks. You are aware of number of clients and servers and their locations in the test scenario.

Web application is a bit different and complex to test as tester don’t have that much control over the application. Application is loaded on the server whose location may or may not be known and no exe is installed on the client machine, you have to test it on different web browsers. Web applications are supposed to be tested on different browsers and OS platforms so broadly Web application is tested mainly for browser compatibility and operating system compatibility, error handling, static pages, backend testing and load testing.

Are you going to start on a new project for testing? Don’t forget to check this Testing Checklist in each and every step of your Project life cycle. List is mostly equivalent to Test plan, it will cover all quality assurance and testing standards.

Testing Checklist:
1 Create System and Acceptance Tests [ ]
2 Start Acceptance test Creation [ ]
3 Identify test team [ ]
4 Create Workplan [ ]
5 Create test Approach [ ]
6 Link Acceptance Criteria and Requirements to form the basis of
acceptance test [ ]
7 Use subset of system test cases to form requirements portion of
acceptance test [ ]
8 Create scripts for use by the customer to demonstrate that the system meets
requirements [ ]
9 Create test schedule. Include people and all other resources. [ ]
10 Conduct Acceptance Test [ ]
11 Start System Test Creation [ ]
12 Identify test team members [ ]
13 Create Workplan [ ]
14 Determine resource requirements [ ]
15 Identify productivity tools for testing [ ]
16 Determine data requirements [ ]
17 Reach agreement with data center [ ]
18 Create test Approach [ ]
19 Identify any facilities that are needed [ ]
20 Obtain and review existing test material [ ]
21 Create inventory of test items [ ]
22 Identify Design states, conditions, processes, and procedures [ ]
23 Determine the need for Code based (white box) testing. Identify conditions. [ ]
24 Identify all functional requirements [ ]
25 End inventory creation [ ]
26 Start test case creation [ ]
27 Create test cases based on inventory of test items [ ]
28 Identify logical groups of business function for new sysyem [ ]
29 Divide test cases into functional groups traced to test item inventory [ ] 1.30 Design data sets to correspond to test cases [ ]
31 End test case creation [ ]
32 Review business functions, test cases, and data sets with users [ ]
33 Get signoff on test design from Project leader and QA [ ]
34 End Test Design [ ]
35 Begin test Preparation [ ]
36 Obtain test support resources [ ]
37 Outline expected results for each test case [ ]
38 Obtain test data. Validate and trace to test cases [ ]
39 Prepare detailed test scripts for each test case [ ]
40 Prepare & document environmental set up procedures. Include back up and
recovery plans [ ]
41 End Test Preparation phase [ ]
42 Conduct System Test [ ]
43 Execute test scripts [ ]
44 Compare actual result to expected [ ]
45 Document discrepancies and create problem report [ ]
46 Prepare maintenance phase input [ ]
47 Re-execute test group after problem repairs [ ]
48 Create final test report, include known bugs list [ ]
49 Obtain formal signoff [ ]

What is White Box Testing?

White box testing (WBT) is also called Structural or Glass box testing.

White box testing involves looking at the structure of the code. When you know the internal structure of a product, tests can be conducted to ensure that the internal operations performed according to the specification. And all internal components have been adequately exercised.

White Box Testing is coverage of the specification in the code.

Code coverage:

Segment coverage:
Ensure that each code statement is executed once.

Branch Coverage or Node Testing:
Coverage of each code branch in from all possible was.

Compound Condition Coverage:
For multiple condition test each condition with multiple paths and combination of different path to reach that condition.

Basis Path Testing:
Each independent path in the code is taken for testing.

Data Flow Testing (DFT):
In this approach you track the specific variables through each possible calculation, thus defining the set of intermediate paths through the code.DFT tends to reflect dependencies but it is mainly through sequences of data manipulation. In short each data variable is tracked and its use is verified.
This approach tends to uncover bugs like variables used but not initialize, or declared but not used, and so on.

Path Testing:
Path testing is where all possible paths through the code are defined and covered. Its a time consuming task.

Loop Testing:
These strategies relate to testing single loops, concatenated loops, and nested loops. Independent and dependent code loops and values are tested by this approach.

Why we do White Box Testing?
To ensure:

• That all independent paths within a module have been exercised at least once.
• All logical decisions verified on their true and false values.
• All loops executed at their boundaries and within their operational bounds internal data structures validity.

Need of White Box Testing?
To discover the following types of bugs:

• Logical error tend to creep into our work when we design and implement functions, conditions or controls that are out of the program
• The design errors due to difference between logical flow of the program and the actual implementation
• Typographical errors and syntax checking

Usability testing - User-friendliness check. Application flow is tested, Can new user understand the application easily, Proper help documented whenever user stuck at any point. Basically system navigation is checked in this testing.

Install/uninstall testing - Tested for full, partial, or upgrade install/uninstall processes on different operating systems under different hardware, software environment.

Compatibility testing - Testing how well software performs in a particular hardware/software/operating system/network environment and different combination s of above.

Comparison testing - Comparison of product strengths and weaknesses with previous versions or other similar products

• CMM describes about the software engineering alone where as CMM Integrated describes both software and system engineering. CMMI also incorporates the Integrated Procees and Product Development and the supplier sourcing.

CMM:

The first CMM (CMM v1.0) was developed for software and released in August 1990.Based on this success and the demand from other interests CMMs were developed for otherdisciplines and functions:a. Systems Engineeringb. Peoplec. Integrated Product Developmentd. Software Acquisitione. Software Quality Assurancef. Measurement.

CMMI:

The CMM Integration Project was formed to:

1. Establish a framework to integrate current and future models

2. Build an initial set of integrated models.

The source models that served as the basis for the CMMI include:

1. CMM for Software v2.0 Draft C

2. EIA ? 731 Systems Engineering

3. IPD CMM (IPD) v0.98a

Note - CMM = 'Capability Maturity Model', now called the CMMI ('Capability Maturity Model Integration'), developed by the SEI

CMM Capability Maturity model it is a type of quality standard.

CMM(Capability Maturity Model) is an industry-standerd model for defining and measuring the "maturity" of a software company's development process and for providing direction on what they can do to improve their software quality.it was developed by the software development community along with the software engineering institute(SEI).


CMM level means here, the CMM levels are 5

Level 1) Initial : Here concentrate on the team, team should be very strong. Software project success depends on having high quality people.

Level 2) Repeatable [Managed]: Here concentrate on the repeatability and used well defined guide lines. Software development successes are repeatable. The processes may not repeat for all the projects in the organization. The organization may use some basic project management to track cost and schedule

Level 3) Defined : The software process for both management and engineering activities is documented, standardized, and integrated into a standard software process for the organization.

Level 4) Quantitatively Managed: Detailed measures of the software process and product quality are collected. Both the software process and products are quantitatively understood and controlled.

Level 5) Optimisation : Continuous process improvement is enabled by quantitative feedback from the process and from piloting innovative ideas and technologies.


CMMI : Capability Maturity Model for Integration, if the companies are producing IT and Non-IT products then it is CMMI CMMP : Capability Maturity Model for People these companies give more benefits to people so people will work more satisfaction.

Role of Tester in SDLC cycle
1. Requirement stage - PM,Tech.Lead, Testlead will review the document
2. Design Stage - PM or Test lease will review the document
3. Coding Stage - Testlead will prepare Testplan, Tester will prepare testcases
4. Testing Stage - Tester will execute the test

SDLC (Software Development Life cycle)
1. Requirement
2. Design
3. Coding
4. Testing
5. Implement
6. Maintainance


STLC (Software Testing Life cycle)
1. Test Plan Preparation: Defines overall testing approach based on Project Summary Document and SRS document.
2. Test Case Design: Defines what is to be tested and describes the expected results.
3. Test Execution: Execute the test cases as per Manual or Automation based on client requirement and software stability.
4. Test Log Preparation: Defines the pass and Fail information
5. Defect Reporting: Log the Bug in Bug Tracker like Bugzilla and PVCS Tracker.
6. Defect Tracking : Monitor the Bug Status.

Recovery testing - testing how well a system recovers from crashes, hardware failures, or other catastrophic problems.

Realization testing is possible in each and every phase mentioned below:(Either it may be verification or validation)

• programming or coding the software
• customizing and configuring the package or the programs
• writing the documentations
• performing the internal tests

Realization includes all the internal activities of the QA and Development team before the final product can be delivered to the end-user or to the customer.

VERIFICATION: THE VERIFY THE PROCESS LIKE SET OF DOCUMENTS,PLANS,SPECIFICATIONS AND REQUIREMENTS.

VALIDATION: THE ACTUAL TESTING OF AN ACTUAL PRODUCT.

Verification all the documents produced during development, and on plans.
i/p for verification:
1 Checklists
2. Issue lists
3.Walk throughs
4. Inspections
5. Reviews and Meetings

Validation is actual testing
i/p for validation:
1. Test Cases based on user requirements.
2. Test Data etc.

Testing is Quality Control
Quality Control-Measure the Quality Of Products
Detection action
Quality Assurance-Measure the Quality of Process.
Prevention action


Quality Control (Testing) : A process of executing the system intending to find defects.

Quality Assurance:A set of activities that are adequate to ensure that system meets its objectives

Performance Testing:

• In performance testing we test the Responce time, efficiency and processing speed.
• To test the complaince of the system.
  

Example - If u open any website in the Url window the opening of the home page is called as
performance testing.

Load Testing:

• Increasing the number of users at a specific interval of time. Load testing is a combination of capacity testing and longetivity testing.
• Load testing Innitially we will start test with single user and based on the transaction
  time we will increase the user one by one.
  

Example - IF 5 users are using the login page of yahoo mail at the same time the performance
is constant. If 10 users are add by the user at the same time . the performance is constant.
At last In If the users add 20 user at the same time the performance should decreased.

Stress Testing:

• Testing is done with max no of users in low disk space, low memory and low configuration.
• The execution of our application build under customer expected configuration and various
  load levels from high level to low level and low level to high level to estimate load
  balancing is called stress testing.

Example: An users are added to with in the specification of the limit, and cannot be added
beyond that.

Volume Testing:

• To estimate the data base in terms of records.
• We are executing the test with diffrent volume of data (eg. Number of records).
  

Example: If 1 user is accessing how many records are retriving. if 2 users are accessiong how many records are retriving, etc....

Alpha Testing:

Alpha testing is done by client side people in development environment..

Testing a software product which is not the final version.This software does not have to necessarily contain the full functionality required for an application, however core functionality to accept input an generate output is required.

Beta Testing:
Beta Testing is done by client side people in real time environment....

Beta Testing is last stage of testing where a product is sent outside the company or offer the product for free trial download.

Unit test case will be based on program design or logical flow of Login that will be written by Developer only. It is related to internal structure.Integration test case will include the TC for linking of 2 module.

E.G.:-
On login screen user will user name & pwd. Click on Submit or confirming object so that i/p will get validate into database. So, First integrate chk will be DB connectivity is correct or not. & it recognizing the user name & pwd for comaparision. & Overall o/p will be Login should be successful & Main Screen should be open up.In system-functional testing, Tester will write the test case based on validation of fields & all combination of positive & -ve data. (Valid & Invalid testing)At acceptance level....User will check only for valid & Invalid entry.Test case format changes as per company.

Unit Testing
The main objective of Unit testing is to test each and every function.Generally unit test is done by developer.It is conducted before integration testing.

The application is divided into different modules as units and testing is performed on each single module.

Integration Testing
Testing of combined parts of an application to determine,if they function together correctly.

Integration testing is the testing of combined parts of an application to determine if they function together correctly.

System Testing
Testing that attempts to discover defects that are properties of entire system.

System testing is Black-box type of testing that is based on overall requirements specifications. It covers all combined parts of the system.

Black Box Testing:- Testing of functionality of software .It does not need knowledge of coding.It is also called as Behavioral testing/opaque box testing.

White Box testing:-Testing of internal structure of software.It require knowlege of coding.It is also called as structral /glass box testing.

Smoke Testing is initial level testing to check whether complete functionality is available or not.It is done at build level.
Sanity Testing is initial level testing to check whether application behaviour is proper or not. It is done at system level.

Conceptually both r same.Perceptionally they r different.
In both the testings we check for the availability for the entire application.

Smoke Testing - we just whether the entire application is present or not.
Sanity Testing - We check for whether the entire application available is proper or not.


Smoke test: Smoke test is done on Builds (.exe file) to check whether Overall Functionalities is working or not....
Sanity test: Sanity test is done to check whether the application is build on client requirements or not ...

Note:If 60 % of Functionality are not working we have to stop testing.

Walk through is unformal review or meeting whereas inspection is formal review or meeting.

Walkthrough is there for both Testing and Coding.

• Walkthrough for Testing means brief review of documents, Test cases, Test script etc.
  
• Walkthrough for Coding means review the coding for whether the Developer follows the Coding standards or not.

Inspection is job of Quality Control (QC). He can conduct Inspections and Audits on the project at any time to check whether the process is going on correctly or not.

Test Efficiency:

a. Test efficiency = Internal in the organization how much resources were consumed, how much of these resources were utilized.

b. Number of test cases executed divided by unit of time (generally per hour).

c. Test efficiency = (Total number of defects found in unit + integration + system) / (Total number of defects found in unit + integration + system + User acceptance testing)

d. Test Efficiency: Test the amount of code and testing resources required by a program to perform a function.

e. Testing Efficiency = (No. of defects Resolved / Total No. of Defects Submitted) * 100.

f. Test Efficiency is the rate of bugs found by the tester to the total bugs found.

When the build is sent to the customer side people for the testing (Alpha and Beta Testing), the customer side people also find some bugs.

Test Efficiency = A/(A+B)
Here A= Number of bugs found by the tester

B= Number of bugs found by the customer side people
This test efficiency should always be greater than 90%



Test Effectiveness:

a. Test effectiveness = How much the customer's requirements are satisfied by the system, how well the customer specifications are achieved by the system, how much effort is put in developing the system.

b. Number of defects found divided by number of test cases executed.

c. Test effectiveness = (Total number of defects injected + Total number of defect found) / (Total number of defect escaped)* 100.

d. Test Effectiveness: It judge the Effect of the test environment on the application.

e. Test Effectiveness = Loss due to problems / Total resources processed by the system.

Re-Testing - Retesting is the process of testing an application after fixing the bugs.

Regression - Regression testing is the process of reexecuting the application whether it affects the other parts of application


Retesting and Regression Testing are slightly different in the sense....they are to be executed on different test cases...

E.g. If there are 1000 test cases to be executed in the first build....And of the 1000 test cases, 100 fail and 900 pass....
Then after bug fixes and when the 2nd build is received, REGRESSION Testing has to be done on the 900 test cases and the remaining 100 test cases are to be RETESTED.