Solution to a problem

2005-07-13T03:34:00.000-07:00

1)Know that the problem exists.
2)Accept that the problem exists.
3)Find a solution to the problem.
4)Apply the solution to the problem.

Testing strategies

2005-07-06T04:59:00.000-07:00

General test case scenarios

Hi,

I am including some general test case scenarios which should be taken into account while
testing. There could be more genaeral scenarios send me if you find one. This is just for information.

1) After configuring or modifying(set) anything check that it is actually
working (configured or modified) correctly by reading it(get).

Ex. for configuring managers.

isadmin># configure system security snmp manager test2 destination 10.10.10.10/2
0 notify-profile test2 nt

check manager is actually configured.

isadmin># info configure system security snmp manager
configure system security snmp
#-------------------------------------------------------------------------------
echo "system"
#-------------------------------------------------------------------------------
manager test2 destination 10.10.10.10/20 notify-profile test2
nt
exit
#-------------------------------------------------------------------------------

2) For range checking e.g we have to check the range from 1-255 for I.P
Address

There could be 9 minimal test case scenarios for boundary value testing.

i) much less than 1 e.g -900
ii) very close but less than 1 e.g 0
iii) equal to 1 e.g 1
iv) very close but greater than 1 e.g 2
v) between 1 and 255 e.g 90
vi) very close but less than 255 e.g 254
vii) equal to 255 e.g 255
viii) very close but greater than 255 e.g 256
ix) much greater than 255 e.g 400.

Write test cases for all.

3)Taking from the same previous example boundary value from 1-255
If the test case fail for one of the boundaries eg. for 255 it fails 254
also (it should otherwise pass). Check the boundaries where the test
passes e.g it may pass at 220 but not at 221 . Report the error and the
boundary values where difference occurs

4) For strings we have the length of string eg 4 to 32. check for boundary
values of length of strings

1) 0 length (NULL string check it always).
2) 3 length.
3) 4 length.
4) between 4 and 32.
5) 32 length.
6) Length greater than 32.

5) Similar to the above test case if the test case fails for length 32 as
well as 31 check the boundary value e.g 20 where it actually passes report
the error.

6) Sometimes the program code actually gives the range values we have to
test.e.g.

for(config=1;config<1000;config++)
{
if(config == 20)
{ /*do this*/

...............
..............
}
}

Here we have to check boundary values for config 1-1000 as well
as boundary values for 20 namely 19,20,21.

Some more scenarios I have received in mail I am including that also.

*****************************************************************************************

rik.verstraete@alcatel.be wrote:

Hi FPLs:
May I clarify that your feature project should cover end-to-end testing of the feature inside the ISAM product. This is much more than sub-system test. For instance, feature test should include:
- Test all CLI/TL1 commands
- Perform traffic tests and cover all relevant traffic types
- Do performance tests
- Test all boundary conditions; test the limits of your feature
- Stability tests (running ATCs overnight/over the weekend, run traffic load overnight/over the weekend)
- Test all possible configurations, also "abnormal" ones
- Test all failure cases
- Test on all possible hw configurations (boards, modems, etc.)
- Test board restarts
- Do tests with multiple boards in the rack
Please review your feature test list in this respect and add relevant tests if necessary. For concrete questions about your feature test coverage, please refer to the relevant domain architect(s).
Regards,
Rik

PS: For sure, the list above is not complete and I welcome your feedback; I just listed some topics which were found in the past to be sometimes forgotten

bug fixers

Solution to a problem

Testing strategies