White Box Testing:
UNIT TESTING
Architecture &
Design <---> Integration Testing | |
Coding <---> Unit Testing
From the service providers point of view the following are to be done. 1.Unit Testing
2.Integration Testing 3.System Testing
UNIT TESTING
In Unit Testing, Different modules are tested, against the specifications produced during design for the modules.
Unit testing is essentially for verification of the code produced during the coding phase and hence the goal is to test the internal logic of the modules.
Module interface is tested to ensure that information properly flows into and out of the program unit under test.
Unit testing is the lowest level of testing
Individual unit of the software are tested in isolation from other parts of a program.
In UNIT TESTING, we have to do the following checks 1.Field level checks.
2.Field level validation 3.User Interface check 4.Functionality check.
Field Level Checks:
In Field Level checks, we have to do 7 types of checks.
Here we are checking a particular field in a screen or module, to check whether the field accepts 1.Null characters 2.Unique characters 3.Length 4.Number 5.Date
7.Default values.
For Example, consider a Course Registration form that contains the following fields.
COURSE REGISTRATION FORM SCREEN
Option (Add/Modify/Delete) Funlty chk.
Type of Course Funlty chk.
Registration Number Student Name
Address Phone Number Date
Time (Part/Full time) Funlty chk.
Timing (7-9am/9-11am/7pm-9pm) Funlty chk.
Student ID Funlty chk.
Batch Code Funlty chk.
Push Button Funlty chk.
Push button Funlty chk.
** Funlty chk. – Functionality Check.
Based on the above screen, we have to prepare a internal test plan. Based on the internal test plan, we can prepare test cases.
Internal Test Plan
FC --> Functionality Check and we have to test the functionality of the screen. Drop down combo box.
Drop down combo box. Number Field
Text Field Text Field Number Field Date Field
Drop down combo box. Drop down combo box. Automatic generation. Automatic generation Save Button
Y --> Have to write Test cases. N --> Not necessary to write test case
Field
Name Remarks(type of check)
Null Unique Length Number Date -ve Default Option FC Type of course FC Student name Y N Y Y N N N Address Y N Y N N N N Phone number N N Y Y N Y N Date Y N Y Y Y Y N Time FC Timing FC Student ID FC Batch code FC Save button FC Exit button FC
We have to write test cases only for the 'Y' option, Not necessary to write test cases for the 'N' Option,
The above internal test plan is mainly to reduce the number of test cases. For Ex. Student name is text field type.
For that, we have unit test cases as indicated below
Unit Test case for Student name field
Sl no. Test case Expected result Actual result
UTC/001 Enter blank space and proceed (Null check)
Should display error message and set focus back to student name field. ( because it should not accept blank)
UTC/002 Skip the field and proceed (Null check)
Should display error message and set focus back to student name field.( because it
null or blank space) UTC/003 Enter name of 20 characters.
(length check)
Should accept and proceed.( we assume 20 as the maximum limit of the student name field)
UTC/004 Enter name of 21 characters (length check)
Should display error message. (Because the maximum limit is 20 characters)
UTC/005 Enter numbers '12345' in the
name field.( number check) Should display error message and set focus back to the field. ( because text field should not accept numbers)
For 'Student name' field we have to write test case. The above test case is written based on the internal test plan. Test cases is written only for 'Y'. i.e. For applicable one.
Not necessary to write Test case for 'N'. --This is to reduce the number of test cases. Field Level Validation:
Here we have to check 1. Date range check 2. Boundary value check.
In date range check, we have to check whether the application is accepting greater than the system date or not.
Date Range check - If we are having a Date field in a screen we have to write test case to check the date field as
Date field.
Sl no. Test description Test case Expected result UTC/001 Enter blank space or skip the
field ( null check)
Should display error message and set focus back to the date field. ( because. Date field should not accept blank space)
UTC/002 Enter date in DD/MM/YYYY
format. (date check) Should accept and proceed UTC/003 Enter date in mm/dd/yyyy
format (date check) Should display error message. And set focus back to the field( because. It is of DD/MM/YYYY
format. UTC/004 Enter number '1234567'
(number check)
Should display error message. Because it should not accept just numbers.
UTC/005 Enter '-23232324' and proceed
( -ve check) Should display error message. Because it should not accept -ve numbers.
UTC/006 Enter date greater than the system date.
Should display error message.( because it should not accept more than system date)
In boundary value check we have to check a particular field with stand in the boundaries For e.g. If a number field has a range of 0 to 99 we have to check whether the field is accepting -1, 0, 1 i.e. < , =, > to the lower boundary and 98, 99, 100 -- have to check with < , = , > values of upper boundary.
User interface Check
In User Interface check, we have to check 1.Short cut keys
2.Help check
3.Tab movement check 4.Arrow key check 5.Message box check. 6.Readability of controls 7.Tool tip validations
8.Consistency with the user interface across the product. For User Interface Check we have to write test case as
Sl no. Test case Expected result Actual result UTC/001 Tab related checks To move across all the field
in the screen with a sequence. UTC/002 Press the arrow keys Should move across the fields
in a sequence. UTC/003 Press the short cut
keys (Alt + K)
Should open the
corresponding screen
UTC/004 Tool tip check To display the tool tip based on the selection.
UTC/005 Screen title check Should visible to the user. UTC/006 Dialog box content Should be clear to the user.
UTC/007 Scroll bar checks Should scroll softy.
In User Interface Check we have to check, how the application is User Friendly. Functionality checks
Here we have to check 1.Screen functionality
2.Functionality of buttons, computation, automatic generated results 3.Field dependencies.
4.Functionality of buttons.
In functionality check, we have to check, whether we are able to
ADD or MODIFY or DELETE or VIEW and SAVE and EXIT and other main functions in a screen.
Here we are checking whether
Combo box drop down menu is coming or not
While clicking 'save' button after entering details, checking whether it is saving or not.
While clicking 'Exit' Button should close the current window...
Automatic result generation like, for e.g. When entering date of birth, system should automatically generate age, based on the system date.
So we have to do this type of functional checks. Let us see a sample test case for functionality checks.
Sl no. Test case Expected result Actual result UTC/001 Select 'ADD' option of the
combo box.
Should open a new Registration form, to enter the new student details
UTC/002 Select 'Delete' option of the
combo box Should delete the current student details.
UTC/003 Select 'View' option of the combo box.
Should display the selected student details.
UTC/004 Select 'Modify' option of the combo box.
Should allow the user
to do the
modification.
UTC/005 Click 'Save' and proceed Should save the entered details and update in the date UTC/006 Click 'Exit' and proceed Should close the