Test Planning:

Test planning is the first activity of test team.

If a tester does not plan for testing then it leads to failure.
Test plans are defined in framework created by test strategy and established by test policy
like any project, the testing also should be driven by a plan.
The test plan acts as the anchor for the execution, tracking and reporting of the entire testing
project.
The test plan acts as the anchor for the execution, tracking and reporting of the entire testing
project and covers.
The following are the test plan activities:
1. To determine the scope and the risks that need to be tested and that are not to be
tested.
2. Determine the strategy.
3. Making sure that the testing activities have been included.
4. Deciding Entry exit criteria.
5. Evaluating the test estimate.
6. Planning when and how to test and deciding how the test results will be evaluated
and defining
7. The test artifacts delivered as part of test execution.
8. Defining the management information, including the metrics required and defect
resolution and risks issues.
9. Ensuring that the test documentation generates repeatable test assets.
Advantages of test planning are :

1. Scope of testing
2. Set objectives of test planning
3. Methodology for testing
4. Requirement,
5. Entry and exit criteria
6. Develop Test matrix
7. Test estimation and administrative component
8. Write and execute test cases.
9. Deciding Criteria for test-to-pass, test-to-fail,
10. Schedule of testing
11. The main purpose of test planning is to show whether software is correct as per
requirement.

Preparing a test plan:

Steps to prepare test plan:
Like any project, the testing also should be driven by a plan. The test plan acts as the anchor
for the execution, tracking and reporting of the entire testing project. Activities of test plan:

1. Scope Management: Deciding what features to be tested and not to be tested.

2. Deciding Test approach /strategy: Which type of testing shall be done like
configuration, integration, localization etc.
 3. Setting up criteria for testing: There must be clear entry and exit criteria for different
phases of testing. The test strategies for the various features and combinations
determined how these features and combinations would be tested.
4. Identifying responsibilities, staffing and training needs.
5. Identifying resource requirements
6. Identifying test deliverables.
7. Testing tasks: size and effort estimation.

Deciding test approach

Factors considered to decide test strategy or test approach :
Analytic testing strategy: This uses formal and informal techniques to access and prioritize
risks that arise during software testing. It takes a complete overview of requirements, design,
and implementation of objects to determine the motive of testing. In addition, it gathers
complete information about the software, targets to be achieved, and the data required for
testing the software.
Model-based testing strategy: This strategy tests the functionality of the software according
to the real world scenario (like software functioning in an organization). It recognizes the
domain of data and selects suitable test cases according to the probability of errors in that
domain.
Methodical testing strategy: It tests the functions and status of software according to the
checklist, which is based on user requirements. This strategy is also used to test the
functionality, reliability, usability, and performance of the software.
Process-oriented testing strategy: It tests the software according to already existing
standards such as the IEEE standards. In addition, it checks the functionality of the software
by using automated testing tools.
Dynamic testing strategy: This tests the software after having a collective decision of the
testing team. Along with testing, this strategy provides information about the software such
as test cases used for testing the errors present in it.
Regression-averse Approach: It tests the software assuming that any component of the
software can stop functioning anytime. It takes help from software developers, users and
systems analysts to test the software.

Setting up criteria for testing

There must be clear entry and exit criteria, pass or fail criteria , suspend criteria, Resume criteria
for different phases of testing. The test strategies for the various features and combinations
determined how these features and combinations would be tested.

1. Pass or fail: - Specify the criteria that will be used to determine whether each test item
has passed or failed testing.

2. Suspend Criteria: - Specify the criteria to be used to suspend test activity.

3. Resume Criteria: - Specify the criteria which must be redone when testing is resumed .
 Resource Requirements
Resource requirement is a detailed summary of all types of resources required to complete
project task. Resource could be human, equipment and materials needed to complete a
project.
The resource requirement and planning is important factor of the test planning because helps
in determining the number of resources (employee, equipment…) to be used for the project.
Therefore, the Test Manager can make the correct schedule & estimation for the project.
Some of the following factors need to be considered:
 Machine configuration (RAM,processor,disk)needed to run the product under test.
 Overheads required by test automation tools, if any
 Supporting tools such as compilers, test data generators, configuration management
tools.
 The different configurations of the supporting software(e.g. OS)that must be present
 Special requirements for running machine-intensive tests such as load tests and
performance tests.
 Appropriate number of licenses of all the software

No. Member Tasks

1 Test Manager Manage the whole project Define project directions Acquire appropriate
resources

2 Tester Identifying and describing appropriate test techniques/tools/automation

architecture Verify and assess the Test Approach Execute the tests, Log
results, Report the defects. Tester could be in-sourced or out-sourced
members, base on the project budget For the task which required low skill,
I recommend you choose outsourced members to save project cost

3. Developer in Implement the test cases, test program, test suite etc.
Test

4. Test Builds up and ensures test environment and assets are managed and
Administrator maintained Support Tester to use the test environment for test execution
 No. Member Tasks

