3.

5 Testing
• Black Box Testing:
• It is a way of software testing in which the internal
structure or the program or the code is hidden and
nothing is known about it.
• It also known as data-driven, box testing, data-, and
functional testing.
• This type of testing is ideal for higher levels of testing
like System Testing, Acceptance testing.
• It is mostly done by software testers.
• No knowledge of implementation is needed.
• It is functional test of the software.
• Testing can start after preparing requirement
specification document.
• Techniques used:
• Equivalence partitioning: Equivalence partitioning divides
input values into valid and invalid partitions and selecting
corresponding values from each partition of the test
data.
• Ex. Username – accept number only.( Fail- Char, fraction)
• Password – Combination of 4 to 6 char. (1caps, 1lower,
1special, 1number)( null/ blank)
• Boundary value analysis: checks boundaries for input
values.
• Advantages of Black Box Testing
• Efficient when used on large systems.
• Since the tester and developer are independent of
each other, testing is balanced and unprejudiced.
• Tester can be non-technical.
• There is no need for the tester to have detailed
functional knowledge of system.
• Tests will be done from an end user's point of
view, because the end user should accept the
system. (This testing technique is sometimes also
called Acceptance testing.)
• Testing helps to identify vagueness and
contradictions in functional specifications.
• Test cases can be designed as soon as the
functional specifications are complete.
• Disadvantages of Black Box Testing
• Test cases are challenging to design without
having clear functional specifications.
• It is difficult to identify tricky inputs if the test
cases are not developed based on specifications.
• It is difficult to identify all possible inputs in
limited testing time. As a result, writing test cases
may be slow and difficult.
• There are chances of having unidentified paths
during the testing process.
• There is a high probability of repeating tests
already performed by the programmer.
• White Box Testing:
• It is a way of testing the software in which the
tester has knowledge about the internal
structure or the code or the program of the
software.
• It is also called structural testing, clear box
testing, code-based testing, or glass box testing.
• Testing is best suited for a lower level of testing
like Unit Testing, Integration testing.
• It is mostly done by software developers.
• Knowledge of implementation is required.
• It is structural test of the software.
• Testing can start after preparing for Detail design
document.
• Techniques Used:
• Statement Coverage, Branch coverage, and Path
coverage are White Box testing technique.
• Statement Coverage validates whether every
line of the code is executed at least once.
• Branch coverage validates whether each branch
is executed at least once.
• Path coverage method tests all the paths of the
program
• Advantages of White Box Testing
• Code optimization by finding hidden errors.
• White box tests cases can be easily
automated.
• Testing is more thorough as all code paths are
usually covered.
• Testing can start early in SDLC even if GUI is
not available.
• Disadvantages of White Box Testing
• White box testing can be quite complex and
expensive.
• Developers who usually execute white box test
cases detest it. The white box testing by developers
is not detailed can lead to production errors.
• White box testing requires professional resources,
with a detailed understanding of programming and
implementation.
• White-box testing is time-consuming, bigger
programming applications take the time to test
fully.
 White box testing Black Box Testing

The tester needs to have the This technique is used to test the
knowledge of internal code or software without the knowledge
program. of internal code or program.

It aims at testing the structure of It aims at testing the functionality

the item being tested. of the software.

It is also called structural testing, It also knowns as data- driven, box

clear box testing, code-based testing, data and functional
testing, or glass box testing. testing.

Testing is best suited for a lower This type of testing is ideal for
level of testing like Unit Testing, higher levels of testing like System
Integration testing. Testing, Acceptance testing.
 White box testing Black Box Testing

Statement Coverage, Branch Equivalence partitioning,

coverage, and Path coverage Boundary value analysis are
are White Box testing Black Box testing technique
technique.
Can be based on detailed Can be based on Requirement
design documents. specification document.

It is carried out by software It is carried out by software

developer tester

Example: By input to check and Example: Search something on

verify loops google by using keywords
 3.6 Test Documentation
• Test Case Template
• Test plan
• Introduction to defect report
• Test summary report.
• Test documentation is documentation of artifacts
created before or during the testing of software.

• It helps the testing team to estimate testing effort

needed, test coverage, resource tracking, execution
progress, etc.

• It is a complete suite of documents that allows you

to describe and document test planning, test
design, test execution, test results that are drawn
from the testing activity.
 Types of Test Documentation
Test Case Template

• A test case template is a document containing an organized

list of test cases for different test scenarios that check
whether or not the software has the intended functionality.

• A test case is a set of steps carried out to test a specific

feature of an application.

• Other than the executable steps, a test case also contains

