KEMBAR78
B Testing Process | PDF | Software Testing | Scrum (Software Development)
0% found this document useful (0 votes)
16 views6 pages

B Testing Process

The document outlines best practices for bug documentation and reporting, detailing the bug lifecycle, SDLC and STLC stages, and the testing approach for features and acceptance criteria. It also explains the Agile methodology, including the roles of Product and Sprint Backlogs, and provides a comprehensive overview of the release process from preparation to post-release support. Key elements such as test plans, sprint planning, and communication strategies are highlighted to ensure effective software development and testing.

Uploaded by

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

B Testing Process

The document outlines best practices for bug documentation and reporting, detailing the bug lifecycle, SDLC and STLC stages, and the testing approach for features and acceptance criteria. It also explains the Agile methodology, including the roles of Product and Sprint Backlogs, and provides a comprehensive overview of the release process from preparation to post-release support. Key elements such as test plans, sprint planning, and communication strategies are highlighted to ensure effective software development and testing.

Uploaded by

rajat.kumar
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 6

Q.

Bug Documentation and Reporting

1. Detailed Bug Reports: Create clear bug reports in Jira, including


screenshots, console logs, and API response details, to better
understanding.
2. Reproduction Steps: Provide clear, step-by-step instructions for
reproducing the bug, along with severity and priority, to ensure
developers could easily understand and fix issues.
3. Shared important API information, like endpoint URLs, response
data, and error messages, to support backend developers for
fixing issues quickly.

Q. If a bug is missed in production and identified by the client


 When a client finds a bug, I confirm it, reassure them it's being
handled, gather issue details, and inform my team.
 I try to recreate the bug in our test environment using the same
conditions as in production. I carefully document all steps, settings,
and results to understand exactly what went wrong.
 I check logs and code to find the root cause and see if the issue
was missed due to a testing gap or environment difference.
 Once we find the cause, my team fix the bug, test it thoroughly,
and then deploy it to production.
 To prevent similar issues, I update our test cases, add automation
if possible, and ensure the test environment matches production
closely.
 Finally, we hold a review to discuss improvements and avoid
similar bugs in future builds.

What is SDLC & STLC, explain the stages involved.


SDLC (Software Development Life Cycle) and STLC (Software Testing Life Cycle) are
processes that guide the development and testing of software, ensuring quality and meeting
requirements.
SDLC Stages:
 Requirement Gathering: Collect and analyses requirements from stakeholders.
 Design: Plan the system architecture and design.
 Development: Write and implement code to build the software.
 Testing: Test the software to ensure it meets requirements and is bug-free.
 Deployment: Release the software for end-user use.
 Maintenance: Provide updates, fix issues, and improve functionality over time.
STLC Stages:
 Requirement Analysis: Understand the testing requirements and scope.
 Test Planning: Define the testing strategy, schedule, and resources.
 Test Case Development: Create test cases and prepare test data.
 Environment Setup: Set up testing environments.
 Test Execution: Run test cases and log defects if any are found.
 Test Closure: Evaluate test results, report metrics, and document learnings for
future projects.

Explain Bug Lifecycle

The Bug Lifecycle is the process a bug goes through from identification to resolution.

1. New: When a bug is first reported, it is assigned the "New" status.


2. Assigned: The bug is reviewed and assigned to a developer for fixing.
3. Open: The developer starts working on the bug.
4. Fixed: The developer has fixed the bug and marks it as "Fixed."
5. Retest: The tester verifies if the bug fix works as expected.
6. Verified: If the fix works correctly, the bug is marked as "Verified."
7. Closed: If the bug no longer exists after testing, it is marked as "Closed."
8. Reopened: If the bug persists, it is reopened and goes through the cycle again.

What is Test plan ?

A Test Plan is a detailed document that outlines the testing strategy, objectives, resources,
schedule, and scope for a project. It serves as a guide to ensure that all aspects of testing are
covered and that the team has a clear understanding of how testing will be conducted.

Key Elements of a Test Plan:

1. Test Objectives: Defines what the testing aims to achieve.


2. Scope: Specifies what features will and won’t be tested.
3. Test Strategy: Describes the testing approach and types of testing to be used (e.g.,
functional, regression).
4. Resource Allocation: Identifies team members, tools, and environments required.
5. Schedule: Outlines timelines and deadlines for each phase of testing.
6. Entry and Exit Criteria: Sets conditions for when testing should start and end.
7. Risk and Mitigation: Lists potential risks and the plans to address them.

Q. Benefits of Agile:
 Adapts quickly to changing requirements and market needs.

 Delivers working software in small, frequent increments.

 Encourage teamwork through regular communication and cross-functional


collaboration.

 Continuous testing and feedback catch issues early, ensuring higher-quality products.

 Involves customers regularly to align the product with their needs.

 Improves visibility for stakeholders through open communication on progress and


challenges.

 Identifies and addresses risks early in the development process.


 Focuses on delivering features that provide the most value to customers.
Sprint Planning Process (Simplified)
A sprint is a short, fixed period (usually 1–2 weeks) where a team works on specific tasks to
deliver a usable part of the product. The goal is to create something valuable and ready for
feedback.