5. SQA members Take in charge of quality assurance Check to confirm whether the testing
process is meeting specified requirements

OR
Human Resource: The following table represents various members in your project team
System Resource: For testing, a web application, you should plan the resources as following
tables:

No Resources Descriptions
.

1 Server Install the web application under test This includes a separate web server, database
server, and application server if applicable

2 Test tool The testing tool is to automate the testing, simulate the user operation, generate the
test results There are tons of test tools you can use for this project such as Selenium,
QTP…etc.

3. Network You need a Network include LAN and Internet to simulate the real business and user
environment

4. Computer The PC which users often use to connect the web server

Test Deliverables and Milestones

Test Deliverables are the artifacts which are given to the stakeholders of software project
during the software development lifecycle. There are different test deliverables at every phase
of the software development lifecycle. Some test deliverables are provided before testing
phase, some are provided during the testing phase and some after the testing cycles is over.
The different types of Test deliverables are:

 Test cases Documents

 Test Plan

 Testing Strategy

 Test Scripts

 Test Data

 Test Traceability Matrix

 Test Results/reports

 Test summary report

 Install/config guides

 Defect Reports

 Release notes

Milestones: milestones are the dates of completion given for various tasks to be performed in
testing. These are thoroughly tracked by the test manager and are kept in the documents such
as Gantt charts, etc.

Test Management:
It concerned with both test resource and test environment management. It is the role of test
management to ensure that new or modified service products meet business requirements for
which they have been developed or enhanced.
Test Management Process:

Test Plan: Test plan served as an initial sketch to carry out the testing. Testing is being
tracked and monitored as per the test plan. It gives a prior picture of test challenge and
aspect that will be carried out for the software.

Test design affords how to implement the testing. Typically creating test cases is with
inputs and expected output of the system and choosing which test cases are necessary for
the execution of the test.

Test Execution : Manner of executing and test the actual system result against the
expected result is test execution. Test execution can be done manually and by using
automation suit. During the execution tester needs to make sure, that the user’s need of
the software is occupied in the software.
 Exit criteria determines when to stop the test execution. Exit criteria is defined during the
test plan phase and used in the test execution phase as a mile stone. Tester needs to set the
exit criteria at the beginning, exit criteria may change during the project run as well.

Test reporting gives the picture of test process and result for the particular testing cycle.
To define the element in the test reporting the first thing that needs to be considered is
whom the audiences of the test report are. For an example a project manager will like to
see the high level picture of the testing, intermediate people will wish to view more detail
and the client will expect the test reporting in the criteria such as requirement basis,
feature basis.

1. Naming and storage conventions for test artifacts: Every test artifacts(test specification,
test case, test results and so on)have to be named appropriately and meaningfully. It enables
a) Easy identification of the product functionality.
b) Reverse mapping to identify the functionality corresponding to a given set of tests. e.g.
modules shall be M01,M02.Files types can be .sh, .SQL.
In addition to file naming conventions, the standards may also stipulate the conventions for
directory structures for tests. These directory structures are mapped into configuration
management repository.
2. Documentation standards: Documentation standards specify how to capture information
about the tests within the test scripts themselves. It should include:
a. Appropriate header level comments at the beginning of a file that outlines the functions to
be served by the test.
b. Sufficient inline comments, spread throughout the file
c. Up-to-Date change history information, reading all the changes made to the test file.
 TCDB
Testing requires a robust infrastructure to be planned upfront. This infrastructure is made up
of three essential elements.

1. A test case database (TCDB) (additional): A test case database captures all the
relevant information about the test cases in an organization. Some of the entities and
the attributes are given in following table

Sr. Test Case Purpose Attributes

No.

1 Test case Records all static information about tests. 1)Test case Id 2) Test case
name (File name) 3) Test case
owner 4) Associated files for
test case.

2 Test case product Provide mapping between the tests and Test case Id Module Id
cross reference the corresponding product features,
enables identification of test cases for
given feature.

3 Test case run Gives the history of when the test case 1) Test case Id 2) Run date 3)
history was run and what was result , provided Time taken 4) Run
inputs on selection of test for regression status(Success/ Failure)
runs

4 Test casedefect Gives details of test cases introduced to 1) Test case Id 2) Defect
crossreference test certain specific defects detected in the reference
product, provides inputs on the selection
of test for regression runs.
 Defect Repository:

Entity Purpose Attributes

Defect details Records all the ― static‖ information Defect ID Defect priority /severity
about the tests Defect description Affected product(s)
Any relevant version information (for
example, OS version) Customers who
encountered the problem (could be
reported by the internal testing team
also) Date and time of defect
occurrence

Defect test Provides details of test cases for a given Defect ID Test case ID
details defect. Crossreferences the TCDB

Fix details Provides details of fixes for a given Defect ID Fix details (file changed ,fix
defect; crossreferences the configuration release information)
management repository

Communication Captures all the details of the Test case ID Defect reference # Details
communication that transpired for this of communication
defect among the various stakeholders
these could include communication
between the testing team and development
team, customer communication, and so on.
Provides insights into effectiveness of
communication

