Compatibility testing is to evaluate the application compatibility with the computing environment like Operating System, Database, Browser compatibility, Backwards compatibility, Computing capacity of the Hardware Platform and compatibility of the Peripherals.
Ex : If Compatibility testing is done on a Game application, before installing a game on a computer, its compatibility is checked with the computer specification that whether it is compatible with the computer having that much of specification or not.

Scalability Testing is used to check whether the functionality and performance of a system are capable to meet the volume and size change as per the requirements. Scalability testing can be done using load test with various software and hardware configurations changed, where the testing environment settings unchanged

Alpha Testing: Alpha Testing is mostly like performing usability testing which is done by the in-house developers who developed the software or testers. Sometimes this Alpha Testing is done by the client or an outsider with the presence of developer and tester. The version release after alpha testing is called Alpha Release.

Beta Testing: Beta Testing is done by limited number of end users before delivery, the change request would be fixed if the user gives feedback or reports defect. The version release after beta testing is called beta Release.

Gamma Testing: Gamma Testing is done when the software is ready for release with specified requirements; this testing is done directly by skipping all the in-house testing activities.

Verification is preventing mechanism to detect possible failures before the testing begin. It involves reviews, meetings, evaluating documents, plans, code, inspections, specifications etc. Validation occurs after verification and it's the actual testing to find defects against the functionality or the specifications.

1. Change in requirements or Incomplete requirements.
2. Time allocation for testing.
3. Developers delaying to deliver the build for testing.
4. Urgency from client for delivery.
5. Defect Leakage due to application size or complexity.

The Functional Requirement specifies how the system or application SHOULD DO where in Non – Functional Requirement it specifies how the system or application SHOULD BE. Some Functional Requirements are, Authentication Business Rules Some Non Functional Requirements are, Performance Reliability Security Recovery Data Integrity Usability

Good code is code that works according to the requirements, bug free, readable, and expandable in the future and easily maintainable.

In good design, the overall structure is clear, understandable, easily modifiable, and maintainable.

Good test engineer has the ability to think the unthinkable, has the test to break attitude, strong desire to quality and attention to detail.

The terms Priority and Severity are used in Bug Tracking to share the importance of a bug among the team and to fix it.

Severity 1. The Severity status is used to explain how badly the deviation is affecting the build. 2. The severity type is defined by the tester based on the written test cases and functionality.

Ex : If an application or a web page crashes when a remote link is clicked, in this case clicking the remote link by an user is rare but the impact of application crashing is severe, so the severity is high and priority is low.

Priority 1. The Priority status is set by the tester to the developer mentioning the time frame to fix a defect. If High priority is mentioned then the developer has to fix it at the earliest. 2. The priority status is set based on the customer requirements.

Ex : If the company name is misspelled in the home page of a website, then the priority is high and the severity is low to fix it.

Different types of Severity:

User Interface Defects – Low Boundary Related Defects – Medium Error Handling Defects – Medium Calculation Defects – High Interpreting Data Defects – High Hardware Failures & Problems - High Compatibility and Intersystem defects- High Control flow defects – High Load Conditions (Memory Leakages under load testing) – High

Defect leakage occurs at the Customer or the End user side after the application delivery. After the release of the application to the client, if the end user gets any type of defects by using that application then it is called as Defect leakage. This Defect Leakage is also called as Bug Leakage.

1. Project
2. Subject
3. Description
4. Summary
5. Detected By (Name of the Tester)
6. Assigned To (Name of the Developer who is supposed to the Bug)
7. Test Lead ( Name )
8. Detected in Version
9. Closed in Version
10. Date Detected
11. Expected Date of Closure
12. Actual Date of Closure
13. Priority (Medium, Low, High, Urgent)
14. Severity (Ranges from 1 to 5)
15. Status
16. Bug ID
17. Attachment
18. Test Case Failed (Test case that is failed for the Bug)

Bug life cycle is nothing but the various phases a bug undergoes after it is raised or reported. The different phases of Bug life cycle are,

• New or Opened
• Assigned
• Fixed
• Tested
• Closed

Error Guessing is a test case design technique where the tester has to guess what faults might occur and to design the tests to represent them.

Error Seeding is the process of adding known faults intentionally in a program for the reason of monitoring the rate of detection & removal and also to estimate the number of faults remaining in the program.

Bug : It is found in the development environment before the product is shipped to the respective customer.

Error : It is the Deviation from actual and the expected value.

Defect : It is found in the product itself after it is shipped to the respective customer.

Boundary value testing is a technique to find whether the application is accepting the expected range of values and rejecting the values which falls out of range.
Ex. A user ID text box has to accept alphabet characters ( a-z ) with length of 4 to 10 characters.
BVA is done like this, max value:10 pass; max-1: 9 pass;
max+1=11 fail ;min=4 pass;min+1=5 pass;min-1=3 fail;
Like wise we check the corner values and come out with a conclusion whether the application is accepting correct range of values.
Equivalence testing is normally used to check the type of the object.
Ex. A user ID text box has to accept alphabet characters ( a - z ) with length of 4 to 10 characters.
In +ve condition we have test the object by giving alphabets. i.e a-z char only, after that we need to check whether the object accepts the value, it will pass.
In -ve condition we have to test by giving other than alphabets (a-z) i.e A-Z,0-9,blank etc, it will fail.

The major activities in Database testing includes,
Checking the Data Validity
Checking the Data Integrity
Checking the Performance related to Database
Checking the Security Aspects

The aspects to be considered in Database Schema testing are,
Checking the Databases and Devices
Checking the Tables, Fields, Constraints, Defaults
Checking the Keys and Indexes
Checking the Stored procedures & Packages
Checking the Error messages
Checking the Triggers - Update, Insert, Delete
Checking the Schema comparisons

Ad hoc testing is concern with the Application Testing without following any rules or test cases. For Ad hoc testing one should have strong knowledge about the Application.

Bottom-up approach: In this approach testing is conducted from sub module to main module, if the main module is not developed a temporary program called DRIVERS is used to simulate the main module.

Top-down approach: In this approach testing is conducted from main module to sub module. if the sub module is not developed a temporary program called STUB is used for simulate the sub module.

Structural testing is a "white box" testing and it is based on the algorithm or code. Functional testing is a "black box" (behavioral) testing where the tester verifies the functional specification.

Re- test – Re-testing means we testing only the certain part of an application again and again with the same build

Regression Testing - Testing the application after a change in a module or part of the application for testing that is the code change/or it can be done by modified build.

• Inadequate requirements from the Client - if the requirements given by the client is not clear, unfinished and not testable, then problems may come.
• Unrealistic schedules – Sometimes too much of work is being given to the developer and ask him to complete in a Short duration, then the problems are unavoidable.
• Insufficient testing – The problems can arise when the developed software is not tested properly.
• Given another work under the existing process – request from the higher management to work on another project or task will bring some problems when the project is being tested as a team.
• Miscommunication – in some cases, the developer was not informed about the Clients requirement and expectations, so there can be deviations.

We can stop the testing when the fallowing points are satisfied

1. When all the requirements are effectively executed successfully through test cases
2. Bug reporting rate reaches a particular limit
3. The test environment no more exists for conducting testing
4. The scheduled time for testing is over
5. The budget allocation for testing is over