Software Test Strategy Document Example

Version 1.0 (Initial Draft) December 30, 2010 Revision History Date Author Description of revisions Version # December 30, 2010 Initial Draft 1.0 1.1 Table of Contents REVISION HISTORY 1. INTRODUCTION 1.1 PURPOSE 4 1.2 SOFTWARE FUNCTIONAL OVERVIEW 1.3 CRITICAL SUCCESS FACTOR 1.4 SOFTWARE TESTING SCOPE (TBD) Inclusions Exclusions 1.5 SOFTWARE TEST COMPLETION CRITERIA 2. TIMEFRAME 3. RESOURCES 4.1 SOFTWARE TESTING TEAM 4.2 HARDWARE REQUIREMENTS 4.3 SOFTWARE REQUIREMENTS 5. APPLICATION TESTING RISKS PROFILE 6. SOFTWARE TEST APPROACH 6.1 STRATEGIES 6.2 GENERAL TEST OBJECTIVES: 6.3 APPLICATION FUNCTIONALITY 6.4 APPLICATION INTERFACES 6.5 SOFTWARE TESTING TYPES 6.5.1 Stability 6.5.2 System 6.5.3 SOFTWARE Regression testing 6.5.4 Installation 6.5.5 Recovery 6.5.6 Configuration 6.5.7 Security 7. BUSINESS AREAS FOR SYSTEM TEST 8. SOFTWARE TEST PREPARATION 8.1 SOFTWARE TEST CASE DEVELOPMENT 8.2 TEST DATA SETUP 8.3 TEST ENVIRONMENT 8.3.1 Database Restoration Strategies. 9. SOFTWARE TEST EXECUTION 1 4 4 4 5 5 5 5 6 6 6 6 6 7 8 8 8 8 8 8 8 9 10 10 11 14 15 16 16 17 17 17 17 18

9.1 9.2 9.3 10. 10.1 10.2 11. 12. 13. 14. 14.1 14.2 14.3 14.4


1. Introduction 1.1 Purpose This document describes the SOFTWARE Test Strategy for the 'PRODUCT' application and tend to support the following objectives:  Identify the existing project information and the software components that should be tested  Identify types of software testing to be done  Recommend and describe the software testing strategy to be employed  Identify the required resources and provide the estimate of the test efforts  List the deliverables of the test project 1.2 Software Functional Overview With the implementation of the 'PRODUCT' system the users community will be able to manage sales contacts, turn sales contacts into sales opportunities, assign sales opportunities to sales team members, generate reports, forecast sales, etc. The 'PRODUCT' application is a client/server system with MS Access database (Soon moving to the SQL server). It consists of the following: 1. Graphical User Interface (GUI) screens, running under Windows or NT/2000 client and Master machines in the MS Outlook 2000 environment; 2. Reports are producing using MS Excel and MS Word 3. E-mails ...(??) 4. Interfaces to MS Outlook 2000 and flat files for data import 1.3 Critical Success Factor To support delivery of an application that meets its success criteria, the critical success factor for the testing are:

Assurance that the data entered.Assurance that the data entered into application system will be returned unaltered. Correctness . The following lists specific items that are included or excluded from the testing scope.Opportunity Comments . and outputted by application system is accurate and complete. Inclusions .Opportunities . The file integrity procedure ensures that the right file is used and that the data on the file and the sequence in which the data is stored and retrieved is correct.Assurance that the program prevents unauthorized access and prevents unauthorized users to destabilize work environment. processed. Execution of the test All test transactions have been executed successfully at least once.  Access control . Accuracy and completeness are achieved through control over transactions and data element. Closure of outstanding problems . which should commence when a transaction is originated and conclude when the transaction data has been used for its intended purpose.  File Integrity .Sales Setup Exclusions Outlook2000 or other MS functionality Software Testing under illegal hardware/software configurations 1.4 Software Testing Scope (TBD) The Software Testing scope will be covered in this plan.  Scalability .Opportunity Journal . It will describe activities that will cover the functions and interfaces in the 'PRODUCT' application.Assurance that the application can handle the scaling criteria within constrains of performance criteria.Opportunity Contact . 1.5 Software Test Completion Criteria Software Testing for a given release will be considered to be complete when the following conditions have been met: Criterion Description Signoff of test cases All test cases defined for the release have been reviewed by the appropriate stakeholders and signed off.

