Unit 02 Types of testing

White Box Testing

• White box testing techniques analyze the internal structures the used data structures, internal
design, code structure and the working of the software .
• White Box Testing is software testing technique in which internal structure, design and coding of
software are tested to verify flow of input-output and to improve design, usability and security.
• White box testing is software testing method in which internal structure/design is known to tester
.The main aim of white box testing is check on how system is performing based on the code.it is
mainly performed by the developer or white box testers who has knowledge on the programming.
• In white box testing, code is visible to testers so it is also called Clear box testing, Open box testing,
Transparent box testing,
Code-based testing and Glass box testing, or structural testing.

Whitebox testing technique

1)Statement Coverage:- This technique requires every possible statement in the code to be tested at
least once during the testing process.
in statement coverage, every node must be traversed at least once..
2)Branch Coverage - This technique checks every possible path (if-else and other conditional loops)
of a software application.
Every edges must be traversed at least once.
As per flowchart all edges must be traversed at least once
3) Path Coverage
This technique is used to ensure that every possible path (each statement and branch) is executed
and tested.

Types of White Box Testing

White box testing can take several forms:
• Unit testing — tests written as part of the application code, which test that each component
is working as expected.
• Mutation testing — a type of unit testing that checks the robustness and consistency of the
code by defining tests, making small, random changes to the code and seeing if the tests still
pass.
Mutation testing is generally conducted to re-check any kind software bugs in the system.
Mutation testing is often used to discover the best coding techniques to use for expanding a
software solution.
 Integration testing — tests specifically designed to check integration points between
internal components in a software system, or integrations with external systems.
 Penetration Testing: In this testing, the tester/developer has full information of the
application's source code, detailed network information, IP addresses involved and all server
information the application runs on. The aim is to attack the code from several angles to
expose security threats.

Classifications of white box testing

1. Static Testing : Static Testing is a type of a software testing method which is performed to check
the defects in software without actually executing the code of the software application. Whereas in
Dynamic Testing checks the code is executed to detect the defects
Static testing is done to avoid errors at an early stage of development as it is easier to identify the
errors and solve the errors. It also helps finding errors that may not be found by Dynamic Testing
Static Testing, a software testing technique in which the software is tested without executing the
code. It has two parts as listed below:
● Review - Typically used to find and eliminate errors or ambiguities in documents such as
requirements, design, test cases, etc.
● Static analysis - The code written by developers are analysed (usually by tools) for structural
defects that may lead to defects.
• Static testing involves manual or automated reviews of the documents. This review is done
during an initial phase of testing to catch Defect early in STLC. It examines work documents
and provides review comments. It is also called Non-execution testing or verification testing.

The two main types of static testing techniques are

• Manual examinations: Manual examinations include analysis of code done manually, also
known as REVIEWS.
• Automated analysis using tools: Automated analysis are basically static analysis which is
done using tools.
What is Tested in Static Testing
In Static Testing, following things are tested
● Unit Test Cases
● Business Requirements Document (BRD)
● Use Cases
● System/Functional Requirements
● Prototype
● Prototype Specification Document
● DB Fields Dictionary Spreadsheet
● Test Data
● Traceability Matrix Document
● User Manual/Training Guides/Documentation
● Test Plan Strategy Document/Test Cases
● Automation/Performance Test Scripts

The types of reviews can be given by a simple diagram:

1.Informal Reviews: This is one of the type of review which doesn't follow any process to find errors
in the document. Under this technique, you just review the document and give informal comments
on it.

2. Walkthrough -- the author of whichever document is being reviewed will explain the document to
their team. Participants will ask questions, and any notes are written down.
The walkthrough can be formal or informal review.
Team member does not need to have detailed knowledge of the content as the author is well
prepared for that and it is kind of knowledge transfer session .
Main objective is to enable learning and giving knowledge to other team members about the
content.

2)Inspection -- a designated moderator will conduct a strict review as a process to find defects.
• inspection is one of the most formal kinds of Reviews.
• It is led by a trained Moderator who is not the author of the meeting.
 • Reviewers are well prepared before the meeting about the documents or what needs to be
discussed.
• Rules and checklists are used in this meeting during which time the product is examined and
defects are logged.
• Defects found in the meeting are documented in the issue log or logging list.
• Meeting has proper entry and exit criteria.
• Reports created during the meeting are shared with the Author to take appropriate actions
on that.