preconditions for testing, test data provided, expected
outcome, and actual result. A tester can judge the success of
a test case by comparing its expected and actual results.
Test Case
• The test case is defined as a group of conditions
under which a tester determines whether a software
application is working as per the customer's
requirements or not.
• Test case designing includes preconditions, case
name, input conditions, and expected result.
• A test case is a first level action and derived from
test scenarios.
Typical Test Case Parameters:
• Test Case ID
• Test Scenario
• Test Case Description
• Test Steps
• Prerequisite
• Test Data
• Expected Result
• Actual Result
• Environment Information
• Comments (TC Pass or Fail)
• Example:
• Let us say that we need to check an input field that
can accept maximum of 10 characters.

• While developing the test cases for the above

scenario, the test cases are documented the
following way.

• In the below example, the first case is a pass

scenario while the second case is a FAIL.
• If the expected result doesn't match with the actual
result, then we log a defect.
• The defect goes through the defect life cycle and
the testers address the same after fix.
 Test Plan

• A Test Plan is a detailed document that describes the test

strategy, objectives, schedule, estimation, deliverables, and
resources required to perform testing for a software product.
• Test Plan helps us determine the effort needed to validate
the quality of the application under test.
• The test plan serves as a blueprint to conduct software
testing activities as a defined process, which is minutely
monitored and controlled by the test manager.
• As per ISTQB definition: “Test Plan is A document
describing the scope, approach, resources, and schedule of
intended test activities.”
• Why are Test Plans important?
• They help individuals outside the QA teams
(developers, business managers, customer-facing
teams) understand exactly how the website or app
will be tested.
• They offer a clear guide for QA engineers to
conduct their testing activities.
• They detail aspects such as test scope, test
estimation, strategy, and so on. Collating all this
information into a single document makes it
easier to review by management personnel or to
re-use for other projects.
Components of a Test Plan
• Scope: Details the objectives of the particular
project. Also, it details user scenarios to be used in
tests. If necessary, the scope can specify what
scenarios or issues the project will not cover.
• Schedule: Details start dates and deadlines for
testers to deliver results.
• Resource Allocation: Details which tester will work
on which test.
• Environment: Details the nature, configuration, and
availability of the test environment.
• Tools: Details what tools are to be used for testing,
bug reporting, and other relevant activities.
• Defect Management: Details how bugs will be
reported, to whom and what each bug report needs to
be accompanied by. For example, should bugs be
reported with screenshots, text logs, or videos of their
occurrence in the code?
• Risk Management: Details what risks may occur
during software testing, and what risks the software
itself may suffer if released without sufficient testing.
• Exit Parameters: Details when testing activities must
stop. This part describes the results that are expected
from the QA operations, giving testers a benchmark to
compare actual results to.
 Introduction to Defect Report
• Defect:
A defect in a software product is also known as a bug, error
or fault which makes the software produce an unexpected
result as per the software requirements. For example;
incorrect data, system hangs, unexpected errors, missing or
incorrect requirements.  

Defect Report is a detailed document about bugs found in the

software application.

Defect report contains each detail about Defect like

description, date when Defect was found, name of tester who
found it, name of developer who fixed it, etc.
• A typical defect report contains the information in an xls Sheet
as follows.  
1. Defect ID :
Nothing but a serial number of defects in the report.  
2. Defect Description :
A short and clear description of the defect detected.  
3. Action Steps :
What the client or QA did in an application that results in the
defect. Step by step actions they took.  
4. Expected Result :
What results are expected as per the requirements when
performing the action steps mentioned.  
5. Actual Result :
What results are actually showing up when performing the action
steps.  
6. Severity : Means impact of defect on application , Severity may be
Low, Medium , High.

7. Attachments :
A sequence of screenshots of performing the step by step actions and
getting the unexpected result. One can also attach a short screen
recording of performing the steps and encountering defects. Short
videos help developers and/or QA to understand the bugs easily and
quickly.

8. Additional information :
The platform you used, operating system and version. And other
information which describes the defects in detail for assisting the
developer understand the problem and fixing the code for getting
desired results. 
Test Summary Report
• Test Report is a document which contains a summary
of all test activities and final test results of a testing
project.
• Test report is an assessment of how well the Testing is
performed. Based on the test report, test manager can
evaluate the quality of the tested product and make a
decision on the software release.
• For example, if the test report informs that there are
many defects remaining in the product, test manager
can delay the release until all the defects are fixed.
• Test Summary
• This section includes the summary of testing
activity in general. Information detailed here
includes
• The number of test cases executed
• The numbers of test cases pass
• The numbers of test cases fail
• Pass percentage
• Fail percentage