. 2.1 Testing Team Name Position Start Date End Date Days of Effort Test Tech Support Sales DBA The Test Team staffing is based upon the following assumptions:  Testing of the coming release is planned to be complete in .All problems found during the testing process have been reviewed. Resources 4. Allocated space for Test Environment.2 Hardware requirements Personal computer with Pentium 233 MHz and higher . plus an additional 8MB for MS Outlook 2000 and higher RAM for Windows NT Workstation. 4..2 clients RAM for Windows 95/98/WinMe: 32 MB of RAM for operating system. plus an additional 8 MB for MS Outlook 2000 and higher 20 MB of available disk space for 'PRODUCT' and higher The box for database . PV and backup could be enough. I do not think that we will need a separate box. closed.. 4.  The System Testing is planned after the coding will be completed  The promoted into the System test environment 'PRODUCT' version will properly Unit and Integration tested by the development team. . Timeframe The critical dates are as follows: 3.. or deferred by the management agreement. Windows 2000: 48 MB of RAM for the operating system.3 Software Requirements . Testers will supply the checklist for Unit testing to development team.

Application Software Testing Risks Profile Different aspects and features of 'PRODUCT' present various levels of risk that can be used to determine the relative levels of testing rigor required for each feature. . Access 2000 Bug Tracking system (TBD) NOTE: 'PRODUCT' for Workgroups requires CDO 1. High Direct or Indirect (due to the loss of opportunity) Loss of Revenue Typically up to $ millions (or thousands) per month (or per year) Examples: High Impact related to the loss of the client Example: 2. Impact is determined by the critical success factors for organization. Medium Typically up to $ millions (or thousands) per month (or per year) Examples: Major inconvenience to the customer Example: 3.0 Service pack 3 or later. such as Dollar Value and Area of Reputation  Business Process Impact Ranking Criteria Dollar Value Impact Reputation Impact 1.21 installed. likelihood of defects is determined mainly by complexity of the feature. This is on the Microsoft Office(r) 2000 CD. 5. Windows 2000 Microsoft Outlook(r) 2000 Microsoft Excel(r) 2000 and Word(r) 2000 for 'PRODUCT' reports.Windows 95/98/WinMe or Windows NT version 4. In this ballpark risk analysis. Low Typically up to $ millions (or thousands) per month (or per year) Examples: Minor inconvenience or no visible impact to a client Example: The "Business Process Risk Assessment" will be in the Appendix A Based on the Assessment the following Processes will receive High Priority during the testing: 1.

3 Application Functionality All areas of the application will be tested for correct results. 6.2 General Test Objectives:  To find any bugs that have not been found in unit and integration testing performed by development team  To ensure that all requirements have been met Positive test cases designed to test for correct functions will be supplemented with negative test cases designed to find problems and to test for correct error and exception handling. Test Approach 6. as documented in the Project requirements document(s).Internal interface with MS Access to verify correct storage and data retrieval . supplemented with interfaces and 6.Text files to verify data Importing capabilities . High Core functionality will be used by all User groups The "Business Process Risk Assessment" will be in the Appendix A Based on the Likelihood the following processes will have a High priority during the testing: 1. Business Process Likelihood Ranking Criteria Likelihood Ranking Low Feature set to be used to a particular company Medium Used by a particular User group. 6.Reporting capabilities with MS Word and MS Excel .Internal interface with Outlook 2000 .4 Application Interfaces The following Interfaces are included in the 'PRODUCT' Test Plan: . 6.1 Strategies Several strategies are employed in the plan in order to manage the risk and get maximum value from the time available for test preparation and execution.

processing. to verify the following: . that is. Special Considerations: There are few questions should be asked with regard of the Stability testing: Should we prepare special environment.1 Stability Stability (Smoke testing or Sanity Checks) testing has a purpose to verify promotions into the test environment in order not to destabilize the test environment. The goals of these tests are to verify proper data acceptance.2 System Testing of the application should focus on any target requirements that can be traced directly to use cases (or business functions). like PV (port verification) or run it in Development environment? What would be the procedure in the case if the new build will not be accepted? 6.5.5 Testing Types 6. use case flow.5. and business rules. Identified below is an outline of the testing recommended for each application: Test Objective: Ensure proper application navigation. or function. The Stability testing usually runs for o one or two hours. and retrieval.6. using valid and invalid data. verifying the application (and its internal processes) by interacting with the application via the GUI and analyzing the output (results). and the appropriate implementation of the business rules. Software Test Objective: Verify the stability of new builds before accepting them in the Test Environment Technique: Manually to validate the new build by running few simple tests on the separate environment. Completion Criteria: The new build will not produce major delays for the testing group when it will be ported into the Test Environment. This type of testing is based upon black box techniques. Technique: Execute each use case. data entry. processing. and retrieval.

