0% found this document useful (0 votes)
8 views22 pages

Simplyfi Tech Testing Overview

Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
8 views22 pages

Simplyfi Tech Testing Overview

Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd

IMAGINE BELIEVE ACHIEVE

Software Testing

[Link]
Topics

Testing Life Cycle


Types of Testing
Test Plan
Test Environment
Test Cases
Test Execution
Testing Methodology
Bug Life Cycle
Bug Status Workflow
Retesting
Regression Testing
Testing Sign-Off
Product Quality
[Link]
Testing Lifecycle

[Link]
Types of Testing

Functional : Test cases have been designed to validate each functional requirement, ensuring
that all functionalities work as expected.

Non-Functional : These include performance, security, and usability testing to verify the
system's behavior under various conditions.

[Link]
Types Of
Functional
Testing
 Smoke Testing: Basic functionality check.

 Sanity Testing: Verify specific functionality after changes.

 Regression Testing: Make sure new code doesn’t break existing functionality.

 Integration Testing: Ensure components/modules work together.

 System Testing: Tests the entire application as a complete system(End to End)

 Database Testing: CRUD operations.

 Api Testing: Verify HTTP methods (Test GET, POST, PUT, DELETE, PATCH requests).
[Link]
Types of Non
Functional
Testing
 Performance Testing
Purpose: Evaluate the system's responsiveness and stability under load.
Subtypes:
 Load Testing: Normal expected load
 Stress Testing: Extreme conditions
 Spike Testing: Sudden large increases in load
 Endurance Testing (Soak): Long periods of normal load

 Security Testing
Purpose: Identify vulnerabilities and weaknesses in the system.
Examples: Penetration testing, ethical hacking, risk assessment

 Compatibility Testing
Purpose: Ensure the software works across different environments.
Types: Browser compatibility, OS compatibility, device compatibility

[Link]
Test Plan
 Test plan : It's a documents which contains all the future testing activities.
Scope
Approach
Objective
Testing Methodology
Effect Estimation
Schedule
Assumptions
Risk
Mitigation plan
Entry and Exit criteria
Test Stop criteria
Defect Tracking
Test Automation
Test Environment
Deliverables
Roles and Responsibilities
Templates
[Link]
Test Environment

 Testing Environment
• Used by the QA team to test new features and fix bugs.
• Frequently updated with the latest code changes.
• Contains test data and tools to help identify and resolve issues early.

 UAT (User Acceptance Testing) Environment


• Used by business users or clients to validate the product before it goes live.
• More stable than the testing environment.
• Helps ensure the product meets all business requirements.

 Production Environment
• This is the live version used by real users.
• Only fully tested and approved updates are deployed here.
• Performance and stability are the highest priorities in this environment.

[Link]
Test Cases

 Test Scenarios of “What to test” will be prepared for each functionality. Test Case document of “How to
test” will be prepared with the criteria like Test Scenario, Test Case Description, Test Data, Test Steps,
Expected Results, Actual results and Status. Test Scenario and Test case document will be prepared in Excel.

 We will apply several Test Designing techniques while creating Test Cases wherever applicable,
• Equivalence Class Partition
• Boundary Value Analysis
• Decision Table Testing
• State Transition Testing
• Use Case Testing

 We also use our expertise in creating Test Cases by applying the below :
• Error Guessing
• Exploratory Testing

[Link]
Test Cases
Format

[Link]
Test Execution

 Once the build is deployed, we will thoroughly review the application and prepare an estimate for the testing
hours required.

 Application Review:
We will go through the deployed application to understand its functionality and identify the key areas
that need testing.

 Testing Estimation:
Based on the application review, we will prepare a detailed estimation of the testing hours required. This
will include the time needed for different types of testing, such as functional testing, regression testing,
and any additional exploratory testing that may be necessary

 Testing :
Once we start testing the application, our focus will be to ensure that all functionalities are working as per
our test cases.
[Link]
Bug Life Cycle

[Link]
 Raising Bugs:

Whenever we encounter issues during testing, we document and raise bugs in our
tracking system. These bugs are then assigned to the relevant developers.

 Developer Coordination:

After raising a bug, we proactively connect with the assigned developer to discuss
the issue and expedite its resolution. This direct communication helps to ensure that
critical issues are addressed as quickly as possible

 Priority-Based Fixing:

Developers address the bugs based on their priority levels. Once a bug is fixed, the
status is updated in the system

[Link]
Bug Report
Format

[Link]
Bug Status Work
Flow

 In-Progress Status:
When a developer starts working on a specific issue, they update the bug status to "In-
Progress.“

 This indicates that the issue is currently being worked on and is actively under investigation or
development.

 Fixed/Closed Status:
Once the developer has resolved the issue, they change the status to “Fixed" (or "Closed"
depending on the workflow).

 This means the issue has been fixed and is now ready for retesting or verification by the QA
team
[Link]
Retesting

 After developers resolve the bugs, we retest the fixed issues to ensure that they have been
addressed correctly. This involves executing the relevant test cases to verify the functionality.

 Updating Status:
If the issues are working as expected and meet the criteria outlined in our test cases, we
change the bug status to “Fixed".

 Simultaneously, we update the status of the corresponding test case to "Pass".

[Link]
Regression
Testing

 Simultaneously, we perform regression testing on the affected module to verify that the recent
changes have not introduced any new issues.

 Monitoring for New Issues: During and after the bug fixing, we closely monitor the module for
any new issues that may arise as a result of the changes.

[Link]
Test Sign Off

After thorough functional and regression testing, we have verified that all
functionalities are working as per our test cases, and no critical issues were found. We
are providing our formal sign-off for the deployment team.

[Link]
Testing
Methodology

 Waterfall Testing Methodology


Testing happens after development is completed.
Sequential approach: Requirement → Design → Develop → Test → Deploy
Easy to manage, but not flexible for changes.
✅ Best for: Stable projects with clear requirements.

 Shift-Left Testing
Testing starts early in the development cycle (even at the design or requirements stage).
Focuses on preventing defects rather than detecting them late.
Unit & API testing start early
Continuous testing throughout

[Link]
Testing
Methodology

Ø Agile Testing Methodology


Testing is continuous and iterative.
Integrated into each sprint (Scrum, Kanban).
QA works closely with developers.
✅ Best for: Fast-moving, changing projects with frequent releases.

[Link]
Product Quality

 Dev team must do Unit testing.

 Without tester permission, new code cannot be deployed to the old branch. If any bug occurs, the
development and DevOps teams will be held responsible.

 Without tester sign-off, the code cannot be deployed to UAT or production.

 Adequate time is required for testing. If the code is given today for testing and is scheduled for production
tomorrow, a bug-free release cannot be ensured.

 The development team must take responsibility for bugs, but they are not owning up to them.

 The new branch code is deployed along with the old code once the development team confirms that the
major functionality is working correctly. The development team must perform basic testing.
[Link]
Thank you

[Link]

You might also like