Unveiling tiny Essentials of

Manual Testing
Sujaeendra Chowbin
 Manual Testing.

Testing:
A step-by-step process of executing a system or software in the intent of
finding bugs. Testing improves the quality of product.
Importance of Software Testing
 Quality.
 Cost Effectiveness.
 Security.
 Customer Satisfaction.
 Easy to add Features.

There are two types of testing, they are Manual Testing and Testing
Automation.

Manual Testing:
Oldest type of testing where the Test Cases are executed manually
without any automation tools or scripts.

Levels of Manual Testing

 Unit Testing : Testing Individual components(units).

 Integration Testing : Testing the integrated component (Comb of units).
 System Testing : Testing the entire system (entire modules or code).
 Acceptance Testing : The last phase of software testing performed after
. System Testing and before making the system available for actual use.
Advantages:
 Cheaper
 Easy to learn
 Short term projects highly used this
 Reliable
 GUI Testing done more accurately.
Disadvantages:
 Human errors
 Time consuming
 Limited scope
 Not suitable for large organizations
 Performance testing and Load testing not possible.

Bug:
The Deviation from actual to expected output, The term related to
Testing.

Software Testing Life Cycle:

 Understand requirements
 Prepare test plan
 Prepare test cases
 Execute testcases
 Raise bugs
 Provide QA signoff
(Positive Testing)
Giving a Valid input and gets out an expected output without breaking
functional flow of application.

(Negative Testing)
Giving an invalid input, in order to break the functional flow of
application.

 Project: Developed based on customer requirement.

 Product: Developed based on market requirement.

SDLC MODELS:
Traditional models:
 Waterfall model (Sequential).
 V-model (Parallel).
 Spiral
 Prototype
--> Requirements are converted into test cases.

Agile:
Agile project management is an incrementive and iterative approach in
which the software/application is released in the form of chunks (releases).
(NO PROJECT MANAGER)
1. Scrum
2. Kanban
3. Scrumban
--> User Stories are converted into test cases.
Agile Manifesto:
 Individual and interactions over processes and tools.
 Working software over comprehensive documentation.
 Customer satisfaction over contract negotiation.
 Respond to change over following the plan.

Scrum model:
In scrum model we deliver a potentially shippable working software in an
incrementive and iterative fashion.
-->Each release we call as chunks.
MMF: Minimally marketable features are released first in scrum.
Scrum Team: 9 members
 4 developers
 2 QA
 1 DBA
 1 Architect
 1 UI designer

Product Owner: Responsible for ensuring the success of a project in Scrum

and He/she Collect User stories, do backlog grooming.
User story: End user explaining his/her requirement in the form of a story.
Format of User story:
 As a user_______
 I want to________
 So that_________

Functionality Testing: Testing the application in a core business functional flow.

Validation Testing: Testing the application functionality in order to break the
flow (Negative functional testing).
Ceremonies of Agile:
1. Release Planning meeting (Before releasing)
2. Sprint planning meeting (Starting of sprint)
3. Daily stand-up call
4. Sprint review (after sprint)
5. Sprint retrospective meeting

1) Release Planning meeting: What are the modules/epics we are going to

deliver as part of the release
 Duration Release – 3months (60 Days)
 PO, Scrum team & Scrum master.
 Voting starts after meeting (T-shirt Sizing – S M L XL XXL XXXL)
 Pick Highest and Lowest estimator.

2) Sprint Planning Meeting: Scrum Team will estimate user stories & Plan
the Sprint. (Planning poker – 0, 0.5, 1, 2, 3, 5, 8, 13, 21, 40, 100, coffee?)
(or)
What work from product backlog Can be completed.
 Story point estimator
 Story Points: a way to estimate the amount of effort required to
complete a user story in your product backlog.
 Duration Sprint – 3 weeks (15 Days)

3) Daily Stand-up Call: Each morning, team members discuss what they
worked on yesterday, what they’re doing today, and what’s blocking them
from moving forward.
 What I have done yesterday.
 What to do today
 Blockers/Impediments

4) Sprint Review Meeting: Last day of each sprint the demo is given to
stakeholders and PO. These can be informal “show and tell” or formals.
 5) Sprint Retrospective meeting: At the end of each sprint, team will
discuss the User stories.
 What went well
 What not went well
 Improvements

Bouncer: Additional resource in scrum team who take care of production/ live
issues.
Backlog: It is remaining or undone work which is to be completed soon.
 Product backlog: Features you want to implement but have not yet
prioritized for release.
 Release backlog: Features that need to be implemented for a particular
release.
 Sprint backlog: User stories that need to be completed during a specific
period of time.

Backlog Grooming: Rearranging the User stories based on their relative value.

