Back to Back Testing is a type of Software Testing in which two or more variants of a component are always tested with similar inputs and their corresponding outputs are compared and examine in case of any discrepancies that may exists in future. Back to Back Testing is a testing process in which events that are associated with it are defined and examined properly.
This testing always involves cross-comparison of entire responses that are always obtained from functionally equivalent software components. In this testing whenever a difference is determined/observed it is measured and if essential a correction is applied too.
Definition
Somerville 1998 defined Back to Back Testing in his own way because he said this testing is always used when several/various versions of a system/application exist for testing. According to him in this testing all versions are tested with similar set of tests and then the results are always compared for some system/application problems if any issue exists.
Example of
Best example for doing this testing is to always test two versions of a component with similar inputs and then comparing the outputs. And further outputs are examined if there are any sort of discrepancies occurs. For example software that exists in ATM centers their outputs should be same with same inputs without bothering how the data is examined at the back end.
Steps for doing Back to Back Testing
Below is given some steps that may carry out during Back to Back Testing.
1. First step is that in which specific purpose set of test cases is always prepared.
2. Now using these test cases we can run the different system/application versions and store the results in different files.
3. Final step of this testing is to perform the automatic comparison of the results stored in different files and then generate the Difference Report.
Some people do not know about Difference Report means what it is all about, so below is given the definition of Difference Report which clears its definition.
Difference Report is that which always indicates the system/application problem that may exists among the different system versions.
Note
Please keep one thing in mind that this very famous testing technique can be very cost effective for new application/system especially for those application which has undergone some major modifications.
Conclusion
This is all I know about Back to Back Testing and if you know some more better points in this testing than you can definitely discuss your thoughts in below comments section so that others can make benefit from your points. And your feedback are always welcomed regarding this post.
Difference between Static and Dynamic Testing
Static Testing
|
Dynamic Testing
| |
1
|
In this type of testing we do not execute the code
|
In this type of Testing we always execute the code.
|
2
|
It means examining and reviewing the software.
|
It means testing, running, and using the software.
|
3
|
In this form of Testing methods like code review, inspection, walkthrough, reviews are used.
|
In this Testing methods like testing and validations are used.
|
4
|
It is done in the phase of verification.
|
It is done in the phase of validation.
|
5
|
This testing means "How we prevent" means it always talks about prevention.
|
This testing means "How we cure" means it always talks about cure.
|
6
|
It is not a time consuming job because its purpose is to examine the software or code.
|
It is always a time consuming job because its purpose is to execute the software or code and it may also involve running more test cases.
|
7
|
As it can always start early in the life cycle it definitely reduces the cost of product or you can say project.
|
As it not starting early in the life cycle hence it definitely increases the cost of product/project.
|
8
|
It is always considered as less cost effective job/task.
|
It is always considered as more cost effective job/task.
|
9
|
It can find errors that dynamic testing cannot find and it is a low level exercise.
|
It can find errors that static testing cannot find and it is a high level exercise.
|
10
|
It is not considered as a time consuming job or task.
|
It is always considered as a time consuming job or task because it requires several test cases to execute.
|
11
|
Techniques/methods of static testing are inspections, reviews, and walkthroughs etc.
|
Technique/method of dynamic testing is always software testing means testing.
|
12
|
Static testing is also known by the name Dry Run Testing.
|
Dynamic Testing is not known by any other name.
|
13
|
It definitely comes before dynamic testing.
|
It definitely follows after static testing.
|
Software Testing is essential for the betterment of the application and software. But apart from this many of us do not know that Software Testing is most time consuming and difficult task to perform.
People still believe that Software Testing is an easy task anybody can do it easily but in reality Software Testing is opposite of it because it is not an easy task to perform. Software Testing is as difficult as developing software because now days it requires more human efforts, as everyone wants quality so doing Software Testing are become difficult because it takes lot of time and money.
Software Testing - Hard and Difficult
Performing Software Testing is considered as Difficult as well as hard too because of the following reasons which are shown below.
1. Software Testing is hard and difficult because we need to test the software/application for both valid and invalid inputs and in Software Testing we also check the performance parameters as well as functionality too.
2. Another reason for considering Software Testing hard as well as difficult because during the time of testing we always need to give the inputs in such a way that each and every line of the program/code is tested efficiently.
3. Another reason for being hard and difficult is that tester needs to give inputs randomly and ensure that the software/application never fails.
4. Another reason is that we need to test the software by keeping the user perspective in mind means by keeping in mind how end user is using it and check whether the error messages displayed properly or not.
5. Another main and clear reason is that we need to test the application/software by simulating the actual/real environment. Considering example if a database application has to be accessed by 200 users simultaneously, then it is not enough if you test the software/application for 5 0r 10 users and declare that application/software is working fine by leaving the software without checking all 200 users simultaneously.
6. Software Testing is considered as hard and difficult because in several cases, it is not almost possible to test the software/application in real/actual environment. Considering example how do you test the software that is used in a satellite launch vehicle or a missile? You can do the complete testing only in a simulated environment.
Your opinion
This is all I know about why Software Testing is considered as hard and difficult task to perform and if you know some more reasons than you can discuss with me in comments to help others so that proper guidance will be given to every people those who are in the field of Software Testing.
Software testing plays a major role in software development, but it is expensive too. In short-term we can say that software testing is time consuming but important too.
2. In case of critical and important software likes flight control, control on nuclear, space satellite control may always involves prototyping. Such testing based on prototyping or simulation is very expensive.
Software development organization spends between 30-40% of total project/product effort on software testing. Software testing thus often consumes several resources, than any other phase in the software project.
Here are some factors that make software testing so expensive:
1. Software testing is carried out throughout the software development mechanism; naturally its cost is for all duration of the software project till validation tests.
The idea behind this is that if bugs are detected earlier, it saves lot of trouble later. In this way software testing is exists from the beginning and increases expenses.
The idea behind this is that if bugs are detected earlier, it saves lot of trouble later. In this way software testing is exists from the beginning and increases expenses.
2. In case of critical and important software likes flight control, control on nuclear, space satellite control may always involves prototyping. Such testing based on prototyping or simulation is very expensive.
Software testing varies from several organizations to organization. Several factors in these organizations affect testing.
The several factors are listed below:
The several factors are listed below:
1. Communication and relationships of people
2. Testing scope
3. Misunderstanding regarding life cycle of testing
4. When test plans are poorly developed
5. Big testing constraints
Conclusion:
At end we conclude that Software testing often consumes more resource, than any other phase of software development. Software Testing is a most important element about the Software Quality Assurance and represents final review, specification, design and coding.
Stubs are dummy modules that are always distinguish as "called programs", or you can say that is handle in integration testing (top down approach), it used when sub programs are under construction.
Stubs are considered as the dummy modules that always simulate the low level modules.
Drivers are also considered as the form of dummy modules which are always distinguished as "calling programs", that is handled in bottom up integration testing, it is only used when main programs are under construction.
Driversare considered as the dummy modules that always simulate the high level modules.
Example of Stubsand Drivers is given below:-
For Example we have 3 modules login, home, and user module. Login module is ready and need to test it, but we call functions from home and user (which is not ready). To test at a selective module we write a short dummy piece of a code which simulates home and user, which will return values for Login, this piece of dummy code is always called Stubs and it is used in a top down integration.
Considering the same Example above: If we have Home and User modules get ready and Login module is not ready, and we need to test Home and User modules Which return values from Login module, So to extract the values from Login module We write a Short Piece of Dummy code for login which returns value for home and user, So these pieces of code is always called Drivers and it is used in Bottom Up Integration
Conclusion:-
So it is fine from the above example that Stubs act "called" functions in top down integration. Drivers are "calling" Functions in bottom up integration.
People are aware regarding Usability Testing, but they do not know about Navigation Testing. So here I am writing the Difference between Navigation Testing and Usability Testing both so that those who have confusion in their mind regarding the Navigation and Usability Testing can simply increase their knowledge by seen the difference on both these confusing terms.
Navigation Testing
|
Usability Testing
|
1. Navigation Testing is done to ensure that external and internal links are working properly.
|
1. Usability Testing is always done to ensure/verify that the GUI is well designed and easily used.
|
2. Navigation Testing is more users friendly and it provides ability to navigate from current page and it provides ability to navigate from current page to other pages directly.
|
2. Usability Testing is always done to verify how much the application is user friendly to an end user.
|
3. In Navigation Testing, tester use the visual hierarchies like color, position etc.
|
3. In Usability Testing tester always test whether the control flow of the application is convenient for end user or not.
|
4. Navigation allows user to control the interaction sequence of pages in the application.
|
4. In Usability Testing tester always test whether the interaction of functionality with the user is effective in nature or not.
|
Distinction between Smoke and Regression Testing - Simple
Smoke testing
|
Regression testing
|
1. Smoke testing is a surface level testing to verify/ensure that build provided/given by development team to QA team is ready to accept for further testing.
|
1. Regression testing is not considered as a surface level testing and it is performed/ executed by testers only.
|
2. Smoke testing is known as a quick-and-dirty test means that the major/crucial functions of a piece of software work/perform without bothering with finer details.
|
2. Regression testing is not known by the quick-and-dirty test and in this testing testers test the application with more details.
|
3. It is executed/ performed when testers have to accept a build for further testing.
|
3. It is executed/performed when tester's have enough time for testing.
|
4. Smoke testing may be conducted manually or by using automation tools.
|
4. Regression testing is also conducted manually or using automated tools.
|
5. Performing smoke testing will not enlarge the product cost and budget because it didn't requires more manpower and time.
|
5. Performing Regression testing definitely will enlarge the product cost and budget because it requires more manpower and time.
|
6. It is also called as BAT (Build Acceptance Test) or BVT (Build Verification Testing).
|
6. It is not known by any other name.
|
7. It is done by developers before the build is released or by testers before accepting a build for further testing.
|
7. It is usually done by testers only.
|
8. We use script for smoke testing.
|
8. We use script for regression testing.
|
Difference between Adhoc and Exploratory Testing
Adhoc Testing
|
Exploratory Testing
|
1. Adhoc Testing means learn the application than test it.
|
1. Exploratory Testing means test the application while learning.
|
2. In Exploratory Testing QA is always asked to test an application without any specific set of documents.
|
2. In Adhoc Testing QA is always asked to test an application with detailed set of documents.
|
3. In this Testing we always gather information regarding the software/application from complete possible sources and document and then test the application/software.
|
3. In this Testing we gather the information, and also document and test the application simultaneously.
|
4. In Adhoc Testing tester should have good knowledge about the application in order to test the software.
|
4. In Exploratory Testing tester should increases their knowledge by exploring the application/software.
|
5. In this testing testers have significant testing of the software before test it.
|
5. In this testing testers may be learning the software before testing it.
|
6. It is not considered as a type of any.
|
6. It is considered as a type of Adhoc Testing
|
7. It is not an approach to testing.
|
7. It is an approach, not a technique.
|
Software testing is the mechanism of knowing that what's the expected result and what the actual result a software project or product has given.
1. Short-term or immediate goals of software testing: - These goals are the immediate results after performing testing. These goals even may be set in the individual phases of SDLC. Some of them are completely discussed below:
Conclusion
You simply say that software testing is nothing but validation and verification. Main goal of software testing is to ensure that software should always be defect free and easily maintained.
IMPORTANT GOALS OF SOFTWARE TESTING
1. Always Identifying the bugs as early as possible.
2. Preventing the bugs in a project and product.
3. Check whether the customer requirements criterion is met or not.
4. And finally main goal of testing to measure the quality of the product and project.
1. Short-term or immediate goals of software testing: - These goals are the immediate results after performing testing. These goals even may be set in the individual phases of SDLC. Some of them are completely discussed below:
a) Bug discovery: The immediate goal about software testing is to find errors at any stage of software development. More the bugs discovered at early stage, better will be the success rate about software testing.
b) Bug prevention: It is the consequent action of bug discovery. From the behavior and analysis of bugs discovered, everyone in the software development team gets to learn how to code so that bugs discovered should not be repeated in later stages or future projects.
Though errors always cannot be prevented to zero, they can be minimized. In this sense prevention of a bug is a superior goal of testing.
2. Long-term goals of software testing: - These goals affect the product quality in the deep run, when one cycle of the SDLC is over. Some of them are completely discussed below:
a) Quality: Since software is also a product, so its quality is primary from the user's point of view. Thorough testing ensures superior quality.
Quality depends on various factors, such as correctness, integrity, efficiency, and reliability. So to achieve quality you have to achieve all the above mentioned factors of Quality.
b) Customer satisfaction: From the user's perspective, the prime goal of software testing is customer satisfaction only. If we want the client and customer to be satisfied with the software product, then testing should be complete and thorough.
A complete testing process achieves reliability, reliability enhances the quality, and quality in turn, increases the customer satisfaction.
3. Post-implementation goals of software testing: - These goals are become essential after the product is released. Some of them are completely discussed below:
a) Reduced maintenance cost: The maintenance cost about any software product is not its physical cost, as effective software does not wear out. The only maintenance cost in a software product is its failure due to errors.
Post- release errors are always costlier to fix, as they are difficult to detect. Thus, if testing has been done rigorously and effectively, then the chances about failure are minimized and as a result of this maintenance cost is reduced.
b) Improved software testing process: A testing process for one project may not be blooming successful and there may be area for improvement. Therefore, the bug history and post-implementation results can be analyzed to find out snags in the present testing process, which can be determine in future projects.
Thus, the long-term post-implementation goal is to improve the testing process for future projects.
Conclusion
At end in one line we conclude that main goal of software testing is to show that application is working as per as the requirements defined by client.
