It is verifying the functionality ( behavior
) against requirement specifications.
Types of Black Box Testing
1)
FUNCTIONAL TESTING
Also called component testing.
Testing each and every component thoroughly (rigorously) against requirement
specifications is known as functional testing.
For
ex, let us consider
that Citibank wants a s/w for banking purpose and it asks the company Iflex to
develop this s/w. The s/w is something as shown below. When the user clicks his
valid user name and enters his password, then he is taken into the homepage.
Once inside the homepage, he clicks on amount transfer and the below page is
displayed. He enters his valid account number and then the account number to
which the money is to be transferred. He then enters the necessary amount and
clicks on transfer. The amount must be transferred to the other account number.
Now in black box testing, the test
engineer tests the s/w against requirements and checks if the s/w is working
correctly as per requirements.
This
is how the requirements given by the client looks like (figure below). It is usually a word
document file. Let us consider that Citibank gives a 80pg SRS in MS-WORD
format. The test engineer then looks at the requirements and correspondingly
checks the s/w.
Now the test engineer does all
possible tests on the 2 account numbers. Now, he proceeds with the testing of
Amount transfer. These are the following tests he conducts for testing the
amount field,
He enters the following data in the
amount field,
a) – 100 X b) 100$ X c)100.50 X
d) Hundred rupees only X e) 100 blank space 0 X
f) 100 g)0.001 X
For all the above cases except for f) , it should throw an error message.
If it doesn’t throw, then there is a bug in the s/w and the s/w must be sent to
the development team to repair the defect.
Thus,
during testing, we must remember the following points,
a) We must always start testing the
application with the valid data. In the above example for amount transfer, we
see that we have entered the valid data 100 only in the 6th test.
This should not be done, because if the valid data itself is not taken
correctly, then we need not have to waste our time checking for the invalid
data
b) If the application works for
valid data, only then we must start testing for invalid data
c) If the application is not working
for 1 of the invalid values, then we can continue testing for all the other
invalid values and then submit the test report of all the defects for invalid
values.
d) In testing, we should not assume
or propose requirement. If we have any queries, talk to the one who knows the
requirements very well and clarify the queries.
e) We must not do over-testing ( testing for all possible
junk values ) or under-testing (
testing for only 1 or 2 values ). We must only try and do optimize testing (testing for only the necessary values- both
invalid and valid data).
f) We must do both positive testing (testing for valid
data) and negative testing (testing
for invalid data).
The
characterstics of a good requirement are,
1)
Unitary ( cohesive ) – the
requirement addresses 1 and only 1 thing
2)
Complete – the
requirement is fully stated in 1 place with no missing information
3)
Consistent – the
requirement does not contradict any other requirement and is fully consistent
with all authoritative external documentation
4)
Non-Conjugated ( Atomic ) – the
requirement is atomic i.e, it does not contain certain conjunctions. Ex – “the
postal code field must validate American and Canadian postal codes” should be
written as two separate requirements : 1) “The postal code field must validate
American Postal codes” and 2) “The postal code field must validate Canadian
Postal codes”.
5)
Traceable – the
requirement meets all or part of a business need as stated by stakeholders and
authoritatively documented
6)
Current – the
requirement has not been made obsolete by the passage of time
7)
Unambiguous – the
requirement is concisely stated without recourse to technical jargon, acronyms
etc. it expresses objective facts, not subjective opinions. It is subjective to
one and only one interpretation.
8)
Mandatory – the
requirement represents a stakeholder defined characterstic the absence of which
will result in a deficiency that cannot be ameliorated
9)
Verifiable – the
implementation of the requirement can be determined through one of 4 possible
methods – inspection, demonstration, test or analysis.
0 comments:
Post a Comment