Software Testing Tools Wednesday, 20 June 2012Manual Testing Concepts Table of Contents1. Software2. Software Testing2.1. Software Testing Definition2.2. History of Testing2.3. Significance Of testing3. Software Quality3.1. Software Quality Assurance3.2. Software Quality Control4. Software Development Life Cycle (SDLC)4.1 Pre-SDLCSign-in:Kick of meeting:PIN (Project Initiation Note)4.2. Software Development Life Cycle (SDLC)4.2.1. Initial-Phase/ Requirements phase:4.2.2. Analysis Phase:4.2.3. Design Phase:4.2.4. Coding Phase:4.2.5. Testing Phase:4.2.6. Delivery & Maintenance phase4.3. SDLC Models4.3.1. WaterFall Model4.3.2 Incremental Models4.3.3. Prototype Model:4.3.4. Spiral Model4.3.5. V Model4.3.6. Agile Model5. Verification and Validation Testing Strategies5.1 Verification Strategies5.1.1 Reviews5.2 Validation Strategies6. Testing Methodologies:6.1. Kinds of testing:Conventional TestingUnconventional Testing6.2. Methods of testing1. White box Testing2. Black box Testing3. Gray box Testing6.3 Levels of Testing1) Unit level testing2) Module level testing3) Integration level testingi) Top Down Approach (TDA)STUBii) Bottom Up Approach (BUA)DRIVERiii) Hybrid Approachiv) Big Bang Approach4) System level testing5) User acceptance testing6.4. TYPES OF TESTING1. Sanitary Testing / Build Verification Testing / Build Accepting Testing.2. Regression Testing3. Re Testing:4. Alpha - Testing:Advantages:5. Beta - Testing:6. Static Testing:7. Dynamic Testing:8. Installation Testing:9. Compatibility Testing:10. Monkey Testing:11. Exploratory Testing:12. Usability Testing:13. End To End Testing:14. Port Testing:15. Reliability Testing (or) Soak Testing:16. Mutation Testing:17. Security Testing:18. Adhoc Testing:19 .Scalability Testing20. Heuristic Testing21. Accessibility Testing22. Performance Testing23. Load Testing24. Stress testing25. Volume Testing26. Context-driven testing27. comparison testing28. Globalization testing7. ENVIRONMENT1) Stand alone environment (Or) One Tire Architecture.2) Client Server Environment (Or) Two Tire Architecture3) Web Environment4) Distributed Environment8. Test Design Techniques8.1.) White box Testinga) Basis Path Testingb) Flow Graph Notationc) Cyclomatic Complexityd) Graph Matricese) Control Structure Testingf) Loop Testing8.2.) Black box Testinga. Graph Based Testing Methods:b. Error Guessing:c. Boundary Value Analysis:d. Equivalence Partitioning:8.3. Structural System Testing Techniques8.4 Functional System Testing Techniques9. Software Testing Life Cycle (STLC)9.1. TEST PLANNING:9.2. TEST DESIGN STAGE:9.2.1. Test Scenario9.2.2. Test Case9.2.3. Requirement Traceability Matrix9.3. TEST EXECUTION PHASE:9.4. RESULT ANALYSIS:9.5. BUG TRACKING AND REPORTING:9.5.1 Difference between Bug, Defect and Error9.5.2. Reporting Of bugs9.5.3. DPD (Defect Profile Document)9.5.2. Final summary report9.6. TEST CLOSURE:10. Defect metrics11. when to stop testing12. Maturity Levelsa) SEIb) CMMc) ISOd) IEEEe) ANSI

1. Software

Instructions or computer programs which when executed provide desired function and performance.Characteristics of software: Software is logical unlike hardware, which is physical (contains chips, circuit boards, power supplies etc.,) Hence its characteristics are entirely different. Software does not wear out as do hardware components, from dust, abuse, temperature and other environmental factors. A software component should be built such that it can be reused in many different programs.2. Software Testing2.1. Software Testing DefinitionThe British Standards Institution, in their standard BS7925-1, define testing asThe process of exercising software to verify that it satisfies specified requirements and to detect faults; the measurement of software quality Software testing is a process of exercising and evaluating the system component by manual or automation, to ensure that the system is satisfying the stated specifications.Software Testing can also be stated as the process of validating and verifying that a software program/application/product (i) meet the business and technical requirements that guided its design and development;(ii) works as expected; (iii) can be implemented with the same characteristics. It is a process of identifying the defects. It is a process of executing program with the intent of finding an error. 2.2. History of Testing

