Agile Methodlogy

Difference between Sanity and Smoke Testing:

Particulars	Smoke testing	Sanity testing
Purpose	Smoke testing is performed to ascertain that the acute functionalities of the program are operating properly.	Sanity testing is done to check that bugs have been fixed after the build.
Documentation	Smoke testing can be documented and scripted.	Sanity testing can’t be documented and is unscripted.
Basis of testing	The major goal of this testing is to ensure that the newly generated build is stable enough to withstand further rigorous testing.	The major goal of this testing is to determine the system’s rationality and correctness to ensure that the proposed functionality performs as intended.
Executed by	It is done by both developers and testers.	It is done by testers.
Subset	It is a subset of acceptance testing.	It is a subset of regression testing.
Performed on	Smoke Testing is first performed on the initial build.	Sanity Testing is performed on stable build or for the new features in the software
Coverage	Covers end-to-end basic functionalities of the system.	Covers specific modules, in which code changes have been made

Differences between Verification and Validation

Particulars	Verification	Validation
Definition	Verification refers to the set of activities that ensure software correctly implements the specific function	Validation refers to the set of activities that ensure that the software that has been built is traceable to customer requirements.
Focus	It includes checking documents, designs, codes, and programs.	It includes testing and validating the actual product.
Type of Testing	Verification is the static testing.	Validation is dynamic testing.
Execution	It does not include the execution of the code.	It includes the execution of the code.
Methods Used	Methods used in verification are reviews, walkthroughs, inspections and desk-checking.	Methods used in validation are Black Box Testing, White Box Testing and non-functional testing.
Purpose	It checks whether the software conforms to specifications or not.	It checks whether the software meets the requirements and expectations of a customer or not.
Bug	It can find the bugs in the early stage of the development.	It can only find the bugs that could not be found by the verification process.
Goal	The goal of verification is application and software architecture and specification.	The goal of validation is an actual product.
Responsibility	Quality assurance team does verification.	Validation is executed on software code with the help of testing team.
Timing	It comes before validation.	It comes after verification.
Human or Computer	It consists of checking of documents/files and is performed by human.	It consists of execution of program and is performed by computer.
Lifecycle	After a valid and complete specification the verification starts.	Validation begins as soon as project starts.
Error Focus	Verification is for prevention of errors.	Validation is for detection of errors.
Another Terminology	Verification is also termed as white box testing or static testing as work product goes through reviews.	Validation can be termed as black box testing or dynamic testing as work product is executed.
Performance	Verification finds about 50 to 60% of the defects.	Validation finds about 20 to 30% of the defects.
Stability	Verification is based on the opinion of reviewer and may change from person to person.	Validation is based on the fact and is often stable.

Agile methodlogy:

Agile testing is a software testing practice that follows the Agile software development methodology. In Agile development, projects tend to evolve during each sprint among collaborators and shareholders. Agile testing focuses on ensuring quality throughout the Agile software development process.

Epic:

An agile epic is a body of work that can be broken down into specific tasks (called user stories) based on the needs/requests of customers or end-users.

User stories:

User story testing is a brief, concise explanation of a product or capability from the end user's perspective. In an Agile process, a user story is a small workflow unit. It allows the development team to understand the user's wants and needs and ensures that the program fits those demands.