For Better Understanding of Manual Testing Concepts Credit : Bharath QA Analyst

1. 9/23/2022 Manual Testing
Bharath Goli

2. Contents
1. SDLC
 Requirement phase
 Analysis phase
 Design phase
 Coding phase
 Testing phase
 Deploy & Maintenance phase
2. STLC
 Stages in STLC
o Requirement Analysis
o Test Planning
o Test case Development
o Environment setup
o Test Execution
o Test Closure
 Entry and Exit criteria
 Functional testing
 Non-functional testing
3. Bug life cycle
 Definitions
 Flow chart
o Defect status
 Purpose

3. SDLC
1. What is SDLC?
A. SDLC stands for Software Development Life Cycle which defines the process how to develop a
quality software application. Without using this method, we can’t estimate the budget,
application release, resources, and requirements to be needed for development.
It is a more efficient way to develop software applications. SDLC divides application
development into phases and each phase has its process.
Stages in SDLC:
1. Requirements phase
2. Analysis phase
3. Design phase
4. Coding phase
5. Testing phase
6. Deploy and Maintenance phase
Analysis phase
Design phase
Requirement phase
Deploy & Maintenance
phas
Testing phase
Coding phase

4. Requirement phase:
Aim: Collecting requirements from clients.
Involvement: Business Analyst (BA), Engagement manager(EM)
Process:
 BA is the person who will contact the client in the initial stage and gathers requirement from the
client.
 Later Engagement manager study the requirements. Suppose he didn’t get clarity on
requirements then he will ask respectively team to build a prototype and that prototype will
share with client and take clear requirements.
 Based on the situation, the Project manager acts like BA takes requirements from the clients.
 Prototype: Prototype is a demo model of a product which is used to present in front of clients
for their approval and gathering requirements.
Engagement manager: An engagement manager is responsible for building a positive
relationship with a client after they have signed a contract. They are responsible for solving any
issue that a client experiences.
 In this phase, all the gathered requirements information will be present in the document. That
document will be called a Business Requirement speciation (BRS).
After that, they made a few requirement documents based on their convenience.
They are
1. FRS: Functional Requirement Specifications
2. CRS: Customer (or) Client Requirement Specifications
3. URS: User Requirement Specifications
4. BRS: Business Requirement Specifications
5. BDD: Business Design Document
6. SRS: Software Requirement Specification

5. Analysis phase:
Aim: Analyzing the requirements which was gathered from client.
Involvement: System Analyst (SA), Project Manager(PM), Technical Manager(TM)
Process:
 Analysis phase is to define and develop the software needs. This process conducted with the
help of Software Requirement Specification document also known as SRS document. It includes
everything which should be designed and developed during the project life cycle.
 Feasibility study:
After study the requirements, they are verifying whether it is possible to develop the
requirements with available resource, time, budget or not.
Tentative planning:
In this phase resource planning and time planning will be temporarily done.
Technology selection & Environment confirmation:
In this phase they select the technology and environment for accomplish those
requirements.
Law:
Can we develop the application as per cyber laws.
*Here requirements may be Human resources, software’s, and Hardware’s.
 Systems analysts is a person who is thoroughly aware of the system and guides the system
development project by giving proper directions. He is an expert having technical and
interpersonal skills to carry out development tasks required at each phase.
 Project managers are in charge of the planning, scheduling, budgeting, execution, and delivery
of software and web projects.
 Technical manager generally oversees the development, implementation and maintenance of
technological company systems and processes, including troubleshooting any potential issues.

6. Difference between Project manager and Technical manager:
A project manager is normally making sure people carry out their tasks, and manages the timeline
of each task finishing in time with the allocated resources etc.
Generally technical manager also did the same thing what project manager do but with slight
difference, he will understand the technical part, what they are doing and also you can explain to
non-technical people.
Design phase:
Aim: Here system and software design documents are prepared as per the requirement
specification document.
Involvement:
 High level design is done by chief Architect (CA)
 Low level design is done by Technical Lead (TL)
Process:
 Based on the requirements specified in SRS, usually more than one design approach for the
product architecture is proposed and documented in a DDS - Design Document
Specification.
 This DDS is reviewed by all the important stakeholders and based on various parameters as
risk assessment, product robustness, design modularity, budget and time constraints, the
best design approach is selected for the product.
 A design approach clearly defines all the architectural modules of the product along with its
