Welcome To TestQSpider

It's Testing World.Lets Explore Your Life Here

When a bug is fixed by the development team than testing the other features of the applications which might be affected due to the bug fix is known as regression testing. 

Regression testing is always done to verify that modified code does not break the existing functionality of the application and works within the requirements of the system.

Regression Testing Example - Real and Practical 

Example of regression testing with its process is explained below:

For Example there are three Modules in the Project named Admin Module, Personal Information, and Employment Module and suppose bug occurs in the Admin Module like on Admin Module existing User is not able to login with valid login credentials so this is the bug. 

Now Testing team sends the above - mentioned Bug to the Development team to fix it and when development team fixes the Bug and hand over to Testing team than testing team checks that fixed bug does not affect the remaining functionality of the other modules (Admin, PI, Employment) and also the functionality of the same module (Admin) so this is known as the process of regression testing done by Software Testers.

What is Regression Testing with its Strategies?

Regression testing is achieved after the bug fixed, means testing the operation whether the fixed defect is affecting remaining functionality of the application or not. Usually in regression testing bug fixed module is tested. During regression testing tester always check the entire system whether the fixed bug make any adverse affect in the existing system or not.

There are mostly two strategies to regression testing, 1) to run all tests and 2) always run a subset of tests based on a test case prioritization technique.

When will we do Regression Testing?

Regression testing is the re-testing of features to make safe that features working earlier are still working fine as desired.

It is executed when any new build comes to QA, which has bug fixes in it or during releasing cycles (Alpha, Beta or GA) to originate always the endurance of product.

Conclusion:

Regression testing will be conducted after any bug fixed or any functionality changed.
Sanity Testing is the subset of Regression Testing and it is performed when we do not have enough time for doing testing.

Sanity testing is the surface level testing where QA engineer verifies that all the menus, functions, commands available in the product and project are working fine.

Sanity Testing Example

For Example in a project there are five modules like login page, home page, user detail page, new user creation, and task creation etc. So we have the bug in login page like on login page username field accepts the less than six alpha-numeric characters which are against the requirements as in requirements it is specified that username should not be below than six characters but as username accepts the less than six characters it is the bug.

So now the bug is reported by the testing team to the developer team to fix it. When the developing team fixes the bug and passed it to testing team than the testing team checks the other modules of the application means checks that fix bug does not affect the functionality of the other modules but keep one point always in mind that testing team only checks the extreme functionality of the modules, do not go deep to test the details because of the short time so this is the sanity testing.  

Sanity testing is performed after the build has clear the Smoke test and has been accepted by QA team for further testing, sanity testing checks the major functionality with finer details.

When we Perform Sanity Testing?


Sanity testing is performed when development team needs to know quick state of the product after they have done changes in the code or there is some controlled code change in a feature to fix any critical issue, and stringent release time-frame does not allow complete regression testing.

Conclusion:

Sanity testing will be done mostly after retest (retest will be done after fixing the bug). We always use Script for Smoke but do not for sanity.

Related Post

Complete Difference Between Sanity and Regression Testing

Smoke testing is the surface level testing to certify that build provided by development to QA is ready to accept for further testing. 

What is Smoke Testing?

Smoke testing is non-extensive software testing, which makes sure that the most crucial functions of a program work, but not bothering with finer details because in smoke testing we only checks the major functionality of the software.

Smoke testing is performed by developers before releasing the build to the testing team and after releasing the build to the testing team it is performed by testers whether to accept the build for further testing or not. 

Smoke Testing Example

For Example in a project there are five modules like login, view user, user detail page, new user creation, and task creation etc. So in this five modules first of all developer perform the smoke testing by executing all the major functionality of modules like user is able to login or not with valid login credentials and after login new user can created or not, and user that is created viewed or not. So it is obvious that this is the smoke testing always done by developing team before submitting (releasing) the build to the testing team.

Now once the build is released to the testing team than the testing team has to check whether to accept or reject the build by testing the major functionality of the build. So this is the smoke test done by testers.


Why Smoke Testing is known as Build Acceptance Testing?


Smoke testing is also known by the name BAT (Build Acceptance Test) because it establishes the acceptance criteria for QA to accept and reject a build for further testing. So apart from smoke testing it is also very important for software people to know about build. 


What is Build in Software Testing?

A build is called as the version of software, typically one that is still in testing stage.

Conclusion:
If the build clears the Smoke test, then it is accepted by QA for further testing, however if the build fails the Smoke test, then it's rejected and QA reverts back to previously accepted build.

Script is use for Smoke testing but does not for Sanity testing so do not get confused. 
Smoke Testing Example is always confused with Sanity Testing Example but in reality both the testing examples are different with each other. Here I am writing Smoke Testing Example in such a way that your confusion can definitely be removed by seen the example.
Now before us proceeding towards Smoke Testing Example it is very important for us to first take a warm look at Smoke Testing.