The separation of debugging from testing was initially introduced by Glen ford J. Myers in 1979.He illustrated the desire of the software engineering community to separate fundamental development activities, such as debugging, from that of verification. Dr. Dave Gelperin and Dr. William C. Hetzel classified in 1988 the phases and goals in software testing in the following stages: Until 1956 - Debugging oriented, where testing was often associated to debugging: there was no clear difference between testing and debugging. 1957-1978 - Demonstration oriented, where debugging and testing was distinguished now - in this period it was shown, that software satisfies the requirements. 1979-1982 - Destruction oriented period, where the goal was to find errors. 1983-1987 - Evaluation oriented period, intention here is that during the software lifecycle a product evaluation is provided and measuring quality. 1988-onward- Prevention oriented period, where tests were to demonstrate that software satisfies its specification, to detect faults and to prevent faults.2.3. Significance Of testing To deliver a quality software to client. Testing is required to check that the application satisfies the requirements. Testing is required to build a Quality Product. Testing will improve the software quality. Testing will also reduce the maintenance cost. Testing will give confidence for the software development Company that the software will work satisfactorily in Client environment. To keep reliability in your product. To withstand in business. To satisfy the client requirements.

3. Software Quality

Conformance to explicitly stated functional and performance requirements, explicitly documented development standards, and implicit characteristics that are expected of all professionally developed software. The degree to which a system, component or process meets specified requirements and customer or user expectations.3.1. Software Quality Assurance Software QA involves the entire software development PROCESS - monitoring and improving the process, making sure that any agreed-upon standards and procedures are followed, and ensuring that problems are found and dealt with. It is oriented to prevention.QA helps establish processes.3.2. Software Quality Control This is a department function, which compares the standards to the product, and takes action when non-conformance is detected for example testing.

3.3. Differences between QA & QC Quality AssuranceQuality Control

A planned and systematic set of activities necessary to provide adequate confidence that requirements are properly established and products or services conform to specified requirements.The process by which product quality is compared with applicable standards; and the action taken when nonconformance is detected.

An activity that establishes and evaluates the processes to produce the products.An activity which verifies if the product meets pre-defined standards.

Helps establish processes.Implements the process.

Sets up measurements programs to evaluate processes.Verifies if specific attribute(s) are in a specific product or service

Identifies weaknesses in processes and improves them.Identifies defects for the primary purpose of correcting defects.

QA is the responsibility of the entire team.QC is the responsibility of the tester.

Prevents the introduction of issues or defectsDetects, reports and corrects defects

QA evaluates whether or not quality control is working for the primary purpose of determining whether or not there is a weakness in the process.QC evaluates if the application is working for the primary purpose of determining if there is a flaw / defect in the functionalities.

QA improves the process that is applied to multiple products that will ever be produced by a process.QC improves the development of a specific product or service.

QA personnel should not perform quality control unless doing it to validate quality control is working.QC personnel may perform quality assurance tasks if and when required.

4. Software Development Life Cycle (SDLC)A set of guidelines followed to have an optimum development.A framework that describes the activities performed at each stage of a software development project.4.1 Pre-SDLCPRE-SDLC PROCESSSign-in:It is the process in which the legal agreement is done between the customer and the development company in such a way that the customer agrees to give the project to the development Company, the project development is done with in a specific budget and the project is to be delivered to the customer on so and so deadline.Kick of meeting:It is the first meeting conducted soon after the project came with in the development company in order to discuss and do the following:Overview of the project, Nature of the customer, Project team selection (project manager the development team, quality head and quality team).The participants of this meeting are HOO (Head of Operations), Technical Manager and the Software Quality Manager. Once the project manager is selected he will release a PIN (Project Initiation Note).PIN (Project Initiation Note) PIN means sending e-mail to the CEO of the development company asking for formal permission to start the project development activities. Once the PM gets the green signal from CEO the project development activities will be geared up (started).4.2. Software Development Life Cycle (SDLC)It contains following phases.1. Initial phase / Requirement phase.2. Analysis phase.3. Design phase.4. Coding phase.5. Testing phase.6. Delivery and maintenance phase.4.2.1. Initial-Phase/ Requirements phase: Task:Interacting with the customer and gathering the requirements

