This chapter is from the book
This chapter is from the book
This chapter is from the book
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 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 |
|
1 |
Open Shortest Path First (OSPF) Routing |
ABR Summarization Default Route Announce OSPF NSSA Redistribution BGP to OSPF Timer Optimizations |
|
2 |
Border Gateway Protocol (BGP) Routing |
Data Center iBGP Optimizations CE-PE eBGP Optimizations BGP Aggregation BGP Policy (Communities and Local-Pref) |
|
3 |
Quality of Service (QoS) |
Marking Queuing Traffic Shaping Policing Remarking at CE-PE to MPLS QoS Transparency Across MPLS CoPP |
|
4 |
Cisco Wide Area Application Services (WAAS) |
WCCP Redirects CIFS/FTP Acceleration |
|
5 |
LAN |
Campus Switching Branch Switching HSRP |
|
6 |
Multicast |
PIM Sparse Mode AnyCast RP with MSDP MVPN–MPLS |
|
7 |
Cisco Performance Routing (PfR) |
Fast Reroute Load Balancing Interop with WAAS |
|
8 |
Cisco Group Encrypted Transport VPN (GET VPN) |
Group Member at Branch and WAN Distribution Cooperative Key Servers |
|
9 |
Network Management |
SNMP SSH AAA NTP Logging NetFlow |
|
10 |
Performance/Scalability |
Branch Router Performance (RFC 2544) WAN Route Saturation WAAS Scale |
|
11 |
Negative Testing |
Circuit Path Failover Line Card Failover Route Processor Failover Power Failures MPLS Cloud Hard Failures MPLS Cloud Soft Failures BGP Flapping |