communication and data flow representation.
 The chief architect will divide the whole project into modules by drawing some diagrams
using unified modeling language (UML).
 The Technical lead will divide the modules into sub modules by drawing some diagrams
using the same UML.
LLD: Ex: DFD-Data Flow Diagram, E-R Diagram, Class Diagram, Object Diagram.
Example of UML diagram

7.  In this phase they will also design GUI part of the application, as well as PSEUDO CODE also
developed.
Pseudocode is an artificial and informal language that helps programmers develop algorithms.
Pseudocode is a "text-based" detail (algorithmic) design tool.
Ex: Set total to zero
Set grade counter to one
While grade counter is less than or equal to ten
Input the next grade
Add the grade into the total
Set the class average to the total divided by ten
Print the class average.
Coding Phase:
Aim: They write code for developing the software product.
Involvement: Developers
Process:
 In this phase, developers start build the entire system by writing code using the chosen
programming language. In the coding phase, tasks are divided into units or modules and
assigned to the various developers. It is the longest phase of the Software Development Life
Cycle process.
 They also need to use programming tools like compiler, interpreters, debugger to generate
and implement the code.
 In this phase, Developer needs to follow certain predefined coding guidelines.
Difference between Design and coding phase:
In developing they build product which requires coding knowledge, where in design phase requires
knowledge around usability and functionality.

8. Examples of coding standards:
1. Limited use of globals
2. Standard headers for different modules etc.
Testing Phase:
Aim: To give quality product to the customer.
Involvement: Tester Engineer, Test lead, QA manager
Process:
 This stage is usually a subset of all the stages as in the modern SDLC models, the testing
activities are mostly involved in all the stages of SDLC.
 After receiving the requirements documents, QA manager makes test plan and test engineer
develop test cases.
 After developing completed they deploy build in the testing environment. The testing team
starts testing the functionality of the entire system with the help of test cases.
 During testing they find any defects, it will report to the developer. After they fix the bug again it
will send it to tester for re-test. This process continues until all the requirements passed.
o Here quality means reaching customer requirements.
o Build means a finally integrated all modules set .EXE form is called a Build.
o Test case is a document which describes step by step procedure of how to test the
application.

9. Deploy & Maintenance phase:
Aim: Hand over the quality product to client.
Involvement: Delivery manager
Process:
 The Delivery manager will go to the customers place, install the application into the
customers environment and handover the original software to the client.
 The final official agreement made between the customer and company is proof document for
Delivery.
 Once the application is delivered. The customer will start using it, while using if at all they
face any problems then that particular problem will be created as tasks.
 They will define the process and solves the problem. This process is known as Normal
Maintenance.
 But some customers may request for continuous Maintenance, in that case a team of
members will be continuously working in the client site to take care of their Software.
Popular SDLC models
1. Waterfall model
2. Incremental model
3. Spiral model
4. V- model
5. Agile model

10. STLC
1. What is STLC?
A. STLC stands for Software testing life cycle. Software Testing life cycle is a process which is used
to test the software application to confirm whether the developed application meets the
requirements or not.
(Or) Software Testing is a process for identifying errors, bugs, defects, gaps, or any missing
requirements as compared to the actual requirements given by the client.
STLC is an integral part of the SDLC, but it only deals with testing phases.
Stages in STLC
1. Requirement Analysis
2. Test Planning
3. Test case Development
4. Environment Setup
5. Test Execution
6. Test Closure
Requirement Analysis:

11. In this phase test team studies, the requirements from a testing point of view to identify testable
requirements and the QA team may interact with various stakeholders to understand requirements in
detail. Requirements could be either functional or non-functional. Automation feasibility for the testing
project is also done in this stage.
Activities in Requirement Phase Testing
 Identify types of tests to be performed.
 Prepare Requirement Traceability Matrix (RTM).
 Identify test environment details where testing is supposed to be carried out.
 Automation feasibility analysis (if required).
Deliverables of Requirement Phase Testing
 Automation feasibility report. (if applicable)
 Requirement Traceability Matrix. Below you can see the sample RTM.

12. Test Planning:
In this phase Senior QA manager determines the test plan strategy along with efforts and cost estimates
for the project. At the same time resources, test environment, test limitations and the testing schedule
are also determined. The Test Plan gets prepared and finalized in the same phase.
Test Planning Activities
 Preparation of test plan/strategy document for various types of testing
 Test tool selection (if applicable)
 Test effort estimation
 Resource planning and determining roles and responsibilities.
 Training requirement