Roles :Business Analyst and Engagement Manager (EM).

Process: First the BA will take an appointment with the customer, Collects the requirement template, meets the customer, gathers requirements and comes back to the company with the requirements document.Then the EM will go through the requirements document. Try to find additional requirements, Get the prototype (dummy, similar to end product) developed in order to get exact details in the case of unclear requirements or confused customers, and also deal with any excess cost of the project.

Proof: BRD, The Requirements document is the proof of completion of the first phase of SDLC.

Alternate names of the Requirements Document: (Various companies and environments use different terminologies, but the logic is same)FRS:Functional Requirements Specification.CRS:Customer/Client Requirement Specification,URS:User Requirement Specifications,BRS:Business Requirement Specifications,BDD:Business Design Document,BD:Business Document.

4.2.2. Analysis Phase:

Tasks: Feasibility Study,Tentative planning,Technologyselection

Roles:System Analyst (SA)Project Manager (PM)Technical manager (TM)

Process: A detailed study on the requirements and judging the possibilities and scope of the requirements is known as feasibility study. It is done by the Manager level teams usually. After that in the next step we move to a temporary scheduling of staff to initiate the project, Select a suitable technology to develop the project effectively (customers choice is given first preference, If it is feasible). And Finally the Hardware, software andHuman resources required are listed out in a document to baseline the project.

Proof:The proof document of the analysis phase is SRS (System Requirement Specification.)

The following is the SRS template of iSpace: 4.2.3. Design Phase:

Tasks:High level Designing (H.L.D) Low level Designing(L.L.D)

Role:Chief Architect (handle HLD) Technical lead (involved in LLD)

Process:The Chief Architect will divide the whole project into modules by drawing some graphical layouts using Unified Modeling Language (UML). The Technical lead will further divide those modules into sub modules using UML. And both will be responsible for visioning the GUI (The screen where user interacts with the applicationOR Graphical User Interface.)and developing the Pseudo code (A dummy code or usually, its a set of EnglishInstructions to help the developers in coding the application.)Proof: TDD Technical Design Document.

The following are the templates of HLD and LLD

4.2.4. Coding Phase:

Task:Developing the programs

Roles:Developers/programmers

Process: The developers will take the support of technical design document and will be following the coding standards, while actual source code is developed. Some of the Industry standard coding methods include Indentation, Color coding, Commenting etc. The complete implementation of Design phase is Coding phase. In this the pseudo code is converted into source code. In this phase developer will develop the actual code using the source code and they release the application to the testee, the application is converted into .exe format in the case of client server applications and the packet of code like WAR files with a URL (web address) in the case of web application will be given for testing. Once test engineer receive this testing is performed.The developers must follow the coding standards in order to ensure that the program is clear and systematic so that anybody can enhance it under maintenance of project in feature. Some of the coding standards are as follows.1. Four character margins have to be left on the left side.2. Comments must be placed for each and every specific block of code.3. Color coding must be maintained for various types of variables.4. A single line space must be maintained between two blocks of code as well as between a comment and a block etc.

Proof: The proof document of the coding phase is Source Code Document (SCD).4.2.5. Testing Phase:

Task: Testing

Roles : Test engineers, Quality Assurance team.

Process:

First, the Requirements document will be received by the testing department The test engineers will review the requirements in order to understand them. While revising, If at all any doubts arise, then the testers will list out all the unclear requirements in a document named Requirements Clarification Note (RCN). Then they send the RCN to the author of the requirement document ( i.e, Business Analyst ) in order to get the clarifications. Once the clarifications are done and sent to the testing team, they will take the test case template and write the test cases. (Test cases like example1 above). Once the first build is released, they will execute the test cases. While executing the test cases, if at all they find any defects, they will report it in the Defect Profile Document or DPD. Since the DPD is in the common repository, the developers will be notified of the status of the defect. Once the defects are sorted out, the development team releases the next build for testing. And also update the status of defects in the DPD. Testers will here check for the previous defects, related defects, new defects and update the DPD. Proof: The last two steps are carried out till the product is defect free, so quality assured product is the proof of the testing phase (and that is why it is a very important stage of SDLC in modern times).4.2.6. Delivery & Maintenance phase