3)Technical reviews -- technical specifications are reviewed by peers in order to detect any errors.
• it is well documented and follows defect detection technique which involves peers
and technical experts
• It is usually led by a trained Moderator and not the Author.
• In Technical Review, the product is examined and the defects are found which are mainly
technical ones.
• No management participation is there in Technical Review.
• The full report is prepared to have a list of issues addressed.
A team consisting of your peers, review the technical specification of the software product
and checks whether it is suitable for the project. They try to find any discrepancies in the
specifications and standards followed. This review concentrates mainly on the technical
documentation related to the software such as Test Strategy, Test Plan and requirement
specification documents.

Summary:
● Static testing is to find defects as early as possible.
● Static testing not a substitute for dynamic testing, both find a different type of defects
● Reviews are an effective technique for Static Testing
● Reviews not only help to find defects but also understand missing requirements, design
defects, non-maintainable code.

What is Dynamic Testing?

Under Dynamic Testing, a code is executed. It checks for functional behavior of software system,
memory/cpu usage and overall performance of the system. Hence the name "Dynamic"
• The main objective of this testing is to confirm that the software product works in
conformance with the business requirements. This testing is also called an Execution
technique or validation testing.
• Dynamic testing executes the software and validates the output with the expected outcome.
Dynamic testing is performed at all levels of testing and it can be either black or white box
testing.

Structural Testing:
 Structure-based testing, therefore, can be defined as a type of software testing that tests
the code’s structure and intended flows. For example, verifying the actual code for aspects
like the correct implementation of conditional statements, and whether every statement in
the code is correctly executed. It is also known as structure-based testing.
 ● To carry out this type of testing, we need to thoroughly understand the code. This is why this
testing is usually done by the developers who wrote the code as they understand it best.

● Structural testing is the type of testing carried out to test the structure of code. It is also
known as White Box testing or Glass Box testing. This type of testing requires knowledge of
the code, so, it is mostly done by the developers. It is more concerned with how system does
it rather than the functionality of the system. It provides more coverage to the testing. For
ex, to test certain error message in an application, we need to test the trigger condition for
it, but there must be many trigger for it. It is possible to miss out one while testing the
requirements drafted in SRS. But using this testing, the trigger is most likely to be covered
since structural testing aims to cover all the nodes and paths in the structure of code.

● Structural testing is a type of software testing which uses the internal design of the software
for testing or in other words the software testing which is performed by the team which
knows the development phase of the software, is known as structural testing.
● Structural testing is basically related to the internal design and implementation of the
software i.e. it involves the development team members in the testing team. It basically
tests different aspects of the software according to its types. Structural testing is just the
opposite of behavioral testing.
● The knowledge of the code's internal executions and how the software is implemented is a
necessity for the test engineer to implement the structural testing.
● Throughout the structural testing, the test engineer intends on how the software performs,
and it can be used at all levels of testing.

The intention behind the testing process is finding out how the system works not the functionality
of it. To be more specific, if an error message is popping up in an application there will be a reason
behind it. Structural testing can be used to find that issue and fix it
Advantages of Structural Testing:
· Forces test developer to reason carefully about implementation
Reveals errors in "hidden" code
· Spots the Dead Code or other issues with respect to best programming practices.
Disadvantages of Structural Box Testing:
· Expensive as one has to spend both time and money to perform white box testing.
Every possibility that few lines of code is missed accidentally.
· In-depth knowledge about the programming language is necessary to perform white box testing.

Functional Testing
• FUNCTIONAL TESTING is a type of software testing that validates the software system
against the functional requirements/specifications. The purpose of Functional tests is to test
each function of the software application, by providing appropriate input, verifying the
output against the Functional requirements.
• Functional testing mainly involves black box testing and it is not concerned about the source
code of the application. This testing checks User Interface, APIs, Database, Security,
Client/Server communication and other functionality of the Application Under Test. The
testing can be done either manually or using automation.
• Functional Testing is a type of Software Testing in which the system is tested against the
functional requirements and specifications. Functional testing ensures that the requirements
or specifications are properly satisfied by the application. This type of testing is particularly
concerned with the result of processing. It focuses on simulation of actual system usage but
does not develop any system structure assumptions.

Functional Testing:
It is a type of software testing which is used to verify the functionality of the software application,
whether the function is working according to the requirement specification. In functional testing, each
function tested by giving the value, determining the output, and verifying the actual output with the
expected value. Functional testing performed as black-box testing which is presented to confirm that
the functionality of an application or system behaves as we are expecting. It is done to verify the
functionality of the application.
Functional testing also called as black-box testing, because it focuses on application specification
rather than actual code. Tester has to test only the program rather than the system.

