Siva

Testing Notes 1

Quality:
It is defined as conformance to the requirements of customer. In other words justification of customers requirements in the product so as to produce customer satisfaction is defined as quality.

Defect:
It is defined as deviation from the requirements.

Error:
Mistake associated in the program, which is the root cause for defect. Hence error is the cause, defect is effect. Errors are two types Syntactical errors Symantec errors

Bug:
Bug is same as defect conceptually from the point of usage, bug is used by professionals mostly where as defect can be used by both professionals and as well as customers.

Latest definition of Quality:L.D = O.D + X Where X is some Value

Quality is defined as not only presence of the requirements or absence of the defects but also the presence of the value. The value means user friendliness of the application. One has to understand that every application must have the user friendliness factor which is termed as usability apart from the functional perfection. As testing engineers we have the responsibility to check for usability along with the functionality of an application.

Siva

Testing Notes 1

Testing:1) Identification of the defects:In this phase one has to carefully examine the product and identify the areas of functionality in which the requirements are not properly justified. In other words identification of various defects. 2) Isolating the defects (separation):In this phase all the defects that are identified in previous step are listed out in the separate document is known as Defect Profile Document. 3) Subjecting these defects for rectification:The defect profile document that is prepared in the previous step will be sent to the development team for the process of defects rectification or fixation. 4) Ensure that the product is defect free:Once the defects are rectified by the developers, same thing is informed to the testing team. The test engineer must ensure that the product is defect free by doing the following. a) To check if the defect are really rectified by the developers. b) To check if at all any new defects due to the rectification of old defects. Testing is defined as a process in which defect are identified, Isolated, Subjected for rectification and ensure that the product is defect free in order to provide quality to product so as to produce customer satisfaction. Or Testing is the process of executing a program with the intent of finding errors. Or Verifying and validating the application with respect to customer requirements. ----------------------------------------------------------------------------------------------

Where exactly testing comes?

Sign-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 the following 1) Over view of entire project 2

Siva

Testing Notes 1

2) Nature of the customer. 3) Project team selection (project manager the development team, quality head and quality team). The participants of this meeting are HOO (Head of Operation), technical manager and the software quality manager. Once the project manager is selected he will release a 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).

Software Development Life Cycle (SDLC):In order to make the software development effort more systematic and scientific with their optimization a special procedure is adapted by organization is known as SDLC. 1) 2) 3) 4) 5) 6) Initial Analysis Design Coding Testing Delivery and Maintenance

1) Initial:In this phase major responsibility are as follows i. End user interactions. ii. Requirement collection. iii. Existing business model study. iv. Gap analysis. v. Suggesting solution for the gap. The role involved in this phase to carry on above responsibilities is business analyst. BA will accomplish all this responsibility as per the guide line provided by the specific quality standards in terms of the process. Once he collects all the information from the customer he will be documenting in terms of Business Design Document (BDD). This document can also termed as various companies (BD, BRS, BRD, FRS) etc. Every role for his documentation has use a specific template to make sure the perfection of the documentation. [Note: BDD-Business Design Document, BRS - Business Requirement Specification, BRD- Business Requirement Document, FRS- Functional Requirement Specification.]

Template:-

Siva

Testing Notes 1

It is defined as predefined format in which the required fields are defined for which the information can be given to prepare a document. Once the document prepared the same is available as a mail to rest of the team members or through the means of common repository (CR) which is kind of share server. Apart from BA the engagement manager will be exercising his responsibilities in this phase in terms of monitoring factor. 2) Analysis:This phase is meant for the following responsibilities. 1) Analyzing the requirements 2) Feasibility study(Technology and system feasibility, Economic feasibility, Legal feasibility, Operational feasibility, Schedule feasibility, Resource feasibility) evaluation or analysis of the potential impact of a proposed project 3) Technology selection 4) Tentative project plan preparation (PM does it in association with a system analyst) 5) System requirement specification analysis All the above responsibilities efficiently carried on by the system analyst with the help of assigned process. Having done the analysis the entire information is documented in terms of system requirement specification.

3) Design:This phase is meant for designing the project, in other words development of blue print or a plan to constructing a project. Designing activities can be done in the following two ways. a) High Level Designing (HLD) b) Low Level Designing (LLD)