Tasks:Delivery:Post delivery maintenance

Roles :Deployment engineers Process:

Delivery: The deployment engineers will go to the customer environment and install the application in the customer's environment & submit the application along with the appropriate release notes to the customer.

Maintenance: Once the application is delivered the customer will start using the application, while using if any problem occurs, then it becomes a new task, Based on the severity of the issue corresponding roles and process will be formulated. Some customers may be expecting continuous maintenance; In that case a team of software engineers will be taking care of the application regularly. In this process usually PM, SQM, DM (Deployment Manager), Development team and testing team are involved. During this phase the following documents are produced. i. Certification document ii. User guide and help stuff iii. Deployment document (used for installation) iv. SDN document (Software Delivery Note) Used for letting know the customer special information about the product.4.3. SDLC Models Waterfall Model Incremental model Prototype Model Spiral Model V Model Agile Model 4.3.1. WaterFall ModelIn a waterfall model, each phase must be completed in its entirety before the next phase can begin. At the end of each phase, a review takes place to determine if the project is on the right path and whether or not to continue or discard the project.Advantages & Disadvantages:Easier and simple life cycle and useful when client has fixed requirements but for a client who is not sure of the requirements and for confused customers this model does not work. 4.3.2 Incremental ModelsThe incremental model is an intuitive approach to the waterfall model. Multiple development cycles take place here, making the life cycle a multi-waterfall cycle. Cycles are divided up into smaller, more easily managed iterations. Each iteration passes through the requirements, design, implementation and testing phases. A working version of software is produced during the first iteration, so you have working software early on during the software life cycle. Subsequent iterations build on the initial software produced during the first iteration. Advantages a) Generates working software quickly and early during the software life cycle. b) More flexible less costly to change scope and requirements. c) Easier to test and debug during a smaller iteration. d) Easier to manage risk because risky pieces are identified and handled during its iteration. e) Each iteration is an easily managed milestone.Disadvantages a) Each phase of aniterationis rigid and do not overlap with each other. b) Problems may arise pertaining to system architecture because not all requirements are gathered up front for the entire software life cycle.4.3.3. Prototype Model:For a nave client, who has no proper idea of the outcome he wants, the developers initially design a prototype model and customer is approached for evaluation and once the client approves the actual development is made.AdvantagesAnother advantage of having a prototype modeled software is that the software is created using lots of user feedbacks. In every prototype created, users could give their honest opinion about the software. If something is unfavorable, it can be changed. Slowly the program is created with the customer in mind.DisadvantagesThere is also a great temptation for most developers to create a prototype and stick to it even though it has flaws. Since prototypes are not yet complete software programs, there is always a possibility of a designer flaw. When flawed software is implemented, it could mean losses of important resources

4.3.4. Spiral Model

The spiral is a risk-reduction oriented model that breaks a software project up into mini-projects, each addressing one or more major risks. After major risks have been addressed, the spiral model terminates as a waterfall model.

Advantagesa. Dynamic requirement changes present.b. Time taken to deliver the product is more.c. Only intended to large and complicated project. Disadvantagesa. The spiral model is intended for large, expensive and complicated projects.b. Requires considerable expertise in risk evaluation and reduction.c. Complex, relatively difficult to followstrictly.4.3.5. V ModelV model of software development parallel involves testing in all the phases. During the initial phase where in requirements are gathered by the Business Analyst and development team, in V model testers are also involves and they analyze the requirements and make reviews.When the development team is involved in design, testers need to write test cases and prepare RTM (requirements traceability matrix). For high level design (which consists of overview of the entire process) integration test cases are written. For a low level design(consists of detailed description of all modules) unit testing is performed.While in coding phase, testers need to execute the test cases.In test execution i) First unit testing is performed (white box testing). Generally developers perform unit testing, which needs technical knowledge.ii) Then system testing (Black box testing) is done which includes Field validations, GUI, UI, Calculation, Database, URL etc.iii) Then integration testing aniv) And finally reporting Advantagesa) Emphasize planning for verification validation of the product in early stages of product development.b) Each deliverable must be deliverable.c) Easy to use, the errors can be corrected in that phase itself.Disadvantagesa) Does not easily handle iterations.b) Does not easily handle dynamic changes in the requirements.c) It needs lots of money and resources.

