AGILE METHODOLOGIES

Q1) Describe the differences in between

SMOKE AND SANITY TESTING

Smoke testing and sanity testing are two types of software testing that serve distinct purposes in the software development life cycle. Both are executed early in the testing process to quickly assess the stability of the application and determine whether further, more detailed testing is feasible. Here are the key differences between smoke testing and sanity testing

1. Purpose: Smoke Testing:

Purpose: The primary purpose of smoke testing is to check if the build is stable enough for more comprehensive testing. It aims to identify major issues that would prevent further testing.
Scope: Broad and shallow. It covers the most critical functionalities of the application.
Outcome: A successful smoke test indicates that the software is suitable for more in-depth testing.
Sanity Testing:

Purpose: Sanity testing focuses on specific functionalities or areas of the application to ensure that recent changes or fixes have not adversely affected those areas.
Scope: Narrow and deep. It verifies specific functionalities or features affected by recent changes.
Outcome: A successful sanity test indicates that the specific functionalities or areas under consideration are working as intended.

1. Timing: Smoke Testing:

Timing: Conducted on a new build or release before more extensive testing. It is an initial check to determine the basic stability of the build.
Sanity Testing:

Timing: Performed after smoke testing and after specific changes or fixes have been made to the application. It verifies that the recent changes did not introduce new issues.

1. Coverage: Smoke Testing:

Coverage: Covers the essential functionalities and major components of the application.
Sanity Testing:

Coverage: Focuses on specific areas or functionalities that are relevant to recent changes. It does not cover the entire application.

1. Depth of Testing: Smoke Testing:

Depth: Shallow testing. It aims to identify showstopper defects quickly without going into detailed testing of individual features.
Sanity Testing:

Depth: Deeper testing than smoke testing. It verifies specific functionalities in more detail to ensure that recent changes have not adversely affected them.

1. Execution Frequency: Smoke Testing:

Frequency: Executed for every new build or release.
Sanity Testing:

Frequency: Executed after specific changes or fixes, not necessarily for every build.

1. Criteria for Success: Smoke Testing:

Criteria for Success: The build is considered successful if it passes the smoke test, indicating that it is stable and suitable for further testing.
Sanity Testing:

Criteria for Success: The sanity test is considered successful if the specific functionalities or areas under consideration pass the test. It verifies that recent changes have not introduced new issues in those specific areas.

1. Scope of Testing: Smoke Testing:

Scope: Wide. Covers the entire application at a basic level.
Sanity Testing:

Scope: Narrow. Focuses on specific functionalities or areas affected by recent changes.
VALIDATION AND VERIFICATION

1. Definition: Verification:

Definition: The process of evaluating a system or component during or at the end of the development process to determine whether it satisfies the specified requirements. It involves checking that the product is being built right.
Validation:

Definition: The process of evaluating a system or component during or at the end of the development process to determine whether it satisfies the user’s needs and expectations. It involves checking that the right product is being built.

1. Focus: Verification:

Focus: Focuses on the design and implementation phase, ensuring that the software is developed according to the design specifications.
Validation:

Focus: Focuses on the testing phase, ensuring that the end product meets the user’s requirements and expectations.

1. Objective: Verification:

Objective: To ensure that the product is built correctly and adheres to the specified design and requirements.
Validation:

Objective: To ensure that the final product meets the intended use and satisfies user needs and expectations.

1. Timing: Verification:

Timing: Performed during the development phase, often before the testing phase.
Validation:

Timing: Performed during the testing phase, after the development phase.

1. Activities: Verification:

Activities: Involves activities such as reviews, inspections, walkthroughs, and other static testing methods to check the documentation, code, and design.
Validation:

Activities: Involves dynamic testing activities such as functional testing, system testing, integration testing, and user acceptance testing to ensure that the software behaves as expected.

1. Outcome: Verification:

Outcome: The outcome of verification is a product that adheres to the specified requirements and design.
Validation:

Outcome: The outcome of validation is a product that meets the user’s needs and expectations.

1. Example: Verification:

Example: Checking that the software architecture and design comply with the requirements specified in the design documents.
Validation:

Example: Executing test cases to verify that the software functions as expected and meets user requirements.

1. Responsibility: Verification:

Responsibility: Typically the responsibility of the development team and involves activities carried out by developers.
Validation:

Responsibility: Typically the responsibility of the testing team and involves activities carried out during testing.

1. Question Addressed: Verification:

Question Addressed: “Are we building the product right?”
Validation:

Question Addressed: “Are we building the right product?”

1. Documentation: Verification:

Documentation: Involves checking the design documents, requirements specifications, and code for adherence to standards and specifications.
Validation:

Documentation: Involves checking user manuals, acceptance criteria, and user requirements to ensure that the software meets user expectations.

1. EXPLAIN ABOUT AGILE METHODOLOGY Agile Manifesto Values: Individuals and Interactions over Processes and Tools:

Emphasizes the importance of communication and collaboration among team members.
Working Software over Comprehensive Documentation:

Prioritizes delivering a working product over extensive documentation. While documentation is important, the focus is on delivering value through functional software.
Customer Collaboration over Contract Negotiation:

Encourages active involvement of customers throughout the development process, seeking collaboration over strict contractual agreements.
Responding to Change over Following a Plan:

Acknowledges that requirements may change, and the team should be adaptable and responsive to those changes rather than strictly following a predetermined plan.
Agile Principles:
Satisfy the Customer Through Early and Continuous Delivery of Valuable Software:

Prioritize delivering valuable features to the customer in small, incremental releases.
Welcome Changing Requirements, Even Late in Development:

Be open to adapting to changing customer needs and requirements, even if changes occur late in the development process.
Deliver Working Software Frequently, with a Preference for the Shortest Timescale:

Aim for regular, small releases to provide the customer with working software and receive feedback more frequently.
Collaborate with Customers Throughout the Development Process:

Involve customers in planning, reviewing, and providing feedback throughout the development lifecycle.
Build Projects Around Motivated Individuals. Give Them the Environment and Support They Need and Trust Them to Get the Job Done:

Empower and trust the team members to make decisions and take ownership of their work.
Use Face-to-Face Communication Where Possible:

Prioritize direct communication to enhance understanding and collaboration within the team.
Working Software Is the Primary Measure of Progress:

The primary metric for progress is the delivery of working, tested software.
Maintain a Sustainable Pace of Work for the Team:

Avoid overloading the team with excessive work, aiming for a sustainable pace to ensure long-term productivity.
Continuous Attention to Technical Excellence and Good Design Enhances Agility:

Prioritize high-quality code and design practices to maintain agility and support evolving requirements.
Simplicity — the Art of Maximizing the Amount of Work Not Done — is Essential:

Embrace simplicity in design and implementation to minimize unnecessary complexity.
Self-Organizing Teams Encourage Great Architectures, Requirements, and Designs:

Allow teams to self-organize, fostering creativity and innovation in solving problems.
Regular Reflection on How to Become More Effective, Then Tune and Adjust Behavior Accordingly:

Encourage regular retrospectives to reflect on the team’s processes and performance, making continuous improvements.
Agile Methodologies:
There are several Agile methodologies, each providing a specific framework for implementing Agile principles. Some common Agile frameworks include:

Scrum:

Organizes work in fixed-length iterations called sprints, with a set of predefined roles, ceremonies, and artifacts.
Kanban:

Visualizes work on a Kanban board, emphasizing continuous delivery and a pull-based system with a focus on limiting work in progress.
Extreme Programming (XP):

Emphasizes coding practices, continuous integration, and frequent releases. It includes practices like pair programming and test-driven development (TDD).
Feature-Driven Development (FDD):

Organizes development around features, emphasizing domain object modeling and regular builds.
Dynamic Systems Development Method (DSDM):

Provides a framework for Agile project delivery and is aligned with the principles and practices of the Agile Manifesto.

1. EXPLAIN ABOUT EPIC AND USER STORIES Epic: An Epic is a large body of work that can be broken down into smaller tasks or components. Epics are often used to represent significant features or functionalities that cannot be completed in a single iteration or sprint. They provide a high-level view of the work that needs to be done and help in planning and prioritization.

Key Characteristics of Epics:
Size and Scope:

Epics are larger in size and scope compared to User Stories. They often represent a broad set of functionalities or a feature that may span multiple sprints.
Timeframe:

Epics are typically worked on over an extended period, and they may require multiple iterations to complete.
User Value:

Epics may not directly deliver value to end-users on their own. Instead, they represent a collection of work that, when completed, contributes to delivering value.
Dependencies:

Epics may have dependencies on other Epics or User Stories. Dependencies need to be managed to ensure smooth execution.
Breakdown:

Epics are broken down into smaller, more manageable User Stories during backlog refinement or sprint planning.
User Story:
A User Story is a small, independent piece of functionality that delivers value to the end-user. User Stories are used to represent specific features or requirements from the user’s perspective. They are written in a user-centric language and follow a specific template: “As a [type of user], I want [an action] so that [benefit/value].”

Key Characteristics of User Stories:
Size and Scope:

User Stories are smaller in size and scope compared to Epics. They are designed to be completed within a single iteration or sprint.
Timeframe:

User Stories are typically completed within a short timeframe, usually within one sprint.
User Value:

User Stories are designed to directly deliver value to end-users. Each User Story represents a specific piece of functionality that contributes to the overall product.
Independence:

User Stories are independent units of work, meaning they can be developed and delivered without relying on other stories. This allows for flexibility in prioritization.
Acceptance Criteria:

User Stories include acceptance criteria that define the conditions that must be met for the story to be considered complete.
Relationship Between Epics and User Stories:
Hierarchy:

Epics and User Stories have a hierarchical relationship. An Epic can be broken down into multiple User Stories.
Planning:

During release planning or sprint planning, Epics are often discussed, and high-priority User Stories are selected for the upcoming iteration.
Progress Tracking:

Progress on Epics can be tracked by monitoring the completion of associated User Stories. As User Stories are completed, progress is made toward completing the Epic.
Backlog Management:

Epics and User Stories are managed within the product backlog. Epics are ranked alongside User Stories, and both are prioritized based on their importance to the product.