Deliverables of Test Planning
 Test plan /strategy document.
 Effort estimation document.
What is an Effort estimation document?
Effort estimation is one the core components of project estimation, along with resource estimation and
cost estimation.
Project estimation is the process of analyzing available data to predict the time, cost, and resources
needed to complete a project.

13. Test Case Development:
After understanding the requirements in SRS document tester develops the test cases for individual
units.
Test Case Development Activities
 Create test cases, automation scripts (if applicable)
 Review and baseline test cases
 Create test data (If Test Environment is available)
Deliverables of Test Case Development
 Test cases
 Test data
Below you can see the test case document. This is only for reference. They won’t follow the same
format.
Test Environment setup:
The test environment is a collection of hardware and software, which helps us to execute the test cases.

14.  The test environment has a software configuration (operating systems), hardware
configuration (RAM, Hard Disk, and Processor), and the test console, which help us to
execute the test cases.
 Test team may not be involved in this activity if the development team provides the test
environment. The test team is required to do a readiness check (smoke testing) of the
given environment.
Test Environment Setup Activities
 Setup test Environment and test data
 Perform smoke test on the build
Deliverables of Test Environment Setup
 Environment ready with test data set up
 Smoke Test Results.
Test Execution phase:
Test Execution Phase is carried out by the testers in which testing of the software build is done based on
test plans and test cases prepared. The process consists of test script execution and bug reporting. If
bugs are reported, then it is reverted back to development team for correction and retesting will be
performed.
Test Execution Activities
 Execute tests as per plan
 Document test results, and log defects for failed cases
 Map defects to test cases in RTM
 Retest the Defect fixes
 Track the defects to closure
Deliverables of Test Execution
 Completed RTM with the execution status
 Test cases updated with results
 Defect reports. Below you can see the sample bug report for your reference.

15. Test Closure:
Test Closure, which is the last stage of software testing life cycle, is a report that is prepared by
the team manager or lead after the completion of software testing process.
Test Closure is a document that gives a summary of all the tests conducted during the software
development life cycle. It also gives detailed analysis of the bugs removed and error found.
Test Closure Activities
 Evaluate cycle completion criteria based on Time, Test coverage, Cost, Software, Critical
Business Objectives, Quality
 Prepare Test closure report
 Prepare test metrics based on the above parameters.
 Test result analysis to find out the defect distribution by type and severity.
Deliverables of Test Cycle Closure
 Test Closure report
 Test metrics
Simply, Metric is a unit used for describing an attribute. Metric is a scale for measurement.
Software testing metrics are a way to measure and monitor your test activities. More
importantly, they give insights into your team's test progress, productivity, and the quality of the
system under test.
Parameters are freely configurable input values that can be assigned to different test types
and used in a variety of ways. They help to define tests by defining test data.

16. What is Entry and Exit Criteria in Test closure?
 Entry Criteria:
1. Test closure has been completed
2. Test results are available
3. Defect logs are available
 Exit Criteria:
1. Test Closure report signed off by client
What is Entry and Exit Criteria in STLC?
 Entry Criteria: Entry Criteria gives the prerequisite items that must be completed before testing
can begin.
 Exit Criteria: Exit Criteria defines the items that must be completed before testing can be
concluded
Types of Testing:
They are two types of testing.
1. Manual testing
2. Automation testing.
Manual Testing: Manual testing is a software testing process in which test cases are executed manually
without using any automated tool. All test cases executed by the tester manually according to the end
user's perspective. It ensures whether the application is working, as mentioned in the requirement
document or not.
Automation testing: Automation Testing is the process of using tools, scripts, and software to perform
test cases by repeating pre-defined actions.

17. Types of Software application testing
1. Functional testing
2. Non-functional testing
Functional testing:
Functional testing is performed by tester to test the functional aspects of a software application. Every
function should be tested to verify if the functional requirements are met. There are various types of
functional testing.
1. Smoke testing
2. Sanity testing
3. Unit testing
4. Integration testing
5. Re-testing
6. Regression testing
7. UAT etc...
Smoke testing: Smoke Testing is a software testing process that determines whether the deployed
software build is stable or not. Smoke testing is a confirmation for QA team to proceed with further
software testing.

