Task 4

Q.NO:1 Smoke & Sanity testing
1. Sanity Vs Smoke Testing
Sanity Testing
1. Sanity testing is used to verify the newly added functionalities/ bugs etc are working fine.
2. - This testing is done when the build is relatively stable.
3. - Sanity testing is usually performed by testers.
4. - Sanity testing is called a subset of regression testing.
5. - Sanity testing is done after the completion of regression testing.
6. - Sanity testing is used in the case of only updated or detected functions of the application.
7. - Sanity testing is always stable.
8. - Sanity Testing's main goal is to verify "rationality".
Smoke Testing
1. - Smoke Testing is used to perform to ensure that the critical functionalities of the application are working fine.
2. - This testing is done at the initial level.
3. Smoke testing is performed by the developers or testers.
4. - Smoke testing is called a subset of acceptance testing.
5. Smoke testing is done on every build.
6. Smoke testing is used to test all over the functionality of the application.

Smoke testing is may be stable/unstable_
Smoke Testing's main goal is to verify "stability".
1. Validation & Verification Verification
  1. Verification is a static practice of verifying documents, design, code and program.
  2. It does not involve executing the code.
  3. It is human based checking of documents and files.
  4. Verification uses methods like Inspections, reviews, walkthroughs, and Desk-checking etc.
  5. Verification is to check whether the software conforms to specifications.
  6. It can catch errors that validation cannot catch. It is low level exercise.
  7. Target is requirements specification, application and software architecture, high level, complete design, and database design etc.
2. Verification is done by QA team to ensure that the software is as per the specifications in the SRS document.
3. It generally comes first-done before validation. Validation
4. Validation is a dynamic mechanism of validating and testing the actual product.
5. It always involves executing the code.
6. It is computer based execution of program.
7. Validation uses methods like black box (functional) testing, gray box testing, and white box (structural) testing etc.
8. Validation is to check whether software meets the customer expectations and requirements.
9. It can catch errors that verification cannot catch. It is High Level Exercise.
10. Target is actual product-a unit, a module, a bent of integrated modules, and effective final product.
11. Validation is carried out with the involvement of testing team.
12. It generally follows after verification.

Q,NO:2 Explain about Agile Methodology.
Agile methodology is an iterative and incremental approach to software development and project management. It emphasizes flexibility, collaboration, customer satisfaction, and continuous improvement. Here are the key principles and characteristics of Agile:
Iterative Development:Agile projects are broken down into small increments or iterations, typically lasting from one to four weeks. Each iteration results in a potentially shippable product increment.
Customer Collaboration:Agile teams work closely with customers or stakeholders throughout the development process to ensure that the product meets their needs and expectations. Feedback is solicited and incorporated regularly.
Incremental Delivery:Instead of delivering the entire product at once, Agile teams deliver it incrementally, with each iteration adding new features or improvements. This allows for early and continuous delivery of value to the customer.
Flexible and Adaptive:Agile embraces change and welcomes requirements that evolve over time. It encourages teams to respond to changes in customer needs, market conditions, or project requirements quickly and effectively.
Self-organizing Teams:Agile teams are typically small, cross-functional, and self-organizing. Team members collaborate closely and have the autonomy to make decisions about how to achieve their goals.
Continuous Feedback:Agile methodologies emphasize regular feedback loops, both within the team and from stakeholders. This feedback helps identify areas for improvement and ensures that the product meets customer expectations.
Emphasis on Individuals and Interactions:Agile values individuals and interactions over processes and tools. Effective communication and collaboration among team members are prioritized to achieve project success.
Emphasis on Working Software:Agile focuses on delivering working software early and frequently. This allows teams to validate assumptions, gather feedback, and make necessary adjustments throughout the development process.
Emphasis on Technical Excellence:Agile promotes technical practices such as test-driven development, continuous integration, and refactoring to ensure the quality and maintainability of the codebase.
Regular Reflection and Adaptation:Agile teams regularly reflect on their processes and outcomes to identify areas for improvement. They adapt their practices accordingly to optimize productivity and deliver better results.

Q.NO:3 Explain about Epic and User Stories
Epic
An epic is a large body of work that can be broken down into smaller tasks or stories. It usually encompasses a broad and high-level initiative that may take weeks, months, or even years to complete. Epics often represent a significant business or project goal and are too big to be completed in a single iteration or sprint.
For example if you're developing a software application, an epic could be something like "Implementing a user authentication system" or "Adding a new feature such as chat functionality." These epics can then be further divided into smaller, more manageable units called user stories.
User Stories
User stories are short, simple descriptions of a feature told from the perspective of the person who desires the new capability, usually a user or customer. They typically follow a specific template: "As a [type of user], I want [some goal] so that [some reason]". User stories are used in agile software development methodologies like Scrum to capture functional requirements from an end-user perspective.
For instance, a user story for the epic "Implementing a user authentication system" could be:
As a registered user, I want to be able to reset my password if I forget it, so that I can regain access to my account.
User stories are often written on index cards or digitally in project management tools and serve as a lightweight means of conveying requirements and driving development. They are small enough to be completed within a single iteration or sprint, making them ideal for agile development practices.