Q1
Difference between smoke and sanity testing

Smoke testing
It is the initial level of testing.
Once the code is deployed as a test engineer we do the smoke testing to make sure the application is stable to proceed with further testing or not.

Sanity testing
Sanity testing is a narrow regression test that verifies that specific functionality or bug fixes have been implemented correctly.
It checks if the reported bugs have been fixed and if no new issues have been introduced.

Difference between Verification and Validation

Verification:
Verification refers to the set of activities that ensure software correctly implements the specific function
It includes checking documents, designs, codes, and programs.
Verification is the static testing.
It does not include the execution of the code.
Methods used in verification are reviews, walkthroughs and inspections.

Validation:
Validation refers to the set of activities that ensure that the software that has been built is traceable to customer requirements.
It includes testing and validating the actual product.
Validation is dynamic testing.
It includes the execution of the code.
Methods used in validation are Black Box Testing, White Box Testing and non-functional testing.

Q2 Agile

Agile:
Agile Methodology is a set of principles and practices for managing and delivering software development projects in a flexible, iterative, and collaborative manner. It emphasizes adaptive planning, evolutionary development, early delivery, and continuous improvement, all in response to changing requirements and feedback from stakeholders.

Scrum
It is a procedure, to develop followed or Process to build the product in agile
There are few key terminologies in Scrum are

1)Product Backlog:
Product backlog in Scrum is a prioritized features list, containing short descriptions of all functionality desired in the product. When applying Scrum, it's not necessary to start a project with a lengthy, upfront effort to document all requirements.

2)Scrum Team
They will have core team members and shared resources

Generally core team members are
-> Scrum master
-> Developers
-> Test engineers

Shared resources are
->BA(optional)
->Architect
->Product owner

3)Sprint Backlog
->It contains list of story card You ore that you are Planning to build or implement the current Sprint
->We will choose those many stories which is Possible for us to develop within a Sprint
->We will take those features which completes one business cycle of customer So that when we release it to production customer should be able to use it for the business.

4)Daily Stand up Meeting:
Here each team members discuss what they have done today and what they are going to do tomorrow.
If there are any queries it will be discussed in the meet after

5)Burn down chart
It is graphical representation of time left vs time taken.

Advantage:
If we get to know product development might take time then we can get to know in the early stage itself also we can track each & every employee.

6)Story Board:

It consists of all stories which we have taken in the current sprint and we can see the status of each story with status like is it under analysis or under development etc.
If there is any issue and the story is blocked those information will also be available here
By doing this we can easily identify stories which are completed and which are yet to be completed

7)Retrospect Meeting:
Once after completing the sprint we will discuss what went good and what can be done better here.
If any team member did exceptional performance during that sprint will be appreciated.
At the end of meeting the scrum master will document what happened during the call and share the document to the clients
8)Epic and User stories(Explained in detail in the next question)

Benefits of Agile Methodology:

Agile allows teams to respond to changes in requirements and priorities quickly.
Regular feedback and communication ensure stakeholders are informed throughout the project.
Continuous testing and integration practices lead to higher-quality software.
Early and frequent delivery of working software ensures alignment with customer expectations.
Early detection and correction of defects minimize rework and associated costs.

In summary, Agile Methodology is a transformative approach to software development, emphasizing adaptability, collaboration, and iterative progress. Its principles and practices enable teams to deliver valuable software efficiently while responding effectively to changing requirements and stakeholder feedback.

Q3 Epic and User story

In Agile development, "Epic" and "User Story" are terms used to describe different levels of requirements that help organize and prioritize work. Here’s a detailed explanation of each:

Epic:

An Epic is a large body of work that can be broken down into smaller tasks (user stories). Epics are generally too big to be completed in a single iteration or sprint, so they are usually split into multiple smaller user stories before work begins. They serve as placeholders for a collection of related user stories that share a common objective or theme.

Key characteristics of an Epic:
->Large Scope: Epics typically represent significant features or components of the software.
->Long-Term Goals: They often span multiple iterations or sprints.
->High-Level Description: Epics are usually described in broad strokes, capturing the overall goal or business objective.
->Subject to Refinement:As the project progresses, epics are refined into more detailed user stories that are smaller and more manageable.

User Story:
A User Story is a small, self contained unit of work that describes a specific piece of functionality from an end user's perspective. Each user story represents a small feature or part of a larger epic and is written in a simple, structured format. User stories help Agile teams understand the work that needs to be done and ensure that the software is developed with the end user in mind.

Components of a User Story often written in the format

1. Role: Specifies the user or stakeholder who will benefit from the feature.
2. Goal: Describes what the user wants to accomplish or what functionality is needed.
3. Reason: Explains the purpose or benefit of the feature from the user's perspective.

Key characteristics of User Stories:

Small and Specific: User stories are granular and focus on delivering small pieces of value.
Independent: Each user story can be developed and tested independently of others.

Negotiable: Details can be clarified and adjusted through collaboration between developers, product owners, and stakeholders.
Valuable to Users: User stories prioritize delivering value to the end user.
Estimable: Teams can estimate the effort required to complete each user story.

Relationship Between Epics and User Stories:

Epics are higher-level entities that encapsulate multiple related user stories.
Epics are decomposed into smaller, more manageable user stories that can be prioritized and completed within a single iteration.
As user stories are completed, the Epic's progress is tracked based on the completion of its constituent user stories.

In summary, Epics and User Stories are integral parts of Agile project management, with Epics representing larger features or components that are broken down into smaller, actionable pieces described by User Stories. This approach helps Agile teams manage complexity, prioritize work, and deliver value incrementally to stakeholders.