High Level Design:It is the type of design in which how many modules an entire project can be divided into is determined. (Module is defined as a collection of similar functionalities which together work for a specific service).

Low Level Design:It is a type of design in which how many sub modules / units an entire module can be divided is determined. High level design is done by CA where as low level design is done by TL.

Siva

Testing Notes 1 Following the process the design activity will be accomplished effectively and is documented in terms of Technical Design Document (TDD). 1. 2. 3. 4. Overall design description Detailed design description Flow Charts Various design diagrams Object Diagrams Class Diagrams Activity Diagrams Sequence Diagrams 5. DFD 6. Functional Specification(Pseudo Code it is a key input for developers)

4) Coding:This phase is meant for development of the programs based on design. It is also referred as implementation of design. The developers are involved in writing the programs with the input information pseudo code of functional specification that is present in TDD. The developers must follow the coding standards in order to ensure that the program is clear and systematic so that any body can enhance it under maintenance of project in feature. Some of the coding standards are as follows. 1. 2. 3. 4. Four character margins have to be left on the left side. Comments must be placed for each and every specific block of code. Color coding must be maintained for various types of variables. A single line space must be maintained between two blocks of code as well as between a comment and a block etc.

Once the development is over and source code document is prepared as such it will not be sent to testing department for testing. But it will be 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 wed application will be given for testing. Once test engineer receive this testing is performed is performed on the module. 5) Testing:Testing domains process Tell me the testing process? How do you test the product? How to prepare test cases? 5

Siva Tell me what do you do in the company?

Testing Notes 1

Testing process: In order to carry the testing on a specific module / product the following steps must be adopted by the industry.

1) BDD Review:In this phase test engineer tries to have functional knowledge about a product to be tested. Unless one has the functional knowledge one cannot perform testing of the product. 2) Preparation of Review Report:As the test engineer study the BDD under the process of review to know the functionality there may be lot of queries / doubts for which the clarifications are required. Hence all these queries or doubts are listed out in a separate document known as review report. 3) Sending Review Report to the Author:The review report document prepared in the previous step is sent to the author of the BDD mostly BA in order to get the clarifications for all the list of queries. BA will respond to those queries and send the clarifications back to the test engineer. 4) Preparation of the Test case Document:In order to make sure that the testing effort is organized, planed and estimated a special document is prepared known as Test case document. Test case: It is defined as a case/ an angle / perception with which the specific functionality can be tested. In other words it is defined as possibility or a chance in which the probability of finding defect is more. 5) Execution of the Test case Document:Soon after the module or a product is released for testing the test case document which is prepared in the previous step must be executed on it to carry on testing on the released module / product. 6) Bug tracking:-

Siva

Testing Notes 1 Soon after the testing is over all the defects encountered during testing are listed out in a separate document known as Defect Profile Document (DPD) 7) Reporting Defect profile Document to the Development Team:Once the DPD is prepared it will be sent to the development team for the process of rectification of the defect [Note: During the development when the developers are building the product the test engineers simultaneously are involved in the process of review, getting the clarifications and preparing the documents like review report and test case document. But during the testing phase the test case document is executed where as DPD and test report documents are prepared.]

6) Delivery and Maintenance:Once the product is developed, tested and certified it will be released to the customer under the process of delivery. Once the product is being used any issue related to the usage, installation and the functionality will be resolved as per the deal by the development company under the process of maintenance. 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. ii. iii. iv. Certification document User guide and help stuff Deployment document (used for installation) SDN document (Software Delivery Note) Used for letting know the customer special information about the product

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 testing

Conventional testing:
Previously the testing use to be happened the developed products are checked if they are right in other words conventional testing is a kind at testing in which the developed functionality is tested for its correctness if it is as per the requirement. This testing mainly focuses upon the developed functionality which is obviously after coding and it is always done by test engineers. This conventional testing is also referred to as validation.

Siva

Testing Notes 1 It typically involves actual testing and takes place after the verifications are

complete. It determines the correctness of final build with respect to its requirements. It checks whether we are building the right product? Also called as exit or end process testing /quality control

