Testing strategy (methodology)
A test strategy describes the approach, objectives, and direction of the effort test. The purpose of a testing strategy or method is to minimize risk and ultimately provide the best software for the client. The testing strategy of choice for a particular application can vary depending on the software, amount of use, and its objectives. For example, the testing strategy for a transactional system like Oracle will be very different from the strategy developed to test an analytical tool as the Data Warehouse. In addition, the strategy chosen for testing a campus-wide purchasing system to a limited number of users of the tool housing requires a very different test strategies. Because some of these examples have higher exposure, they also have a higher risk.
Below one is the common and best example of Testing Strategy
STAGES OF THE TEST OF LIFE CYCLE
A Software has used several variations of one or more test methods. Lets say, if software is “IMSS” Typical stages include preparation, conference room pilot (CRP), unity, integration, system testing and user acceptance.
These steps are also called stages or levels. The project manager should review the steps below and consider the same terminology and sequence. If it makes sense, certain phases and tasks May be deleted. In other cases, tasks and phases of May should be added. May perform some tasks in parallel, and some steps can be combined. In most cases, each phase must be completed before another can begin.
Duration of the tasks vary depending on the timing and risk of the project manager is ready to absorb.
Test Preparation Phase (before testing begins)
Team - Develop test strategy
Task - Develop high-level test plan
Team - Identify the test cases
Task - Develop scenarios, test scripts
Team - Identify and share test data
Team - Identify the processes, procedures, standards, documentation requirements
Team - Identify and create test environment
Task - Identify test team (s)
Team - Train testers
Unit test phase - The purpose of this testing is to verify and validate the function modules
correctly. This is completed by developers and must be completed before future phases can begin. The
Testing Manager are not normally involved in this phase.
Phase CRP (Conference Room Pilot - optional). The purpose of this phase is to verify proof of concept.
The CRP is generally necessary for new, large, not projects.
Assumption - Test instance is ready
Assumption - Metadata is inserted test example
Assumption - The unit tests and simulations has been completed
Assumption - test scenarios have been identified (by script or ad hoc)
Task - Identify CRP participants
Team - Determine and establish logistics CRP
Task - Define expectations.
Team - Start of CRP
Task - Collect and document feedback
Task - End CRP
Team - Obtain approval phase / sign-off
Team - Collect / share / integrate lessons learned, incorporate the necessary changes
Task - Tune / revise and approve the new test plan
Integration of the testing phase - The purpose of this testing is to verify and validate all the modules are
interface and work together.
Assumption - Requirements are frozen and the design is determined
Assumption - Application is ready for integration tests
Assumption - Metadata was populated by such test tables
Assumption - Unit testing is complete
Task - Test system and document using the test scripts
Team - Test interfaces
Task - Identify and report bugs
Task - Retest fixed bugs / regression test
Team - Test Security
Team - Test browsers / platforms / operating systems
Team - Obtain approval phase / sign-off
Team - Collect / share / integrate lessons learned
Task - Tune / revise and approve the new test plan
The test phase of the system - The purpose of this testing is to verify and validate the system works as if it were production.
Assumption - Metadata was populated pending test
Assumption - Application is ready and has successfully completed the integration tests
Task - Test system and document using the test scripts
Task - Identify and report bugs
Task - Retest fixed bugs / regression test
Team - test business processes and reports
Team - Stress test
Task - test performance (eg, refreshes the screen)
Team - test connection security, responsibilities, piracy
Team - Obtain approval phase / sign-off
Team - Collect / share / integrate lessons learned
Task - Tune / revise and approve the new test plan
Acceptance phase users - The objective of this testing is to verify and validate the system and
for end users as if it were the production
Assumption - Show-stoppers and the highest level of bugs were fixed and work around have been identified and approved
Assumption - All other phases have been signed off
Assumption - Application is ready for acceptance testing by the user
Assumption - Metadata was populated by such test tables
Team - Train users testers
Task - Populate and approve test scripts
Task - Test system and document using the test scripts
Team - Obtain approval phase / sign-off
Team - Collect / share / integrate lessons learned
Go to –>
SPONSORED LINKS