How to do Functional Testing

Following is a step by step process on How to do Functional Testing :
✔ Understand the Functional Requirements
✔ Identify test input or test data based on requirements
✔ Compute the expected outcomes with selected test input values
✔ Execute test cases
✔ Compare actual and computed expected results

Code Coverage :
Code coverage is a software testing metric that determines the number of lines of code that is
successfully validated under a test procedure, which in turn, helps in analyzing how comprehensively
a software is verified.
Code coverage is a software testing metric or also termed as a Code Coverage Testing which helps in
determining how much code of the source is tested which helps in accessing quality of test suite and
analyzing how comprehensively a software is verified. Actually in simple code coverage refers to the
degree of which the source code of the software code has been tested. This Code Coverage is
considered as one of the form of white box testing
As we know at last of the development each client wants a quality software product as well as the
developer team is also responsible for delivering a quality software product to the customer/client.
Where this quality refers to the product’s performance, functionalities, behavior, correctness,
reliability, effectiveness, security, and maintainability. Where Code Coverage metric helps in
determining the performance and quality aspects of any software.
Code coverage is one such software testing metric that can help in assessing the test performance and
quality aspects of any software.
Such an insight will equally be beneficial to the development and QA team. For developers, this metric
can help in dead code detection and elimination. On the other hand, for QA, it can help to check
missed or uncovered test cases. They can track the health status and quality of the source code while
paying more heed to the uncaptured parts of the code.

• Code Coverage testing is determining how much code is being tested. It can be calculated
using the formula:
• Code Coverage = (Number of lines of code executed)/(Total Number of lines of code in a
system component) * 100
Code Coverage Criteria
1.Statement coverage: how many of the statements in the program have been executed.
2.Branches coverage: how many of the branches of the control structures (if statements for
instance) have been executed.
Condition coverage: how many of the boolean sub-expressions have been tested for a true and
a false value.
3.Line coverage: how many of lines of source code have been tested.
These metrics are usually represented as the number of items actually tested, the items found in
your code, and a coverage percentage (items tested / items found)
4.Function coverage: how many of the functions defined have been called.

Code Complexity Testing

• Cyclomatic Complexity in Software Testing is a testing metric used for measuring the
complexity of a software program. It is a quantitative measure of independent paths in the
 source code of a software program. Cyclomatic complexity can be calculated by using
control flow graphs or with respect to functions, modules, methods or classes within a
software program.
• independent path is defined as a path that has at least one edge which has not been
traversed before in any other paths.
• Cyclomatic Complexity is software metric useful for structured or White Box Testing. It is
mainly used to evaluate complexity of a program. If the decision points are more, then
complexity of the program is more. If program has high complexity number, then probability
of error is high with increased time for maintenance and trouble shoot
• For example, if source code contains no control flow statement then its cyclomatic
complexity will be 1 and source code contains a single path in it. Similarly, if the source code
contains one if condition then cyclomatic complexity will be 2 because there will be two
paths one for true and the other for false.
• This metric was developed by Thomas J. McCabe in 1976 and it is based on a control flow
representation of the program. Control flow depicts a program as a graph which consists of
Nodes and Edges
• In the graph, Nodes represent processing tasks while edges represent control flow between
the nodes.

Uses of Cyclomatic Complexity:

• Cyclomatic Complexity can prove to be very helpful for developers and testers.
• Helps developers and testers to determine independent path executions
• Developers can assure that all the paths have been tested atleast once
• Helps us to focus more on the uncovered paths
• Improve code coverage in Software Engineering
• Evaluate the risk associated with the application or program
• Using these metrics early in the cycle reduces more risk of the program

Black box testing

Black Box Testing is a software testing method in which the functionalities of software applications
are tested without having knowledge of internal code structure, implementation details and internal
paths. Black Box Testing mainly focuses on input and output of software applications and it is
entirely based on software requirements and specifications. It is also known as Behavioral Testing.
Black box testing is a type of software testing in which the functionality of the software is not
known. The testing is done without the internal knowledge of the products.
• It is also known as specification based testing
• The black box testing is also known as an opaque, closed box, function-centric testing. It
emphasizes on the behavior of the software. Black box testing checks scenarios where the
system can break

Types of Black Box Testing