Unconventional testing:
Later on over a period of time the industry realized the testing of inputs apart from testing the out puts. In other words unconventional testing is defined as a kind of testing in which the input information in terms of documents and the process followed by roles are tested. This testing focuses upon the documents and the processes and is performed in all the phases at SDLC right from the initial phase till the end. The unconventional testing is performed by quality assurance engineer (QAE).This testing is also referred to as verification. Verification is also known as In-Process Testing and Quality assurance. Verification typically involves reviews and meetings to evaluate documents, plans, code, requirements, and specifications. It determines of consistency, correctness and completeness of a program at each stage. It checks whether we are building the product right?

Siva
HOW TO TEST ON AN APPLICATION?

Testing Notes 1

TESTING METHODOLOGY: Depends upon what part of application to be tested. There are basically 2 methods at testing that are evolved, they are 1. Black box testing 2. White box testing Black box testing: It is defined as method of testing in which one can perform testing on an application without having internal structural knowledge. The black box testing focuses up on the functional part of an application and it is always done by test engineers. White box testing: It is defined as method of testing in which one can perform testing on an application having internal structural knowledge, specifically program knowledge. The white box testing focuses up on the structural part of the application, in other words the program of an application is tested. White box testing is always done by developers. White box testing is also called as glass box testing. Gray box testing: It is defined as another derived method of testing in which both the techniques of white box and black box testing are applied. In other words grey box testing is a method of testing in which basically the test engineer will be performing black box testing on functionality but having internal structural knowledge in terms of program or design or environment. How to perform systemic testing on product? Has the software development companies wants to achieve more quality of the product basically introduced validation in terms of conventional testing, eventually they have further introduced verification in terms of unconventional testing and finally they have realized the product can be tested systemically when it is being developed to achieve more quality rather than testing it after its development. This systemic testing is referred to as levels of testing, as the product is developed at each level.

Siva Levels of Testing:1) 2) 3) 4) 5) Unit Testing Module Testing Integration Testing System Testing User Acceptance Testing

Testing Notes 1

Unit testing: It is defined as an initial level of testing in which once the unit is developed it will be tested for its correctness, if it is justified the requirements. Unit testing belongs to white box testing as at this level no screen is available and program only be tested. Hence it is always done by developers. Module testing: Soon after units are developed to form single module if at all any are performs testing on it to check its operational perfection this type of testing is known module testing. The module testing belongs to black box testing as GUI is available at this level to check the functionality on it. Hence module testing is always done by test engineers. Integration testing: Once the modules are individually developed and tested for their perfection they are brought together to form an application. Once the modules are integrated if testing is performed on integrated modules it is known as integration testing. Purpose: 1. to check if the individual modules retain their perfection even after integration 2. to check the integrated behavior of these modules 3. To check if the data communication among the modules is as per DFDs of the technical design document. Integration process/integration approaches: Depend upon how the modules are getting integrated; there are 3 approaches of integration as described below. Top to bottom approach: This approach is usually preferred when there is no interference of customer in the development sequence. In this approaches as child modules are developed they will be integrated with parents and since the direction of integration is from top to bottom it is known as top to bottom approach. In this process as the child modules are integrated with parents there is every possibility that some child modules will be missing yet to be developed. Due to this integration between other modules may not be possible, in order to get along with this situation a temporary dummy programme is used in place of missing module, this program is known as stub.

10

Siva

Testing Notes 1

Bottom up approach: This approach is proposed when ever the customer interferes in the beginning and changes sequence of development. In this approach as the parents are developed they are to be integrated with children. Since the direction of integration of is bottom to up. It is known as bottom up approach. In this approach that is every possibility that the parent is missing that causes obstruction for integration. As a solution a small temporary dummy programme is used in the place of missing module is used is known as DRIVER. Sandwich approach: This approach is proposed whenever the customer interferes in between and tries to alter sequence of developer. In this approach both top to bottom and bottom up approaches are used. Hence both stubs and drivers are used in this approach. Basically integration testing belongs to white box testing as it is done in the program level for the first time and it is obviously done by developers. Integration testing depends on where it is performed how it is performed it has been classified into following.
Low level integration testing:

Integration testing by default low level testing, by always it is done at low level and it is always done by developers.
High level integration testing:

Once at low level programs are integrated, the testing is performed at high level in other words GUI level to check if one screen is able to talk to other screen. This type of testing the checks for the integration of screens is known as HLIT. It is always done by test engineers. In a way it is also known as navigation testing. To check if the user is able to navigate among different pages of the application. System Testing Once the application is developed it has to be deployed into the customers specified simulated environment so as to prepare a system. (when once software is integrated to hardware it is said to be a system). If one performs testing on the system to check the operational behavior, performance, look and feel it is known as system testing. In a way system testing is a full fledged testing as it includes GUI testing, functional testing, load testing, performance testing, stress testing, security testing etc. Note: High level integration testing is covered under system testing. System testing belongs to Black Box testing and is always done by Test Engineers.

11

Siva

Testing Notes 1

User Acceptance Testing It is final level of testing in which the application is tested in the customer specified simulated live environment (Production Site) in the presence of the customer with in the development company(some times in the client place) to ensure the justification of acceptance criteria and it is designed to determine whether software is fit for use or not. The UAT belongs to Black Box testing and is done by test engineers/customers/end users.

12

Siva

Testing Notes 1

Environments
Depends on how the application is deployed in the environment, basically environment has been classified into four categories. Stand alone Environment (1-Tire Architecture) Client-server environment (2-Tier Architecture) Web Environment (3-Tier Architecture) Distributed Environment (N-Tier Architecture)

Stand Alone Environment (1-Tire Architecture):It is the environment in which three components of application Presentation Logic (PL), Business Logic (BL) and Data Base (DB) are deployed into single computer. The application running on it is known as stand-alone environment.

Client-server environment (2-Tier Architecture):It is known as two tier architecture in which two computers are used one being client and the other one is server. Usually the application is deployed into this environment in such a way that (PL + BL) is on the client where as the DB is on the server. This type of client is known as Thick client. If the client has only PL is known as Thin client.

Web Environment (3-Tier Architecture):This type of environment has three tier one is client in which PL is present the second one is the application server in which BL is present and the third one is data base server in which DB is present.

Distributed Environment (n-Tier Architecture):In this environment the application server BL is distributed among n number of machines depends on volume. This environment is known as distributive environment and it is also referred as n-tire architecture. Based on the business transactional scope we have two types of application. B2C- this is business to customer application which always play a role between the customer and a business organization. B2B-this is business to business which is capable of establishing a communication between two business organizations and ultimately provides service to the end users.

13

Siva

Testing Notes 1

MD

D1

D2
CEO

D3

HOO1

HOO2

OM

HRM

TM

SQM

BA

SA

NM

EM

DM

PM1

PM2

QL1

QL2

QA

QC

TL1

TL2

TL1

TL2

SSE1

SSE2

STE1

STE2

SE1

SE2

TE1

TE2

MD = Managing Director. CEO = Chief Executive Officer. HOO = Head of Operations. OM = Operations Manager. HRM = Human Resource Manager. TM = Technical Manager also known as Chief Architect. PM = Project Manager also known as Project Lead. TL = Technical Lead 14

Siva

Testing Notes 1 SSE = Senior Software Engineer JSE = Junior Software Engineer SQM = Software Quality Manager QL = Quality Lead TL = Test Lead STE = Senior Test Engineer (writing the test cases) JTE = Junior Test Engineer (executing the test cases) QA = Quality Assurance QC = Quality Control BA = Business Analyst SA = System Analyst NM = Network Administrator Manager EM = Engagement Manager DM = Deployment Manager

In an organization with respect to the corresponding hierarchy communication system plays a vital role to get the tasks accomplished successfully and effectively. Communication system can be understood in terms of the following practices. Intimation (reporting) Escalation 1) Intimation (reporting):It is the process in which the accomplished responsibilities are usually documented and same is reported to the team leads (point of contacts) to let them know the status. 2) Escalation:It is the process of communication in which slippages as well as issue are intimated to the high level management so that they will interfere to resolve their issue as well as possible. Escalation can be done in multiple level (from level one to level n) depends on the delay that is involved to resolve that issue.

15

Siva

Testing Notes 1

The Types of Testing

1) Smoke testing 2) Sanity Testing 3) Regression Testing 4) Re-Testing 5) Alpha Testing 6) Beta Testing 7) Static Testing 8) Dynamic Testing 9) Installation Testing 10) Compatibility Testing 11) Monkey Testing 12) Exploration Testing 13) Usability Testing 14) Forced Error Testing 15) End to End Testing 16) Accessibility Testing 17) Heuristic Testing 18) Security Testing 19) Scalability Testing 20) Reliability Testing 21) Ad-hoc Testing

16

