Home > Articles > Cisco Network Technology > General Networking > Crafting the Test Approach

Crafting the Test Approach

Chapter Description

This chapter will begin to fill in the practical details of what is necessary to build an effective approach toward different types of test requests. It begins with a suggested approach for assessing and scoping a test project, and offers guidance and best practices.

Test Planning

Now that you and your client clearly understand and agree on the test scope, objectives, and criteria for success, it is finally time to roll up your sleeves and start working on the test plan. As always, it is important to collaborate with the stakeholders on the test plan to determine specifics regarding the application characteristics, behaviors, and new features that are expected of the new system. The prototype network system, equipment specifications, test cases, test tools, data to be collected, and results format must also be discussed and agreed upon. This is an important step in the process because it requires many decisions and significant teamwork.

Design the Functional Prototype Network System

For most types of tests, a working prototype network system of the intended design will serve as the platform upon which functionality, operation, and performance of the new system will be evaluated. A prototype network system is commonly illustrated in a set of network topology diagrams that represent a miniaturized version of the end-state network.

Designing the working prototype for the lab requires experience, creativity, ingenuity, and a deep understanding of the network design, solutions, and technologies to be evaluated. An awareness of the test triggers and motivations of the clients requesting the test is also necessary so that the right aspects of the design are represented and modeled. The first challenge you will face when designing the prototype is how much of the network system will need to be implemented to convince your client that the design meets business and technical requirements. The working prototype must be functional and able to demonstrate performance under stress and scale conditions, but it rarely needs to be a full-scale implementation of the new system. The design and scale of a prototype will vary, depending on the type of test you are conducting and what features or components of the design must be showcased for your clients. How little or much of the network is represented in the prototype will be bounded by the people, money, equipment, and time you have to complete the test.

Use the information you collected during the Scoping Phase to help you determine the size and design of the network prototype, particularly the input and requirements from the key stakeholders. Whereas the design architect may be primarily focused on technical issues, such as validating a routing design or gaining performance benchmarks, network operations may be concerned only with the manageability and usability benefits of the new design. Pay attention to corporate politics and organizational structure with the client. For example, the primary stakeholder funding the project may be someone from the business side of an organization, possibly having rejected designs that the stakeholder considered overbuilt and expensive. The stakeholder's motivation might be to evaluate a "bronze standard" version of the design, composed of less costly components.

Constructing a High-Level Lab Topology Diagram

Early in the Plan Phase, you need to process all the input gathered from the Scoping Phase and develop a high-level topology diagram to start the test plan dialog with your clients. The high-level topology diagram is your initial draft of what the final lab network topology will look like, and it should be one of the first documents you share with your customer when discussing your approach. This diagram should include the major devices, including routers, switches, firewalls, servers, workstations, telephony, video, WAN simulators, test equipment, and so forth, that will be necessary to conduct the tests. Connections between the various devices should be shown, using "clouds" where appropriate to represent elements that will provide connectivity to the system, but not necessarily be under evaluation, such as a provider Multiprotocol Label Switching (MPLS) backbone or the Internet.

Figure 4-1 illustrates an example of a high-level lab topology diagram.

Figure 4-1

Figure 4-1 Example High-Level Lab Topology Diagram

Note the relative lack of detail as compared to a typical network topology diagram. There are no IP addresses, equipment hardware configuration details, circuit speed indicators, or port numbering information. This is completely acceptable for a high-level test diagram considering that its purpose at this point is simply to gain consensus on the topology that you are proposing, and to serve as a reference to the test cases you will be developing. You will add details to this diagram to facilitate the lab build, and you most likely will be adding test-specific diagrams that illustrate particular test cases when it comes time to finalize the test plan.

Identifying the Test Suites and Test Cases

A test case in the context of internetworking is a set of conditions or variables under which a tester will determine whether or not a design element (network service, component, or feature) is working correctly. Test cases are the essence of the test plan, and they are sometimes collected or aggregated into test suites. Identifying the right test cases and expected output is an art form in itself, often requiring a series of conversations with the project stakeholders, architects, and operators of the network.

A simple description of the test cases you expect to run, and accompany the network topology diagram you have prepared, is sufficient to begin the test plan dialog. Your client may already have some ideas of the kinds of tests they want to see, so you should request their input right away. However, some clients have no idea on how testing is conducted; in these situations, you need to rely on your own testing experience and an understanding of the design goals, test triggers, and motivations for the testing.

A sample list of test suites and cases would look something like Table 4-1.

Table 4-1. Example Test Suites and High-Level Test Cases

Test Suite #

Test Suite

Test Case


Open Shortest Path First (OSPF) Routing

ABR Summarization

Default Route Announce


Redistribution BGP to OSPF

Timer Optimizations


Border Gateway Protocol (BGP) Routing

Data Center iBGP Optimizations

CE-PE eBGP Optimizations

BGP Aggregation

BGP Policy (Communities and Local-Pref)


Quality of Service (QoS)



Traffic Shaping


Remarking at CE-PE to MPLS

QoS Transparency Across MPLS



Cisco Wide Area Application Services (WAAS)

WCCP Redirects

CIFS/FTP Acceleration



Campus Switching

Branch Switching




PIM Sparse Mode

AnyCast RP with MSDP



Cisco Performance Routing (PfR)

Fast Reroute

Load Balancing

Interop with WAAS


Cisco Group Encrypted Transport VPN (GET VPN)

Group Member at Branch and WAN Distribution

Cooperative Key Servers


Network Management









Branch Router Performance (RFC 2544)

WAN Route Saturation

WAAS Scale


Negative Testing

Circuit Path Failover

Line Card Failover

Route Processor Failover

Power Failures

MPLS Cloud Hard Failures

MPLS Cloud Soft Failures

BGP Flapping

4. Choosing the Right Test Tools | Next Section Previous Section

There are currently no related articles. Please check back later.