lack of privilege to create directories. Run few tests to verify the surrounding functionality.3 Software Regression Testing Software Regression testing has tree purposes. Completion Criteria: 'PRODUCT' transactions execute successfully without failure. The second purpose is to verify that. etc. an upgrade. The first is to insure that the promoted problem is properly corrected.5. Test Objective: Verify that the reported problems were fixed properly and no additional problems were introduced during the fix. Third purpose is to verify that the new promoted into the test environment functionality did not brake any previously working software parts. The second purpose is to verify that the corrective actions did not produce any additional problems. The appropriate error / warning messages are displayed when invalid data is used. All identified defects have been addressed. the software operates correctly.4 Installation Installation testing has two purposes.5. Technique: Manually or develop automated scripts to repeat tests were the problems were originally discovered. and a complete installation or custom installation. Completion Criteria: All planned tests have been executed. such as a new installation.The expected results occur when valid data is used. Special Considerations: (TBD) [Identify / describe those items or issues (internal or external) that impact the implementation and execution of System test] 6. . This usually means running a number tests that were developed for Function testing. Special Considerations: What is the extend of verification of surround functionality? 6. Each business rule is properly applied. This usually means repeating a number tests that were the problems originally created and running few tests to verify surrounding functionality. The first is to insure that the software can be installed on all possible configurations. Abnormal conditions include insufficient disk space. once installed. and under normal and abnormal conditions.