1) Smoke testing:-

2) Sanity Testing:Smoke In software industry, smoke testing is a 1 shallow and wide approach whereby all areas of the application without getting into too deep, is tested that means it is a type of testing in which an initial, non detailed and quick testing to is performed if are all on an the application check Sanity A sanity test is a narrow regression test that focuses on one or a few areas of functionality. Sanity testing is usually narrow and deep.

windows/features/objects 2 3

basically A sanity test is usually unscripted. A Sanity test is used to determine a small section of the application is still working after a minor change. Sanity testing is a cursory testing; it is performed whenever a cursory testing is sufficient to prove the application is functioning according to specifications. This level of testing is a subset of regression testing.

available to carry for further testing. A smoke test is scripted--either using a written set of tests or an automated test A Smoke test is designed to touch every part of the application in a cursory way. It's is shallow and wide. 4 Smoke testing will be conducted to ensure whether the most crucial functions of an application, but not bothering with finer details. (Such as build verification).

Smoke testing is normal health check up to a build of an application before taking it to testing in depth.

Sanity

testing

is

to

verify

whether

requirements are met or not, By checking all features breadth-first.

3) Regression Testing:It is a type of testing in which an already tested functionality is once again tested repetitively to ensure refinement and also to ensure existing right functionality is unaffected as and when a change is added to it.

Types of Regression Testing

There are basically two types of regression testing based on the objective of testing is performed. a) Bug Regression Testing b) Functional Regression Testing a) Bug Regression Testing:It is the type of regression testing in which an already tested module / product, is once again tested to ensure previously raised bug are rectified and no new bugs due to the rectification of the old bugs. Precisely it provides refinement to the perfection.

b) Functional Regression Testing:It is a type of regression testing in which an already tested module / product is once again tested to ensure the existing right functionality is unaffected due to the new change that is added. Hence functional regression testing will always carried on the old functionality rather than the newly added functionality. 4) Re-Testing:-

Retesting is the repeat execution of test cases which lead to a defect or bug, with the aim of proving that the defect has been cured to ensure the

robustness of the application. 5) Alpha() Testing:It is a type of user acceptance testing that is conducted on the product as a final testing with in the development company just before it is delivered to the customer. 6) Beta() Testing:It is a type of testing in which the testing is conducted on the product once it is delivered to the customer, deployed into the customers environment and when it is used by the real time users to ensure the functional perfection in the real environment. Beta testing is also a type of user acceptance testing. Beta testing is usually done by a set of third party test engineers is known as Beta Testers. The advantage of alpha () testing is that in case any defects are encountered this can be rectified immediately. Where as the disadvantage of beta()

testing is that the encountered defects can not be rectified immediately and as it is always time consuming as it needs to follow the process. 7) Static Testing:It is a type of testing in which one can perform testing on an application when it is not being executed. Ex: Document testing, Reviews, Walkthroughs and Inspections (unconventional testing) 8) Dynamic Testing:Its a type of testing in which one can perform testing on an application when it is being executed in other words one has to interact with application to check the functionality in this testing. Ex: Functionality testing / functional testing. 9) Installation Testing:It is a type of testing in which the test engineers check if the released module is successfully deployed in the environment as per the guideline provided in the Deployment Document. Deployment Document It is basically a document prepared by a project manager and is sent along with the module to the testing team for the successful deployment. This document contains the guidelines to the deployer for successful accomplishment of the installation process. [Note: The test engineer irrespective of the deployment knowledge with the help of deployment document and accomplish the deployment process.] Port Testing: Once the application is deployed in user specified environment, testing the application whether it is compatible or not is called port testing.

10) Compatibility Testing:It is a type of testing usually conducted on a product in the various environments simulated with several combinations of the environmental components like browsers, application server, data base server, operating systems etc. to check if the product is compatible with these environments. Difference between Project and Product: Is that if the requirements are coming from the outside customer and the out come of the development is known as project and that can be delivered to the specific customer, where as if the requirements are originated with in the development company and outcome of the development called product and it is for any customer. The compatibility testing is mostly done on products.

11) Monkey Testing:Its a type of testing in which one can perform abnormal, beyond capacity, more volumes of data related operations are performed on an application intentionally in order to check if the application is stable despite the abnormal behavior of the user.