Smoke Testing � Brief Look

Smoke Testing is considered as the surface level testing which is always used to validate that build provided by development to QA team is ready to accept for further testing. In Smoke Testing we test the major point's means major functionality of the application and it is also known by the name Build Acceptance Testing (BAT).

Smoke Testing Example


Smoke Testing Example is given below which is totally based on Real Practical Scenario means which totally reflect your software testing process in a company environment.

For example we are working in a small project named Employee Management System and in this project there are four modules like New Employee Module, Existing Employee Module, Admin Module, User Module etc. So firstly in this four modules development team performs the Smoke Testing by executing all the major functionality of modules like New Employee is able to login or not and after login new employee can seen the record of the existing employee or not, and employee that is created can also be edited, deleted or not.

So in this way Smoke Testing is done by development team before releasing means submitting the build to the Software Testing team.

Now when the build is hand over means releasing to the testing team than the software testing team has to check whether to accept or reject the build by checking the major functionality of that build. So as you know we are taking the example Employee Management System, so our build is Employee Management System.

Now when the build (Employee Management System) is submitted means release to the testing team than the testing team has to check whether to accept the build (Employee Management System) or not by checking the major functionality of the build like employee is able to login or not and after login they can seen the existing employee record or not and after that logout easily or not. So this is the Smoke Testing done by Software Testers.

Keep in Mind

Please keep one thing in mind that firstly Smoke Testing is done by developer before releasing the build to the tester and when developers done the smoke testing than they releasing the build to the testing team and then testing team decide whether to accept the build or not for performing further testing by checking the major or you can say essential functionality of the build.

Conclusion

Smoke Testing Example is widely used and Smoke Testing is always done whenever we have to accept the build means before accepting the build we do smoke testing to check whether we accept the build or rejected (Refused).
Verification and Validation example is also given just below to this table. 

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

Example of verification and validation are explained below:-


Suppose we have the specifications related to the project than by checking that specifications without executing to see whether the specifications are up to the mark or not is what we have done in verification.

Similarly Validation of the software is done to make sure that the software always meets the requirements of the customer by executing the specifications of the project and product. 

Note that the customer and end users are concerned in validation of the software. 

It is also crucial to differentiate between end users, and customers. Considering example, if you are developing a library monitoring system, the librarian is the client and the person who issue the books, collect fines etc. are comes under the category of the end users.

Techniques or Methods of Verification and Validation


Methods of Verification

1. Walkthrough

2. Inspection
3. Review
Methods of Validation
1. Testing

2. End Users

Conclusion:

1) Verification and Validation both are necessary and complementary.
2) Both of them provides its own sets of Error Filters.
3) Each of them has its own way of detect out the errors left in the software.

Lots of people use verification and validation interchangeably but both have different meanings. 

Verification process describes whether the outputs are according to inputs or not, and 

Validation  process describes whether the software is accepted by the user or not.

Note:
If you remain have any problem regarding Difference between Verification and Validation than you can definitely discuss with me in comments section below. 
When individual software modules are merged and tested as a group than it is known as integration testing. Integration testing is sets between Unit Testing and System Testing.

Integration Testing Example

For example you have to test the keyboard of a computer than it is a unit testing but when you have to combine the keyboard and mouse of a computer together to see its working or not than it is the integration testing. So it is prerequisite that for performing integration testinga system must be unit tested before.

Black-box test case design tactics are the most typical during integration, although limited amount of testing of white box may be used to ensure description of major control paths. 

What is Integration Testing?

Integration testing is executed to establish whether the components interact with each other consort to the specification or not. Integration testing in large refers to joining all the components resulting in the complete system. It is further performed by the developer or the software Tester or by both. Example- checking that a Payroll system interacts as required with the Human Resource system.

Integration testing is always sub-divided as follows:

Types of Integration Testing

1) Top-Down Integration Testing: Top Down Integration as the term suggests, starts always at the top of the program hierarchy and travels towards its branches. This can be done in either depth-first or breadth-first.

2) Bottom-Up Integration Testing: Bottom - Up integration as it name implies starts at the lowest level in the program structure.

Some Techniques of integration testing: Techniques of integration testingcan be given below

1) Top-down testing approach
2) Bottom-up testing approach
3) Big-Bang testing approach
4) Sandwiched testing approach

Conclusion: At last we conclude that Integration testingfocuses on testing multiple modules working together.

Integration testing (sometimes called the Integration and Testing, abbreviated as I and T) is one of the extensive exercises of the software testing in which particular software modules are merged and tested as a group.