Confusing testing techniques

Type of Testing in software

There are a plenty of testing techniques ranging from ad hoc monkey testing to moral formal unit testing. White box testing, black box testing, Grey box testing and so on so forth. Being under graduate in software engineering or fresher in software industry, you may always confuse between one testing and other. So let’s explore some of the most confusing and interrelated terms used in testing terminology;

Sanity testing and smoke testing

Sanity testing is a testing technique in which you take a specialized functionality of the whole system and travel deep into that and try to find out if that functionality is working correctly in every aspect. Actually, it follows the depth-first approach.
Smoke testing is a testing technique in which you just check broadly whether the system in question worth testing. The scope of the test is the whole system and follows the breadth-first approach.

Smoke testing is generally used in hardware testing if a hardware component produces smoke as soon as it is put in a test that means that the component is not yet ready for testing and require more time. The same principle is applied to software too.

Regression testing and Retesting

When you fix a bug in code and you want to be sure that this fixing has not affected any other part of the program you re run all existing test case again. This is called regression testing.
Retesting is a process in which we write different or more test cases for the same functionality in order to test it completely and satisfactorily after there has been testing with the existing test case.

Load testing and stress testing

When you test a system for its robustness, giving inputs within the allowed range this is called load testing. For example if an application has to support 500 users, load testing will be done with simulating 500 users and noting the performance degradation of the application.
When you test a system for its robustness, giving inputs which are out of bound or beyond the scope of the system, it’s called stress testing. Like if your system supports only 100 users, and you simulate 110 users and see how the performance of the system degrades.

Integration testing and interface testing

When you combine two components that are independently developed you need to test that these two components work correctly together and perform the task assign to the integrated component in a seamless manner. To test this you do integration testing.
When there is communication between two components, protocols and message formats are defined to communicate. Interface testing confirms that the data passing from one component to another is in the correct and in the specified format and follows the protocol decided upon. Whether two components perform the correct task is none of the concern of interface testing.
Hope after reading this post your doubts, about slightly different and confusing testing techniques, may have vanished.

What is regression testing?

Regression Testing

Regression testing is the process of finding defects in features of the software which were working perfectly prior to bug fixation or inclusion of new features. So most of the test cases will be already present and we have to just re-run them. If a new feature has been added, we might have to create new test cases.
Why we need regression testing? The answer to the question lies in the design process. However perfectly we design our system or software, there may be some interdependency among various functions and modules of the software called as coupling. As a result, a small change in one function can have a catastrophic effect on the other. So to be assured that, any change done to fix a bug in one module has not affected any other module, we use regression testing.

Qualifying a component for regression testing: When any build comes for regression testing, we have to check whether or not the build worth testing. It may be possible that the build doesn’t satisfy the major requirements, so there is no point putting efforts in testing various smaller requirements. So it is advised that always test critical and difficult parts of the software at first glance and then move on to the trivial and smaller parts. This process of qualifying software for detailed testing is called as smoke testing.

These are the four types of tests one shall run on the software before qualifying it for further testing.
1) Customer based tests: Find out all scenarios in which software is going to be used and run test cases to test software functionalities in those scenarios. Think at a higher level i.e. product level and ask what are the test case critical for your customer and run them on priority. Operation profile of the software may be handy
2) Complex tests: Find out which are the test cases which will test the majority of the important features of the software.
3) Expected failure tests: From the past experiences and intuition one can find out what are the ways in which the system can fail and try to test those things first before moving to other features.
4) Big picture test: Test the performance of the software and any other quality attributes. If the software doesn’t satisfy these attributes tests then avoid testing other features.
Hence one can now understand that regression testing is not about blindly running already created test cases but there are some other subtle issues to be taken care of.