Boundary value analysis and Equivalence Class Partitioning both are test case design techniques in black box testing. In this article we are covering “What is Boundary value analysis and equivalence partitioning & its simple examples”.
Practically, due to time and budget considerations, it is not possible to perform exhausting testing for each set of test data, especially when there is a large pool test cases. We need an easy way or special techniques that can select test cases intelligent from the pool of test-case, such that all test scenarios are covered.
For that, we use two techniques - Equivalence Partitioning & Boundary Value Analysis testing techniques.
Equivalence Partitioning – It is a black box technique (code is not visible to tester) which can be applied to all levels of testing like unit, integration, system etc. In this technique, you divide set of test condition into partition that can be considered the same. To get a better idea let see an example.
Let's consider the behavior of tickets in the Flight reservation application, while booking a new flight.
Ticket values 1 to 10 are considered valid & ticket is booked. While value 11 to 99 are considered invalid for reservation and error message will appear, "Only ten tickets may be ordered at one time". 
Here is the test condition
- Any Number greater than 10 entered in the reservation column (let say 11) is considered invalid.
- Any Number less than 1 that is 0 or below, then it is considered invalid.
- Numbers 1 to 10 are considered valid
- Any 3 Digit Number say -100 is invalid.
We cannot test all the possible values because if done, number of test cases will be more than 100.To address this problem, we use equivalence partitioning hypothesis where we divide the possible values of tickets into groups or sets as shown below where the system behavior can be considered the same.
The divided sets are called Equivalence Partitions or Equivalence Classes. Then we pick only one value from each partition for testing. The hypothesis behind this technique is that if one condition/value in a partition passes all others will also pass. Likewise, if one condition in a partition fails, all other conditions in that partition will fail.
Boundary Value Analysis- in Boundary Value Analysis, you test boundaries between equivalence partitions
In our earlier example instead of checking, one value for each partition you will check the values at the partitions like 0, 1, 10, 11 and so on. As you may observe, you test values at both valid and invalid boundaries. Boundary Value Analysis is also called range checking.
Equivalence partitioning and boundary value analysis are closely related and can be used together at all levels of testing.
End to End Testing is the approach in which tester/developer always validate whether the flow of application/software from the starting point to the end point is working perfectly or not.
End to End Testing Example - Real
For Example we are testing the web page of application than the start point will be logging in to web page and the end point will be logout of the web page means logout from the application/software.
So in this example of End to End Testing, tester/developer check whether the flow of application from starting to end point is working fine or not.
So in the above example when we login to the web page than tester/developer check that after login flow is properly working or not like they check after login we get into home page or not, they also check after login we are able to do some work or not, and finally they check after doing some little bit work we are able to logout from the application or not. So this is the End to End testing of web page performed by Developer/Tester, in which they check the complete flow of application from starting to end point.
Another Example of End to End Testing
Let's take another example of this testing which is given below:
Suppose you are logging in to Gmail than End to End Testing is that after login you get into inbox or not, you are able to open and compose a mail or not, you are able to forward the mail or not, then finally you are able to logout from the Gmail or not. So this is the End to End Testing of Gmail in which tester check the flow of Gmail from starting to end point means from logging to logout point.
Conclusion
At end we conclude that End to End Testing is considered as the part of System Testing, and this testing is always conducted (carried out) to validate the flow of data between different modules. And you may also note that this testing is obviously conducted before closing the testing.
Difference between Testing and Debugging are very important terms especially for those who are new to Software Testing field.
Difference between Testing and Debugging
Testing
|
Debugging
|
1. Testing always starts with known conditions, uses predefined methods, and has predictable outcomes too.
|
1. Debugging starts from possibly un-known initial conditions and its end cannot be predicted, apart from statistically.
|
2. Testing can and should definitely be planned, designed, and scheduled.
|
2. The procedures for, and period of, debugging cannot be so constrained.
|
3. It proves a programmers failure.
|
3. It is the programmer's vindication.
|
4. It is a demonstration of error or apparent correctness.
|
4. It is always treated as a deductive process.
|
5. Testing as executed should strive to be predictable, dull, constrained, rigid, and inhuman.
|
5. Debugging demands intuitive leaps, conjectures, experimentation, and some freedom also.
|
6. Much of the testing can be done without design knowledge.
|
6. Debugging is impossible without detailed design knowledge.
|
7. It can often be done by an outsider.
|
7. It must be done by an insider.
|
8. Much of test execution and design can be automated.
|
8. Automated debugging is still a dream for programmers.
|
9. Testing purpose is to find bug.
|
9. Debugging purpose is to find cause of bug.
|
Conclusion
This is all I know about Difference between Testing and Debugging, but the big difference is that debugging is conducted by a programmer and the programmers fix the errors during debugging phase. Testers never fix the errors, but rather fined them and return to programmer.
Distinction between System Testing and Acceptance Testing
System Testing
|
Acceptance Testing
|
1. System Testing does not include any thing means it is not known by any other name.
|
1. Acceptance Testing Include Alpha Testing means it is also sometimes known as alpha testing.
|
2. User is not involved in System Testing.
|
2. User is completely involved in Acceptance Testing.
|
3. It is performed before Acceptance Testing.
|
3. It is performed after System Testing.
|
4. It is not the final stage of Validation.
|
4. It is the final stage of Validation.
|
5. System testing of software or hardware is testing conducted on a whole, integrated system to estimate the systems compliance with its specified set of requirements?
|
5. Acceptance Testing of software or hardware is testing conducted to evaluate the system compliance with its specified set of user requirements.
|
6. The only things Tester should be testing at the System Test stage are things that he and she couldn't test before.
|
6. The only things Developer and User should be testing at the Acceptance Test stage are things that developer and tester couldn't test before.
|
7. It is done to check how the system as a whole is functioning. Here the functionality and performance of the system is validated.
|
7. It is done by the developer before releasing the product to check whether it meets the requirements of user or not and it is also done by the user to check whether I have to accept the product or not.
|
8. It is used to check whether the system meets the defined Specifications or not.
|
8. It is used to check whether it meets the defined User Requirements or not.
|
9. System Testing refers to the testing of complete system as a whole that is carried out by testers and sometimes by developers to check whether it meets the system specifications or not.
|
9. Acceptance Testing is carried out by the users to determine whether they accept the delivery of the system or not. It is normally performed by users and sometimes developers are also involved in it.
|
10. System Testing determine the developer and tester for satisfaction with system specifications.
|
10. Acceptance Testing determine the customer for satisfaction with software product.
|
11. System Testing involves both Functional and Non- Functional Testing.
|
11. Acceptance Testing only involves the Functional Testing based on the requirement given by client/user.
|
Note
System Testing: The process of testing an integrated system to verify that it meets specified requirements is known as system testing.
Acceptance Testing: After the system testing is over, the software/application is tested by the client/user to check whether it meets the requirements given by him or not. This is known as acceptance testing.
Acceptance testing can be performed either at the developer's site (premises) or client site.
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 among SRS, FRS and BRS are seems to be same but in reality they all are different and important too because many of us do not know these simple basic terms, in simply we know these terms but not exactly. That is why I am writing the difference among SRS, BRS and FRS in tabular form so that those who are new to software testing field can learns it easily.
You can see the difference between SRS and BRS in tabular form below so that you can learn it easily and effectively.
Distinction among BRS,FRS and SRS - Top 7
SRS
|
FRS
|
BRS
|
1. It means "Software Requirement Specification" (SRS).
|
1. It means "Functional Requirement Specification" (FRS).
|
1. It means "Business Requirement Specification" (BRS).
|
2. It deals with resources provided by Company.
|
2. It deals with requirements given by client.
|
2. It deals with aspects of business requirements.
|
3. It always includes Use cases to describe the interaction of the system.
|
3. In this Use cases are not included.
|
3. In this Use cases are also not included.
|
4. It is developed by System Analyst. And it is also known as User Requirement Specifications.
|
4. It is always developed by developers and engineers.
|
4. It is always developed by Business Analyst.
|
5. In SRS, we describe all the business functionalities of the application.
|
5. In FRS, we describe the particular functionalities of every single page in detail from start to end.
|
5.In BRS, we defines what exactly customer wants. This is the document which is followed by team from start to end.
|
6. SRS tells means explains all the functional and non functional requirements.
|
6. FRS tells means explains the sequence of operations to be followed on every single process.
|
6. BRS tells means explains the story of whole requirements.
|
7. SRS is a complete document which describes the behavior of the system which would be developed.
|
7. FRS is a document, which describes the Functional requirements i.e. all the functionalities of the system would be easy and efficient for end user.
|
7. BRS is a simple document, which describes the business requirements on a quite broad level.
|
Conclusion
So this is all about what is the Difference between SRS and FRS and if you know more differences than discuss it here your opinions are always welcomed here.
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.
|