4.3.6. Agile Model

Agile methodology is more of people oriented. Agile methodology helps us to increase productivity and reduce risks. There are 2 popular agile methods- Extreme programming (XP) and Scrum. People believe that there is less documentation in Agile.But agile also includes documentation and it can be used either a small or a large projects. In agile Development, testing is also integrated throughout the life cycle. But for the testers, they will not have a good business requirement. So they have to get the details from the client or through the developer. The testers will do more of Quality Assurance work than testing.Agile Methodology- Characteristics Frequent Delivery More Iterations Test frequently Less defects

The Requirement functionality may not becovered in one iteration for releasing the project, but it will be covered in multiple iterations. This idea is to have a defect free release available at the end of each iteration.

Advantagesa) The team does not have to invest time and effort and finally find that by the time they delivered the product, the requirement of the customer has changed. b) The documentation is crisp and to the point to save time.

Disadvantagesc) There is lack of emphasis on necessary designing and documentation.d) The project can easily get taken off track if the customer representative is not clear what final outcome that they want.5. Verification and Validation Testing Strategies5.1 Verification StrategiesThe Verification Strategies, persons / teams involved in the testing, and the deliverable of that phase of testing is briefed below:Verification StrategyPerformed ByExplanationDeliverable

Requirements ReviewsUsers, Developers, Test Engineers.Requirement Reviews help in base lining desired requirements to build a system. Reviewed and approved statement of requirements.

Design ReviewsDesigners, Test EngineersDesign Reviews help in validating if the design meets the requirements and build an effective system. System Design Document, Hardware Design Document.

Code WalkthroughsDevelopers, Subject Specialists, Test Engineers.Code Walkthroughs help in analyzing the coding techniques and if the code is meeting the coding standardsSoftware ready for initial testing by the developer.

Code InspectionsDevelopers, Subject Specialists, Test Engineers.Formal analysis of the program source code to find defects as defined by meeting system design specification.Software ready for testing by the testing team.

5.1.1 Reviews The focus of Review is on a work product (e.g. Requirements document, Code etc.). After the work product is developed, the Project Leader calls for a Review. The work product is distributed to the personnel who involves in the review. The main audience for the review should be the Project Manager, Project Leader and the Producer of the work product.

There are three general classes of reviews:A) Informal or Peer ReviewB) Semiformal or Walk-ThroughC) Format or Inspections

i) Peer Review is generally a one-to-one meeting between the author of a work product and a peer, initiated as a request for import regarding a particular artifact or problem. There is no agenda, and results are not formally reported. These reviews occur on an as needed basis throughout each phase of a project.

ii) Walkthroughs: The author of the material being reviewed facilitates walk-Through. The participants are led through the material in one of two formats; the presentation is made without interruptions and comments are made at the end, or comments are made throughout. In either case, the issues raised are captured and published in a report distributed to the participants. Possible solutions for uncovered defects are not discussed during the review.

iii) Inspections: A knowledgeable individual called a moderator, who is not a member of the team or the author of the product under review, facilitates inspections. A recorder who records the defects found and actions assigned assists the moderator. The meeting is planned in advance and material is distributed to all the participants and the participants are expected to attend the meeting well prepared. The issues raised during the meeting are documented and circulated among the members present and the management.

5.2 Validation StrategiesThe Validation Strategies, persons / teams involved in the testing, and the deliverable of that phase of testing is briefed below:

Validation StrategyPerformed ByExplanationDeliverable

Unit Testing.Developers / Test Engineers.Testing of single program, modules, or unit of code. Software unit ready for testing with other system component.

Integration Testing.Test Engineers.Testing of integrated programs, modules, or units of code.Portions of the system ready for testing with other portions of the system.

System Testing.Test Engineers.Testing of entire computer system. This kind of testing usually includes functional and structural testing.Tested computer system, based on what was specified to be developed.

Production Environment Testing.Developers, Test Engineers.Testing of the whole computer system before rolling out to the UAT.Stable application.

User Acceptance Testing.Users.Testing of computer system to make sure it will work in the system regardless of what the system requirements indicate.Tested and accepted system based on the user needs.

