# Agile Methodology

**Q1.Describe the difference between:**

1.Smoke & sanity Testing

| Smoke Testing | Sanity Testing |
| --- | --- |
| A smoke test is a type of software test that verifies that the most important functions of a program work. | Sanity testing checks whether a software product works when a new module |
| It is known as Build verification testing where the build is verified by testing the important features of the application | his testing is a software testing technique that evaluates the quality of the software release to determine whether it is eligible for further rounds of testing. |
| Smoke tests are typically a subset of the full product test suite and involve basic functionality tests. | Sanity testing is the subset of regression testing, |
| QA will do the smoke testing | QA team done this activity |
| Help to identify major issues quickly | Focusing on specific areas |
| Smoke testing often uses a limited set of test cases. | Not documented, Since this testing has a relaxed plan, it might not be as thorough as other types of testing. |
|  |  |

2.Verification & Validation:

| Verification | validation |
| --- | --- |
| Verification means checking the documents, languages, designs, and other programming things. | Validation means testing the actual product. |
| Verification does not involve the execution of the code. | Validation involves the execution. |
| It is considered static testing. | It is considered dynamic testing. |
| It includes checking documents delivered by humans. | It includes the execution of a program executed by a computer. |

**Q2.Explain about agile Methodology?**

 Agile:

Agile Testing is a fast and informal testing process. In simple terms, we can say that it is specified as an advanced and **dynamic type of Testing** that is performed regularly throughout every iteration of the **SDLC (Software Development Life Cycle)** by the agile test engineers.

Agile principals:

**Constant response**

**Less documentation**

**Continuous Testing**

**Customer Satisfaction**

**Easy and clean code**

**Involvement of the entire team**

**Test-Driven**

**Quick feedback**

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1715267469652/e9b2e6bf-6202-4047-b869-314a7ea8c307.png align="center")

Client input is required throughout the product development

Changes can be made at any stage.   

It is really useful in large and complex projects.

The cost of development is less.

**Q3.Explain about Epic and User story:**

Epic:

 A epic is a large body of work that can be broken down into several smaller stories, or tasks. It is essentially a large user story that encompasses many features and various stakeholder.

Generally, an epic describes the end goal of a project; it often involves multiple scrum team (such as product management, engineering, UX/UI design) working together to accomplish the goal.

The epic typically represents a theme that is larger than a single story and often includes several related stories or tasks. Epics are commonly used for larger initiatives, such as launching a new product or feature.

User stories:

User story is a simple, yet powerful tool used in Agile development. It is a brief description of a feature or functionality that the end user will benefit from. User stories are written by the Product owner and often include details such as who the user is, what they want to do and why they need it.

As such, user stories provide clarity and context to the development team. They help teams to better understand the purpose of their work, focus on delivering value efficiently, and facilitate better collaboration between team members and stakeholders.

An example of an Agile user story might be "As a customer, I want to be able to purchase products online." This helps the team understand what is required for them to deliver value in the form of an online shopping experience.