Static Testing: Static testing targets to the assessment of code and

documentation.
 Testing done without execution.

 Includes document tests, emails, codes also tested.

 Verification

Dynamic Testing: Testing the code with executing it (finding & fixing bugs).
 Needed execution.
 Type of validation

White box Testing: Coding

Black box Testing: QA
Grey Testing: SDET
Software Test Plan:
Blue print/ master document which talks about how testing is carried
out across the software lifecycle.
 Each & every minute detail is present.
 Prepared by QA lead

What happen without test plan: for example, if the client asked us to develop
a software which is to be work only in edge browser. If we have written
everything in test plan, we will be safe side if they ask us about another
browsers.

BLACK BOX TESTING:

 Functional Testing: software testing which is used to verify the
functionality of the software application, whether it’s working according
to the requirement.

 Non-Functional Testing: software testing to test non-functional

parameters such as reliability, load test, performance and
accountability of the software

 Regression Testing: Adding New features to the application and testing

old functionalities of the application ensuring that they are working fine.

BLACK BOX TESTING TECHNIQUES:

 Boundary Value Analysis: It’s a technique in which boundary values are
taken has input values because boundaries have higher chances of error.
(Or)
Boundary Value Analysis is based on testing the boundary values of valid
and invalid partitions
 Equivalence Class Partition: Technique that divides the input data of a
software into Equal partitions in which test cases can be derived.

 Decision Table Testing: a commonly used black-box testing technique and is

ideal for testing two or more inputs that have a Complex business logic or
(logical relationship)

 State Transition Technique: a black box testing technique, in which

outputs are triggered by changes to the input conditions (or) state of
the system.
(Or)
a black box testing technique to observe the behaviour of the system or
application for different input conditions passed in a sequence.
  Use Case Testing: black box testing that helps in identifying test cases
that cover the entire system transaction-by-transaction from start to
finish.

WHITE BOX TESTING:

These below testing’s cover under white box testing

 Path Testing (program’s control structure)
 Loop Testing.

 Conditional Testing.
 Unit Testing.
 Mutation Testing.
 Integration Testing

 Penetration Testing.
 Testing based on Memory Perspective
Testing Techniques:
 Statement coverage: In this technique, the aim is to traverse all
statements at least once. Hence, each line of code is tested. In the case
of a flowchart, every node must be traversed at least once. Since all
lines of code are covered, helps in pointing out faulty code.
(Or)
Shortest number of paths in which all nodes are covered.

 Branch Coverage: In this technique, test cases are designed so that

each branch from all decision points is traversed at least once. In a
flowchart, all edges must be traversed at least once.
(Or)
Aim to cover all Possible ways.
  Condition Coverage: In this technique, all individual conditions must
be covered as shown in the following example:
1. READ X, Y
2. IF(X == 0 || Y == 0)
3. PRINT ‘0’
4. #TC1 – X = 0, Y = 55
5. #TC2 – X = 5, Y = 0

 Multiple Condition Coverage: In this technique, all the possible

combinations of the possible outcomes of conditions are tested at
least once. Let’s consider the following example:
1. READ X, Y
2. IF(X == 0 || Y == 0)
3. PRINT ‘0’
4. #TC1: X = 0, Y = 0
5. #TC2: X = 0, Y = 5
6. #TC3: X = 55, Y = 0
7. #TC4: X = 55, Y = 5

OTHER TYPES OF TESTING:

Smoke Testing: Testing the core basic functionalities of any application end
to end is called smoke testing.
 High Surface Level testing immediately after code deployment.
 Bugs identified in smoke testing are called blockers (or) show stoppers.

Regression Testing: Adding a new feature or any change in the application,

testing the old functionalities whether they are working or not.
 It is end to end test such that it takes more time to complete.

Sanity Testing: It is a quick and basic test (or set of tests) to ensure that the
code changes made are working properly without any bugs.
(Or)
It is a subset of regression testing where only a few functionalities in the
application are tested end to end due to time constraints of release.
Test Cases: Actions required to verify a specific feature or functionality in
software testing.
(Or)
Set of steps/actions required to verify the functionality of a software.

Test Scenario: A document that covers the end-to-end functionality of the

software very briefly, mostly in one line, from an end-user perspective.

Bug includes:
1. a title
2. bug description
3. environment information
4. steps to reproduce
5. Priority
6. Severity& more

What should be included in writing Test Cases:

1. Test Case ID
2. Section
3. Testing Type
4. Priority
5. Title
6. Pre-Conditions
7. Procedure/Steps
8. Expected result
9. Actual result
10.Estimated time
11.Test Cases Type (Manual/Automation)
12.Comments