Installation Testing.Test Engineers.Testing of the Computer System during the Installation at the user place.Successfully installed application.

Beta TestingUsers.Testing of the application after the installation at the client place.Successfully installed and running application.

6. Testing Methodologies: 6.1. Kinds of testing: Depends on what part of (SDLC) is tested, there are basically two kinds of testing that are evolved 1. Conventional testing(as usual)2. Unconventional testingConventional TestingIt is a sort of testing in which the test engineer will test the application in the testing phase of SDLC.Unconventional TestingIt is a sort of testing in which quality assurance people will check each and every outcome document right from the initial phase of the SDLC.6.2. Methods of testingThere are 3 methods are there White Box Testing Black Box Testing Gray Box Testing1. White box Testing (Or) Glass box Testing (Or) Clear box TestingIt is a method of testing in which one will perform testing on the structural part of an application. Usually developers are white box testers perform it.2. Black box TestingIt is a method of testing in which one will perform testing only on the functional part of an application without having any structural knowledge. Usually test engineers perform it.3. Gray box TestingIt is a method of testing in which one will perform testing on both the functional part as well as the structural part of an application.6.3 Levels of TestingThere are 5 levels of testing in a software environment. They are as follows1) Unit level testingIf one performs testing on a unit then that level of testing is known as unit level testing. It is white box testing usually developers perform it.Unit: - It is defined as a smallest part of an application.2) Module level testingIf one perform testing on a module that is known as module level testing. It is black box testing usually test engineers perform it.3) Integration level testingOnce the modules are developing the developers will develop some interfaces and integrate the module with the help of those interfaces while integration they will check whether the interfaces are working fine or not. It is a white box testing and usually developers or white box testers perform it.The developers will be integrating the modules in any one of the following approaches.i) Top Down Approach (TDA)In this approach the parent modules are developed first and then integrated with child modules.STUBWhile integrating the modules in top down approach if at all any mandatory module is missing then that module is replace with a temporary program known as STUB.ii) Bottom Up Approach (BUA)In this approach the child modules are developed first and the integrated that to the corresponding parent modules.DRIVERWhile integrating the modules in bottom up approach if at all any mandatory module is missing then that module is replace with a temporary program known as DRIVER.iii) Hybrid ApproachThis approach is a mixed approach of both Top down and Bottom up approaches.iv) Big Bang ApproachOnce all the modules are ready at a time integrating them finally is known as big bang approach.4) System level testingOnce the application is deployed into the environment then if one performs testing on the system it is known as system level testing it is a black box testing and usually done by the test engineers.At this level of testing so many types of testing are done.Some of those areSystem Integration TestingLoad TestingPerformance TestingStress Testing etc.5) User acceptance testingThe same system testing done in the presents of the user is known as user acceptance testing. Its a black box testing usually done by the Test engineers.6.4. TYPES OF TESTING1. Build Verification Testing.2. Regression Testing.3. Re Testing.4. Alpha - Testing.5. Beta - Testing.6. Static Testing.7. Dynamic Testing.8. Installation Testing.9. Compatibility Testing.10. Monkey Testing11. Exploratory Testing.12. Usability Testing.13. End To End Testing.14. Port Testing.15. Reliability Testing16. Mutation Testing.17. Security Testing. 18. Adhoc Testing.19. Scalability Testing.20. Heuristic Testing.21. Accessibility Testing.22. Performance Testing23. Load testing24. Stress Testing25. Volume Testing26. Context Driven Testing27. Comparison Testing28. Globalization Testing1. Sanitary Testing / Build Verification Testing / Build Accepting Testing.It is a type of testing in which one will conduct overall testing on the released build in order to check whether it is proper for further details testing or not.Some companies even call it as Sanitary Testing and also Smoke Testing. But some companies will say that just before the release of the built the developers will conduct the overall testing in order to check whether the build is proper for detailed testing or not that is known as Smoke Testing and once the build is released once again the testers will conduct the overall testing in order to check whether the build is proper for further detailed testing or not. That is known as Sanitary Testing2. Regression TestingIt is a type of testing in which one will perform testing on the already tested functionality again and again this is usually done in scenarios (Situations). Scenario 1:Whenever the defects are raised by the Test Engineer rectified by the developer and the next build is released to the testing department then the Test Engineer will test the defect functionality and its related functionalities once again. Scenario 2:Whenever some new changes are requested by the customer, those new features are incorporated by the developers, next built is released to the testing department then the test engineers will test the related functionalities of the new features once again which are already tested. That is also known as regression testing. Note: Testing the new features for the first time is new testing but not the regression testing.3. Re Testing:It is a type of testing in which one will perform testing on the same function again and again with multiple sets of data in order to come to a conclusion whether the functionality is working fine or not.4. Alpha - Testing:It is a type of testing in which one (I.e., out Test Engineer) will perform user acceptance testing in our company in the presents of the customer.Advantages: If at all any defects are found there is a chance of rectifying them immediately.5. Beta - Testing:It is a type of testing in which either third party testers or end users will perform user acceptance testing in the client place before actual implementation.6. Static Testing:It is a type of testing in which one will perform testing on an application or its related factors without performing any actions.Ex: GUI Testing, Document Testing, Code reviewing and etc7. Dynamic Testing:It is a type of testing in which one will perform testing on the application by performing same action.Ex: Functional Testing.8. Installation Testing:It is a type of testing in which one will install the application in to the environment by following the guidelines given in the deployment document and if the installation is successful the one will come to a conclusion that the guidelines are correct otherwise the guidelines are not correct.9. Compatibility Testing:It is a type of testing in which one may have to install the application into multiple number of environments prepared with different combinations of environmental components in order to check whether the application is suitable with these environments or not. This is use usually done to the products.10. Monkey Testing:It is a type of testing in which one will perform some abnormal actions intentionally (wanted) on the application in order to check its stability.11. Exploratory Testing:It is a type of testing in which usually the domain expert will perform testing on the application parallel by exploring the functionality without having the knowledge of requirements.12. Usability Testing:It is a type of testing in which one will concentrate on the user friendliness of the application.13. End To End Testing:It is a type of testing in which one will perform testing on a complete transaction from one end to another end.14. Port Testing:It is a type of testing in which one will check whether the application is comfortable or not after deploying it into the original clients environment.15. Reliability Testing (or) Soak Testing:It is a type of testing in which one will perform testing on the application continuously for long period of time in order to check its stability.16. Mutation Testing: It is a type of testing in which one will perform testing by doing some changesFor example usually the developers will be doing any many changes to the program and check its performance it is known as mutation testing.17. Security Testing: It is a type of testing in which one will usually concentrate on the following areas.i) Authentication.ii) Direct URL Testing.iii) Firewall Leakage Testing.i) Authentication Testing:it is a type of testing in which a Test Engineer will enter different combinations of user names and passwords in order to check whether only the authorized persons are accessing the application or not.ii) Direct URL Testing:It is a type of testing in which a test engineer will specified the direct URLs of secured pages and check whether they are been accessing or not.iii) Firewall leakage Testing:It is a type of testing in which one will enter as one level of user and try to access the other level unauthorized pages in order to check whether the firewall is working properly or not.18. Adhoc Testing:it is a type of testing in which one will perform testing on the application in his own style after understanding the requirements clearly.19 .Scalability TestingIt is a type of testing in which one can perform testing on the application to check if the application is enhance able / expandable and measurable without having to do with design changes and environmental alterations.20. Heuristic TestingIt is a type of testing in which the test engineer performs testing on the application based on the past experience to ensure through testing and complete coverage in the testing.21. Accessibility Testing It is a type of testing in which the test engineer checks the application if it has accessibility factor. In other words he checks if the application is able to serve the abnormal disable users apart from normal users.22. Performance Testingperformance testing is testing that is performed, from one perspective, to determine how fast some aspect of a system performs under a particular workload. It can also serve to validate and verify other quality attributes of the system, such as scalability, reliability and resource usage.23. Load TestingTesting an application under heavy loads, such as testing of a web site under a range of loads to determine at what point the system's response time degrades or fails.24. Stress testingTesting the stability and response time of an application by applying the load which is more than design load25. Volume TestingTesting the stability and response time of an application by passing the huge volume of data across the application26. Context-driven testing Testing driven by an understanding of the environment, culture, and intended use of software. For example, the testing approach for life-critical medical equipment software would be completely different than that for a low-cost computer game.27. comparison testing comparing software weaknesses and strengths to competing products.28. Globalization testing Developing the application in multiple languages is known as globalization. Testing this kind of application is called as globalization testing. We need to test the application for different languages example: - English, French, Chinese etc.It is of two types:-1. Localization testing.2. Internationalization testing.internalization testing It is the testing done to check the application is working on different platforms of international languages.Ex: - Spanish, German etc.