There are many types of Black Box Testing but the following are the prominent ones -
• Functional testing - This black box testing type is related to the functional requirements of a
system; it is done by software testers.
 • Non-functional testing - This type of black box testing is not related to testing of specific
functionality, but non-functional requirements such as performance, scalability, usability.
• Regression testing – Regres is done after code fixes, upgrades or any other system
maintenance to check the new code has not affected the existing code.

Black Box Testing Techniques

In order to systematically test a set of functions, it is necessary to design test cases. Testers can
create test cases from the requirement specification document using the following Black Box Testing
techniques.
• Equivalence Partitioning
• Boundary Value Analysis
• Decision Table Testing
• State Transition Testing
• Error Guessing
• Graph-Based Testing Methods
• Comparison Testing
1.Boundary Value Analysis(BVA)
• Boundary Value Technique is used to test boundary values, boundary values are those that
contain the upper and lower limit of a variable. It tests, while entering boundary value
whether the software is producing correct output or not.
• Boundary value testing is focused on the values at boundaries. This technique determines
whether a certain range of values are acceptable by the system or not. It is very useful in
reducing the number of test cases. It is most suitable for the systems where an input is
within certain ranges.
• Boundary value analysis is one of the widely used case design technique for black box
testing. It is used to test boundary values because the input values near the boundary have
higher chances of error.
• Whenever we do the testing by boundary value analysis, the tester focuses on, while
entering boundary value whether the software is producing correct output or not.
• Boundary values are those that contain the upper and lower limit of a variable. Assume that,
age is a variable of any function, and its minimum value is 18 and the maximum value is 30,
both 18 and 30 will be considered as boundary values.
• The basic assumption of boundary value analysis is, the test cases that are created using
boundary values are most likely to cause an error.
• There is 18 and 30 are the boundary values that's why tester pays more attention to these
values, but this doesn't mean that the middle values like 19, 20, 21, 27, 29 are ignored. Test
cases are developed for each and every value of the range.
Assume, we have to test a field which accepts Age 18 – 56

• Minimum boundary value is 18

• Maximum boundary value is 56
• Valid Inputs: 18,19,55,56
• Invalid Inputs: 17 and 57
• Test case 1: Enter the value 17 (18-1) = Invalid
• Test case 2: Enter the value 18 = Valid
• Test case 3: Enter the value 19 (18+1) = Valid
• Test case 4: Enter the value 55 (56-1) = Valid
• Test case 5: Enter the value 56 = Valid
• Test case 6: Enter the value 57 (56+1) =Invalid
2. Equivalence partitioning
• Equivalence partitioning is a technique of software testing in which input data divided into
partitions of valid and invalid values, and it is mandatory that all partitions must exhibit the
same behavior.
• This technique is also known as Equivalence Class Partitioning (ECP). In this technique, input
values to the system or application are divided into different classes or groups based on its
similarity in the outcome.
• Hence, instead of using each and every input value we can now use any one value from the
group/class to test the outcome. In this way, we can maintain the test coverage while we
can reduce a lot of rework and most importantly the time spent.
• As present in the above image, an “AGE” text field accepts only the numbers from 18 to 60.
There will be three sets of classes or groups.
Example:
Two invalid classes will be:
• a) Less than or equal to 17.
• b) Greater than or equal to 61.
• One valid class will be anything between 18 to 60.
• We have thus reduced the test cases to only 3 test cases based on the formed classes
thereby covering all the possibilities. So, testing with anyone value from each set of the class
is sufficient to test the above scenario.

3. Decision Table
• Decision Table Technique is a systematic approach where various input combinations and
their respective system behavior are captured in a tabular form. It is appropriate for the
functions that have a logical relationship between two and more than two inputs.
• Decision Table is aka Cause-Effect Table. This test technique is appropriate for functionalities
which has logical relationships between inputs (if-else logic). In Decision table technique, we
deal with combinations of inputs. To identify the test cases with decision table, we consider
conditions and actions. We take conditions as inputs and actions as outputs.
• In some instances, the inputs combinations can become very complicated for tracking several
possibilities.
• Such complex situations rely on decision tables, as it offers the testers an organized view
about the inputs combination and the expected output.

Let's understand it by an example:

• Most of us use an email account, and when you want to use an email account, for this you
need to enter the email and its associated password.
• If both email and password are correctly matched, the user will be directed to the email
account's homepage; otherwise, it will come back to the login page with an error message
specified with "Incorrect Email" or "Incorrect Password."
• Now, let's see how a decision table is created for the login function in which we can log in by
using email and password. Both the email and the password are the conditions, and the
expected result is action.
In the table, there are four conditions or test cases to test the login function. In the first condition if
both email and password are correct, then the user should be directed to account's Homepage.
In the second condition if the email is correct, but the password is incorrect then the function should
display Incorrect Password. In the third condition if the email is incorrect, but the password is correct,
then it should display Incorrect Email.
Now, in fourth and last condition both email and password are incorrect then the function should
display Incorrect Email.
In this example, all possible conditions or test cases have been included, and in the same way, the
testing team also includes all possible test cases so that upcoming bugs can be cured at testing level.

4. State Transition Technique

● The general meaning of state transition is, different forms of the same situation, and
according to the meaning, the state transition method does the same. It is used to capture
the behavior of the software application when different input values are given to the same
function.
● State Transition Testing is a technique that is used to test the different states of the system
under test. The state of the system changes depending upon the conditions or events. The
events trigger states which become scenarios and a tester needs to test them.
● .In some systems, significant responses are generated when the system transitions from one
state to another. A common example is a login mechanism which allows users to
authenticate, but after a specific number of login attempts, transition to a different state,
locking the account.
● If testers identify a state transition mechanism, they can design test cases that probe the
system when it transitions states. For example, for a system that locks the account after five
failed login attempts, a test case can check what happens at the sixth login attempt.
● We all use the ATMs, when we withdraw money from it, it displays account details at last.
Now we again do another transaction, then it again displays account details, but the details
displayed after the second transaction are different from the first transaction, but both
details are displayed by using the same function of the ATM. So the same function was used
here but each time the output was different, this is called state transition. In the case of
testing of a software application, this method tests whether the function is following state
transition specifications on entering different inputs
● This applies to those types of applications that provide the specific number of attempts to
access the application such as the login function of an application which gets locked after
the specified number of incorrect attempts. Let's see in detail, in the login function we use
email and password, it gives a specific number of attempts to access the application, after
crossing the maximum number of attempts it gets locked with an error message.
● There is a login function of an application which provides a maximum three number of
attempts, and after exceeding three attempts, it will be directed to an error page.
 STATE LOGIN VALIDATION REDIRECTED

S1 First Invalid S2
Attempt

S2 Second Invalid S3
Attempt

S3 Third Invalid S5
Attempt

S4 Home
Page

S5 Error Page

In the above state transition table, we see that state S1 denotes first login attempt. When the first
attempt is invalid, the user will be directed to the second attempt (state S2). If the second attempt is
also invalid, then the user will be directed to the third attempt (state S3). Now if the third and last
attempt is invalid, then the user will be directed to the error page (state S5).
But if the third attempt is valid, then it will be directed to the homepage (state S4).

5. Requirements based Testing

Requirements-based testing is a testing approach in which test cases, conditions and data are
derived from requirements. It includes functional tests and also non-functional attributes such as
performance, reliability or usability.
• The requirements-based testing (RBT) process is comprised of two phases: ambiguity
reviews and cause-effect graphing.
• An ambiguity review is a technique for identifying ambiguities in functional requirements to
improve the quality of those requirements.
• Cause-effect graphing is a test-case design technique that derives the minimum number of
test cases to cover 100 percent of the functional requirements.
• It employs many methods like creating graphs for cause and effect, analyzing test conditions
and analyzing ambiguities. Usually a list of defects in the requirements document is used to
detect requirements ambiguities and then remove them.
• To determine test conditions that must be covered, one must make an in-depth study of the
requirements document.
Stages in Requirements based Testing:
1.Defining Test Completion Criteria - Testing is completed only when all the functional and non-
functional testing is complete.
2.Design Test Cases - A Test case has five parameters namely the initial state or precondition,
data setup, the inputs, expected outcomes and actual outcomes.
3.Execute Tests - Execute the test cases against the system under test and document the results.
4.Verify Test Results - Verify if the expected and actual results match each other.
 5.Verify Test Coverage - Verify if the tests cover both functional and non-functional aspects of
the requirement.
6. Track and Manage Defects - Any defects detected during the testing process goes through
the defect life cycle and are tracked to resolution. Defect Statistics are maintained which will give us
the overall status of the project.