Test case specification:

1. The purpose of the test.
2. Items being tested, along with their version/release numbers as appropriate.
3. Environment that need to be set up for running the test case.
4. Input data to be used for the test case.
5. Steps to be followed to execute the test.
6. The expected result that are considered to be “correct result”
 7. A steps to compare the actual results produced with the expected results.
8. Any relationship between this test and other tests.

Test Reports types

Test reporting is a means of achieving communication through the testing cycle. There are3 types of
test reporting.
1. Test incident report: A test incident report is communication that happens through the testing
cycle as and when defects are encountered .A test incident report is an entry made in the
defect repository each defect has a unique id to identify incident .The high impact test
incident are highlighted in the test summary report.
2. Test cycle report: A test cycle entails planning and running certain test in cycle , each cycle
using a different build of the product .As the product progresses through the various cycles it
is expected to stabilize.Test cycle report gives
 A summary of the activities carried out during that cycle.
 Defects that are uncovered during that cycle based on severity and impact
 Progress from the previous cycle to the current cycle in terms of defect fixed
 Outstanding defects that not yet to be fixed in cycle
 Any variation observed in effort or schedule
3 Test summary report: The final step in a test cycle is to recommend the suitability of a product for
release. A report that summarizes the result of a test cycle is the test summary report. There are two
types of test summary report:
 Phase wise test summary, which is produced at the end of every phase.
 Final test summary report.
A Summary report should present

1. Test Summary report Identifier 2 Description: Identify the test items being reported in this
report with test id 3 Variances: Mention any deviation from test plans, test procedures, if any.
4 Summary of results: All the results are mentioned here with the resolved incidents and their
solutions. 5 Comprehensive assessment and recommendation for release should include: Fit
for release assessment and recommendation of release.

OR
 A test report is any descriptions, explanation or justification the status of a test project.
 A comprehensive test report is all of those things together.

Preparing Test Case Report

Step 1: Purpose of the document

It gives the short description about the objective behind preparation of the document.
Example: Document explaining various activities performed as part of Testing.
Step 2: Overview of an Application
In this step brief description about the application to be tested is mentioned.

Step 3: Create a Testing Scope

The team mentions those modules or areas that are in scope, out of scope, and untested
owing to dependencies or constraints.
 In-scope: We completed the functional testing of the following modules:

 User registration
 Registration confirmation
 Ticket booking
 Hotel package booking
 Payment
 Out of scope:
 Multi-tenant user testing
 Concurrency
 Untested modules:
 The User Registration page that has the field values in mixed cases
Step 4: Test Metrics
Test metrics include the following:
 The count of planned test cases
 The count of executed test cases
 The count of passed test cases
 The count of failed test cases
The usage of test metrics is to analyze test execution results, the status of the cases, and
the status of the defects, among others. The testing team can also generate charts or
graphs to represent the distribution of defects: function-wise, severity-wise, or module-
wise.
Step 5: Implemented Testing Type
The team includes all the types of testing it has implemented on the ABC application.
The motive for doing so is to convey to the readers that the team has tested the
application properly.
 Smoke testing
When the QA team receives the build, the team implements smoke testing to
confirm whether the crucial functionalities are working as expected. The team
accepts the build and commences testing. After the software application passes
the smoke testing, the testing team gets the confirmation to continue with the next
type of testing.
 Regression testing
The team conducts testing not on a particular feature or defect fix but on the
entire software application. It consists of defect fixes and new enhancements.
This testing confirms that after these defect fixes and new enhancements exist in
the software application, the application has rich functionality. The team adds
and executes new test cases to the new features.
 System Integration testing
The team performs system integration testing to ensure that the software
application is functioning as per the requirements.
Step 6: Test Environment and Tools
The team notes all the details of the test environment used for the testing activities (such
as Application URL, Database version, and the tools used).
The team can create tables in the following format.

Step 7: Learnings during the Testing Process

The team includes information such as the critical issues they faced while testing the
application and the solutions devised to overcome these issues. The intention of
documenting this information is for the team to leverage it in future testing activities.
The team can represent this information in the following format.

Step 8: Suggestions or Recommendations

The team notes suggestions or recommendations while keeping the pertinent
stakeholders in mind. These suggestions and recommendations serve as guidance during
the next testing cycle.
Step 9: Exit Criteria
When the team defines the exit criteria, it indicates test completion on the fulfillment of
specific conditions, such as the following:
 The team has successfully executed all its planned test cases.

 The team has closed all the critical issues.

 The team has planned the actions for all open issues, which it will address in the next
release cycle.
Step 10: Sign-off
If the team has fulfilled the exit criteria, the team can provide the go-ahead for the
application to ‘go live.’ If the team has not fulfilled the exit criteria, the team should
highlight the specific areas of concern. Further, the team should leave the decision about
the application going live with the senior management and other top-level stakeholders.