localization testing It is the testing done to check the application is working on different platforms of local languages.Ex: - Win 95/98/2000 etc.7. ENVIRONMENTEnvironment is a combination of 3 layers. -Presentation Layer-Business Layer-Database LayerTypes of Environment There are 4 types of environments.i) Stand alone Environment / One tier Architecture.ii) Client Server Environment / Two tier Architecture.iii) Web Environment / Three tier Architecture.iv) Distributed Environment / N tier Architecture.1) Stand alone environment (Or) One Tire Architecture.This environment contains all the three layers that is Presentation layer, Business layered and Database layer in a Single tier.2) Client Server Environment (Or) Two Tire ArchitectureIn this environment two tiers will be there one tier is for client and other tier is for Database server. Presentation layer and Business layer will be present in each and every client and the database will be present in database server.3) Web EnvironmentIn this Environment three tiers will be there client resides in one tier, application server resides in middle tier and database server resides in the last tier. Every client will have the presentation layer, application server will have the business layer and database server will have the database layer.4) Distributed Environment It is same as the web Environment but the business logic is distributed among application server in order to distribute the load.Web Server: It is software that provides web services to the client.Application Server: It is a server that holds the business logic. Ex: Ton tact, Tomcat, Web logic, web Spear etc8. Test Design Techniques8.1.) White box TestingWhite box testing strategy deals with the internal logic and structure of the code. White box testing is also called as glass, structural, open box or clear box testing. In order to implement white box testing, the tester has to deal with the code and hence is needed to possess knowledge of coding and logic i.e. internal working of the code.a) Basis Path TestingEach independent path in the code is taken for testing.b) Flow Graph NotationThe flow graph depicts logical control flow using a diagrammatic notation. Each structured construct has a corresponding flow graph symbol. c) Cyclomatic ComplexityCyclomatic complexity is software metric that provides a quantitative measure of the logical complexity of a program. In basis path testing method, the value computed for Cyclomatic complexity defines the number for independent paths in the basis set of a program and provides us with an upper bound for the number of tests that must be conducted to ensure that all statements have been executed at least once. An independent path is any path through the program that introduces at least one new set of processing statements or a new condition. Computing Cyclomatic ComplexityCyclomatic complexity has a foundation in graph theory and provides us with extremely useful software metric. Complexity is computed in one of the three ways:1. The number of regions of the flow graph corresponds to the Cyclomatic complexity.2. Cyclomatic complexity, V (G), for a flow graph, G is defined as V (G) = E-N+2Where E, is the number of flow graph edges, N is the number of flow graph nodes.3. Cyclomatic complexity, V (G) for a flow graph, G is also defined as: V (G) = P+1Where P is the number of predicate nodes contained in the flow graph G. d) Graph MatricesThe procedure for deriving the flow graph and even determining a set of basis paths is amenable to mechanization. To develop a software tool that assists in basis path testing, a data structure, called a graph matrix can be quite useful. A Graph Matrix is a square matrix whose size is equal to the number of nodes on the flow graph. Each row and column corresponds to an identified node, and matrix entries correspond to connections between nodes. e) Control Structure TestingDescribed below are some of the variations of Control Structure Testing. Condition TestingCondition testing is a test case design method that exercises the logical conditions contained in a program module. Data Flow TestingThe data flow testing method selects test paths of a program according to the locations of definitions and uses of variables in the program. f) Loop TestingLoop Testing is a white box testing technique that focuses exclusively on the validity of loop constructs. Four classes of loops can be defined: Simple loops, Concatenated loops, nested loops, and unstructured loops. Simple Loops The following sets of tests can be applied to simple loops, where n is the maximum number of allowable passes through the loop. 1. Skip the loop entirely.2. Only one passes through the loop.3. Two passes through the loop.4. m passes through the loop where m