Key Features of a Sprint:

1. Fixed Timeframe: duration of time, typically 2 weeks.


2. Sprint Planning: At the beginning, the team decides what tasks to work on based on
priorities and team capacity.
3. Sprint Backlog: A list of tasks and user stories chosen for the sprint.
4. Daily Standup: A quick daily meeting to discuss progress, blockers, and plans for
the day.
5. Deliverable (Increment): By the end of the sprint, the team delivers a working
product piece that meets all requirements.
6. Sprint Review: The team shows their completed work to stakeholders for feedback.
7. Sprint Retrospective: The team reflects on the sprint to find ways to improve for the
next one.

Benefits of Sprints:

 Better Planning: Fixed timelines help with scheduling and progress tracking.
 Focused Work: Teams focus on a manageable set of tasks.
 Adaptability: Any new priorities or changes are handled in the next sprint.
 Faster Delivery: Frequent delivery of working product pieces keeps stakeholders
satisfied.

Sprints allow teams to deliver value consistently while improving how they work.

Q. If a feature is given to you, what will be your testing approach?

1. Understand the feature requirements and acceptance criteria.


2. Identify the test scenarios (positive and negative cases).
3. Prepare test cases covering all scenarios.
4. Execute tests manually or automate them if applicable.
5. Log defects (if found) in a tool like Jira and retest after fixes.
6. Perform regression testing to ensure existing features are unaffected.

Q. There are multiple acceptance criteria; what will be your testing


approach?

 Break down each acceptance criteria into test scenarios.


 Write and prioritize test cases for each scenario.
 Ensure all criteria are covered in functional, boundary, and edge cases.
 Test step by step to validate all the criteria independently and together.
Q. In Agile methodology, both the Product Backlog and Sprint Backlog

Product Backlog:

 A list of all tasks, features, bug fixes, and improvements needed for the product.
 Managed by the Product Owner, who prioritizes items based on business needs,
customer feedback, and market demands.
 Contains broader tasks (User Stories) that may span multiple Sprints.
 Continuously updated as new tasks are identified and work is completed.
 Focuses on long-term product goals.

Sprint Backlog:

 A subset of the Product Backlog chosen for a specific Sprint (usually 2-4 weeks).
 Created by the Development Team during Sprint Planning by breaking down items
into smaller, actionable tasks.
 Focuses on short-term goals and acts as a detailed plan for the Sprint.
 Guides the team on what needs to be completed within the Sprint timeframe.

Q. URL resulted in a blank page

I want to understand whether the issue is on the front end or an API


problem on the back end.

 Verified the URL to make sure it was correct.


 Clear my browser cache and cookies in case they were affecting
the page load.
 Tried accessing the page on different browsers to check any
browser-specific issues.
 Check the Console tab, to see if there were any JavaScript errors
or warnings that could explain why the page wasn’t loading
correctly.
 In the Network tab I looked at the API calls made by the page, to
check if any requests were failing, which could be the reason for
the blank page.
 Check any requests returning 404, 500.

Verifying the API Response

 I will check the failing API calls using Postman.


 There I can see the raw response and identify if there was an
issue with the data being returned, such as missing fields, errors in
the response, or authentication issues.
 I could check if the API returned empty data that might lead to a
blank page on the front end.
Q. Release Process Overview:

Preparation and Planning


 Identify and document the features, bug fixes, and enhancements
to set clear expectations for the release.
 Outline the timeline, allocate resources, and communicate roles
and responsibilities to the team to ensure a smooth release
process.
 Ensure all requirements are clearly understood and documented
to avoid confusion during the release.
Code Freeze and Final Testing
 Freeze the codebase to prevent new features from being added,
allowing only critical bug fixes.
 Perform regression testing, performance testing, and User
Acceptance Testing (UAT) to ensure the product meets
requirements.
Build the Release
 Generate the release build (e.g., WAR, JAR, Docker image).
 Tag the final version in the version control system (like Git or
Bitbucket) for easy tracking and reference.
Deploy to Pre-Production
 Deploy to a pre-production environment that mirrors production to
validate the release.
 Run smoke tests in pre-production to catch any critical issues
early.
Release to Production
 Create backups of the production environment (databases,
configurations) to ensure we can roll back if needed.
 Deploy the release to production using a CI/CD pipeline to
minimize errors.
 Continuously monitor performance, crashes, or errors post-
deployment.
Post-Release Testing
 Run quick tests in the production environment to ensure
everything is functioning as expected.
 Track system performance and logs to detect any issues early.
Communication and Documentation
 Inform internal teams, clients, and users about the release,
including new features, bug fixes, and known issues.
 Update release notes, API documentation, and deployment
guides to keep everything current.
Feedback and Monitoring
 Gather feedback from end-users to identify areas for
improvement.
 Use tools like Jira to track bugs and prioritize fixes for future
releases or hotfixes.
Post-Release Support
 Hotfixes: Implement hotfixes for critical issues and deploy them
quickly.
 Continue to monitor the system to maintain stability and address
any emerging issues.

You might also like