About delay, loss, fuzz and unfortunate events

I covered importance of testing the impact of delayed response earlier.

It is also important to test for lost responses to see how queuing up impacts the application/device under test.

Semantically confusing fields in networking data (like http://192.168.1.255 over a 255.225.255.0 LAN) should be tested to avoid gaffes and towards more secure code. Protocol fuzz testing should ideally cover such tests.

At last, there is also a possibility of events related to other protocols happening at unfortunate events. How does your system behave when route summary is happening from OSPF to BGP AND an OSPF update arrives? Testing such scenario is extremely difficult for the want of right set of tools and skills. It also unleashes combinatorial nightmare for testing. However, with careful “code baking” policy, it is possible to find strange, bad and nasty bugs before customers find them in the field.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s