Learn Manual Testing From Scratch Part 3
Difference between White Box Testing and Black Box
testing
1)
White Box Testing 2)
Black Box Testing
White Box Testing
a)
1) Done by
developers
2) Done
by test engineers
b) 1) Look into the source code and test the
logic of the code
2)
Verifying the functionality of the application against requirement
specifications
c) 1) Should have knowledge of internal
design of the code
2) No
need to have knowledge of internal design of the code
d)
1) Should
have knowledge of programming
2) No need to have knowledge of programming
BLACK
BOX TESTING
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
CITIBANK
ONLINE – SRS
1. LOGIN
1.1
Username : should
accept only 8 – 22 characters
1.2
Password : should accept only 8 – 36 characters. Special characters
are
allowed.
1.3
Forgot Password : . . . . . . . . .
1.3.1
. . . . . . . . . .
1.3.2 . . . . . . . . . .
1.4
Registration : . . . . . . . . . . . . . .
1.4.1 . . . . . . . . . . .
1.4.2 . . . . . . . . . . .
2. LOANS
2.1
Personal Loan : . . . . . . . . . . .
2.1.1 . . . . . . . . . . . . . . .
2.1.2 . . . . . . . . . . . . . . .
2.2
Home Loan : . . . . . . . . . . . . .
2.2.1 . . . . . . . . . . . . . . .
2.2.2 . . . . . . . . . . . . . . .
3. INSURANCE
3.1
. . . . . . . . . . .
3.2
. . . . . . . . . . . .
.
. . . . . . . . .. . . . .. .
.
. . . .. . . . . . . . . .. . .
..
. . . . . .. . . . .. . . . ..
Now, we scroll to page 30,
and see the 60th requirement.
We see the requirements
specification for AMOUNT TRANSFER
60. AMOUNT
TRANSFER
60.1 From account number text
field
60.1.1 Should accept 10-digit integer
60.1.2 Should accept only those accounts which are created by
Manager
60.2 To account number text field
60.2.1 Should accept 10-digit integer
60.2.2 Should accept only those accounts created
by manager
60.3 Amount Textfield
60.3.1 Should accept only positive integers
60.3.2 Should
not accept more than balance
.
. . . . . . .. . .
.
. . . . . . . .. .
.
. . . . . . . . . .
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.
2) INTEGRATION
TESTING
Testing the data flow or interface between two features is known as integration testing.
Take 2 features A & B.
Send some data from A to B. Check if A is sending data and also check if B is
receiving data.
Now let us consider the
example of banking s/w as shown in the figure above ( amount transfer ).
Scenario
1 – Login
as A to amount transfer – send 100rs amount – message should be displayed
saying ‘amount transfer successful’ – now logout as A and login as B – go to
amount balance and check balance – balance is increased by 100rs – thus
integration test is successful.
Scenario
2 – also
we check if amount balance has decreased by 100rs in A
Scenario
3 – click
on transactions – in A and B, message should be displayed regarding the data
and time of amount transfer
Thus
in Integration Testing, we must remember the following points,
1)
Understand
the application thoroughly i.e, understand how each and every feature works.
Also understand how each and every feature are related or linked to each other.
2)
Identify
all possible scenarios
3)
Prioritize
all the scenarios for execution
5)
If you
find defects, communicate defect report to developers
6)
Do
positive and negative integration testing. Positive
– if there is total balance of 10,000 – send 1000rs and see if amount
transfer works fine – if it does, then test is pass. Negative – if there is total balance of 10,000 – send 15000rs and
see if amount transfer happens – if it doesn’t happen, test is pass – if it
happens, then there is a bug in the program and send it to development team for
repairing defects.
Let us consider gmail software as
shown above. We first do functional
testing for username and password and submit and cancel button. Then we do integration testing for the above. The
following scenarios can be considered,
Scenario 1 – Login as A and click on compose mail. We then do functional testing for the individual
fields. Now we click on send and
also check for save drafts. After we
send mail to B, we should check in the sent
items folder of A to see if the sent mail is there. Now we logout as A and
login as B. Go to inbox and check if
the mail has arrived.
Scenario 2 – we also do integration testing for spam folders. If the particular contact
has been marked as spam, then any mail sent by that user should go to spam folder and not to the inbox.
We also do functional testing for each and every feature like – inbox,sent items etc .
Let us consider the figure
shown above.
We first do functional testing for all the text
fields and each and every feature. Then we do integration testing for the related features. We first test for add user and list user and delete user and
then edit user and also search user.
Points
to remember,
1) There are features we might be doing only doing functional testing and there are features we might be doing both integration and functional testing. It depends on features.
2) Prioritizing is very important and we should do it at all the stages which means – open the application and decide which feature to be tested first. Go to that feature and decide which component must be tested first. Go to that component and decide what value to be entered first. Don’t apply same rule everywhere!!. Testing logic changes from feature to feature.
3)
Focus is
important i.e, completely test 1 feature and then only move onto another
feature.
4)
Between 2
features, we might be doing only positive integration testing or we might be
doing both positive and negative integration testing. It depends on the
feature.
There are two types of integration testing,
Incremental Integration Testing :
Take two modules. Check if data flow between the two is working fine. If it is, then add one more module and test again. Continue like this. Incrementally add the modules and test the data flow between the modules.
There are
two ways,
a)
Top-down Incremental Integration Testing
b) Bottom
– up Incremental Integration Testing
Top-down Incremental Integration Testing:
Incrementally add the modules
and test the data flow between the modules.
Make sure that the module that we are adding is child of previous
one.
Bottom-up
Integration Testing :
Testing starts from last child up to parent. Incrementally add the modules and test the data flow between modules. Make sure that the module you are adding is the parent of the previous one.
Non – incremental Integration Testing
We use this method when,
a) When data flow is very
complex
b) When it is difficult to
identify who is parent and who is child.
It is also called Big – Bang method.
Stub and Driver
Stub is a dummy module
which just receives data and generates a whole lot of expected data, but it
behaves like a real module. When a data is sent from real module A to stub B,
then B just accepts the data without validating and verifying the data and it
generates expected results for the given data.
The function of a driver is it checks the data from A and
sends it to stub and also checks the expected data from stub and sends it to A.
Driver is one which sets up the test
environment and takes care of communications, analyses results and sends the
report. We never use stubs and drivers in testing.
In WBT, bottom-up integration testing is preferred because writing
drivers is easy. In black-box testing, no
preference and depends on the application.
INTERVIEW TIPS and QUESTIONS
1)
In interview, they’ll ask – Which is the most preferred method of testing and
give 4options –
a)
Functional Testing b) White-box testing c) Top-down integration testing
d)
Bottom – up Integration testing
Ans) Always write Bottom-up testing – unless asked specifically for anything else
2)
In interview, they’ll ask – When does testing start ?
Ans)
always tell, testing starts as soon as the requirements are handed over – coz
the interviewers always have V&V model in mind – if any specified model is
asked, then answer according to that model.
3)
In interview, they’ll ask – I have 2modules A and B – A has been built, B is
yet to be built – but i need to test B, how can I do Integration Testing for A
and B ?
Ans)
we create a dummy module B also known as Stub, and then tell about stubs. If
they ask have you ever written a stub – then tell – stubs are very rarely used
and that you just know about the concept through the internet.
Comments
Post a Comment