18. Sanity testing: Sanity Testing is a type of software testing which is usually performed on a stable build to
ascertain that bugs have been resolved and there are no new defects introduced due to changes in the
code, or functionality of software product.
Unit testing: Unit testing involves the testing of each unit or an individual component of the software
application. It is the first level of functional testing.
Integration testing: Integration testing is used to check the data flow between the combined modules. It
is the second level of testing.
Retesting: Retesting is a type of testing which is used to check that the previous failed functionality is
working as per requirements after bug fixed by developer.

19. Regression testing: Regression testing is a type of testing which is used to check whether the existing
functionality remains same or not after modifies the code.
User Acceptance testing: UAT is a type of testing which can be performed by the end-user or the client
to verify/accept the software system before moving the software app to the production environment.
Non-Functional Testing:
Non-functional testing is done to test the performance, security, and usability of the application. This
testing helps to improve the quality of the application. Non-functional testing is performed using certain
tools and not done manually.
1. Performance testing
2. Scalability testing
3. Recovery testing
4. Security testing
5. Compatibility testing
6. Configuration testing
7. Configuration testing
8. Soak testing etc...
Performance testing: Performance testing is a type of software testing which is used to check that the
software application performs properly under their expected workload.
Scalability testing: Scalability testing is a type of load testing that tests how the system is going tp
perform during a sudden spike or fall of users.
Recovery testing: It is a type of testing where the testers will test the application to check how well the
software application recovers from disasters or crashes.

20. Security testing: It is a type of testing that uncovers vulnerabilities, threats, risks in a software
application and prevents malicious attacks from intruders.
Compatibility testing: It is a type of testing to check whether your software is capable of running on
different hardware, operating system, network environments or mobile devices.
Bug life cycle
1.Definitions
1. What is Error?
A. A mistake in code found by the developer while developing the application, then it is called an
Error.
2. What is Defect?
A. If the tester finds any deviations in functionality while testing the application, then it is called a
Defect.
3. What is Bug?
A. A defect is accepted by the developer, then it is called a Bug.
What is Defect Life Cycle?
Defect Life Cycle or Bug Life Cycle in software testing is the specific set of states that defect or bug goes
through in its entire life. The purpose of Defect life cycle is to easily coordinate and communicate status
of defect which changes to various assignees and make the defect fixing process systematic and
efficient.

21. 2.Flow Chart:
 Bug life cycle
Fail
Pass
NEW
ASSIGN
DEFERRED
OPEN
FIXED
TEST
CLOSED
DUPLICATE REJECTED
REOPENED
AS PER DESIGN

22. Defect Status:
Defect Status or Bug Status in defect life cycle is the present state from which the defect or a bug is
currently undergoing. The goal of defect status is to precisely convey the current state or bug in order to
better track and understand the actual progress of the defect life cycle.
New:
If the tester finds any new deviation while testing the application, then the tester reports the bug to the
Team lead/Project Manager and creates a status “New”.
Assign:
The team lead/Project Manager validates the deviation which was submitted by the tester. If the
deviation is valid then they will assign that bug to the development lead or respective developer and
change the status to “Assign” otherwise he rejects the deviation.
If Bug is accepted by the Development lead, then he will assign that bug to the associate developer.
Open:
If the developer accepts the deviation, then it will be treated as Bug, and he/she will change the status
to “Open”.
Fixed:
After Bug fixed by the developer then he will change the status to “Fixed”.
Test:
Here testers test the fixed deviation, for knowing if it is fixed or not. If it is fixed, then he/she will change
the status to “Closed”, other he/she will move the status to “Reopen”.
Reopened:
If a bug is not working properly after rectification, then the tester will change the status to “Reopen”.
Closed:
After the tester confirms that the bug was fixed then the tester will change the Status to “Closed”.
Deferred:
If the developer accepts the defect and wants to rectify it later then he/she will change the status to
“Deferred”.
Rejected:
If the Development lead/developer doesn’t accept the defect, then they will change the status to
“Rejected”.

23. As Per Design:
If the tester raised a defect without knowing the latest requirements, then the developer lead/
developer will change the status to “As Per Design”.
Duplicate:
If the developer/ Development lead finds the defect is repeated, then they will change the status to
“Duplicate”.
3.Purpose
1. Why do we use the Defect life cycle?
A. The main intention is to easily coordinate and communicate the status of the defect and the
process of defect fixing to make it efficient.