. never installed previously with 'PRODUCT' Update machine previously installed 'PRODUCT'.5. 'PRODUCT' same version or older version already installed).'PRODUCT' never installed. software. Test Objective: Verify that recovery processes (manual or automated) properly restore the database. Failover testing ensures that. or network malfunctions with undue loss of data or data integrity. Using a predetermined sub-set of Integration or System test scripts. Special Considerations: What 'PRODUCT' transactions should be selected to comprise a confidence test that 'PRODUCT' application has been successfully installed and no major software components are missing? 6.5 Recovery Failover / Recovery testing ensures that an application or entire system can successfully recover from a variety of hardware. Launch / perform installation. Recovery processes are invoked and the application / system is monitored and / or inspected to verify proper application / system / and data recovery has been achieved. a new machine. same version Update machine previously installed 'PRODUCT'. when a failover condition occurs. run the transactions. older version Technique: Manually or develop automated scripts to validate the condition of the target machine (new . for those systems that must be kept running. Recovery testing is an antagonistic test process in which the application or system is exposed to extreme conditions (or simulated conditions) such as device I/O failures or invalid database pointers / keys. Completion Criteria: 'PRODUCT' transactions execute successfully without failure.Test Objective: Verify and validate that the 'PRODUCT' client software properly installs onto each client under the following conditions: New Installation. the alternate or backup systems properly "take over" for the failed system without loss of data or transactions.

Interruption. return to a known. pointers and keys should be corrupted manually and directly within the database (via database tools). Invalid database pointer / keys Invalid / corrupted data element in database Technique: Tests created for System testing should be used to create a series of transactions. The following types of conditions are to be included in the testing: Power interruption to the client Power interruption to the server Communication interruption via network server(s) Interruption. Testing for the following conditions requires that a known database state be achieved.applications. known. database. the following actions should be performed (or simulated) individually: Power interruption to the client: power the PC down Power interruption to the server: simulate or initiate power down procedures for the server Interruption via network servers: simulate or initiate communication loss with the network (physically disconnect communication wires or power down network server(s) / routers). and system should. Completion Criteria: In all cases above. additional transactions should executed and upon reaching this second test point state. Additional transactions should be executed using the tests from System Testing and full cycles executed. This state includes data corruption limited to the known corrupted fields. state. and reports indicating . or power loss to DASD and or DASD controller(s) Incomplete cycles (data filter processes interrupted. the application. communication. and system to a desired. data synchronization processes interrupted). pointers / keys. Testing for incomplete cycles utilizes the same technique as described above except that the database processes themselves should be aborted or prematurely terminated. upon completion of recovery procedures. desirable state. Once the desired starting test point is reached. Once the above conditions / simulated conditions are achieved. Several database fields. or power loss to DASD and or DASD controller(s): simulate or physically eliminate communication with one or more DASD controllers or devices. communication. recovery procedures should be invoked.

Execute selected transactions to simulate users activities into and out of 'PRODUCT' and Microsoft applications. such as Excel and Word. Client workstations may have different software loaded (e. etc.) and at any one time many different combinations may be active and using different resources. Completion Criteria: For each combination of 'PRODUCT' and Microsoft application. applications. This may call for the separate test server. drivers. Special Considerations: What Microsoft Applications are available. 'PRODUCT' transactions are successfully completed without failure. The entire systems. 6.the processes or transactions that were not completed due to interruptions. and Networking groups are required. etc. such as diagnostic software tools may be required. Database. large spreadsheet opened in Excel. network connections and database servers vary. Test Objective: Validate and verify that the client. Repeat the above process. Special Considerations: Recovery testing is highly intrusive. should also be documented as part of this test. 100 page document in Word). minimizing the available conventional memory on the client.6 Configuration Configuration testing verifies operation of the software on different software and hardware configurations. network servers. the particular hardware specifications for the client workstations.5. . Resources from the Systems (or Computer Operations).e. Procedures to disconnect cabling (simulating power or communication loss) may not be desirable or feasible. either as part of the test or prior to the start of the test. databases.g. accessible on the clients? What applications are typically used? What data are the applications running (i. netware. Technique: Use Software Integration and System Test scripts Open / close various Microsoft applications. In most production environments. These tests should be run after hours or on an isolated machine(s). 'PRODUCT' Application function properly on the prescribed client workstations. Alternative methods.

This testing may not be required as it maybe a function of .7 Security Security and Access Control Testing focus on two key areas of security: . including logging into / remote access to the system. Application security ensures that. Create tests for each user type and verify each permission by creating transactions specific to each user type. including financial data. users are restricted to specific functions or are limited in the data that is available to them. and . testing ensures that user "type" one can see all customer information. however. Test Objective: Function / Data Security: Verify that user can access only those functions / data for which their user type is provided permissions. user two only sees the demographic data for the same client. but only managers can delete them. Modify user type and re-run tests for same users. System Access (see special considerations below) Completion Criteria: For each known user type the appropriate function / data are available and all transactions function as expected and run in prior System tests Special Considerations: Access to the system must be reviewed / discussed with the appropriate network or systems administrator. System Security: Verify that only those users with access to the system and application(s) are permitted to access them. If there is security at the data level. including access to the Data or Business Functions. Technique: Function / Data Security: Identify and list each user type and the functions / data each type has permissions for. based upon the desired security. everyone may be permitted to enter data and create new accounts.Application security.System Security. System security ensures that only those users granted access to the system are capable of accessing the applications and only through the appropriate gateways. For example.6. In each case verify those additional functions / data are correctly available or denied.5.

8. the test cases along with check lists that will be explored to a level that will allow a tester to understand the objectives of each test will be developed. 8. The remote access control is under special consideration. Test Preparation 8.Quick Guide.doc .network or systems administration.Installation Manual. 7.User Managing Contacts and Opportunities Managing the database Reporting Views Features User Tips 8. 4. 5.Changes to the PST. Business Areas for System Test For the Test purpose the system will be divided into the following areas: 1.Defining Views. However. (To consult with DBA) Test Data setup could be not an issue. the data dependencies (what data and from where) should be identified. 2.doc .doc .doc .doc . 6.2 Test Data Setup The test data setup and test data dependencies are described in the Appendix B.doc . 9.doc . If the timeframe will not permit the development of detail test scripts to test a coming version of 'PRODUCT' with precise input and output.doc Rather than developing detail test cases to verify the appearance and mechanisms of the GUI during the Unit testing. .Linking Activities. 3.1 Test Case Development Test cases will be developed based on the following: .Uninstalling. Performance (Synchronization issue) TBD> 7. we will develop a standard checklist to be used by developers. Sales Setup Creating Databases Getting Started .Company Setup.Online help .Importing Contact.

9. controlled databases. The database will be backed up daily. These types of testing will be done by the testing team and supporting personnel Note: The Usability testing will be done during the whole testing cycle and it will concentrate on user friendliness issues.5 section of this document. Test Execution 9. in secure testing environment.  Stage 3 will include the System testing to be done by the test team and supporting personnel. Compatibility.) 9. Backups are to be kept for two weeks. because the Unit testing will be functional.1 Test Execution Planning (See testing types) will be scheduled as follows. 8. (This will be more work if the database definition has changed in the interim. so it should be possible to drop back to a clean version of the database if we will have a database corruption problem during the testing. Any printouts used to verify results will be annotated with the step number and attached. The Stability testing will be executed for all new promotions in the separate environment in order not to destabilize the Test environment.8. The GUI checklist will be supplied by the test team and reviewed by the appropriate stakeholders. The System testing will be mostly approached from the Business rules angle.  Stage 1 will include Unit and integration testing to be done by development team. It to be done by the Test team lead.3 Test environment Test will only be executed using known. . Security and other types described in the 6.2 Test Execution Documentation Testers will check off each successful step on the test sheets with the execution date.  Stage 4 will include the Installation.3. This documentation will be retained for inclusion in the package for hand over to the UAT team at the end of the Testing cycle.1 Database Restoration Strategies. In the case when the database will be moved from the MS Access to SQL server the data conversion could be run if the test database will have a lot of data.  Stage 2 will include the Stability testing. then sign and date-completed sheets.

problems found during the testing process. (Four) problem Priority and Severity Levels will be used. closing. The number of test cases will be calculated for each sub-Business process and percentage of executed test cases will be constantly tracked. reports. as appropriate.For test steps that find problems. The Test Lead will hand all problem logs over to the appropriate stakeholder.3 Problem Reporting Problem Reporting will be processed using automated Bug tracking System (Name) Summary reports of outstanding problems will be produced daily and circulated as required. printouts of database queries. the test Lead will hand over the tested system and all . Total problems discovered ratio Re-Open / Fixed problem ratio (TBD) 11. etc. The above procedure will depend on the problem Priority and Severity levels. fixing. These are described in the Appendix D. recording. and also annotate the test sheet with the problem log week .2 Problem Status The following metrics in the forms of graphs and reports will be used to provide the required information of the problem status: Weekly problem detection rates Weekly problem detection rates . tables. demonstrating the problem will be attached to a hard copy of each problem log. Screenprints. 10. etc. Test Cases template is described in the Appendix C. testers will note the test step number in the problem logs. Once the problem has been fixed and successfully retested. Handover for User Acceptance Test (UAT) Team On the System test completion. the tester will update the problem log to reflect this. 9. 10.diagram Priority 1-2 problems vs.1 Test Execution Process Each Business area will be further subdivided into the sub-Business processes up to smallest business execution unit. Specific procedure will be developed for capturing. Status Reporting 10. The appropriate actions will be designed based on the problem Status at given period of time.

01 . Approvals The Test Strategy document must meet the approvals of the appropriate stakeholders.1 Appendix A (Business Process Risk Assessment) 14.3 Appendix C (Test Case Template) Business Areas 01.2 Appendix B (Test Data Setup) ## Function Data Required Data source 1 14. and reports will be created during the testing process: Deliverables By Whom To Whom When 1.01. Test Strategy 2. Process name 01. Appendixes 14. tool.01 Test Case 01. Test Plan 3. Test Results 13. Specific handover criteria will be developed and agreed upon. Deliverables The following documents. 12. 2. 3. Title Name Signature Date 1. 14.accompanying test documentation to the (stakeholder).

1 14. promotions may be scheduled to include several changes. or managing teams doing either activity. During the testing activities all promotions to the test environment must be associated with a problem log. because they will hold up the testing. using a single database for all participating systems. will be given "write" access to the database. except for problems classed as high priority (urgent). To avoid destabilizing the test environment unnecessarily. Everyone who will be testing. Either of these can be combined with XXX's filtering capabilities to report on selection of data.Test Case Prerequisites Tester Sign off Date Version Step Action Date Results Expected Results Pass/Log# Retest . Several different kinds of reports and graphs can be produced in XXX using its standard versions.01 1. and agreed with a Testing Team. communicating with a clients. fixing bugs. All problems found during the testing will be logged in the XXX Bug tracking system. or using the included report writer to create custom reports. .4 Appendix D (Problem Tracking Process) This document describes the Bug Tracking Process for the 'PRODUCT' program.

Log Problem Problem Originator:  Tester  Technical Support  Sales  Open new log in XXX system  Try to reproduce the problem.Partial function deficiency Priority 5 .Nuisance Regular Bug Tracking Process Step Process Responsible stakeholder Action Bug Status Problem Type 1.change the Priority and Severity and specify the reason why the severity or/and Priority were changed: 2.  Verify whether any duplicates of the same problem is already in the system  Enter full description of the problem  If necessary print the log & attach any supporting printouts  Assign the Priority an Severity of the Problem  Assign the Owner as a responsible person to look after the problem resolution (TBD) Open Bug 2.The function does not work. If the problem is not reproducible. . Evaluate the problem and initiate the problem resolution Development Leader Review the Problem Review the Problem Priority and Severity.1 If this is a Bug.The following Severity Strategy will be used: Severity 1 Severity 2 Severity 3 Severity 4 Severity 5 The following Priority Strategy will be used: Priority 1 . specify in the problem log. Assign the Problem for correction to a developer. If disagree .Complete crash of a system Priority 2 . but there is a work around Priority 4 .The important function does not work and there is no workaround Priority 3 .

time or resources limitation:  Escalate for decision/agreement  Set the problem type as appropriate  Annotate the log with recommended solution  Set status to pending  The Development Leader remains as a problem owner until the problem will be re-assign for resolution. but it will not be corrected at this time due to the low Priority/Severity rating.4 If this is an Originator's error:  Annotate the problem log with explanation  Change problem type to Non-problem. Duplicate or Change Request  Get a Problem Originator's agreement  Set status to Void Void Non-Problem Duplicate Change Request 2. initiate the environment correction process by assigning to the appropriate person Assign Environment Setup 2.5 If the problem will not be corrected. corrected.Assigned Bug 2.3 If this is an environmental issue. but it was reported by the Technical support or Sales as a client complain:  Change problem type to Training  Annotate the problem log with explanation on the workaround  Get a Problem Originator's agreement  Notify sales and technical writer about new training issue (TBD with sales and technical writer of how they want to proceed from there)  Set status to Deferred  Consider the problem correction in the next release Deferred Training 3 . send to training or closed by the management decision with a Pending status assigned Pending Bug 2.2 If this is a bug.

1 If the problem is fixed:  Change the problem status to Closed  Originator remains as a problem owner after he/she closes the problem Closed .)  Fix and test setup in the reported environment  If required notify sales and technical writer about possible setup problem with setup correction solution  Update the problem log with resolution information  Set status to Fixed and redirect the ownership to the problem Originator Fixed Setup 5 Originator agreed with Non-problem or Duplicate Originator Close the problem log:  Change the problem status for Closed  Update other log fields if required  Originator remains as a problem owner after he/she closes the problem log Closed Non-problem. Duplicate or Change Request 6 Promote the fix to the test environment Development Leader  Verify the fix  Promote any modified programs to the next release. and update the problem status to Promoted Promoted Bug 7 Verify the fix Originator  Retest the fix  Update the problem log  Change status to Closed or Re-open  Annotate the test execution history with retest information 7.Fix the problem Developer  Fix and Unit test a corrected problem  Update the problem log with resolution information  Set the status to Fixed  Pass back to problem Originator to verification Fixed Bug 4 Fix Setup problem ? (could be a network admin.

2 If the problem is not fixed or other problems were created as a result of the fix:  Change status of the problem to Re-open  Annotate the test execution history with retest information  Redirect the ownership to Development Team Leader Re-open Bug NOTE: Priority 1 problems will require immediate attention. 'PRODUCT' program Test Strategy Version 1. If Priority 1 problems will be discovered.1 END.Bug 7. Software Test Strategy Document Example Extreme Software Testing Main Page © 2000 Alex Samurin geocities. because they will hold up the testing. the problem resolution will follow process structured as follows:  Problem will be logged into the XXX system  The notification with request for immediate problem resolution will be sent to Development Team Leader  The problem fix will be done in the Test environment and promoted if necessary into the development after the fix the retest in the test environment will be .

Sign up to vote on this title
UsefulNot useful