6. Positive Testing
Positive Testing is a type of testing which is performed on a software application by providing the
valid data sets as an input. It checks whether the software application behaves as expected with
positive inputs or not. Positive testing is performed in order to check whether the software
application does exactly what it is expected to do.
• There is a text box in an application which can accept only numbers. Entering values up to
99999 will be acceptable by the system and any other values apart from this should not be
acceptable. To do positive testing, set the valid input values from 0 to 99999 and check
whether the system is accepting the values.

Positive Testing is testing process where the system is validated against the valid input data. In this
testing, tester always check for only valid set of values and check if a application behaves as expected
with its expected inputs. The main intention of this testing is to check whether software application does
that what it is supposed to do. Positive Testing always tries to prove that a given product and project
always meets the requirements and specifications. Positive testing is testing of the normal day to day life
scenarios and to check the expected behavior of application.
Example of Positive Testing:Consider a scenario where you want to test an application which contains a
simple text box to enter age and requirements say that it should take only numerical values. So here
provide only positive numerical values to check whether it is working as expected or not is the Positive
Testing.

7. Negative Testing
• Negative Testing is a testing method performed on the software application by providing
invalid or improper data sets as input. It checks whether the software application behaves as
expected with the negative or unwanted user inputs. The purpose of negative testing is to
ensure that the software application does not crash and remains stable with invalid data
inputs.
• For example -
• Negative testing can be performed by entering characters A to Z or from a to z. Either
software system should not accept the values or else it should throw an error message for
these invalid data inputs.

In Negative Testing the system is validated by providing invalid data as input. A negative test checks if an
application behaves as expected with its negative inputs. This is to test the application that does not do
anything that it is not supposed to do so. Such testing is to be carried out keeping negative point of view
& only execute the test cases for only invalid set of input data.

The main reason behind Negative testing is to check the stability of the software application against the
influences of different variety of incorrect validation data set. Negative testing helps to find more defects
& improve the quality of the software application under test but it should be done once the positive
testing is complete.
Example of Negative Testing :Considering example as we know phone no field accepts only numbers and
does not accept the alphabets and special characters but if we type alphabets and special characters on
phone number field to check it accepts the alphabets and special characters or not than it is negative
testing.

Here, expectation is that the text box will not accept invalid values and will display an error message for
the wrong entry.
In both the testing, the following needs to be considered:
• Input data
• An action which needs to be performed
• Output Result
Testing Technique used for Positive and Negative Testing:
Following techniques are used for Positive and negative validation of testing is:
• Boundary Value Analysis
• Equivalence Partitioning

8. User Documentation Testing

User Documentation covers all the manuals, user guides, installation guides, setup guides, read
me files, software release notes, and online help that are provided along with the software to
help the end user to understand the software system.
• User Documentation Testing should have two objectives:-
1) To check if what is stated in the document is available in the software
2) To check if what is there in the product is explained correctly in the document
• This testing is plays a vital role as the users will refer this document when they start using the
software at their location. a badly written document can put off a user and bias them against the
product even the product offers rich functionality.
• Defects found in the user documentation need to be tracked to closure like any regular software
defect. Because these documents are the first interactions the users have with the product. A
good User Documentation aids in reducing customer support calls. The effort and money spend
on this effort would form a valuable investment in the long run for the organization.
• A good observation is that projects that have all the documents in place have a high level of
maturity as compared to the un-documented project.
• Documentation for an organization saves time, cost and makes testing easy and systematic.
• It is equally important for the client’s acceptance because documentation defines a software
product’s effectiveness. If the documentation is poor, deficient, or defective, it may affect the
quality of software or application. QA practices should be documented such that they are
repeatable, and are not dependent on any individuals.
• During manual software testing, documentation will include specifications, test designs, test
plan, prevalent business rules, reports, configurations details, changes in code, test cases, bug
reports, user manuals, etc.
• As a part of documentation, there needs to be a system for easily finding and obtaining
documents and determining what documentation will have a particular piece of information.
• Once the details are documented, they should be placed at a common databank where easy
search and timely availability of the records is feasible. These documents come handy in times
of any dispute or comparing the requirement specification with the delivered product.
Few essential software testing documents that need to be used and maintained on a day to day
basis:
1) Test design document
2) Test case specification
3) Test Strategy
4) Test summary reports
5) Document of Weekly Status Report
6) User Documents
7) Document of User Acceptance Report
8) Report of Risk Assessment
9) Test Log document
10) Test plan document
11) Bug reports document
12) Test data document
13) Test analysis