12) Exploratory Testing:It is a type of testing in which the test engineers will not be having the functional knowledge initially and as he explores the application the functional knowledge is obtained testing is performed simultaneously. Since testing is carried on with exploration it is known as exploration testing.

13) Usability Testing:It is a type of testing in which one can perform testing on an application to check the usability in other words user friendliness apart from perfection.

14) Forced Error Testing:It is a type of negative testing in which one can perform testing on the application with invalid inputs in order to check whether the application displays appropriate error messages from the point of usability.

15) End to End Testing:It is a type of testing in which a full fledged transaction is accomplished successfully to ensure that all the environmental components are operationally available. In other words this is a testing performed on all these environmental components to check if they are working fine. So that end user is able to accomplish the transaction completely and successfully.

16) 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.

Accessibility:
It is defined as an extensibility of the usability from the normal user to the disable / handicapped user. US federal regulation act # 508 has defined the criteria for accessibility.

18) Heuristic Testing:It 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.

19) Security Testing:It is a type of testing in which the test engineer performs testing on the application to check if the security is maintained in such a way that the valid users are able to access, invalid users are unable to access and the vital information is protected from destructive agents like viruses. Security testing can be done in many ways with several objectives in many areas. Some of them are given below. Login Screen: Using the login screen one can test valid user is able to access and invalid user is unable to access. Illegal access of web page: The test engineer tries to access the web page with URL with out login and see the security is maintained. Firewall: It is a means of security usually is established before the servers where in vital information is stored. The test engineer must check if the firewall is working as per the administrative setting to allow the desire requests and not to allow the undesired requests. In other words it must have capability to block destructive agents like viruses for the sake of protection.

A1: Injection A2: Cross-Site Scripting (XSS) A3: Broken Authentication and Session Management A4: Insecure Direct Object References A5: Cross-Site Request Forgery (CSRF) A6: Security Misconfiguration A7: Insecure Cryptographic Storage A8: Failure to Restrict URL Access A9: Insufficient Transport Layer Protection A10: Unvalidated Redirects and Forwards

20) Scalability Testing:It 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. In other words for an existing product they may be a situation that it may take extra functionality added to it based on a business need or even number of users may be increase over a period of time. In both the cases the application / products performance should not be degraded. At the same time it must be expandable with out demanding the design and environmental change.

21) Reliability Testing:-

It is a type of testing in which one can perform normal as well as abnormal actions on the application for a longer duration (Say 48 hrs to 72 hrs) to check if the operational capability in terms of stability is retained with out any performance degradation. This testing is also known as soak testing.

22) Ad-hoc Testing:It is a type of informal and random testing performed on the application with out using the test case document unlike formal testing, in order to cover the uncovered functional areas with the test case document. In a way ad-hoc testing defines test case document to the perfection. So that it provides more coverage for testing. That in turn produces quality to the product.

22)

Mutation Testing:It is a type of white box testing done by developers in which an initial version of programme is modified to several other versions as and when new requirements are incorporated every time is such changed version is known as mutant. As and when new mutant is generated test data is generated to test that mutant. Since mutants are involved and it is known as mutation testing.

When do you stop Testing?

In fact the testing is never ending process. It has to be compromised based on the threshold value defined by the quality policy of the organization. Stoppage of testing can be understood in the following ways. 1) Unsuccessful stop: Whenever a module is developed and is released to testing if that module is unable to be tested due to the unavailability of most of the functionality. The testing can be abruptly stopped unsuccessfully. 2) Successful stop: The testing can be successfully stop provided the quality policy define criteria by the organization is justified in other words when the testing encounters the product / module with zero defects and enough value present in it. This can be possible with one round of formal testing one round of Ad hoc testing. Hence successfully the testing can be stopping once the Ad hoc testing once after the formal testing.

You Can't determine when to stop testing. Now a days software applications are so complex and should run in a interdependent environment that complete 100 % testing can never be done. Few things are there to stop....

1. When bug rate falls to certain level 2. Test cases completed with certain percentage passed 3. Depending on Test Budget 4. Deadlines (may be release deadlines or testing deadlines) When to stop testing" is one of the most difficult Questions to a test engineer. The following are few of the Common Test Stop criteria: - All the high priority bugs are fixed. - The rate at which bugs are found is too small. - The testing budget is exhausted. - The project duration is completed. - The risk in the project is under acceptable limit.